Agile vs. Phase-Based Project Management

By: Scott Converse

Project managers know there is no perfect way to get from the beginning to the end of a project. Methodologies, project types, team sizes, and resources are all contributing factors, but what exactly is the difference between the Agile and phase-based project management frameworks? Is one approach more effective than the other? In some ways, this is THE question when discussing project management, so let’s dive right in:

Phase-based Project Management

First, a quick overview of phase-based project management:

Initiate:
Phase-based project management excels when there is a solution that end users need and they can articulate the features, capabilities, and/or requirements. The organization that is building the solution can articulate the cost, schedule, quality, resource, and risk constraints that make creating the solution a challenge. We typically then summarize this information into a charter document and describe the scope of the project.

Plan:
The project manager, team, and decision makers for the project balance the articulated needs against the project constraints and craft a project plan. The project plan includes a schedule and a budget. This is no easy task, so don’t rush the process.

Execute and Control for Changes:
The project plan is never perfect. We use the plan for initial estimates, and to help identify if there are problems with assigned tasks. Problems that can’t be resolved quickly get escalated to issues. Issues get escalated to change requests. Change requests may or may not be approved. If they are approved, typically it changes the scope of the project. There must be this flexibility because plans are never perfect.

Close:
Once all the deliverables in the project plan have been completed and the approved change requests have been implemented, we hand off this solution to the project owner. A close out check list (among other things) shows the owner that the project is complete, and this temporary endeavor is now done. Team members can be assigned to new projects. Project owners can now harvest the benefits of this new solution. Everyone is happy because the future state world with this solution is better than the current state world without this solution.

Problems with Phased-based Project Management

No approach is perfect. Here are some problems with phased-based project management:

• What if the solution chosen is NOT the correct or best solution to meet end user needs? Then you do a bunch of work, create a solution, and no one uses it.
• What if end users can’t articulate all the features or needs they have? Then we either build an incomplete solution or we guess at what the real needs are. If we guess wrong, we’ve wasted everyone’s time building the wrong solution.
• What if the organization is unaware of the constraints that dictate schedule and cost? Those incorrect estimates then lead end users to think the solution will get done sooner or in a less costly manner.
• What if the organization is not sure how to build the solution? It might be their first attempt or there’s a new technology that has new learning curves. This leads to bad estimates and projects that exceed schedules, budgets, or quality thresholds.

The Biggest Problem with Phase-based Project Management:

When there is a high amount of uncertainty on the front end (requirements), building a detailed plan and working through that detailed plan is wasteful because of the inherit rework that will inevitably occur. If there’s a high level of uncertainty on the back end (build/test/implement), building a detailed plan is a waste because the plan will be wildly off in its estimate and there will likely be a large amount of rework and changes to the plan.

Agile Project Management: Solving for Uncertainty Using an Iterative and Incremental Approach

If you don’t know what to build or how to build it, don’t start by creating a detailed project plan as is done in phase-based project management. Rather, build a detailed plan for only a small increment of the whole solution, get feedback on that small increment, and either modify the small increment, or start building another small increment if the first one was done correctly. Continue doing these iterations until the whole solution is useable enough that you’re ready to release it to the world. This iterative and incremental approach is in many ways the essence of Agile. Agile’s incremental and iterative approach is built upon short-burst “sprints” of two to four weeks. Each sprint, or iteration, tries to build a valuable piece of the whole solution.

Feedback is used to refine the approach taken on each increment until the solution is in a useable form and can be released. Each sprint has a framework that includes iteration planning, execution, and the sharing for feedback. Each new sprint focuses on a few of the most important features to the customer. In theory and in practice, the final solution is often released before all the features are implemented in these sprints. While it seems counterintuitive to take ownership of a solution that doesn’t have all the initial features implemented, keep in mind that often some of the initial features aren’t high priority and aren’t going to be used that frequently. For many individuals, a solution that meets most of their needs now is far more valuable than a solution that meets every possible need but takes much longer and costs much more to build.

Problems with Agile Methodology:

Agile mythology is great for projects with high levels of uncertainty – like new software development or new product development – but it’s not perfect. Agile struggles when:
• Teams aren’t co-located.
• Teams aren’t dedicated to just one project.
• Teams can’t self-manage or make decisions due to rigid top-down organizational structures, cultures, or regulatory environments.
• There isn’t anyone in the organization that can represent all the different end-user needs (a product owner that isn’t knowledgeable).
• The needs of the organization (cost, schedule, and resources) are more important that the needs of the customer (features, quality, and capability).
• The solution can’t be incremental or iterative. Sometimes a solution must be one “big bang” like a bridge, a parking lot, an office move, or a large-scale, off-the-shelf software rollout.

In the end, you’ll choose the methodology that best suits the type of project you have. With highly uncertain projects, Agile fits best. For other projects that have been done many times before, phase-based is best. Both approaches borrow from each other. For example, if you do an Agile project there is a little bit of phase-based activity happening each sprint. Good phase-based project management will also incorporate feedback loops – a core Agile concept. What we just covered is the tip of the iceberg. There is so much more in the details for each approach. Learn more by joining us for Project Management: Planning, Scheduling, and Control (Online), Agile Scrum Master (Online), or Agile Product Owner (Online) to learn how to adapt these approaches to your organization’s existing software, new product development, and project management methodologies.


Scott Converse

Scott Converse teaches Process Improvement and Project Management programs for the Wisconsin School of Business Center for Professional & Executive Development. To learn more about these programs, view our Lean Six Sigma and Project Management Certificates.