Finding the Practical Middle Ground to a Project Management Approach

By Daren Tucker, PMP, CBAP, PSM, Prosci, Senior Consultant at Navigator
By now, most of us have learned that a single project management approach does not work for all projects.  We have learned that rarely are we able to approach each project in the same manner. We have learned that often times, the success of the project is determined by how well we are able to adapt our approach to each project.
What are the options available to us as we approach Project Management? 
The Project Management Institute (PMI) and, in particular, the Project Management Body of Knowledge (PMBOK) has defined project management in somewhat of a prescriptive, rigid approach that has been defined as a “Waterfall.” We all know the steps: Initiate, Plan, Execute, Monitor & Control, and Close, which (aside from Monitor & Control) are conducted sequentially. 
An alternative that has gained widespread traction is Agile. Agile is a mindset or movement; more than a strict methodology.  While this mindset grew out of software development, it is an approach that can be used across industries and project types. At the core of the Agile approach is the Agile Manifesto, which consists of the following value statement:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and Interactions over process and tools
Working Software over comprehensive documentation
Customer Collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

The Manifesto is supported by twelve principles advocating the importance of satisfying the customer, rapid and frequent deliveries, adapting to changing requirements, teamwork and collaboration, and continuous improvement.  There are many specific methodologies that adhere to the Agile principles, including Scrum, Kanban, Extreme Programming, Paired Programming, Lean Development, Rapid Application Development, Feature Driven Development, Mob Programming and others. Many clients have defined their own approach to Agile, incorporating parts of several of these methodologies. 
In a practical world, what does all of this mean to a project manager? Do we get to eliminate our project plans? Do we get to disregard our project charters, communication plans, or test plans? Probably not. However, the way we approach the development of these documents, while at the same time producing real value - like working software - is where the real project management value lies.
So does every project have to be either Waterfall or Agile, and how do we decide?  The first thing to remember is that no two projects are alike. They can certainly be very similar in terms of scope, budget and timeline. However, they could be very different in terms of location, team members, product owners, or the current market environment.
To point us in the general direction, we can consider the following: 
Agile is best suited for situations where:
  • The final solution is not clearly defined;
  • Stakeholders need the ability to modify the scope; 
  • Changes are anticipated throughout the project; or 
  • Rapid, iterative deployment is the goal.
Waterfall is best suited for situations where:
  • Changes are not expected and scope is defined;
  • Requirements are well-known and fixed;
  • Stakeholders have a clear vision of what they are looking for; or 
  • The project is predictable.
PMI defines these in a graph, where projects falling into the lower left lend themselves to Waterfall approaches and projects to the upper right lend themselves to more adaptive (Agile) approaches. In many instances, we find ourselves falling into a hybrid framework because projects do not fit neatly into either specific approach. 

Many of the projects we have worked on have not lent themselves to iterative production releases as would be expected in a pure Agile approach. Typically, they were replacing an existing system, which could not be done incrementally, but in a manner where the old system is shut down and the new system went live concurrently.  In these cases, we were able to realize the benefits of an Agile approach with an iterative planning and development process, where the Business Analysts worked ahead of the development team, by creating and maintaining a backlog of at least three sprints worth of groomed and prioritized requirements.  The deliverables in each iteration were individually tested as a part of that cycle and then combined into a full release build in advance of training, User Acceptance Testing and implementation, as in a “Waterfall” approach. 

The approach looked something like this:

Whether a project manager chooses a Waterfall, Agile or some hybrid approach to execute a project, this is a decision that is made early in the project planning effort, and should be based on the project scope and complexity, as well as the client’s project maturity, flexibility, and tolerance for risk. 
Navigator has developed our Beacon Project Management Methodology to increase project success. It is not a prescriptive approach to project management, but rather, it is a framework and toolkit of proven deliverables for managing projects that can be adapted to fit any client, situation, solution, project or requirement.

Contact us at