The project scope is established through the Define Scope Process.
In most cases, the product scope will also be created through activities in this process or undergo revisions.
The project scope statement explicitly describes all the project’s deliverables and the work necessary in order for the project to meet its objectives and all its approved requirements.
The scope statement needs to contain or reference other documents that describe all these elements:
- Product scope
The characteristics of the product, service, or result for which the project was undertaken. In projects that are part of a larger program, the project itself may only be creating components of the product, but the product scope or product description is still necessary so that everyone knows what the overall objective is.
- Project objectives
Objectives are the success metric for the project. Specifically, what will it take for the project to be considered successful? This includes the business, cost, schedule, technical, and quality objectives, and other specific targets should be included where applicable.
- Project requirements
The capabilities that the product, service, or result must possess and meet.
Requirements are the translated expectations and needs of the stakeholders into prioritized, descriptive requirements and work items.
- Project exclusions
Nearly just as important as what in the project, the scope should include items that are excluded from the project.
Doing this helps eliminate any confusion within the stakeholders or project team.
- Project deliverables
The core product, service, or result should be fully described, as well as any ancillary deliverables.
Any needed project artifacts, those documents not directly related to the deliverables, such as management, technical, or status reports, should also be described.
- Product acceptance criteria
The process and criteria for product acceptance should be defined.
This includes customer-specific requirements and any testing or other threshold limits.
- Project constraints
Any limiting factors the project must work within, such as deadlines, budget, staffing, facilities, equipment, materials, or contractual restraints, should be described.
- Project assumptions
Every project has assumptions, and these should be described because assumptions are risk factors.
Risks should be identified at least at a high level.
The risk register is where all risks are logged, but having major risks explained in the scope statement helps make everyone aware and on the lookout for them.
Any important dates, including deliverable- or artifact-oriented dates should be included in the project scope statement.
- Approval requirements
Any specific approval requirements for items such as deliverables, documents, and work should be described.
Define Scope Process Decomposition
Define Scope Process: Inputs
- Project charter
The project charter formally authorizes the project and the project manager. It also provides the business case, objectives, and success criteria of the project.
The charter provides the framework for the project’s requirements.
- Requirements documentation
The product scope and project objectives are broken down into requirements and described in a collection of requirements documentation that's applicable to the project and requirement type.
Requirements can be documented and described in a number of different levels (executive, summary, and detailed) and in a variety of methods (textually or visually).
- Organizational process assets
Organizational process assets are the source of existing policies, processes, organizational data, and knowledge.
These assets include the entire collection of formal and informal methodologies, policies, procedures, plans, and guidelines, as well as the organization's "knowledge base," which includes historical performance data, labor information, service and maintenance history, issue and defect history, project files, and financial data. In developing requirements and the project scope, templates, checklists, and lessons learned from previous projects are useful.
Define Scope Process: Tools and Techniques
- Expert judgment
Expert judgment is based on the experience and knowledge of subject matter experts. It's used to assess and evaluate the inputs and the information they contain.
- Product analysis
Product analysis translates product objectives into tangible project requirements and deliverables by dissecting the product into components.
- Alternatives identification
Finding alternatives looks for different approaches in performing the work required by the project, or in the methods for achieving the project's objectives. Alternatives identification is applicable to many project components.
- Facilitated workshops
Facilitated workshops are interactive discussions with participants usually conducted informally to encourage an open dialogue.
Facilitated workshops are central to many different methodologies, and include Quality Function Deployment, Voice of the Customer, and Joint Application Development.
Define Scope Process: Outputs
- Project scope statement
The project scope statement details the measurable goals, objectives, deliverables, and requirements of the project, and what the acceptance criteria of deliverables will be.
It also describes the work required to meet all objectives and deliverables of the project, and it also contains milestones, assumptions, risks, and costs. The deliverables will be compared to the project scope statement to make sure they comply with it.
- Project document updates
Defining the project scope is likely to uncover additional requirements, so updates to requirements documentation and the requirements traceability matrix are to be expected.
A project scope can’t be developed without having a good understanding of the product, even if our project is only delivering a part of a larger product, service, or result.
Disconnects between the product scope and project scope can result in deliverables that don’t fulfill the need for which they were intended.
Product analysis is a tool that translates product objectives into tangible project requirements and deliverables by dissecting the product into components.
Some of the generalized methods of product analysis include:
- Use cases/modeling
These are step-by-step accounts of system behavior and how it interacts with the user.These are very common in software development projects, but they are also widely used in other industries.
- User scenarios/user stories
These are also step-by-step accounts, but they take a more fictional narrative approach, and they are usually written by the customer, user, or analyst and they describe interactions less from a system's standpoint as they do from what the customer needs the product to do.
- Product breakdown
This approach takes a complex product and separates it into simpler components that can be more easily described.
- Functional analysis/functional requirements
These approaches take an even more detailed approach than use cases and describe in detail specific functions of the product from the system's viewpoint.
- Systems engineering
This approach is highly different from industry to industry, but it generally takes a broad, overall view of the product lifecycle, focusing on balancing the customer's needs, cost, quality, and complexity.
- Quality function
A quality management practice whose goal is to fully understand the customer’s needs.
There is usually more than one way to solve a problem or reach our project's objectives.
Alternatives identification looks for different approaches in performing the work required by the project, or in the methods for achieving the project's objectives.
This can result in a project and organizational benefits, such as fewer production costs or time, better quality, or competitive advantages.
Alternatives identification can also turn up methods of addressing stakeholder concerns, usually negative, while still maintaining the integrity of the project's objective.
Looking for alternative solutions requires energy, effort, and creating an environment where this behavior is encouraged.
Project managers may need to lead and encourage stakeholders and the project team through creative thinking techniques.
We're speaking here about technical creativity (new techniques, technologies, processes, and procedures) rather than artistic creativity, though that form of creativity can also be applicable to some projects.
There are two main branches of technical creativity: programmed thinking and lateral thinking.
Programmed thinking is based on pattern recognition, and humans are especially good at this.
We're able to recognize images, pictures, objects, situations, and learn by cause-and-effect.
This type of thinking can help us refine and improve our work processes, but it generally leads only to small, incremental improvements.
And the very fact that we rely on past experiences in programmed thinking can get us into a rut by approaching problems the same old way.
Lateral thinking doesn't completely disregard programmed thinking, but it uses tools that help us break up the patterns and see things differently.
Techniques such as brainstorming, free association, and mind mapping are lateral thinking techniques.
The results of these techniques are a large pool of ideas which can later be reviewed more thoroughly.
Regardless of the lateral thinking technique used, there are general guidelines that we can use to encourage the process:
- Creative thinking is not an inherent talent. It can be learned and improved upon by anyone.
- Creative thinking requires us to believe we are creative (self-perception), so encourage, reinforce, and reward creative thinking in the project team.
- Creative thinking is usually enhanced through a group setting rather than an as an individual activity.
- Do not criticize or judge any initial ideas. All ideas, even the silliest and absurd, should be welcomed.
Once the scope is approved and the WBS and WBS dictionary has been created (in section 5.3), the scope baseline comes into existence.
The scope baseline is the collection of the approved project scope statement, the work breakdown structure, and the WBS dictionary.
All project baselines are the current plans that have all approved changes incorporated into them.
Once these documents are approved in some manner, the baseline is created, which just means that any further changes must go through the change control process.
Baselines are not the original plans. Though this may seem illogical at first, an example may help us better understand baselines.
Imagine that we originally planned for a low-budget surprise birthday party for a friend and had invited five other people.
It was going to be held at our home and everyone was going to chip in and bring food. The entire event was only going to take two days to plan and cost no more than $100.
But later everyone agrees that the guest of honor deserves a bigger party, and so it's now going to be held at a restaurant with dinner and drinks for 50 guests. The party is going to take us seven days to organize and will cost $5,000. The big day arrives and everything comes off exactly as planned.
Was our project successful? If we look at the original plan compared to what actually occurred, it took us 350% longer to execute the project and we exceeded our original budget by 50 times! However, the original plan is not what our comparison should be based on because the scope of the project changed midway through.
Our comparison should be based on the seven-day schedule and budget of $5,000. The purpose of any project management baseline is to provide measurements of the approved plans.
We want what's currently been agreed upon as our measuring stick, and when we do this with the example since the original plan was altered and agreed upon by all the stakeholders and we performed exactly as we expected, the project should be considered a success.