Project requirements: how to collect and analyze them

Project requirements are a key aspect in order to complete the project on time and without exceeding budget limits.

This is one of the essential skills of a project manager, often underestimated, which consists in the collection and analysis of these aspects of the plan.

Understanding clearly the requirements of any project you are about to undertake is very important.

Too many projects have failed because of no well-defined requirements.

As stated by the Project Management Institute

47% of projects failed due to poor requirement management.

There are no two identical projects: each project has its own set of requirements and it is a project manager’s responsibility to identify them correctly.

The more complex the project is, the greater the need to define the requirements in order to find certain processes for each part of the project.

What are the project requirements?

Stakeholders hear the term “requirements”, but everyone get its meaning in different ways, depending on the goals.

Therefore, before we can examine anything, it is essential to have a univocal operational definition.

Part of the confusion related to the requirements lies in the fact that there are several types. We will therefore try to stick to the classification made by the PMBOK (link all’articolo PMBOK)

The 6th edition of the PMBOK classifies the project requirements as follows:

• Corporate: they describe the reason for the project;
• Stakeholders: they describe the needs of a stakeholder or group of stakeholders;
• Solution: they describe the characteristics, functions and characteristics of the product, service or result that will satisfy the company and the stakeholders;
• Functional: they describe the behavior of the product or service;
• Non-functional: they describe the environmental conditions or the qualities required for the product or service to be effective;
• Transitional: they describe the temporary capacities necessary to pass from the current state to the desired state in the future;
• Project: they describe the actions, the processes or the other conditions that the project must satisfy;
• Quality: they describe any condition or criterion that validates the successful completion of a project result or the fulfillment of other project requirements.

But why are the requirements so important for a project?

When requirements are not clear, projects are at risk; they may not produce the desired and necessary result.

At least, the missing requirements involve reworking.

In short, the lack of project requirements or their poor definition produces negative impacts on the program and on the budget.

Obviously customers, as well as team members, will not be happy with these shortcomings.

We examine the essential steps to arrive at a correct identification and processing of the project requirements.

Collect the project requirements

A project manager can not expect the project requirements to be delivered on a silver platter.

Stakeholders may not know exactly what they want and should therefore be helped in formulating their requirements.

A good project manager knows how to gather the requirements. In case he does not know, he will have to ask for help from those who possess the skills.

The tools for gathering the requirements

Here are some tools and techniques that can be useful for gathering the requirements:

• Brainstorming: also called as group thinking or group creativity. Usually people with different roles and functions are brought together for this This technique is very useful when you do not have fixed needs and you want try to explore new requirements and new horizons
• Interviews / questionnaires: this technique is usually used in the case of large groups. Having a large number of interested parties does not allow to organize an individual interview. Be careful, however, to ask the right / pertinent questions for a correct and real collection of the needs of the interested parties.
• Interviews: a tool that involves personally stakeholders in order to understand their needs. Interviews can be facilitated through personal meetings or phone calls.
• Benchmarking: in this technique, a comparison is made between existing practices and market best practices. With the gap analysis with respect to these examples of excellence, possible project requirements can be.
• Context diagram: these diagrams represent a pictorial visualization of various interactions between users and different systems. Therefore, they describe the necessary steps to obtain the results and they may be suitable for identifying the requirements.

In each of these cases it is important to have project management software that allows, in the drafting of the project, these requirements, as an integrated part of the project itself.

Requirements analysis

The word “analyze” means to break down or examine in detail the constitution or structure of something.

If the situation allows it, one of the most powerful ways to analyze is to create prototypes or diagrams.

When users can see and / or touch things, it’s easier to see what they like and what do not like. A prototype or a diagram is more tangible than simple data.

Furthermore, in some cases, the priority of each requirement is examined during the analysis. In order to do this, you should ask yourself some questions. Here are some examples:

1. Which features and functions offer the maximum benefit for the project?
2. Which ones can cause the greatest risk?

Once analyzed, the requirements are documented and formalized in the project document.

What the project manager must do in general is to keep his team and client focused on clearly defining project goals and mapping valid, detailed and understandable requirements.

All this, in order to create a final solution that provides what the customer really wants.

The criteria for a project requirement

In general, a good requirement must meet four basic criteria:

• A good requirement must satisfy a specific need
• A good requirement is verifiable
• A good requirement is reachable
• A good requirement is understandable by all stakeholders

A good requirement must satisfy a specific need

A requirement is basically a declaration of something that someone needs.

That something is a product or a solution that performs a service or a function.

Even if it is verifiable, reachable and well declared, a requirement that is not necessary for the final solution is not really a good requirement.

Of course, the definition of the need will depend on the context and circumstances and must be deepened by the team and the client in each specific situation.

A good requirement is verifiable

A requirement must state something that can be verified through quantification, inspection, analysis or testing.

It is also important to determine the specific criteria for acceptance, which will consequently guarantee verifiable requirements.

A good requirement is reachable

The requirement must be within the budget and must be technically feasible.

It is important not to write requirements for things that can not be built or that are not reasonably within the budget or project timeline.

This is not always easy to determine and a project manager may not have the experience to judge whether a requirement is technically feasible.

In this case, it is necessary to ensure to include the members of the development team in the review process in order to predict technical problems.

It may be necessary to do a research in order to determine the feasibility of a requirement before it is added to the project baseline.

A good requirement is understandable by all stakeholders

A good requirement is understandable by all the subjects involved in the project. It expresses a single thought, is concise and is written in short and simple sentences with coherent terminology.

In this way, as you progress in the design and development phases of the project, the requirement will not change in meaning and will always remain clear to everyone.

Another advice is to formulate the requirements with affirmative language whenever possible.

For instance, it is easier to develop and test a product that does something specific than one that does not do something specific.

In conclusion, we can say that a thorough understanding of how to design, modify and adapt the requirements processes is the key for a successful completion of the project.

Have you ever found yourself in difficulty in collecting and analyzing the requirements? How did you handle the situation? Tell us about your experience.