MaRS Library The product release and the project triangle: Scope, cost and schedule
Working toward a product release
If you are working toward a product release, your first will have been to:
- Outline which product requirements to build
- Prioritize your product requirements
- Understand the effort required to deliver them
Once you have completed these steps, you will have compiled a list that will serve as the basis for a product release.
In most cases, the list will be prohibitively long. If you were to tackle every item on the list, the release could take years to complete.
Armed with the data on your product requirements, in priority order, you can decide how you would like to deliver your release. Consider:
- Do you want to release your product on a particular date?
- Would you like to deliver a particular set of product requirements?
- Do you want it all?
Most people would like it all, but this is not possible.
The project triangle (scope, cost and schedule) in project releases
Every product release has three variables (or levers), which are known as the ”project triangle”:
- Scope —the requirements that should be built
- Cost —the number of people (or amount of resources) involved in the project
- Schedule —when the project will be delivered
When deciding what to include in a release, you will only be able to move two of these three levers at any one time:
Scope and cost
If you have a set number of team members, and you want the full scope of your list of requirements, then the effort needed to deliver the full scope will determine the release date. This means letting the requirements drive the delivery date.
Cost and schedule
If you want the release to occur on a particular date, and you have a set number of team members, then you will have to reduce the scope of the requirements. This means cutting requirements from your list.
Scope and schedule
If you want the release to occur on a particular date, and you want a particular scope, then you might have to add team members. This means hiring extra people.
The project triangle is a constant. Your team might believe that they can deliver on the full scope, and do it on schedule with the existing team. However, when the release date begins to loom, things will start to slide (that is, either the date or the scope).
One area that tends to suffer when trying to achieve all three (scope, cost and schedule) is quality. Testing time gets shortened, and releases are of lower quality. When good testing does not occur, it tends to take much longer for a feature to be considered complete as it will need revisiting at the time of future releases.
The project triangle in product development methodology
Once the scope of the release has been set, the development team will begin building. Depending on which product development methodology you employ, the project triangle will be in affected in different ways:
- Agile methodology: This approach to development decrees that the most important work is done first, in small incremental iterations. The list of priorities is set by the product manager. When using the Agile methodology, the cost and schedule are usually fixed, while the scope is adjusted as iterations are completed.
- Waterfall methodology: This approach to development relies on research and design being done in advance, with the work later completed in phases, like a waterfall. The intent here is to estimate the work and resources ahead of time (from the list of prioritized requirements) so that the schedule can be set; the aim is have all three levers of the project triangle fixed in place. However, if anything changes in the project (and something always does), one of the three levers will have to be adjusted in order to reach the project goals. For example, if the end of the project is nearing and the full scope is not completed, the team may need to add resources, or face delays.
Each product development methodology has its advantages and disadvantages. It is up to your organization to choose which method will work best for you.
For more information on product requirements, refer to the other five articles in this series:
- Creating product requirements
- Validating product requirements
- Prioritizing product requirements
- Understanding the cost of product requirements
- Product requirements template
Chatfield, C. & Johnson, T. (2003). Microsoft Office Project 2003 Step by Step. Microsoft Press.
Waterfall vs. Agile Methodology. (2010). Agile Introduction for Dummies. Retrieved August 9, 2010, from http://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile-methodology/