Collect Requirements Define Scope processes with PMBOK
Let’s look at how to “collect requirements define scope processes” in more detail
In this article, I want to focus on the Collect requirements and defining the scope management processes that are carried out within the planning process group only.
The phrase “Collect Requirements Define Scope processes” is fairly broad, so let’s break it down and go through it in detail. The key document outputs which will be dealt with here are first:
- Requirements documentation
- Requirements management plan
- Requirements traceability matrix
- And from the Define Scope Process, the Project Scope Statement
So, let’s look at what’s involved in more detail for –
Collect Requirements Define Scope Processes
Put at its simplest, a project scope defines precisely what is included and what is not included by clarifying the boundaries. It is counter-intuitive in many ways because often organizations try to deliver more than was agreed upon, to exceed customer expectations.
This can be called ‘gold plating’, and can cause projects to overrun schedules, and budgets and hence increase risk. It is very easy in performing collect requirements that folks will ask for more than they actually need.
To be in control of scope throughout the project requires close management of collect requirements, the details etc, and the processes. Any scope changes must be handled in a structured, linear, and controlled manner.
Each requirement is documented clearly along with its acceptance criteria as it is vital that the scope is well defined and clearly communicated.
The key to the success of scope control is to ensure that if any change is requested, that it is first evaluated, captured, and documented and that no change should be implemented unless it is clear that it is necessary, and that the right authority has first been given for its implementation.
It is important to compare this against the output from Collect Requirements.
From the planning process group perspective, the requirements for the product and project are first gathered, then the deliverables forming part of the product and the project scope are defined and documented, leading to the creation of the work breakdown structure (WBS). I shall cover the WBS in a separate article.
I will now deal with each PMBOK process in turn
Collect requirements
The detail contained within the requirements leads to a clear understanding of what is needed to satisfy the stakeholders so that their expectations can be managed. This key documentation is the touchstone from which the schedule, budget, quality specifications, resource plans, and risks emanate.
The prerequisites to the collect requirements process are the project charter and the stakeholder register. The project charter provides an overview of the project’s product, service, or result and this is used to determine the requirements.
The stakeholder register lists all of the project stakeholders and it is important that the right stakeholders are involved in helping to explain the requirements along with the underlying needs from the earliest point in time of the project.
There are three documents that are created as a result of the Collect Requirements and Define Scope processes:
Collect requirements – Requirements documentation
This lays out what needs to be performed and justifies why each requirement is important.
Information captured here should include:
- The source of the requirement and the core business problem that is being solved
- How each requirement addresses the problem
- Relevant measurements for each requirement
- How existing business processes interact with the requirements
- Constraints and assumptions
- Predicted impact of the requirements on others
- Business, legal, and ethical compliance
Collect requirements – Requirements management plan
This is in effect, a strategy for how the requirements will be managed, and covers the team activities to both gather and then manage the project requirements. This document forms part of the project management plan and covers how requirements will be obtained and decisions made, how the requirements will be documented, and how requirements changes will be managed.
Requirements traceability matrix
Part of the requirements documentation includes the source of each requirement, and identifying the source is what this document does. Here the sources will be named, whether an individual, group or organization. The source origin could be a legal requirement or clauses within a contract. Additional information may include who owns the requirement for example.
There are eight tools that may be used to assist in the Collect Requirements process:
- Interviews. Subject matter experts should be used here as they are more able to articulate what the product should consist of and why this is important. The project manager or a business analyst may conduct such interviews.
- Facilitated workshops. These are a highly efficient way to capture and define the requirements, but the use of an experienced facilitator is key, along with inviting all appropriate stakeholders of course.
- Group decision-making techniques. There are many techniques available to assist in bringing the stakeholders to a decision. These include unanimity, majority, consensus, plurality, and dictatorship.
- Focus groups. As the name suggests these are carried out by a member of the project team meeting with a group of stakeholders to determine their requirements, needs, and expectations for the project and its outcome.
- Group creativity techniques. Generating a creative environment where people can openly discuss their ideas is a powerful and creative way to ensure the requirements are fully captured. Techniques can include; brainstorming, nominal group technique using votes and priorities, diagramming techniques such as mind mapping, and where a participant’s real unbiased opinion is needed, the Delphi technique.
- Questionnaires and surveys. Using a standard questionnaire or survey allows requirements to be gathered quickly among large groups of people and because of the standard format, analysis is also quicker.
- Observation. Put simply, an observer watches as a worker performs their job and notes how the worker performs this last capturing less obvious requirements that would be missed by other methods.
- Prototypes. A prototype’s use and style will depend upon the end product of the project and any methodologies being used for its creation. One or more part-functioning prototypes can be a powerful visualization aid when attempting to understand requirements.
The Define Scope process
Here, the project requirements (from collect requirements), are more thoroughly understood and documented and may be carried out in a simple informal manner or a complex formal and detailed manner. If this were a construction project for example, then the Define Scope process will need to be done in detail as errors here can have huge cost, resource, and schedule implications.
Because projects are progressively elaborated, the Collect Requirements and Define Scope processes will often be performed numerous times throughout the project.
The main input is the project charter itself, as it will detail the goals and objectives of the project, a description of the scope, and any constraints and assumptions.
The requirements documentation is also an input as the Define Scope process translates these requirements into more detail.
A final input is the Organisational Process Assets. These can take many forms, including project plans from previous similar projects, templates, policies procedures or guidelines, etc.
There are two main outputs from the scope management process, the project scope statement, and project document updates.
The Project Scope Statement
The project scope statement provides the baseline agreement among all of the stakeholders of the project and its deliverables.
The project scope statement includes the objectives of the project, the product description, and requirements for the project, the constraints, and assumptions, and the risks are have been identified relating to the project scope. This document should also include the acceptance criteria for the end product.
Project document updates. Obviously, this relates to any documents that may need to be updated as a result of defining the project scope, and typically includes the requirements documentation and the requirements traceability matrix, and the stakeholder register. Estimating data, issues, and risk data may also need to be updated.
Tools that are used in the define scope process are:
Expert judgment. This is the use of technical experts helping to develop relevant parts of the project scope statement.
Product analysis. This involves a detailed analysis of the project product service or a result and the output here is a better understanding of the requirements. Many tools are available to carry out product analysis and these may include; requirements analysis, value engineering, product breakdown, and systems analysis.
Facilitated workshops. This is described in the collect requirements process and is here used to further refine knowledge of the project scope.
Alternatives identification. Brainstorming is it method here with the aim of helping the team to understand and consider all options relating to the project scope.
Want to Pass Your PMP Exam On First Try? hope on over here for more information:
