Articles and White Papers

Get Stakeholders to Read Your Requirements Specifications

By Phil Vincent, PMP, CBAP

You’ve held the interviews, read the documentation, done your analysis, asked a ton of questions, and even received some answers. As the requirements delivery deadline looms, you need to get your project stakeholders to read and approve your requirements specifications.

Now your real problems start.

Your project stakeholders are too busy. Or worse, they don’t answer your requests. Or maybe they prefer to have a meeting. And there’s never enough time at the meeting. And the requirements keep changing.

Why is it so difficult to get people to read a requirements specification document? You would think that something so important would have the full attention of your key stakeholders. Yet time after time, in company after company and industry after industry, business analysts complain that getting their stakeholders to read and approve their requirements specifications is unexpectedly difficult.

Requirements from the Stakeholder’s Perspective

Why is this happening, and what can you, as a business analyst, do about it?

Let’s look at it from the project stakeholders’ point of view. They told you the requirements, and you wrote them down. Then you went off to do some analysis for a few days or weeks, and when you returned and showed them what you had done, they said that it was either wrong or so different that they didn’t know what to do with your specifications. And you probably had more questions for them—questions that they had great difficulty answering.

Things probably started to go wrong when you wrote the requirements down. If your notes were informal, and if you weren’t precise about confirming your understanding of what they told you, it’s likely that there was some miscommunication going on that you probably weren’t even aware of it. Then you went away to do your analysis. You did some research and deep thinking, learned a lot, and probably gained great insight into the business domain. But if your stakeholders didn’t share that process with you, their perception of the requirements won’t be the same as yours. And then you added the details, such as data descriptions and validation rules and GUI navigation—topics really needed by your designers—but in so much detail and from such a different perspective that it overwhelmed your subject matter experts.

And when you asked the stakeholders to review the requirements documentation, you really asked them to take a huge mental leap to catch up with your understanding—to understand your way of describing the requirements, which is very likely to be different from theirs.

It’s frustrating for you and for your stakeholders, and it’s bound to lead to missed or wrong requirements and a delayed system delivery.

There are several things you can do to address this problem:

1. Be careful who you ask; you’ll always get an answer (but not necessarily the right one).
2. Combine your requirements elicitation activity with your analysis and documentation activities.
3. Let the stakeholders dictate the wording of the requirements. (This isn’t nearly as outrageous as it sounds.)

Requirements Protocol

When you invite people to a meeting and ask them questions, it’s human nature for them to want to help you by providing answers. But if you are asking requirements of the wrong people, at best it will be frustrating for both of you and at worst you will get the wrong requirements. These “subject matter experts” will naturally be hesitant to approve requirements if they aren’t sure they are right. Avoid asking people to sign off on something they either don’t understand or don’t have the authority to approve.

For successful requirements, the first thing you should do is to identify all your stakeholders and determine which stakeholders will provide you with which requirements. Think “stakeholders” rather than “users,” because often the people in the role of user have a limited perspective of the system. For each of your stakeholders, determine which requirements they should be able to provide you with as their part of the requirements, and then confirm this with those stakeholders. This helps you to be sure that you will be getting requirements from the right people, and it helps to confirm their interest and willingness to participate.

Conduct Business Analysis and Documentation “On the Fly”

Do your homework: read the documentation, learn the words, and review the processes before you meet with your stakeholders. Learning about the domain on your own is usually much more efficient than asking a roomful of people in project meetings to explain it to you—more efficient for you and for them. Next, choose an elicitation technique that is appropriate to the kind of requirements you are trying to get and that will work with that particular group of project stakeholders. Interviewing shouldn’t be the only technique in your repertoire.

Now here’s a real project management time-saver: when you conduct the requirements-gathering session, plan to use electronic tools such as a work-flow modeling tool or even just a word processor to document and analyze the requirements during the gathering session. Use a formal model or template to help guide you as to what details are needed and when. Share the screen with the stakeholders as you are capturing and documenting the requirements. This will help them to understand your models and diagrams and to understand the level of detail that you need. More important, it gives both of you a chance to confirm that what the stakeholders thought you said is what they think you heard. If there is a miscommunication, you will both recognize it and be able to correct it right away.

Let the Project Stakeholders Dictate the Business Analysis Requirements

This is the most crucial step in the requirements process of your business analysis. As you guide them through your various models and documents, use the words of the stakeholders, exactly as they say them. But coach them along. When you are working through a use case with stakeholders in project meetings, let the stakeholders see your screen with your use case template and other models. Ask the stakeholders to dictate each step. They may need a little coaching to get used to the formal way of phrasing the sentences, but they tend to catch on pretty quickly.

Write each step exactly as they say it, and let them see what you wrote. As you work through the use case, all of you will participate in correcting assumptions, fleshing out details, identifying variances, and so on. In short, for better results, you will be doing the analysis together.

At the end of this requirements-gathering, analysis, and documentation session, you will have requirements documentation that accurately reflects what the stakeholders told you, in a structured format useful to other stakeholders such as designers and testers. And these requirements will have already been subjected to a lot of analysis during your project meetings. Share the electronic or paper copy of the document right away, so that your stakeholders can study it further. If changes are required, you and your stakeholders are likely to identify them sooner rather than later.

Remember to review, confirm, and obtain approval from the appropriate stakeholders before making any changes to these documents.

Summary

The three techniques described here will help you to facilitate (i.e., “make easier”) the project requirements approval process and project meetings.

1. Ask the right people, and get their buy-in early.
2. Manage the communication of the requirements so that you both know that you have a common and correct understanding.
3. Capture the requirements in a structured format that helps you to analyze them as you elicit them.

As you get better at these three techniques, the final requirements approval process will be easier to accomplish and will involve much less risk to the project than you may be experiencing now.

About the Author:

Phil Vincent, PMP CBAP, Certified ScrumMaster and Certified Rational Solution Designer, is a Senior Consultant and Trainer for Corporate Education Group. Phil offers a wealth of experience and a passion for teaching, coaching and mentoring and is an expert in all aspects of the software development lifecycle, especially business analysis and project management.