Often 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.