I recently participated in an online discussion in response to a question that was asked on “What are the most practical ways to do project planning?” It’s a critical issue and it comes up a lot so I thought I would share some thoughts on this subject.
Factors to Consider
In my opinion, there are two very significant factors in determining what planning approach would make the most sense for a particular project:
The level of uncertainty in the project is probably the most important factor. If there is a high level of uncertainty that cannot easily be resolved, it would probably be foolish to try to develop a highly-detailed, plan-driven approach. An example would be attempting to find a cure for cancer. It would probably be foolish to try to develop a detailed plan for that effort, there’s just way too much uncertainty. That doesn’t mean that you wouldn’t do any planning at all. You would take stock of what you know and don’t know and try to develop at least a cursory plan based on that information and then continually revise the plan based on what you learn as the project is in progress.
2. Customer Relationship
The second major factor is the relationship with the customer. If you have a contractual relationship with the customer where the customer is expecting a firm set of deliverables for a given schedule and cost, you might be forced into a planning model to try to effectively manage and satisfy those customer expectations. If there is more of a collaborative relationship with the customer, you probably have a lot more ability to optimize the approach based on the level of uncertainty in the project.
Obviously, there may be a conflict between these two factors. I’ve created a diagram below to show some of the possible combinations of these two factors:
Lets look at each of these quadrants individually:
1. Low Uncertainty, Contractual Relationship
This is the area that most project managers are most familiar with and it is the area that is most well-suited for a traditional plan-driven project management model. In this area, the level of uncertainty may be low enough to permit developing a detailed plan that is consistent with managing customer expectations in a contractual relationship model.
2. Low Uncertainty, Collaborative Relationship
If the level of uncertainty associated with a project is low, you might develop a more collaborative relationship with the customer but that might not be the most efficient way to do the project. If the level of uncertainty is truly low and it is relatively easy to define the project requirements upfront, it may not make too much sense to engage the customer too heavily in a collaborative relationship to further define detailed direction for the project as it is in progress.
3.. High Uncertainty, Collaborative Relationship
This is the area where an Agile approach makes sense but the success of that effort will generally depend on a collaborative relationship with the customer to make it work. In this area, instead of trying to develop a highly-detailed upfront plan prior to starting the project, you would probably:
- Reach agreement with the customer on at least a vision for the project and at least some higher level objectives and requirements that the project must meet, and
- Then further elaborate those requirements and the plan for meeting them as the project was in progress
It’s easy to see how this kind of planning model may not work well unless there’s a collaborative spirit of trust and partnership with the customer since:
It may be almost impossible to accurately define the costs and schedule for completing the project prior to starting the effort; and
- Further defining the plan as the project is in progress requires a close working relationship with the customer.
4. High Uncertainty, Contractual Relationship
This area is the quadrant that is likely to be most problematic:
- Attempting to do an Agile project with highly uncertain requirements without a collaborative relationship with the customer is not likely to work very well:
- The customer may not be committed to actively engage in the project as it is in progress to help elaborate and resolve questions related to the requirements; and,
- As a result, the project may either get stalled or go off in the wrong direction
- Attempting to apply a contractual, plan-driven approach in this kind of environment is also likely to be problematic. There would likely be a very high risk associated with trying to develop a firm, plan-driven contractual relationship based on highly uncertain requirements. What is likely to happen is:
- The project meets the defined requirements but the defined requirements were wrong, or
- There are so many changes as the project is in progress that the scope of the project winds up being completely different from what the customer was expecting
It’s easy to see how either of these scenarios might present a very high risk.
Of course, this is somewhat of an over-simplification and all projects don’t fall very neatly into one of these quadrants. There is a very broad range of scenarios in the middle of this diagram that call for some kind of hybrid approach.
What are the Most Practical Ways to Do Project Planning?
There are a number of conclusions that I think we can draw from an from understanding of this model:
- There is not just one way to do project planning – Project Managers who have been heavily indoctrinated in a traditional, plan-driven model and attempt to force-fit all projects to that kind of planning model are likely to not have optimal results
- This is not a simple binary and mutually-exclusive choice between an Agile and traditional plan-driven planning model; it is much more complicated than that. There’s a whole spectrum of different possible scenarios and it is a multi-dimensional problem
- The right approach is to fit the planning model to the nature of the problem based on the level of uncertainty and the relationship with the customer. Attempting to use a single “one size fits all” planning model for all projects is not likely to work very well.
This creates a big challenge for project managers to learn how to blend an Agile and traditional plan-driven approach in the right proportions to fit a given situation. And, that’s not an easy thing to do – PMI still treats these two areas as separate and independent domains of knowledge with little or no integration between the two. This is exactly the challenge that my Agile Project Management training is designed to address.
You will find much more detail on this in my Online Agile Project Management Training.