If you are working toward a product release, your first will have been to:
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:
Most people would like it all, but this is not possible.
Every product release has three variables (or levers), which are known as the ”project triangle”:
When deciding what to include in a release, you will only be able to move two of these three levers at any one time:
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.
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.
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.
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:
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:
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/