Project planning is focused on answering the questions, what needs to be built, when it needs to be completed, how much will it cost, and who needs to be involved. As project managers, we also want to know any dependencies between activities so we can minimize idle time and optimize the schedule.
The conventional wisdom is that estimates improve as the project progresses. Barry Boehm was the first to graph uncertainty levels at different stages in the life cycle of a high-tech project in 1981. The result later was nicknamed “the cone of uncertainty” by McConnell (2006). The idea behind the cone is that at the start of the project there is significant uncertainty about “what” needs to be built. This makes it very hard to answer the “when will it be completed?” and “how much will it cost?” questions. While the project progresses, the project team gains a better understanding of what it needs to build and how they are going to build it. As a consequence it becomes easier to estimate the completion date and project cost, therefore lowering the uncertainty of the estimates. Of course, at the end of the project there is no uncertainty anymore, just reality.
Agile and traditional project planning deal differently with this uncertainty. Ultimately the goal is to create a project plan that moves the project from its initial state to where the project meets the project objectives. The traditional project planning approach creates a project plan by following several planning steps. These steps include:
- Determine the project objectives
- Collect the project requirements
- Define the project scope on a work level
- Identify dependencies between activities
- Estimate work effort and dependencies
- Prepare the overall schedule and project budget
- Receive approval
- Baseline the plan
Traditional project management assumes that projects are managed within certain constraints. In project management, these constrains are often referred to as “the triple constraint.” The PMBOK® Guide (PMI, 2004) refers to the triple constraint as “a framework for evaluating competing demands.” The competing demands are often illustrated as a triangle where each side or corner refers to one of the constraints that are applied to manage a project.
Exhibit 1 shows illustrations of the triple constraint triangle for a project. Quality is often assumed to be fixed, and therefore many organizations forget to make quality requirements a part of their scope, cost, and time planning analysis. We assume that quality affects each of these constraints and has to be taken into consideration by all constraints.
Exhibit 2: Project key constraints definitions (PMI, 2004)
Understanding how to manage a project within these constraints can make the difference between project success or failure. The constraints are related to and dependent on each other. A change in one constraint has an impact on the others (Koppensteiner, 2008). Often, changes are related to scope changes or alteration of deadlines. Adding functionality to the scope would require increasing the budget to fund additional resources in order to keep the deadline and satisfy the quality criteria. If both budget and deadline cannot be changed, scope has to stay constant too.
Suggested Read: Agile principles and the project management constraints
In traditional project management approaches, project execution would start after receiving approval for the project scope, timeline, and budget. Throughout the life of the project, progress will be measured against the baseline plan. The approaches deal with uncertainty by implementing a rigorous control process. Any significant changes to the project scope, timeline, and budget will need to go through a change control process and approval before being incorporated into the plan.
This stringent change control process coupled with long development cycles has created a customer mindset that all requirements need to be part of the project scope (e.g., in form of specifications) from the start of the project, since it is so hard to change anything after the project has started. The customer views development as a black box: they provide their requirements at the start of the project and then have to wait until the end of the project to see the results. When change happens or is needed, it takes a long time to be incorporated in the project. As a result, a customer is likely to receive a product/service that fulfills the specifications and not necessarily his needs at the end of the project.
Agile project planning acknowledges the fact that the scope will change throughout the project. It believes change is inevitable. Only the scope of an iteration is fixed. This means the customer can change the priority of their requirements and add or remove requirements after every iteration. This provides the customer with a great deal of flexibility and also makes them part of the team throughout the project. Of course there are limitations to the amount of change the project can absorb, based, amongst others, on chosen architecture: if you were planning to build a two-story building and halfway through, the customer then wants it to be a 15-story building, you will have to start from scratch.
The project team makes detailed estimates for the functionality implemented in the next iteration only. Agile project management recognizes that scope, time, and costs will change as part of iterative planning activities. From a triple constraint perspective, agile projects can be considered time-“boxed,” as each iteration of development has the same duration; the resources can be assumed to be somewhat flexible, and scope is most flexible.