Getting the Project Client to Focus on Requirements

Having trouble extracting project requirements from your customer? Does your project client think they have already handed you all of their requirements and is asking why you aren’t starting to design the solution yet? Are they worried about eating up the project budget with useless planning when you could be starting the “real” work on the project?

I know starting the real work on the project is tempting. It may even be possible – if it’s a two day or two-week project. But if your project is of any length and dollar amount to speak of, then you must – repeat MUST – have genuine project requirements. These requirements must be detailed enough to design and build a solution, and complete and complex enough for you to avoid making wrong assumptions that result in expensive and time-consuming rework later on in the engagement.

You can’t please everyone all of the time

For me, it’s about asking the right questions. For the business analyst who is likely leading much of the requirements definition effort and functional design document work, it has to be about asking the right questions as well. What the customer thinks are the requirements usually aren’t the real requirements. Often, as many have found, and the rest will soon discover, what the customer thinks is the problem is probably only a symptom of the real issue. The actual project may be a few layers down – and that’s the problem, need or issue you need to address. Otherwise, you’ll end up delivering something that doesn’t solve the end users’ real needs.

You may have followed the customer’s perceived requirements perfectly and gotten paid handsomely at the end of the engagement (and during). But 30 days later you find out that your customer is not very happy because what you delivered – while spot on with requirements – is not what they needed. And you now have a dissatisfied client and one who will likely point the finger at you while going somewhere else to get it fixed, and their overlooking you for their next project. Ouch. No, let’s get it right the first time. Here’s how you get there.

The key questions for the client

Related Article: Process Approach to Requirements Gathering

What are you current business processes as they pertain to this project?

The key here is to understand how the business operates now. It will help you understand their need or the perceived need. It will help you see the layers you may need to dig through to get to the “real” need if it isn’t the one the customer is currently presenting. It will help you see who else you may need to include in the discussion. What other key areas of the business are tied into this process? You should find that out here.

What do you want the new solution to be?

This one goes hand in hand with the question above and will give you even more insight into what the customer is thinking and if the real need is the one they have identified. Knowing the “as is” and the “to be” environment is critical to connecting the dots to get the client there. The “as is” situation tells you where they are coming from, and the “to be” will tell you a lot about what they are hoping to accomplish. It may help you better define the questioning process from this point forward.

What specific problems are your end users experiencing?

This is where you find out how tied into the process the end users are or have been up to this point. Maybe they originated the project request. Or maybe they know nothing about it. You need to know the answer to this question, and you need to draw them into the process. They are key.

Do you have specific technology needs or wants in mind?

There may be some underlying desire for a specific technology. I’ve gotten to this point a couple of times only to find out that a new technology – no real urgent need – is the only reason for the project. That’s not a bad thing – just a good thing to know up front. It may (or may not) change how you manage the project or the urgency of it. Just ask, you won’t be sorry.

Is this project supported by the executives?

Finally, make sure there is support for the project by the higher ups. It may not be appropriate to ask of an outside client. But if this is an internal project, it is definitely a question to ask. Why? Because lots of project “phishing” happens before any real funding or project approval has happened when you’re dealing with projects that are internal to your own company. They tend to skirt the formal process and may end up wasting a lot of your time and PMO time when there is no project out there. And how do you approach this on an external project? Well, carefully. But a skilled PM or BA can figure out a way to ask if the customer’s leadership is behind the effort. If you see this as a “weak” project or one that may not really be necessary, it’s a good question to ask no matter how you may go about it.

Summary

There really aren’t any magic questions that will that will draw out everything you need to know to deliver the right solution. No magic question that will make everyone happy and make all those potentially costly change orders completely unnecessary. Stuff happens, change orders happen, requirements change and sometimes they are foggy no matter how hard you try. They key is to try hard up front – put the effort into it. Good PM and good BA oversight and investigative questioning of the project client will get you 90% of the way there. The other 10% will be experience, skill, interpretation and a little luck.

How about our readers?  What do you “ask” or “demand” to get you through the muck to the real customer need and true customer requirements?  Please share your thoughts and expertise (and failures if you don’t mind).