When the Customer Doesn’t Know What They Want
Posted by Brad EgelandOften times the customer knows exactly what they want and they know what technology they want it developed in and they know when they want it and exactly how they’re going to use it. These are the projects that usually come with well-defined business processes mapped out (both as-is and to-be) and a solid list of documented high-level requirements…possibly even detailed requirements.
These projects are the least likely to have scope creep, stand the best chance of avoiding unknown risks and issues and in the long run are the least likely to experience a high level of customer dissatisfaction, unless something goes terribly wrong.
When the Customer is Clueless
What happens on the other side of the coin? Surely we’ve all had some projects – or at least one – where a project came to you with a customer who knew they needed something, but they really didn’t know what. I know this has happened to me. It seems to be most prevalent on smaller projects and – for me at least – internal projects.
When the customer heads into an engagement with a poorly defined vision of what they want and what their processes are, the risks can be high. A few to consider are:
- Extreme scope creep
- Longer than anticipate Exploration phase
- Design and Development phases may be lengthened do to changing requirements
- High potential for customer frustration as they perceive that their needs are not being met by the ‘experts’
At this point, because the customer is coming in fairly unaware, it is up to the Project Manager and the delivery team to ask the right questions, drag the ‘real need’ out of them, and help them to form it into a vision of the to-be processes and application.
When the Customer Seems to Know Too Much
Likewise, we have to be aware of those customers who seem to know what they want, but they aren’t sure why they want that. Experienced PMs, Business Analysts and developers must remain aware of these types of customers and ask the right questions to truly identify the need.
If we go down the path and develop a system for a customer who wants something but doesn’t fully understand what and why, then we’re going to end up with a frustrated and dissatisfied customer when we implement a system to their specifications but it doesn’t really fit the need that they themselves didn’t fully understand at the start of the project. Yes, we will have developed what they asked for on paper, but we won’t have a satisfied or repeat customer.
The Solution
The key for the PM and the delivery team is to not go into the project with blinders on. Look for these types of customers and be ready to recognize these issues, as they’re not always obvious.
And for both types, the solution is really the same. Be sure to:
- Spend enough time during Exploration on helping the customer define business processes and requirements
- Review the SOW and ensure that all deliverables are documented
- Re-work the project plan and re-set customer expectations because Exploration and possibly future phases of the project will likely take longer
- Prepare the customer for change orders due to extended timelines and more effort hours if the original budget has already been set by Sales
- Educate the customer to use their SMEs to help define what they need and why they needed – their end user base acceptance of the solution will be higher
We just have to realize that whatever is on paper is not always the true picture. It’s never wrong to ask tough questions and ensure that we’re creating something for our customer that they will truly use and benefit from.
Related posts:
9 Comments to “When the Customer Doesn’t Know What They Want”
Post comment
Barry Moses says:
No longer do product development teams want to work in the “traditional” Define, Design, Build, Test, Implement approach. They want to experiment with their product and get the results back from their experimentation quickly so that they can adapt the product quickly based on those results. No longer do they want to have to anticipate where their product needs to be in 3,6, 12 months time when they next expect to release their product.
It is, surely, the role of the project manager to reduce the cost of this experimentation by putting together a strategy and set of processes that allows the business owner to reliably innovate i.e. adapt rather than anticipate to move their product forward. Would it not be better to deliver working software that is providing real ROI and providing valuable feedback to the business owner as to what their customers want rather than spending time reviewing documentation.
Laura Brandau says:
Hi Brad,
I couldn’t agree more…without understanding what problem you are trying to solve, you have a project bound for failure, whether the solution is well-specified or not.
Laura
http://www.bridging-the-gap.com
Brian Mossing, MBA, PMP says:
Too true. I’m working on a project right now that has dragged on for three years (!!!)(I’ve only been assigned since January) because the customer didn’t know what they wanted. It didn’t help that business and security requirements changed multiple times, but it’s just this year that the project finally seems to be under control and driving toward conclusion — and the bottom line at the start was the customer didn’t really know what they wanted and the PM at the time jumped in to solve a problem he didn’t really understand.
Also, we should understand that even when the customer does know what they want (or thinks they know), it doesn’t mean they’ll have the requirements and processes already laid out for you. Your solution tips above will also help in this situation.
Thanks, Brad, good post.
Charlotte says:
Agree with Brian in ref to the establishing the needs of the client; what can help – is a dedicated requirements gathering phase which is a project in itself (think agile increments). It’s only after the objectives have been defined that you can then really get stuck into the ‘nuts and bolts’ of production and, of course, the delicate specialist science of managing client expectation. It does depend on sector but generally (for example) if the client is NFP or Gov’nt you’re looking at collating info from multiple stakeholders with varying input into the final project – establishing the needs and degree of influence they have in the final project should make life that bit easier. If the project is more commercially focused you’ll need to watch out for changing brand guidelines and potential in-house politics across departments..result being that the design phase may need to be extended but the deadline doesn’t seem to be moveable ;)
An additional consideration to throw into the mix are other key client facing members of the team (AM/ New business etc) who are a little bit too keen to say yes to the client and who then quickly hand over the resulting ‘lovely’ to the producer or project manager to work through with the client from the first meeting. Really do understand where they’re coming from (I’ve been on both sides of the fence as an AM and PM) but communication with the rest of the team is key – cutting them out of the loop to save time is a false economy and may well bite you (and the rest of the team) in the backside further down the line. A simple thing like having a ‘sanity check’ (with the producer and the rest of the team) to ensure everyone is ’singing from the same sheet’ cuts a sizable amount of stress out of the equation.
Blimey.. I went on a bit ;)
David Smith (IT BA) says:
I’ve worked on several projects where the Customer didn’t know what they wanted (or had a ’solution’ in mind). To me the key point in Brad’s article is “Spend enough time during Exploration on helping the customer define business processes and requirements”. If the processes are not in place when the IT deliverables are delivered, then the ’solution’ is unlikely to work, leaving the Customer very frustrated (and they’ll probably blame the solution for this).
H M Thakur, PMP says:
Exactly true, it is essential that the PM identifies the REAL expectations of the stakeholders. Unless the expectations are identified, one only gropes in dark without achieving the project objectives. The end result is constant building up of frustrations and consequent delays. It is therefore important to not only indentify the stakeholders and their REAL expectations but also segregate them into wants, desires and Wish lists.. Prioritisation of the expectations then serves as a road map for the stakeholders and eliminates misunderstandings which often is the root cause of derailing the project.
Karine Simard says:
I completely agree! In my work, I often see customers who approach us with a solution, but sometimes this solution is not the most efficient way to fulfill their need. We have to discover what the root problem is, and then propose a solution that is tailored to the customer. Otherwise, as you described, we end up with unhappy customers.
The Project and the End User Perspective | Project Management Tips || Project Management, Collaboration and Knowledge Management Blog says:
[...] covered this to some degree in the article “When the Customer Doesn’t Know What They Want.” In that article I stated, “it is up to the Project Manager and the delivery team to ask the [...]
Should We Give the Customer What They Want? « PMBOK Cafe says:
[...] When the Customer Doesn’t Know What They Want [...]