How to Define Requirements and Important Role of Project Manager

Inaccurate requirements gathering is a top-cited cause of project failure. That is what PMI’s Pulse of the Profession™ research says. So what role can a project manager play in requirements definition? How can we improve the chances of project success?

As a project manager, I had various experiences. I had a dedicated person responsible for defining requirements on one project. And there were cases when I had to elicit requirements on my own.

I can tell you for sure in both cases challenges are the same. You need to work with stakeholders. And most of the time they are short on time. Stakeholders usually do not see the value of the requirements management process. Quite often they think that it is a part of the execution process.

Key stakeholders try to shorten the period of requirements collection to a minimum.

General Approach

In my opinion, the very first thing is to prove it is a crucial activity. Stakeholders should understand the negative impact of poorly defined requirements. Business “vision” has nothing to do with the project scope. Deliverables they will receive may drastically differ from their expectations.

Quite often stakeholders don’t know what they want. At least until they see it. On the other hand, once deliverables become more tangible new opportunities appear. Stakeholders lay hands on a prototype or the first version of the product, and new ideas pop up.

You need to facilitate this process. Stakeholders need to have a clear picture of what they want and need as soon as possible. Visualizing the end result or product is one of the best strategies. So try to insist on early designs or wireframes.

There is a particular relation between requirements, scope, and quality. You can see it throughout PMBOK Guide. In short, it looks as follows:

Requirements are the wants and needs that describe the product, service, or results of a project.
Scope describes what needs to be done to deliver the result that complies with all requirements.
Quality is the degree to which a product complies with the requirements.

The better you know requirements, the better you will be able to define the scope. The better you understand the project scope, the better quality you can achieve.

The ambiguity in requirements leads to an uncertainty of scope, and therefore, leads to poor quality.

“Requirements are always in a state of flux, and that’s something project managers have to embrace.” – Filipe Altoe

The process of requirements definition strongly depends on the methodology you choose.

Should you adopt Scrum, Kanban, or waterfall? It is not a question of what approach is better. They all work well. Under certain circumstances, they have pros and cons.

Are you able to clearly and comprehensively define requirements beforehand? It may be better to choose a waterfall. You will be able to use your resources more efficiently.

Are the requirements consistent and stable throughout the project lifetime? Then an Agile approach will do better. You will need to adapt to changes fast.

In the long run, you need to answer one question. How to deliver a quality product that complies with requirements as they are known as of today.

That was a theory. So what happens in practice.

Define Requirements

You will need to focus your efforts on managing processes to define requirements. You should act as a facilitator. Try not to get bogged down by the routine. You need to state on the management level to see the whole picture.

Customers or sponsors may be interested in the project’s success. So, they will be engaged in the process and motivated to provide all the information they have. Though, they might not have enough expertise to describe what they want. They might not think through all specific details.

The majority of the key stakeholders will not provide you requirements in a timely manner. They may know nothing about your project. So you need to be proactive. It is much better to contact them as early as possible. They may help you to define critical requirements before your planning is over.

There are dozens of techniques. But there are three that you will need to use most of the time.

Document Analysis. This way or another, stakeholders will provide you different kinds of documents. It may vary from laws and codes to software manuals, use cases, policies, process workflows, business plans. As easy as it sounds you need to read, analyze, and elicit relevant requirements.

Brainstorming. Use this technique when you lack clear “wants” from stakeholders. It will give you the creativity to generate requirements. Gather relevant stakeholders or project team members. Then let them generate as many ideas as they possibly can. You will have to prioritize them later after that.

Interviews. Talk to stakeholders directly. Record their answers. Analyze their ideas and convert them into requirements.

Prototyping. By creating a working model of a future product, you can give stakeholders the ability to provide early feedback. When you gather enough information, you will be able to compile the requirements for the final product. As a prototype, you can also use storyboards. It is a sequence of images that show how a real product will behave.

So my point here is that you don’t need any fancy activities to collect requirements. Try using these four first.

There are several other techniques that you should be aware of. They include facilitated workshops, focus groups, nominal group technique, mind mapping, affinity diagrams, observations, questionaries, and surveys, benchmarking, and so on.

In rare cases, you might need to conduct one of such information gathering events. But not on a daily basis. So my advice here is to master the four techniques I mentioned above. After that discover the main ideas of the rest. Once you need them, look for additional information.

During the whole process, you need to log the collected requirements. Even better to have each requirement signed by relevant stakeholders. In the end, you want to have requirements that are complete and accurate, unambiguous, verifiable, testable, and sufficient for design.

In the case of a complex project, you may want to use the Requirements Traceability Matrix. It is a tool that helps to track a requirement to its owner, a business need, and relevant information.

Analyze Requirements

So now you have a bunch of requirements documented and signed by stakeholders. First of all, you need to review them all and ensure that they are aligned with business needs. Each requirement should be connected to a business case described in Project Charter.

Otherwise, you are planning to do something that is not requested by a customer and sponsor. It is a bad practice.

Next, you need to prioritize all requirements. Your project has constraints of time, money, and scope. When your plan exceeds them something will have to be excluded from the project. That should be the low priority requirements.

And now you need to identify conflicting requirements. Yes, different stakeholders can provide contradicting or conflicting requirements. You will have to resolve such conflicts. You may need to meet with both owners of conflicting requirements. Act as in any case of conflict resolution. The best results can be achieved by collaborating and compromising. Forcing, avoiding, or smoothing the conflict in requirements usually backfires later.

I need to warn you. Quite often project managers are afraid to ask other stakeholders about requirements. Because it always leads to conflicts. You need to be wary about such notions. You do need to define all requirements and resolve all the conflicts. Otherwise, you will get into the statistics of the failed projects

To summarise it a bit. I want you to keep in mind that you need to create and manage a process of collecting requirements. It is not your sole responsibility. There should be dedicated, trained and experienced specialists to work. Nevertheless, keep in mind that you need to find a balance between rigid process and no process at all.

If you would like to more about processes you can apply to define requirements, I can suggest the following: