A Project Lifecycle is rarely "A" to "B"...
What a client truly needs
In web development, the single greatest challenge is identifying what a client wants and truly needs to meet their business goals online. It may sound odd or even a bit presumptuous to say so given the technical hurdles that must get solved, the meeting of deadlines, the options to weigh, and the coordination of all of the moving parts and interests of multiple stakeholders. It is tempting to assume that when a client says they have “A” and simply want “B,” that is the end of it. Some development firms take the client requests at face value and assume the job is to build “B,” except that when the client sees “B” they realize that’s actually not what they wanted. They meant to say something else during discovery because now they know they really want “C”. This situation occurs all too often and the consequences can lead to major conflicts over scope, schedule, and budget. To ensure our clients have a solution that truly solves their challenges, our agile process educates and illuminates so they get to that "C."
Alleviating anxiety and apprehension
Clients often come to the table with a great deal of apprehension, anxiety, and outright fear about their ideas, requests, and goals. Many have been burned by a bad experience with dev teams that had poor communication or maybe even no communication for months at a time only to turn up out of the blue with a half baked site that’s broken and nothing like what the client envisioned. These emotions can inhibit a client’s ability to effectively describe what they want and can lead to misunderstandings.
It is our job to help the client alleviate those anxieties and help them communicate what it is they’re looking for. Often a client oversimplifies what is a very complex build. It works the other way as well when the client assumes something is far more complicated to implement than it actually is or is not even what they really want. They may be assuming that to get the critical 10% functionality they want and they have to accept the 90% of extra features that are unnecessary.
We often employ a Value vs Effort matrix as illustrated below. We want to stay in quadrants 1 and 2, dip into 3 only as needed, and stay away from 4.
Collaboration is key
Getting to “C” with a client is a collaborative process. As a PM, I always emphasize to my clients the notion that we are a team and are dependent upon each other to succeed. The process of discovery, requirements, and building is a two way street and a push pull relationship if we’re going to build what the client wants. For the PM, this means placing a heavy emphasis on listening. Second only to listening is the ability to ask effective questions. Rather than simply reflecting back what a client wants, questions should go beyond clarifications and include talks about potential pitfalls, sustainability and future-proofing.
Listening to clients to figure out what to ask them is key to asking effective questions. The more a client can describe what it is they’re looking for, the easier it is to gauge their knowledge and clarity about their request. Rather than jumping to conclusions right away, the challenge is to ask questions of the client that help the client to better understand what they are asking for. The process can be difficult at times, but can pay off in the long run as the PM and the client gain a much deeper understanding of what needs to be built and how at a much earlier stage of the process. By seeking deeper clarification, we can help the client understand what it is they really want when the answer isn’t “B” it’s “C.”