How important is planning?

Planning is critical. Without planning there is little chance that you can every complete your project, let alone complete it on time.

 The act of preparing a plan, if done correctly, will uncover the issues and risks, provide the bulk of key data for your estimation efforts, provide a clear view of what resource is needed when and lots more.

 It will also help to discover the dependencies that may exist with other projects and activities.
Once prepared, the plan gives the team a better view of how their efforts will come together and points out the need for communication in critical areas.

How important is the plan?

Much less important than the act of planning, but still very important. The reason I say this, is because:

1)  It is rare to be able to complete a first draft plan and then not have to make any adjustments.
Most plans develop as they go along and reach a baseline when well into the project timeline.
The most obvious examples of this are projects that involve investigating a problem designing a solution and then finding suppliers to deliver it.
You can allow extra time at the start in the hope that it is definitely too much , but even then, the chances are that you will end up adjusting your plan.

2) Risks and opportunities are a part of every project plan. Sometimes risks come to fruition and they affect the plan profoundly, sometimes opportunities come along that are either too good to miss and causes change of requirements, or  reveal a cheaper, or faster way to get it completed.

In either case, the initial plan will have changed. To live in denial of this as many commentators on project management still do, is a huge mistake and will always be counterproductive.

E.G. If you become so obsessed with meeting a specific date that you are prepared to pare away key features, there is a strong likelihood that the project will fail entirely. The answer is to treat the plan as a guideline and treat planning as an ongoing task.

Starting a new venture is much more volatile than starting a project, but it is also higher pressure with greater risks and a lot more to lose.  They don’t actually tear up the plan of course, they adjust it and maintain it, but the discussion served to get their point across that management is about managing and adapting on a daily basis, not stubbornly following a plan regardless.
Managing a project should be driven by the business case in the same way that a new venture is driven by reaching a profitable trading position at some point.

Critical also is the acceptance that like a start-up, many good projects are based on a strong hunch and a bit of a gamble for a wothwhile prize. This is enterprise nd without there would be no paydays.  project managers haven’t earned indemnity from this either. 

Features – Deadlines -Budgets – ROI

Here’s where it all happens.  A project will have a goal and that goal will usually be a financial one though success is not always measured in financial terms.
For the sake of this example I will assume that the project is a cost cutting exercise with a specific financial aim. Right at the beginning, the same ground rules should have been laid down such as;

• What saving are we aiming for?  
• What investment are we willing to make?
• What is the maximum our budget can rise to, or the minimum our savings can drop to.?

This latter question is best answered in terms of ROI and in fact, in most commercial organisations the answer will be worked out on the basis of how much ROI exceeds  ”Cost of Capital” in order to qualify the project as “best use of capital”. The critical thing is that it is agreed in advanced and set up as he target.

Once this understanding is in place and the variances have been explored and allowed for, the business case should clearly show the expected returns and the tolerances that are allowable.

The project now has an ambitious goal (maximum realistic returns) and realistic allowable variances. The importance of these variances is not to make the project management team relax, but to assure the sponsors that their investment is relatively safe. Projects set up this way rarely fail.

MSF, the Microsoft flavour of project management introduces a very useful concept known as the project triangle. It is a simple triangle with the three corners being occupied by Features – Resources – Time.

The significance of the triangle will be obvious to any mathematicians reading in that only one corner of a triangle can be fixed unless you want all three to be immovable.
This is why the prioritisation of concerns is a valuable part of stakeholder alignment. If stakeholders are allowed to follow their natural instincts and demand that all three corners are fixed (two fixed corners means the same thing) then there is no room for the project management team to steer the project out of trouble.

A realistically aligned project will choose one of  Time, Features or Resources to set in stone and the other two will remain free to move.  This way, if time is fixed, then a PM can choose between increasing resources, or decreasing features in order to hit the target (ROI). The decision making process can also be agreed in advance.

This example is one of the simpler ones, but it is indicative of the ills that beset many projects right at the beginning and rob them of any real chance of succeeding, or being seen to succeed.

Defining the scope/budget/resources

Once again, with the ROI in mind and the statement in the business case that based on initial studies, there is a strong likelihood of success, the task now arises to define in more detail the features required to deliver the expected benefits.

Having defined the features, accurate costing has to be worked out on the basis of supplier estimates, internal efforts and other costs, with adjustments for risk, all of which will rely on your emerging plan.
 Another sanity check at the end of this planning phase should check whether  the cost and time estimates are still within the constraints initially set for the project and whether it has a healthy amount of slack remaining to see it through to a likely successful completion.

This exercise of working up plans from draft to more detail as the work progresses from an outline business case through to a detailed contract with suppliers and a detailed plan of implementation with all the appropriate slack allowances  and a rigorous risk assessment will often take up half of the lifecycle of the project, or even more and some projects will be abandoned when it becomes obvious that there is little likelihood of success.

 The number of “stage gates” (sanity checks) should be agreed at the start on the basis of how well known the territory is and how volatile the estimation is likely to be.

The illusion that a project board can put some dates (when we’d like it done) and amounts(how much we’d like to spend) on an A4 sheet at the beginning of the exercise and that perhaps a year or more later, a project team will deliver exactly what was asked for on that sheet, within exactly that amount and on that date is really a surprising error of judgement, but it still happens and contributes strongly to the list of project failures that appear on the Standish report and other investigations.

How to go about project planning

Planning should always be done by starting at a very high and general level, involving experienced big picture thinkers and applying a sanity check before then drilling down not too far to the next level  detaiil to repeat the exercise.
Planning should always resist the temptation to go into great depth in one specific area while remaining at a high level on others with one exception.

Plans should not be in extreme detail a long way in advance, because the likelihood is that when that time draws closer you will find yourself redrawing them and the effort has been wasted.  As planning continues to drill down, a plan should be retained for each level of detail and when the detail highlights an error in the high level plan, as it frequently will, then the high level plan should be adjusted.

The commonest method of estimation to begin with is to break the project down into products.
These products can in turn be broken down further until they reach a level whereby they can be more easily estimated and planned and later assigned to teams.

Out of this comes a product flow diagram that describes the order , if any, in which these products must be completed in order to take account of interdependencies.

Calculating critical paths ( the longest path you can follow) through the products and then amongst the products, the project manager can get a much closer view of the true schedule of the project.

Using PERT to make a high level allowance for uncertainty adds a further level of sanity check to the emerging plan.

Some of the issues that commonly affect project plans drawn by the unwary include :

1. The calendar is not taken into account when calculating for tasks in the plan, e.g seasonal breaks, Summer holidays and other disruptions that happen every year.  Key personnel  disappear and dependencies become critical.
Make sure you discuss each team members responsibilities and schedule with them and get agreements.

2. Suppliers work to their own schedules and regardless of what they agree,  they will place commercial concerns first and may not follow your plan.
Ask them for their plan and question to satisfy yourself that it is thought through. If you  lead, or take part in the contract negotiations, try to place some extra responsibility on them to deliver on time, or warn you in advance.

3. Estimates from technical people are accepted at face value and in reality they are vastly underestimated 80% of the time.
Get second and third opinions, look at records of old projects and as a minimum double the estimates from the best people and use factors as high as five for others.

4.  There’s gaps between what the supplier delivers and what the internal team have allowed for.
e.g. Inexperienced people might assume that a system can arrive, be plugged in and start testing.
Clear acceptance criteria may not exist and there may be problems agreeing acceptance.
Cut over from an old system to a new one may not be catered for.
 This list can grow quickly. If you are not an experienced systems person make sure that there is one in charge of this part of the plan.

5. There may be several suppliers and communication between them may be less than ideal. Often this situation leads to gaps where nobody is responsible and the work grinds to a halt, or even enters dispute , or litigation.

Make sure you hold joint planning meetings and get sign-off to theses joint plans

6. Beware Johari’s window. What you don’t know you know is a terrible waste, so consult and consult again. What you don’t know you don’t know will come back to haunt you, so involve everybody in risk management sessions and try to be ahead of the game, have sufficient slack and keep stakeholders informed of the true position.

7. Over ambitious, or over confident plans create a sense of expectation amongst stakeholders that changes to discontent when the plan slips. Perfectly good projects are often deemed poor projects as a result of this very mistake.

Take the time to estimate risk realistically and maintain realistic slack for the high risk areas of the project.

So in summary:

1. Planning is critical and underpins everything, but it is an ongoing everyday task, not a game of snakes and ladders.

2. Managing projects is primarily about handling and working with uncertainty to remain within agreed, acceptable boundaries, not shooting a silver bullet at a precise point.

3. Planning for well known items is easy, beware what you don’t know, this is where you will get caught out.

4. Risk and opportunity go hand in hand, avoiding risk is no more important than spotting opportunity , but it requires an open mind and a fluid approach to planning.

5. Start with an achievable goal, make sure it is well understood and shared  and keep it in front of mind at all times.