Avoiding the What the Customer Wanted Syndrome
You have likely seen some variation on the cartoon that illustrates the differences in interpretation of a customer’s requirements by various participants in a project (if not, click here) so you’d expect that there is a general understanding of how common this issue is and how to avoid it.
Unfortunately, this is another case of practice not aligning with theory. Most waterfall project methodologies utilize documents to provide the contributors for each phase of the lifecycle with knowledge of what the customer wanted. While we would normally hope to have a business analyst or similar role to ensure consistency of understanding and communication across all phases, in some cases, there may be no resource continuity and this knowledge is transferred purely in documentation form.
If we assume that each handover results in a certain degradation of the knowledge captured in the previous phase, the effects of this requirements corruption compounds the more steps we add. It is still common to find projects where there might be four or even more handoffs between the customer and the actual creator. The most likely outcome of this during product handover is a quality variance which will result in customer satisfaction, budget and schedule variance issues.
This is the rationale behind one of the key principles of agile approaches – make the customer an integral part of the project. Yet even on agile projects, one often sees an increase in the distance between the customer and the creators. This might be due to legitimate geographical or time zone limitations, but other times it is because of political or priority reasons. The “easy” answer in such cases is to start introducing proxies for the customer, thereby increasing the likelihood of expectation gaps. This gets worse in cases where the delivery organization outsources portions of the delivery process as there are likely to be even more hops introduced.
As project managers, we need to avoid the temptation to follow the path of least resistance – if the pushback in involvement is coming from the customer, it is important to have those “difficult” conversations to help them understand the risks introduced and to confirm the relative priority of the project deliverables. If resistance is originating from the delivery team due to concerns of constant requirements refinement or change, it may be worthwhile to review the outcome of projects where the customer had not been involved to prove the merits of an alternate approach and to explain how other project constraints (e.g. schedule, cost) can be fixed thus allowing scope to be flexible.
While six degrees of separation might be enough to connect you with Kevin Bacon, striving for zero degrees of separation between your project customer and your team might help to bring home the bacon!
Don’t forget to leave your comments below.