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.
Wednesday, 18 April 2012 10:54
Avoiding the What the Customer Wanted Syndrome Featured
Written by Kiron Bondale
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.
Published in
Kiron Bondale
Tagged under
Kiron Bondale
Kiron D. Bondale, PMP, PMI-RMP has worked for over thirteen years in the project management domain with a focus on technology and change management. He has setup and managed Project Management Offices (PMO) and has provided PPM consulting services to clients across multiple industries.
For more of Kiron’s views on project & change management, please visit his blog or contact him directly at kiron_bondale @ yahoo.ca.
Comments
I would add that even in waterfall projects, the "customer" (In all the different definitions thereof) can and should be involved, and the project plan created with that in mind. Clearly the process of one person talking to the customer to gather requirements, then passing that along to another to formulate into a plan, and then another person interpreting that and building something, then passing the "completed" project back to the customer runs a high risk of failure. In my opinion, this is because most people either don't take, or don't have, the time to spend on each step to make sure it is on target, or as you say, they take the short and easy path. Add to that tight budgets, unrealistic expectations and miscommunicatio n, and the result is actually predictable.
To use a woodworkers mantra, measure twice, cut once. The meaning being if you spend the time up front to make sure the specs are accurate, the outcome are pieces that fit. The same is true in project management.
I definitely did not want to leave the impression that I feel that waterfall projects cannot be appropriately structured & managed to avoid this risk, but it is usually much trickier than on "true" agile projects (i.e. those that really adhere to agile principles).
Thanks again for sharing!
Kiron