Project plans and planning are inevitably a part of any project initiative. In almost all enterprise environments projects are next to impossible to initiate and to execute without a plan.
By “plan” I mean any artefact that attempts to define the current and future activities and outcomes for a project.
I know there are many who don’t support the idea of a forward looking or deterministic plan, but even those who don’t follow “big plan” methodologies recognise there is value in some level of planning. And in fact very few plans at all ever produce the level of certainty that their stakeholders would wish them to provide. This post focuses more on the communicative and predictive purposes which attempt to answer the questions: “is the project going to complete on time?” and “how do we know what is going to happen?”
Regardless of any “standards”, e.g. from a PMO, that might dictate the ideal form and function of a plan, the actual plans that are used day-to-day evolve pragmatically around local stakeholder drivers and influences and are often the lowest common denominator of all inputs that the project can get away with. Very few plans ever get to the stage where they “lead” the project and can be put to use as predictors of the future or can drive discussions about what might need to be done differently to maintain a desired outcome. Most plans are “trailing” plans that document changes or conclusions that have been made elsewhere on other criteria.
There seem to me to be several repeating patterns. Below I’ve outlined a list of the types of plan that I’ve seen and used in the past, with some thoughts on their pro’s and con’s, and also perhaps why they survive.
Top-Down Fixed End Date Plan
The type of plan that starts with a Senior Executive imperative: “You must launch this product on the day of the company annual general meeting”. The level of detail in this type of plan is fairly low, since the detailing of the plan stops when the executives stop asking for more information. This type of plan helps with stakeholder orientation , but it’s worse than useless as a forecast: everything from current date to the future is structured to show no slippage in the end date. The purpose of this plan is survival: of the project, of the key stakeholders and the project team.
Aspirational Milestones Plan
Similar to the “Fixed Date plan” above, this plan type consists of a small set of milestones created to communicate commitments and to show the project achieving its dates. It is useful at the level of communicating known tasks, but it doesn’t describe what people are working on in any reliable way. It describes what stakeholders are prepared to have publicly communicated that they are working on. This plan contains neither understanding of how to achieve the milestones nor real commitment to hitting them on the dates indicated. Issues in the intermediate milestones, e.g. forecast date slippage, don’t impact later milestones in any forecast-able way. They are updated when reality shows that they cannot be achieved.
Keep Buggering On (KBO Plan)
This type of plan is based more on overall goals than on a tasks or deliverables or dependencies, although it can be expanded to accommodate them when it’s useful. Tasks and milestones are set based on the best available information at the time the goal is set. This plan is a “mud map” that guides relentless investment and commitment by the team to acheive the goal, but it provides little guidance in exactly how it will be achieved. The team just keeps on keeping on working the plan and doing their best to achieve them, adjusting and adapting as they go. The team members neither believe nor disbelieve in the plan itself, but they are very much invested in the end result; there’s usually no question of people’s commitment or work ethic. This type of plan can suffer the same problems of intermediate milestone slippage as the “Top-Down Fixed Plan” and the “Aspirational Milestones Plan”. But if the level of engagement and investment in the milestones can be increased then it can become more reliable. (Btw, thanks to Winston Churchill for the name)
Bottom Up Plan
The Bottom Up Plan starts with low-level detailed tasks, deliverables etc and aggregates them into larger tasks or task groups. These are in turn aggregated up into larger task groups and so-on. This type of plan has a lot of upside value because the tasks and estimates mostly come from the teams and organisations that are doing the work. The value of the plan is the discovery and validation of the real set of work to be done, deliverables to be produced and dependencies. It’s downsides are largely twofold: it is time-consuming to create and maintain, and some tasks are hard to make detailed without invention. For example It becomes difficult to represent highly variable but repetitive tasks such as Testing. Also, depending on how bottom-up the plan is, these type of plans almost always over-estimate resource needs, which is fine as long as everyone understands.
Jackson Pollock Plan
The Jackson Pollock Plan is a detailed plan that doesn’t follow any particular organising structure. This type of plan is extremely detailed with very fine-grained tasks and milestones. Extensive use is made of the specific features of whatever scheduling tool is being used, e.g. MS Project schedules will show extremely complex sets of dependencies that to try to model the real world exactly. This type of plan becomes rapidly unwieldy and out of date. Typically no-one who is asked to use the plan recognises much in the way the plan has been defined. And the PM has to spend an inordinate about of time maintaining it. The “beauty” of this type of plan is only apparent when standing some distance away.
MBA Assignment Plan
This is a plan that is designed to be assessed (or “marked”) according to some theory of practice. It is not necessarily designed to be used. The plan inevitably includes phases and tasks and deliverables that are recommended in textbooks but don’t actually get much practical traction. The non-schedule parts of the plan (e.g. PMP) will contain lots of explanation and rationalisation about the reasons the plan is the way it is etc.
PMO Template Plan
This type of plan is very similar to the MBA Assignment Plan, but in this case is designed to show compliance with an established PMO methodology and/or process for projects, rather than be used. This plan usually places great emphasis on events and tasks that are of relatively little importance to the PM (e.g. review and governance processes).
Single Point of View (PoV) Plan
A plan that has been created based on one organisation or person’s Point of View (PoV). Often this is the Project Manager, who falls into the trap of defining tasks based on what s/he think is (or should be happening). But usually this usually occurs in projects dominated by a larger team such as an engineering team that sees the project falling wholly or majorly into their domain. Example: “you’re not running a project; networks is doing a component upgrade, and we’re following our plan for exactly that”.
Where Agile meets ingrained PMO practices you will most commonly find the Sprint-based plan. This type of plan identifies the functionality that the project is to deliver in the project and distributes this functional deliver over a number of sprints. This type of plan is also useful in a hybrid Agile/Systems integration project in which the sprint-developed code must interface with other systems that are modified by more traditional skills. But the huge downside to this kind of plan is the inevitable “clash of cultures” between Agile teams and the PM, especially if the Agile variant has a very negative view of planning and forecasting. I’ve used these plans in the past with the caveat “our mileage will vary” to highlight the inevitability of change, but they fall into the “Aspirational Milestone” category.
And lastly, just for completeness there is using no plan at all to run projects. It is the planning equivalent of the #NoEstimates movement. Having a #NoPlan obviously has the benefit of no work required. Leaving aside the methodological drivers, this type deprives your team of the ability to objectively test planned activity vs actual behaviour. On the other hand, in very rare circumstances a plan can make the project go materialy slower, so in this case a #NoPlan might be indicated. I can tell you from experience, this is a tough sell..Typically this isn’t acceptable to many stakeholders (notably management), and under pressure the #NoPlan will evolve to an something else, typically an “Aspirational Milestones Plan” or a “KBO plan”. It seems there’s a fixed view that the absence of a plan means a badly run project.
Can you think of more? in reality any given plan is likely to be a combination of these types, with all the aggregate strengths and weaknesses of their composite types.
Which do you use? Or should you use? More on that in another post. But the short answer is “whatever works”.