Agile vs. Waterfall (Part 3 of 5). Cost, functionality and timeDigital Project Management
Welcome back to part 3 of Agile vs. Waterfall. Our first part introduced the Waterfall model and our second part introduced the agile Scrum model. In this part I will describe the relationship between the cost, functionality and time aspects of a project's execution.
If you have not read part 1 it can be found here.
If you have not read part 2 it can be found here.
Without further ado, let's dig in!
Cost, functionality and time
Like any human undertaking, projects need to be performed and delivered under certain constraints. Traditionally, these constraints have been listed as cost, functionality and time/scope. These are also referred to as the Project Management Triangle (PMT), where each side represents a constraint. One side of the triangle cannot be changed without affecting the others. This relationship is illustrated below.
The time/schedule constraint refers to the amount of time available to complete a project. The cost constraint refers to the budgeted amount available for the project. The functional/scope constraint refers to what must be done to produce the project's end result. These three constraints are often competing constraints: increased functionality typically means increased time and increased cost, a tight time constraint could mean increased costs and reduced scope, and a tight budget could mean increased time and reduced scope.
Depending what type of company/project you are working for/on two of these will be more important than the third. If it is a fixed price project cost is a constraint that cannot be changed. In that case, either functionality or time will be the one that suffers.
In other words you have three options:
- Develop a product quickly with high quality or much functionality, but then it will not be low cost
- Develop a product quickly and with a low cost, but then it will not be of high quality or have much functionality
- Develop a product with high quality or much functionality and with a low cost, but then it will take a relatively long time
Quality is not a part of the PMT, but it is the ultimate objective of every delivery. Hence, the PMT implies quality.
Many project managers are under the notion that 'high quality comes with high cost', which to some extent is true, unless amount of functionality is the parameter that suffers. In all cases, using low quality resources to accomplish project deadlines often does not lead to success of the overall project.
Like with the scope, quality will also be an important deliverable for the project.
In agile functionality or cost are usually the ones that suffer. Time is usually less of a factor because iterations continue until the team/project/customer believes the product is ready to be released. It is more about continuously getting functionality out the door so the project can stop at any time and still have a working product.
This is the end of part 3. I hope it was enlightening and you are still hanging on.
Come back and read part 4: Agile vs. Waterfall. Why Waterfall can be the best approach.
Photo by The Chef!