Business model innovation. Transformational change. Value chain optimization. Agile project management. For us as PPM professionals, as for everyone else, the rate and scale of change as well as the demands placed on us to do things better and faster continue to grow. Yet for all this change and the levels of anxiety it can cause us, occasionally it’s good to step back, filter out the buzzwords and concentrate on basic principles. Nowhere is this truer than in the world of effective program planning.
We’ve all faced unrealistic expectations from management, or even made such requests ourselves. But fate has a way of getting its own back when you’re reminded through experience to return to the “fundamentals” of effective planning. The following six “rules” are not new, but they remain as relevant today as ever. And they serve as testament to the idea that the “new wine” of complex transformational change can sometimes best be accommodated in the “old bottles” of planning that we’ve always known.
A good plan tells a story. And the narrative arc of that story should be focused on outcomes — specific, measurable, agreed and communicated outcomes that drive the overall scope of the program and ultimately its component projects and work packages. Securing a clear overall “blueprint” of consistent outcomes doesn’t require sophisticated tools and can be done relatively quickly and iteratively. By working through a set of typical Business and Operating Model components and agreeing the current and target states of each will effectively give you a set of start and end points that can quickly tie back to measurable outcomes.
What is the incremental sequence of releases to deliver the outcomes? At this point we’re starting to “block out” our overall outcomes into smaller time phases. The keys here are to be able to describe what change in business operating capability the organization will be able to see with each release, how those changes incrementally build up to the overall outcomes and how they collectively and mutually support the benefits targets. At an overall program level, we should be able to start telling a compelling story of how all the pieces of the jigsaw are fitting together and give senior managers a clear sense of direction, purpose and focus. This is a critical outcome when dealing with complex multi-year Transformational Change.
Anyone with a background in PRINCE2 will understand the principle of product-based planning, and engineering organizations focused on Product Lifecycle Management instinctively think this way. But somehow the lure of the scheduling tool can create a habit of defining detailed delivery activities too quickly. Without a clear view of our products and deliverables (including management and governance deliverables) we can’t produce a meaningful schedule. Getting a sequential view of products and the links between them is the best way of visualizing real cross-project dependencies. It’s also a good way to “back test” that we’re still aligned to our overall capability release plans.
A coherent and comprehensive WBS that ties back to a PBS is one of the most critical (and oldest) tools in a program or project manager’s armoury. The two in combination are fundamental to defining, communicating and managing scope. (And there is a wealth of effective and easy-to-use tools now available that remove most of the legacy drudgery and can tightly integrate into most scheduling engines.) Feel free to ignore the purists who demand that a WBS should not be time-phased or linear. Having time-phased views of the overall plan, the products it requires and the work they demand makes life simpler and communication more effective. It’s also the place where we can start to identify key waypoints and milestones. And this is a good time to start to think about what delivery approach might best deliver the product — traditional, agile or a hybrid.
Apart from ensuring that we understand any corporate scheduling policies or views of consistent best practice, there are two means to success here. The first is to define (and possibly negotiate) plausible planning horizons. Despite rumours to the contrary, program and projects managers are not blessed with clairvoyance. Attempting to schedule in detail beyond an (at best) six-month planning horizon makes us hostages to fortune (and is one clear area where we can learn from our Agile-trained application delivery colleagues). Having a detailed schedule for a subset of defined work packages (and a rolling timeline for dealing with future planning packages) is important. The other thing to remember is to differentiate between “level of effort” work and true ‘task-based work.” As a rule of thumb, concentrate your scheduling attention on the latter, not the former. This is also clearly an area where we can learn from our Agile-trained colleagues on the benefits of tightly time-boxed delivery and workload allocation.
From a project or work package perspective, maintaining a clear “horizontal” line of sight, focused on the critical path, while not necessarily easy, will at least be well-known and sufficient. From a program (or even portfolio) perspective, the management challenge is compounded. It’s not enough to work horizontally in the same way across multiple projects. What’s needed is the ability to understand what’s happening vertically too, in multiple dimensions. Having a mature and secure view of real product dependencies (an area where many PMs and organizations struggle) clarifies quickly what will happen if one (or more) element is delayed. And often the tight relationship between release points and benefits realization points can quickly decouple too. Good program management requires an ability to think and act simultaneously across these different horizontal and vertical dimensions. As good as modern scheduling tools are, they will only help to clarify the horizontals on your program “wiring diagram.”
It may sound illogical to suggest that the best way to plan in these days of accelerated and ever more complex and demanding change is to “do it the old-fashioned way.” Many project and program managers will do many, most or even all of these things anyway. But experience suggests that most won’t.
Working top down, breaking the work into easily understood chunks, rapidly workshopping and iterating during development, working across the entire program community to get consensus, and getting the basic frameworks nailed before getting involved in the complexities of the schedule: these are all things that most of us have known for a long time. But it’s good to be reminded by practical experience that those old unused bottles in the corner are still perfectly capable of holding the complex new wines that organizations are creating for us.
This article was written by Stephen Allenson.
Loved what you just read?
Let's stay in touch.
No spam, only great things to read in our newsletter.
Choose your language
A monthly digest of our best articles on all things Project Management.
Our website is not supported on this browser
The browser you are using (Internet Explorer) cannot display our content.
Please come back on a more recent browser to have the best experience possible