Or more conventionally – The map is not the terrain.
This is an old quote attributed to Alfred Korzybski which is highly appropriate to my current client, as we make Charts of the oceans. They will be the first to agree that a chart is not the topography.
Charts can and frequently go out of date and so frequent updates of changes have to be notified to mariners promptly. In response to the Titanic disaster there was an international convention for the Safety of Life at Sea and now all larger ships are legally required to carry the latest charts and to keep them up to date in response to warnings. But even with an up to date chart no mariner would blindly assume it covered all hazards or was completely correct at any given point in time. Sands shift, sea beds may have objects that drift, some hazards may seem too small to note at some scales, some Hazards are temporary, etc.
The expression though is a warning to planners and navigators that the information they are using to plan is a simplified and likely an out-of-date illustration of the terrain. Navigational charts will often come with additional advice on approaching ports or other hazards but none can confidently claim to cover everything accurately.
Have you ever used a Sat Nav and found it taking you a convoluted and often much slower route because the pathfinding thinks a particular route looks shorter but is actually a narrow country lane that has limited passing places, I’m sure we’ve all see photos of trucks stuck in a narrow road as a result of following a map (or Sat Nav) without really understanding the terrain.
When planning a project you gather information to help you make the plan but here is the challenge of all planners:
- If you try to cover every detail, every eventuality and every hazard it would likely take you as long as if you acted out the plan, probably longer as you would be mapping potential avenues that are never followed.
- If you over simplify the plan you may omit key information and as in the case of the Sat Nav missing something crucial like a bridge being closed could throw the plan entirely. Making it difficult to stick to a plan.
- If you plan from an illustration it is difficult to truly anticipate how long the actual journey will take.
Accurately planning for a team, large or small requires that you understand in detail both the journey and the team.
So how is it possible to get a team to successfully follow a detailed project plan?
In a rather defeatist way, my answer is that it is not possible, or at least not consistently.
In waterfall projects the normal solution is often to add huge amounts of contingency, if I think it is a 6 month project call it 12 months etc, have milestones to regroup and get back on track, but contingency when not needed is waste and in waterfall contingency is generally consumed. But contingency is in essence a form of planning based on an assumption that our plan is flawed – which it likely is, but hardly efficient.
We may also throw more staff at a plan or change scope or move dates the usual reactive crisis management that occurs when a Waterfall project is running late, but all of these are the result of a flawed plan, and in my experience the longer the plan duration the more inaccurate it becomes.
So if it is not possible to successfully plan a complex project why bother?
Essentially what I am saying is that Eisenhower hit the nail on the head when he said
“Plans are useless, But planning is indispensable”
In Agile terms, my advice is to set a clear Vision, we absolutely must know where we want to go, and then simplify the plan into high-level objectives, and then prioritise them. Flesh out the detail of the highest priority item, and begin to explore more detail on the next highest priority and so on. Have a plan that has the minimal detail and expand it as you go and be prepared to adjust. Agile projects have the wonderful tendency to separate the wheat from the chaff and you will get a much leaner solution, lower priority features are deferred until later and often dropped altogether.
If we return to a voyage analogy if I were planning a voyage that involved multiple stops, I’d want to know the final destination and the major ports on the way perhaps an idea of key navigational way points, I would eventually want a detailed chart for each stage of my journey but I don’t need to study them yet (the charts may change or perhaps I will need to add a stop or skip one), the detail only matters when I reach that point. Right now all I need are detailed charts for the current stage, so long as I can plan that part of the journey I can proceed.
“But I’m a Project Manager and I need to know how long the project will take.”
If you have been nodding along with me as you read this you will be in agreement that the notion of accurately planning a complex project is a flawed concept, and that your previous attempts to predict project duration inevitably result in inflated estimates to cover contingency and you are not competitive. So the question becomes one of “do you really?” Or “why do you need to know how long it will take?”
Generally this falls into a number of categories:
If you are planning a launch date and it must coincide with another particular event then this may seem to be a reasonable request, but the question isn’t really one of how long the project will take, but one of how much can be completed by that date? Can it be delivered in phases? What is the MVP? How fixed is the date? Could it slip? Could it be deferred? What are the consequences if we are late?
The best advice would be to defer planning the date as long as possible if content (MVP) is critical, or to ask yourself if you are willing to adjust scope, and or cost to meet the date? It is rare to find a project where 100% of the requested features are truly mandatory on a particular date and when that is the case it is unwise to have a fixed delivery date.
2 Return on investment
More often the usual reasons for wanting a plan are because of cost constraints or price/profit related issues, neither of which are helped by an inaccurate plan. What they mean is “How can I predict if this project be profitable?” or “I’d like an estimate for how much is this project going to cost me?”
In all cases where Scope, Time or Cost are a limiting factor Agile planning and Agile delivery should mean that you get the highest Business Value items for the lowest cost, and that you will know at the earliest possible moment when there are issues that may impact on the success of the project. The aim is to deliver value at the earliest opportunity, in theory this is the most efficient and therefore most profitable/lowest cost solution for the given parameters. And if the project fails it will fail quickly for the lowest cost.
Agile doesn’t guarantee success or profitability, but when applied well it maximizes the value of successful projects, and perhaps more crucially in commercially driven projects it enables mitigation of failures at the earliest opportunity.
But you will have spotted that doesn’t answer the question: An estimate is a different matter entirely – see Estimates – Planning and estimation are frequently confused and shouldn’t be, but that is another topic.
3 Resource allocation
There may be other projects and you may want to predict when the team will become available, but assuming you are working on the highest priority project then your team is being utilised in the most appropriate way. Programme planning, like project planning is better done at a high level for the future and only becoming more specific as the task draws closer. If there is a dependency then see above, otherwise trust that the project will be completed as quickly as possible and can move on to the next task at the earliest opportunity.
There is nothing wrong with planning, planning is vitally important, the mistake is relying on a flawed plan, rigidly sticking to it in the face of reality.
Plan with the expectation that your plan will change.