Unfolding projects
Reforming Project Management Theory and Practice
Project e-Tip of the Week: In this week's Project e-Tip I suggest project managers/leaders adopt an emergent approach to planning and delivering their projects. I contrast an emergent approach with the approach of operating to a fixed baseline plan. Most projects are neither fully emergent or fixed to an original plan. We all know that. However, it doesn't keep us from measuring and reporting to a baseline. Nor does it keep us from wanting to deliver the project the way we conceived it to be. Let the pendulum swing towards an emergent approach. Let's stop fighting with the uncertainty and unknowability of the future. We can't win.
How might we go about "unfolding" a project as it progresses? How does the project emerge as it executes? In my view, this is exactly where risk and uncertainty come into play. Go ahead and create the baseline project, but then be ready for that baseline to shift as you round first and head for second, and again as you head toward third. One the way to home, you might have something completely different on your hands. New circumstances always arise that cannot be known in advance.
One might look at critical chain project management as being geared toward this. In traditional PM, individual tasks take longer or shorter than expected, and these changes impact the overall project. But with a critical chain view, the focus moves away from the completing activities per the baseline and towards doing those things which help the overall project succeed.
3 Comment(s)
This is one of the areas where we have had the most difficulty in our critical chain implementation: balancing initial detail with the level of understanding available.
From a technical standpoint, there has to be an easy way to define projects at the high level and then dive down into the details, once they are available - typically as you get near execution. Of course, given the details, you may discover an unanticipated impact on the overall project. But that is the price of uncertainty.
This sounds quite like the approach taken by eXtreme Programming in that it gives the project permission to change from what was originally requested. Typically and relentlessly software development projects are faced with changing customer priorities. As these unfold into view, there are two options to choose from. 1) Stick to the original brief no matter what or 2) Adapt to the new priorities. The latter means you will create something not previously planned for. But the results count. You have something you can use rather than a project plan which is worthless.
Hey Jack,
One of the challenges we face with an unfolding approach is with the formal systems of our company. It can be a real pain in some companies to set up the accounting for a project once, let alone keep it up-to-date. Customer contracts also constrain us. We give in to the boilerplate language that requires us to operate to and report against a baseline schedule. Yet, we have no choice but to stray from the plan as the project proceeds.
There are three things I encourage people to do:
1..set your plans at the highest possible level.
2..add detail to the plan at the last responsible moment to take advantage of what you encounter and what you learn
3..always plan with the people who are performing the work
These three steps support the emergence of a project and they still allow for the usual requirements to interact with the accounting systems and client contracts.
Thanks for reading Reforming Project Management!