Don’t Let Your Clients Blindly Trust You
Earlier this year, as we were winding down after a project review, a client made the off-hand statement: “I don’t understand what we’re doing, but I trust you.” While the trust was appreciated, this statement left me troubled as it indicated a communications problem; I was not being effective in communicating the systems engineering process being applied to address the client’s problem.
This lack of understanding, the client team blindly “cranking the handle” in their execution, is dangerous for a multitude of reasons. Incomplete/incorrect work products are generated, resulting in rework. Team members become disconnected and lose sight of the end target. Needs go unmet as they cannot be clearly communicated. Milestones are missed and costs are overrun. In the worst case, the project fails.
One of the keys to successful project execution is the client team understanding the project at the macro and micro levels.
At the macro level, the team executing the project is a system consisting of hardware, software, people, and processes. Team members need to understand the “system”; what it is and the objectives in its execution, its components and interfaces, what it consumes and produces, and the end target.
At the micro level, each team member needs to know their role and responsibilities, how and why they fit into and communicate within the macro system, and how (and why) the larger system consumes what they generate to reach the end-target. Essentially each individual needs to know they are important — and why.
So how did I move the team from “blind trust” to “understanding”?
I changed my communications style.
I switched from telling and explaining to asking questions. The answer (or non-answer) to a question would lead to the next question, and then to the next, and so on, each time drilling down onto the target topic and/or leading down a selected path of discovery. In parallel, the questioning always had a larger objective; the client discovering additional understanding of the project. This Q&A approach got the client much more engaged; it also surfaced problems that had originally been unseen. What really got the client excited is when they identified and revealed a problem of their own accord. Them making the discovery would springboard then right into solution development, also of their own accord.
I shifted work onto the client team.
With the client doing more of the work they achieved a better understanding of what was being done, and more importantly, why. They learned how to do it, gaining new skills to the point they could self-serve at times, with help when needed. In several cases they took ownership of the work and continued and grew upon it without my oversight.
With these changes, in time I noticed a distinct shift in the client, both collectively and individually. Before where there was uncertainty and doubt, there was now confidence and understanding. With them understanding the project as a “system”, they could foresee needs and next steps and thus be proactive. Project execution sped up and “misses” drop to next-to-nothing. In the final phase I largely just provided oversight. They owned the project, and in the end, it was successful in addressing the client’s problem.
