The art of project planning

I’ve taken part in a number of big projects over the years and I firmly believe there is an art to good project planning, based on strong analytical skills and the ability to communicate well with your team and wider stakeholder group.

This guide details the principles and techniques that I believe enable effective project planning, which ultimately leads to successful project delivery.

line

If you are in a hurry, you can use the following links to jump to different parts of the article:

Iterative project planning, not one-off

High level project plan

Business goals and requirements

Running a planning session

– Index card technique

– Straw man plan technique

– Other techniques

Estimating

– The time, cost and quality impact

– Team-led estimates

– Just-in-time estimates

– Prioritisation

– Contingency

– Allowing for non-productive time

Planning assumptions

Documenting the plan

Thinking about your audience

Publishing your plan

Tracking and re-planning

The art of project planning – a summary

line

Iterative project planning, not one-off

The first step is to be clear that project planning is not a one-off process that takes place at the start of the project and then gets promptly forgotten about.

The reality is that it is an ongoing, iterative process that takes place throughout the whole project, something that you need to do every time you learn some new information, need to mitigate a risk or want to take advantage of a new opportunity.

The other important point to remember is that there is no standard template for planning projects.

This is where the ‘art’ comes into it; being able to determine which tools, techniques and processes to use for your specific project conditions is just as important as learning the latest ‘must know’ project management methodology.

Just like any other skill, this ‘art’ comes from reading, researching, experimenting and taking every opportunity to build on your project experience.

High level project plan

One important lesson that I learnt early in my career was not to try and capture every single detail of your project activities into a single planning document.

It is easy to understand the rationale for why you might want to attempt this (particularly the desire to centralise all your information and thinking in one place), but certainly for larger projects a single plan soon starts to become an administrative nightmare.

A much more effective alternative is to have different plans for different parts of the project, all living under the umbrella of a high level project plan (a ‘federal’ approach to planning if you like).

High level plan

The high level plan (also referred to as a roadmap), is the equivalent of Base Camp One in an expedition.  In other forms of management speak this plan provides you with your helicopter view, allowing you and your audience to see the overall framework of the project.

Ideally the high level plan should be pictorial, so that it can quickly convey the story of what you are aiming to achieve with the project and how you will get there.

It won’t cover the intricate details of each project stage or task. However that is not a problem, as at the start of the project you probably won’t know what those tasks are going to be.  Indeed you may not even know what all the key stages of the project will be!

But as new stages or milestones are identified during the project, you can very quickly add these to the plan.  Plus, as you are only working on rough time lines and ownership, you don’t need to waste countless hours plotting and updating intricate details each time something changes.

High level planning

For large complicated projects, the high level plan is the ideal starting point, but for much smaller projects, it may be all you need.

Business goals and requirements

To successfully plan how to do something, you need to know where you want to end up.  So another initial action is to understand and validate the goals that your organisation wants to achieve with the project, and then set about capturing some high level business requirements.

In fact these two activities are likely to form two of the first steps in your high level plan.

Be careful though that you don’t try to undertake all your business requirements capture and analysis at the start of the project, as this too is an ongoing, iterative process.

The key is to focus on breadth, not depth.  Understanding the broad scope of the project so that you can determine how to tackle it.

Knowing your goals and having a high level roadmap that shows how you will get there will provide a fantastic foundation for your project.

Once the goals are established and the high level roadmap is set-up, the project has a strong grounding to progress on, and so the ongoing activity of project planning continues with more detailed plans covering the key activities.

So lets dive into the nuts and bolts of project planning.

Running a planning session

Involving your project team in the development of the plan not only produces more accurate and rounded plans, but also helps achieve far greater buy-in and ownership from each team member involved.

Planning sessions can take place at any point during the course of the project, whether to plan a high level roadmap, a key stage or activity within the project, a response to a significant risk or issue, or to review progress and re-plan based on new learnings and changing circumstances.

Running a planning session is simply a case of getting your team into a meeting room for an hour maximum (any longer becomes counter-productive) and brainstorming the various steps that need to take place to complete key activities.

The key to a successful planning session is being able to extract the right knowledge and information out of each team member’s area of expertise.  I’ve always found the following two techniques to be very useful for this:

Index card technique

Note: This technique also works well with post-it notes.

At the start of the session give each participant a dozen or so blank index cards.  Then pose your question, which for example could be:

  • What are the key stages in Project XYZ?
  • Which stakeholders do we need to involve in Activity A?
  • What are the steps required to complete Activity B?

The participants should be allowed five or six minutes to write their ideas and thoughts down – one item per card only.

Once the time is up, get you participants to take it in turns to feedback their ideas.  As the ideas are fed back, you can begin to group the index cards by idea and arrange them into order of delivery / process / category on the meeting room table.

You’ll probably find that a number of ideas will be duplicated by different participants, but don’t worry about this, just group all similar ideas together in the same area.

Post-it note planning

The index card technique works just as well with post-it notes

Image from: VFS Digital Design

At the end of the session, you should have the process steps for delivering Project XYZ or completing Activity B laid out on the table in front of you.  Then it is simply a case of taking a picture of the cards on the table (in their order and groupings) with the camera on your mobile phone and emailing it to yourself to write up after the meeting.

This technique has generally worked well for me because:

  • It is engaging and ensures everyone in the group (especially quieter members) gets a chance to contribute.
  • The index cards can be quickly and easily moved around to different positions or groups in the process and the whole team can be involved in this activity.
  • Additional information can be captured on the index cards, such as notes on timings, responsibilities and risks whilst the brainstorming is in full swing, ready to be written up after the session.

Straw man plan technique

Often people find it easier to tell you what they don’t want, rather than define what they do want, so spending some time before the meeting to prepare a ‘straw man plan’ can really help to get the discussions under way.

The straw man plan is your rough draft – a prototype proposal that people can object to, knock-about and change to formulate a good, solid plan.

You can present your straw man plan either by projecting it onto a screen or printing off handouts and distributing them at the start of the session.

Handouts tend to work well as they allow people to see the plan in detail and you can scribble notes and changes on the paper as the meeting progresses.

As you present the plan for feedback, try to run through each stage methodically.  Often you will already be aware of the gaps in your planning and at the given points you can pose the question to the group: ‘how do we get from Point A to Point B?’.

In addition to scribbling on the straw man plan, it is useful to have somewhere to capture other notes / points / new requirements / actions that will arise during the session.  This is where the straw man plan technique works very well in combination with the index card technique to quickly capture and collate the key points.

Other techniques

There are of course many other ways to run a planning session and it is good to try a variety to see what works best for you and your team.  Sometimes the more informal the process the better and an impromptu five minute gathering around a whiteboard to thrash out some ideas can be just as effective.

In the end, provided you are gathering the right information from your team, it does not matter what technique you use.  The key is to make planning as interesting and involving as possible, so that the team will be enthusiastic and motivated, rather than dreading being cooped up in a meeting room all day.

This is not always an easy task, but it is definitely a goal to strive towards.

Estimating

Estimating timings (and therefore costs) is an important, but challenging task.

Why?

Well, to begin with an estimate can only be a guess about how long it will take to complete a future activity.  Previous experience of delivering similar activities will help with the accuracy of the estimate, but many projects require the undertaking of unknown activities where experience is minimal.

Secondly, once somebody has written an estimate down, they tend to get held to it from that point onwards, even if they have written the word ‘DRAFT’ next to it in bright red ink!

This tends to put people off communicating estimates, especially when there are commercial implications involved.  The customer will always want the reassurance of a fixed price, but with the flexibility of a time & materials contract; whilst the supplier will not want to commit to a specific scope without the freedom to allow for unforeseen costs.

The time, cost and quality impact

Every project deliverable is constrained by the following factors:

  • Time
  • Cost
  • Quality

So if the estimate for an activity is wrong and it takes longer to deliver than expected, there will be an impact on either the cost or the quality.

Now consider a project that needs to meet a fixed deadline, but beyond the original budget there is no more money in the pot to pay for the extra resource required.  The only option remaining is to deliver the project with a lower level of quality (e.g. software with more bugs), which is unacceptable.

This is why the Agile project management community have focused on a fourth variable – Scope.

By prioritising the requirements and structuring the project to deliver in batches or segments that can be released to the market independently of those requirements still in development, it is possible to reduce the scope when required and fix the time, cost and quality.

Quality triangleAdmittedly this agile approach tends to work better for IT software projects than it does for big infrastructure and construction projects, but the principle of breaking the project up into key component parts that can be put into use whilst other component parts are developed (or shelved) makes a lot of sense.

In addition to a flexible scope, there are other techniques and approaches to help you provide better estimates:

Team-led estimates

This is vital.  You cannot expect your team to commit to or take ownership of a task that you have estimated without consulting them.

Sometimes you’ll want an individual to tell you how long they think the task will take them, either during a planning session (scribble the estimate on the index card) or in a one-to-one conversation or you may need to task a team leader to consult with his or her team and present you with their own mini-plan showing how a complex activity will be completed and how long it will take.

Just-in-time estimates

The closer you can leave your estimating to the actual implementation, the more accurate it will be.  This is purely due to the team having built up much more knowledge and experience during the delivery of the project, allowing them to take a more expert view and knowing the latest circumstances concerning the business environment your project is operating in.

Agile project methodologies (such as Scrum) advocate development windows lasting just two weeks, which begin with a planning session to estimate tasks and end with a retrospective to learn from the lessons gained during the ‘sprint’.

Again at a commercial level, this may not always be practical, but if you are entering into commercial negotiations, it always helps to promote the benefits of this approach with your client, so that they will consider adopting it for the project.

Prioritisation

Creating an estimate for a task can be quite an effort in itself and sometimes a team will need go away and do some initial concept testing with the code, audience or infrastructure to get a real feeling for the sub-tasks and effort involved.

If for example you have 50 customer requirements in your list and you require 5 man-days per task to produce a viable estimate, you are looking at a total of 250 man-days of estimating work before the project even begins!

Considering many of those requirements will be nice-to-have features, it should be possible to work with the customer to whittle the requirements down into the following categories of priority:

  • Must – I must have this requirement no matter what
  • Should – I should have this requirement, but it does not necessarily need to be available in the first instance
  • Could – I could have this requirement, but I can live without it if we run out of time or budget
  • Won’t – After consideration, I have decided I won’t have this requirement and it will be recorded as out-of-scope

Beginning with your Must requirements, identify the two or three most important and focus the estimation work towards these.  Then a decision can be made with the customer to proceed on these initial key requirements after just 15 man-days of concept testing and not 250.

Contingency

Building in some additional time or budget to cover overruns is the classic estimating tactic.  Having some contingency also helps with client or management negotiations, as the project manager will invariably be asked to shave some time or cost off the delivery, so it always helps to have some extra fat on the bone when you first present it.

However, adding contingency to projects needs to be carefully controlled.  Simply adding 10% contingency to every project task will make the overall project appear much more expensive than it should, which means you run the risk of appearing uncompetitive.

Instead be selective with what you apply contingency to, under-promising and over-delivering on the more complex tasks and trimming the fat on easier tasks.

Allowing for non-productive time

If you are allocating resources to a specific task or set of tasks, remember those people may have other projects that they are required to work on.  So whilst you can estimate it will take them 5 man-days to complete a task, if the person you have allocated the task to is only available for 50% of the time on your project, the actual duration will be doubled.

It is also worth remembering that a single man-day will never be 100% productive.  A good example being a computer programmer.  Out of a 7.5 hour working day, the programmer will probably need to attend a meeting, fix a fault on his computer, undertake some research, have a coffee and some lunch, stretch his legs, etc.

In fact you may find that his hours of productivity have been reduced from 7.5 down to 4 and if this level trends on a daily basis then you will need to take this into consideration for your planning.

Note: This is a good example of why it is important to minimise meetings and invest in good equipment, allowing you to maximise productivity.

Planning assumptions

Assumptions are a key instrument for planning.  Whether you need to allocate time for the delivery of an unknown task or you have a dependency from an external supplier or client for which you have limited or no control over, your planning assumption will probably be somewhere ranging from pure guess-work, through to a well researched estimate.

Using assumptions enables you to complete a picture of how your project will be delivered whilst you still have little detailed knowledge of the conditions the project is going to be operating in.

When you make a big assumption in your plan, it is best to record that assumption either on the plan or in a separate document, so that stakeholders are clear that it could change once you have more information.

You should also communicate any assumptions that are dependent on external stakeholders with those stakeholders directly, allowing them the opportunity to validate your estimate and be aware of their responsibilities to the project.

For example a software development project will need to assume that the client can commit x number of days to define requirements, view demonstrations and undertake user testing.  If the client is not aware of their responsibilities or cannot commit sufficient days then the project is going to be put at risk.

In fact, if you think about it, all assumptions are effectively project risks and should be recorded in the Risk & Issues Log (certainly the big assumptions anyway).

For example my schedule depends on Supplier A delivering the equipment within four weeks.  But:

  • What is the likelihood that they will fail to meet that deadline?
  • What is the impact of a [insert time] delay?
  • What can be done to mitigate both the risk occurrence and the risk impact?

Having the answers to these questions requires you to go through a thought process and you may not have sufficient time to look at every assumption-based risk in detail, but by prioritising on those most likely to occur, with most impact, ensures you have some answers in case the risk needs dealing with.

Documenting the plan

When I think of a project plan, it is the classic Gantt chart and other sorts of visual timelines that spring to mind.

However a plan can be documented in many different ways and it really depends on the types of people using it, the level of detail covered, the organisation(s) involved and the situation that will inform how the plan is best conveyed.

At its most simplest, a plan could just be an email sent out after a meeting with a list of actions for different people to follow up on or at the other extreme it could be a whopping great big 100 page contractual document for a programme of public works that an outsourcing company has just won the tender for.

Many people will regard a PID (project initiation document) as a key part of the plan, so it really helps to understand what your audience are looking for.

Thinking about your audience

Knowing your audience is key to effective communication and people at work are generally very busy with limited time to wade through complicated documents.

Whilst a detailed document like a PID is a good exercise to help you consider all the different aspects of a project, you’ll find that the majority of people won’t bother to read through it.

Instead they will want a one-sider which will quickly show them what you are trying to achieve and how it will be done, allowing them to understand their role in the big picture.

This is why I always advocate a pictorial high-level plan that shows the key sections or steps in the project in just one page.  I often use Microsoft Visio to produce the plan, with coloured blocks to represent the key activities overlaid onto either a month-by-month or week-by-week timeline (depending on the size of the project).

High level planning

Note: If you have not got access to Visio at work, then Powerpoint is equally effective for producing pictorial plans.

Specific activities may require more detailed planning, which is where Gantt charts are probably more useful.  They still provide a visual representation of the time required for each activity, but give you more scope to detail the activity, assign an owner and set specific start and end dates.

Microsoft Project is the Gantt chart software commonly used within businesses and it has a whole host of technical planning features.

Alternatively you can create your own Gantt chart template in an Excel spreadsheet (featured below).  This won’t have the advanced features of MS Project, but very few people need or use all the MS Project features.

Gantt chart

Another alternative is to use one of the many online Gantt chart tools available.  These are hosted services, so you’ll probably need Finance and IT to agree payment and permissions (depending where you work).  The main advantage of a hosted service is that many of them are much more user friendly compared to MS Project and they also allow for more collaborative working practices with multiple users able to read and update the plan.

Publishing your plan

I’ve always preferred exporting my plans to PDFs (bar emails with lists of actions), before distributing them to my colleagues.  This helps to overcome any issues people have opening the document (normally only a few people have access to MS Project and Visio) and makes the plan non-editable.

The reason I like the plan to be non-editable is all to do with version control and not having different people looking at variations of the same plan (after it has been tinkered with), which just leads to confusion.

Any feedback and change that people require should be updated via the project manager, with a new version published and distributed to the whole team.

Version control can look like this:

  • v1.0 – First version
  • v2.0 – Second version
  • v3.0 – Third version
  • etc

Adding the date the plan was published is also useful for reference.

Tracking and re-planning

Whilst the focus of this article is on the process of planning, it is important to remember that planning is not a one-off activity.

The plan acts as a guide for you and your team through unknown project territory, so it should be followed closely and updated as new information becomes available.  Planning is an iterative process, so taking the time to sit down with your team to review progress and make changes, is not only essential, but it can also be very motivational.

Weekly or fortnightly project review meetings provide a good forum for tracking progress and agreeing issue mitigation actions.  This might involve a run-through of the high level plan or could focus on the completion of tasks in one of the activity sub-plans, such as recruitment of staff, procurement of office space or IT equipment, or documentation of business processes for example.

Alternatively, those working in an Agile delivery environment (such as a software project) will be familiar with short daily sessions to review progress against the tasks they are working on.

What this shows is the frequency of reviews and re-planning will depend on the activity being undertaken, the type of project and ultimately the size and importance of the project.  Again it is good to ask your project team what sort of review frequency they think is required, so that everyone has bought into the meetings.

The art of project planning – a summary

Planning is a key project management skill and there is definitely an art to creating and implementing successful project plans, which like all art forms, only improves with continuous practice and experience.

Whether you are seasoned project professional or just starting out on your first project, the ability to draw out the knowledge and information from your stakeholders; organise, categorise and distill it into a cohesive form and communicate it back to the team for implementation will always be a critical success factor.

So remember:

  • Start with a high level plan and use this as your project framework.
  • Consider the ‘breadth’ of the project goals and key requirements, before diving down into the ‘depth’.
  • Expect your planning activities to be iterative, with regular reviews and re-planning.
  • Involve your team in planning and estimating activities to secure their buy-in and support.
  • Experiment with different approaches and techniques for running planning meetings, until you find the ones that work best for you.
  • Use and document your assumptions to fill in gaps in your knowledge of the project-environment.
  • Document and distribute your plans in easy-to-understand formats, so that everyone can access and quickly read them.
  • Schedule regular review sessions with your team to keep everyone onboard and on-track.