Take a moment and Google up reasons for project failure.
What is the common reason you would find in top few?
Articulated in different words, meaning the same – lack of clarity on requirements.
Ulad Shauchenka analyzed various failed projects and wrote the book ‘Why Projects Fail’. He shares some of the findings from research surveys in this book.
Three out of five research findings have reasons related to requirements –
- Unclear goals and objectives that change during the project (Coverdale Organization research)
- Incomplete requirements (Chaos Report)
- Poor articulation of user requirements (OASIG Study)
Sample these findings from some of other sources –
- Failure to adequately identify, document and track requirements
- Poor or No Requirements
- Unclear goals and objectives
- Loose definition of project scope and management
- Vague requirements
They all indicate the all-important step in ensuring success of a project – collecting the right requirements.
Note – A sample Software Requirements Template is linked at the bottom of this post.
Requirements are basically the capabilities and qualities to be present in the outcome of the project (product, service, or result) as given by the stakeholders.
Project and project scope is derived from requirements. Further WBS is created from the scope. Then activities are identified from WBS. Costing and scheduling is done based on requirements.
Now we can see the potential impact of not capturing requirements (stakeholder needs) properly at this stage on the project. No matter how well the project is executed and managed, incorrectly captured requirements can ruin the project.
What are the different types of requirements to be collected?
This is an important consideration for the project manager, and is largely dictated by the industry. For many organizations (especially in software industry), usual categorization is Business / Functional requirements and Non-functional requirements (such as availability of system, performance, maintainability, response time and so on).
For some, the categorization is Business requirements and Technical requirements – former indicating what stakeholders want, and the latter indicating what project should do to implement these stakeholders’ wants.
In general, there are 6 areas that can be looked at while collecting requirements.
This mind map outlines these requirement categories (click the image to open mind map) –
Figure 1: One of the ways to categorize requirements
At this stage of the project the documents that are already available are project charter and stakeholder register.
Who already knows the requirements that you can collect from? The stakeholders. So we need the stakeholder register and the stakeholder engagement plan to understand who to approach for requirements elicitation and how to communicate.
Then we need business case document, any agreements that are in and of course the scope management plan.
Recall the contents of project charter from Developing Project Charter project management activity –
It contains, but not limited to,
- short description of the project,
- high level requirements
- assigned project manager who is authorized to come up with budget, resource planning, decision on types of people based on skill set
- milestones
- ballpark budget figures
- any identified risks
High level requirements are available at this stage to start collecting detailed requirements.
How are requirements gathered?
There are quite a few ways. Take a look at this mind map to get a hold on all of them. Spend few minutes, we shall look into them individually in further posts. Start with ‘Interviews’ bulb and move clockwise.
As a project manager it is not essential to try and use each of these techniques. The ones to be used depend on the tailoring considerations based on various factors such as existing requirement gathering practices in the organization, lessons learned from previous projects, industry best practices, resource availability and so on.
Let us look at these in a bit detail in the next couple of lessons.
Figure: Some of the techniques used in collecting requirements
Recall the characteristics of a project –
- Definite start and end date
- Produces a specific benefit
- Progressively elaborated
The progressive elaborative nature of project means that not everything about requirements is known upfront. It starts with high-level information that is required to get started, and as project progresses you pick up more details and include them into requirements.
What is requirements documentation
A project creates a product, service or result that satisfies customer’s business needs. The requirements documentation identifies individual requirements and describes how they map to these business needs. So, when these requirements are implemented during project execution, business needs of customer are met.
Although requirements are progressively elaborated, they cannot be ambiguous when baselined. Only baselined requirements are taken for implementation, and at that point they need to be clear, complete, verifiable, and acceptable to stakeholders.
The format and level of detailing of requirements depends on the nature of project and is left to the discretion of stakeholders and project management team. Some may have just description of requirements listed per business priority. Some may have elaborate structure, attachments etc.
In software industry, Requirements Documentation is sometimes called as Software Requirements Specifications.
Some of the parts of requirements documentation are –
- Business needs detailed from the project charter
- business and project objectives
- business rules
- Stakeholder requirements
- stakeholder communication and reporting needs
- Solution requirements
- functional requirements – behavior of the product
- non-functional requirements such as performance, safety, security, government or industry compliance needs, reliability, ease of use, maintainability. These are the inherent expectations from the product.
- standards and compliance (industry, domain, government) requirements
- product support and training needs
- quality needs and reporting needs
- Project requirements – performance, safety so on. Includes acceptance criteria.
- Transition needs (to production, support and/or operations)
- Assumptions and constraints
Consider our earlier example of Landscaping project that Kathy was managing. The business need is to build a jogger’s garden, blending nature’s feel and functional needs of jogging track.
To satisfy this business need, one of the functional requirements would be to have jogging track, which is a spray-coated anti-slip rubber runway, with rebound value of 24%.
Non-functional requirements would be that it is environmental-friendly and should last at least 5 years.
What is Requirements Traceability Matrix (RTM)
RTM is second document created in this process. It is the way in which baselined requirements are linked across different baselined data, such as use case, design, test plan and test case. This document will ensure that various activities of the project work fulfill the business needs, and that none of the business needs go missing from implementation.
A sample requirements traceability matrix would be –
Figure: A sample Requirements Traceability Matrix
If you manage Software projects and need a quick start-up document, you can download a simple Software Requirements Template: MSDoc version or PDF version. This is based on IEEE recommendation for Software Requirements Specifications. For non-software projects this document may need some tweaking specific to the industry.
Usually the requirements are collected in less than ideal ways in organizations. Reasons are many – from customer’s inability to provide access to real stakeholders (end users) to lack of awareness about tools and techniques, to lack of support in the organizational process assets. What has been your experience with gathering requirements for any of your project? Let me know in Comments below.
We are not done studying requirement gathering concepts. This is a critical activity for the project manager, and in next two posts we shall look at some of the tools in detail, starting with this one.
[SneakyAffiliate sneakyaffiliateurl=”https%3A//www.pmexamsmartnotes.com/pmprecast-myposts” sneakyaffiliatecookiexpdays=”1″ sneakyaffiliatesplash=”Are%20you%20sure%20you%20want%20to%20leave%20before%20you%20checkout%20special%20PM%20PrepCast%20sale%20by%20Cornelius%3F”] [/SneakyAffiliate]
