Project Requirements, Scope, and Deliverables: the Purpose of a Project
A project is generally defined as organized, time-based work for a specific aim. This can include individual or collaborative activities. But projects always aim to deliver a product, process, or solution.
Every project team faces how to get from requirements to scope to deliverables at the start of their project. This is true whether you're using agile or waterfall project methodology (or anything else).
Get your Project Started with the Requirements Funnel
By understanding what you're going to do and what success looks like. You can build a plan, a budget staffing schedule, and everything you need to run the project.
It is good to think of Requirements, Scope, and Deliverables as a funnel. You collect all requirements, distill them into the needed scope, and then refine them into clear Deliverables the project needs to deliver.
How to get the right Project Requirements
Requirements are essentially the wish list for the outcome requirements that can be given by users, the ultimate owner, the support team, or the customer.
It's good to get a broad understanding of the requirements. Include all of your stakeholders. This may include the
product owner
users
customer of the users
support process roles of the users
design team
technology team
support team
The goal is to understand the ecosystem in which the target requirements will work and how that impacts upstream and downstream processes, people, and technology. And how those other teams support the outcomes needed to make sure the Product is supported and succeeds in its goal.
Example: The Product is a new business process for a Customer Services Team of users serving customers. This Team is responsible for customer satisfaction and issue resolution. But they cannot do it alone. They need the help of support from other teams using their own rules, processes, and technology in Accounting, Order Management, and the Call Center. When shaping the new Customer Service processes, the related Team's working methods need to be considered so that the new process will work within the larger systems (of people, processes, and technology) currently running.
Using a Workshop approach can be a good way to start collecting requirements. This allows your various stakeholders to create a shared understanding of the
the project outcome (or Product)
the User of the Product
the support systems, people, and processes needed to maintain the Product
and the requirements for the Product.
How to Collect Requirements
Make a list of the Roles and People who need to contribute.
Plan a Workshop and create a document to share your approach
Run the Working session to understand the person who will use the Product (User), the person who will benefit from the Product (Customer), who needs to support the Product (Service), and who needs to align with the Product (other Departments)
Ask for Requirements
Group the requirements by type, look for conflicts (ideas that don't work together), connections (where two or more ideas improve the requirement), and collisions (where two or more ideas create an opportunity for a new concept).
Prioritize the Requirements
Review the full list of Requirements to ensure if put together. These would create a logical and whole Product (a solution that can stand on its own)
Note requirements that create precursor work (such as a field that needs data or a process that requires a change in another department)
Note Risks and Assumptions
Share the list with the key stakeholders and ask for a confirmed list of the most important requirements.
Create a Storyboard or Product example based on the prioritized requirements.
Test the sample product with the end-users.
A workshop will help your Team understand and assess the User and Product. This helps the Team confirm that requirements are logical, linked (they relate to each other), and confirm at least some of the criteria needed for the net phase: Scope.
How to define your Project's Scope
How to manage a project: Limit its scope. Make it Simple, Get Success, Then iterate
- Auren Raphael Hoffman, entrepreneur and angel investor
The Scope is the goal. It is the sum of the requirements you're putting into the final Product. The work the Team is committing to is more than just the core product. Understand the Proudc or solution specifications, but also be clear about the related Scope, such as:
Product Build documentation
Testing documentation
Training and training documentation
Communications
Product sign-off processes and paperwork
Team management and skill-building (if needed)
Scope optimally makes the product goal tangible, clear, and attainable.
Of all the things I've done, the most vital is coordinating the talents of those who work for us and pointing them towards a certain goal.
- Walt Disney
The Scope also includes naming what you will not be doing as part of the work. This is especially true when there's a "grey area." A type of work or functionality that may be included but was not included. If some work is planned for future phases, name it and document the planned phase. This is helpful if design work needs to include future design ideas, but the build will focus only on the in-scope work. Outcomes that don't fit the project goal should be considered out of Scope.
Confirm the Project Scope in the Project Charter. Document:
Quality metrics that can be measured and meaningful to the final Product. (e.g., test requirements)
Product Specifications (e.g., speed, efficiency)
Outcomes of the Product that are important to the stakeholders (e.g., KPI goals based on staff reductions or improved services)
Confirm the final Deliverables
Deliverables are what you will provide at the end of the Project. They are based on the final Product or Solution, but as with Scope, Deliverables can be much broader. It is a good idea to create a checklist to help you know what :
What you need to Deliver
How you will Deliver
Who on the Team will oversee the Delivery
When the components are due to be Delivered
It is also helpful for the Project Manager to understand why deliverables are needed. The team leader needs to understand the purpose of each required document and outcome to ensure it is done correctly.
Make sure each deliverable is tagged as such. This includes workpapers, product designs, build specifications, testing, and training documents. Secondary documentation of the Project may also be considered a deliverable. If it is, you will want to know this in advance and prepare a summary of the Project Plan, Budget, and documents related to stage reviews and other decisions made during the Project.
If the Project requires regulatory or steering committee sign-off, ensure you know the steps, requirements, and dates for this work. This effort will need to be staffed and estimated as part of the project costs.
Starting with the end in mind when it comes to Deliverables will help the Team understand the project goal and allow the Project Manager to plan for the complete Scope of work required by the Project.
The process from requirements to scope to deliverable is an ongoing issue. Changes can come up mid-project. Setting up a Change Control process is key to maintaining the Project's integrity and the final Product's value. Consider creating a user steering committee to review all change requests. This will help you protect the Project. Ensure that changes to the Requirements, Scoper, or Deliverables are documented, assessed, and approved by the Product Owner.