Business technology vendors and contractors assign project managers, but some standard project management methods can hurt client relationships. I have seen it first hand how traditional project management methods are counterproductive in technology sales. Project managers are taught to narrow the focus to a particular set of steps, while a technology client is always looking to leverage technology adoption and expand their scope.
It’s not the project manager’s fault. The common vendor practice of braking up a technology implementation into separate specialties of system design, budget estimating, and project management does not provide for a feedback loop from the client to modify projects as the client comes to understand the potential applications for the technology they are buying.
Most project managers are responsible for a particular project and not for maintaining an ongoing consultative relationship with the client. Clients must continually evaluate, modify, and expand their use of technology. Their current vendor is the logical resource for clients to turn to in planning future technology adoption. Those new technology applications are likely an outgrowth of the current technology plan, yet project managers forestall such ad-ons and expansions so they can close out the current project as originally planned, even if the client’s requirements have changed or become better informed than when the project was initially conceived.
Traditionally project managers are tasked with completing a project within the current budget estimate. The sales consultant will typically discuss the client’s needs. Those needs define a rough specification for the equipment or software to be used. Then an estimate is rendered by an estimation specialist who makes certain assumptions about manpower requirements and how systems will be integrated. Integration can include a wide range of tasks, from delivering and installing equipment, to programming and testing connections to the corporate servers. This visualization by the estimator is rarely shared to the project manager, but instead the system designer reduces the requirements to a specific equipment list. The project manager then focuses on the equipment list to get the project “signed off”.
Salespeople know that one of the best times to sell to their client is immediately after the client has just purchased something. In technology sales, that after-sale window of opportunity occurs before the initial sale is fully installed and operational. When project managers fear expanding the project scope, the client is left to seek those follow-on features from another vendor. The potentially lucrative long-term technology advisory relationship with the client does not materialize, no matter how efficiently the initial sale is closed out.
The principles of the Project Management Institute, which awards the PMP (Project Management Professional) certification, include many important principles for construction projects. Chief among them is communications with stakeholders and definition of scope. Without a clear, agreed definition of project scope the client’s expectations will be ambiguous and therefore you cannot definitively satisfy those expectations. Those PMI principles are taught to audiovisual professionals in the CTS curriculum (Certified Technology Specialist, certified by the AV industry trade association Infocomm).
How do you define scope without limiting the overall project? Creatively! At each step in the design process, as you are defining needs which leads to equipment selections and tasks lists, document it! Then, any changes or add-ons become new projects. As technology advances there should always be something new to provide the client, so don’t get trapped into defending an older system design or steering the client dialog back to the project at hand if the client wants to talk about adding more stuff.
On a recent project I was doing AV systems designs for a new headquarters building being built for a marketing firm. The project included a score of conference rooms, seminar rooms, and training classrooms, most with videoconferencing and IPTV, and a vague requirement for recording and streaming. I was provided a base design the client company had implemented in another office, but the client’s stated desires called for variations on the original designs, partly because some product models had changed in the year since the other office was designed. Whereas my inclination was to value-engineer for what the client desired, utilizing models that were newer and that were more specifically applicable for the new system requirements, the project managers insisted I defend the old plans requiring larger, more expensive matrix routing switchers that had features we would not be using.
Perhaps there was some logic in that the same menus and support procedures could be used at both locations, but in fact each location would be doing their own support and the control systems could be designed to be similar. Perhaps there was some politics involved if the original designers needed to save face having told the client their old designs would be applicable, but it was clear to the client the applications in the new office were different, and it was clear to me that rather than economize by reusing the old designs the client would actually be spending more. The project managers, adhering to the mindset that projects should not change once underway, were at odds with the client, undermining their relationship.
At one point the client asked for a blue-sky future forecast of where all their new AV, multimedia, and unified communications could lead. Between the IPTV, streaming, recording, and videoconferencing an elaborate future scenario would be an enterprise video system with asset management, cloud services, training-on-demand, digital signage, user authentication and such. A mere mention of this potential could have cemented a long term relationship with the client as their applications evolved in this direction. Instead the project managers dismissed the client’s desire to free associate about future technology, and made a presentation that refocused the dialog on the year-old designs, accepting a minimum of the requested modifications.
Did this approach help them move further towards closing out the project? Perhaps it did, by directing the project towards old, expensive systems, and postponing the desired modifications to be codified in a new project scope. Did it lock in the client to a long term relationship to realize those enterprise video aspirations? Definitely not! That client will be open to discuss those future applications with any other vendor, contractor, or consultant.
Had the project managers cataloged the requested changes and further created a plan to advise the client on new technology, they would have written two new deals, with many more to come. Sometimes trying to keep things simple, boiler-plate, and finite to close out a project will also close off future business opportunities. If the project manager is in charge of the client dialog, then besides the responsibility to render project status reports to the client, don’t miss the opportunity to listen to the client and make it a two way dialog. Keep the scope of each task finite, but the relationship with the client could be infinite.