Benjamin Franklin is often attributed with the quote “Failing to plan is planning to fail” and in perhaps no other area of business is the quote more apt than in project management.
A poorly run project is doomed from the start, and without a project plan it is almost impossible to run your project well. Cost control, making a business case, stakeholder communication, contract management, scheduling and resource management are all parts of a project that will be poorly controlled and managed without a project plan.
Start at the beginning
A project plan is the most fundamental document you need to produce – without agreeing a plan your team don’t know what is and isn’t in the project scope, your stakeholders can’t be confident about timescales or deliverables, and you, as project manager, need the plan to keep you focused on the project in front of you.
Project managers are frequently either writing project plans, or amending existing ones as the nature of a project changes. Much of the work of a project manager is in the detail of the planning, and of ensuring the whole team stay on the plan to ensure a successful delivery.
However, even though a multitude of project plans are written that doesn’t mean all of them are written as thoroughly and in enough detail as they could be. Project managers may be pushed for time by clients eager to see more tangible progress being made, and don’t forget that “familiarity breeds contempt”, another apt saying relevant to project planning because once plan writing becomes an everyday task it has the potential to get sloppy as the writer works on “autopilot”.
Which is why we’ve put this guide together…
It will help PM apprentices looking at contributing to their first few project plans, but we hope it will also remind experience and well-established project managers what the purpose of the plan is and ensure no part of their planning is neglected or allowed to be incomplete.
Determine the scope of the project
“Once upon a time there was a project manager who wrote a perfect project plan…”
Fairytale? Perhaps, but it can be helpful to think of your project plan as a story linking the different phases of the project together. Like a story it needs a beginning (the plan), a middle (intermediate milestones) and an ending (the deliverables) to wrap it all up neatly. Hopefully with a happy on budget, on time and they all lived happily ever after ending.
Project managers need to start with ascertaining what the major deliverables are instead of “once upon a time”. This could be a new piece of software, a building or something ephemeral such as the completion of a successful music festival. There may be more than one deliverable, and at this point it’s fine to write fairytales (within reason) so note down all the deliverables you’d like to be able to provide, or that the client wishes for, and idealised deadlines for completion. You’ll review these as the story progresses, throwing away some goals and moving deadlines until you, the client and all other stakeholders are happy with the plan.
A story isn’t a story without some characters so you also need to analyse who you need in your team and what their role in the team will be. You may find you need multiple teams or that the team structure is determined by some other aspect of project. Unfortunately reality needs to take precedence here – you will almost certainly have personnel available and you will have to work with their abilities, or factor in recruitment or training costs and time into your planning.
Finally, consider the milestones that you will need to meet to know that progress is being made. These need their own deadlines and a plan for moving from one milestone to the next to progress the project.
Do your research
One of the more important project management skills is understanding when you know all the facts, and when you need more data. Having looked at the scope of the project you may feel that deadlines might be too optimistic or the gaps between milestones too short.
This stage is where you read as much documentation surrounding the project as you can and talk to as many people involved as possible. You’re looking for answers to the following questions (and any others that might arise as you work):
- What does the project hope to achieve (the goals)?
- What does the client expect from us and are there any specific needs to address?
- Who is the project sponsor – how hand’s on will they be?
- How will the client review our work in order to accept it?
- Who are the stakeholders? Do they understand their responsibilities?
- Have the sales team promised anything we can’t deliver?
Talk to the client
You might need to ask your client some difficult questions to fully understand what they are expecting from the project. You will need to discuss the project risks and process with them to ensure you are on the same wavelength, and you may need to take into account organisational politics within their enterprise.
Home in on a realistic deadline, and be clear on how much movement there is in the deadlines. A project plan for a product may have more flexibility in it than, say, a project plan to build infrastructure for a major event such as the Olympic Games.
Determine who really owns the project – who will sign off on it – and if there are any hidden stakeholders who will need to be consulted. You should also determine if there are any parts of the project process that the stakeholders might not fully understand, and explain to them what is going to happen.
Assess yourself and your team
Use your project management skills to analyse the resources you have available to you. Is this the sort of project your team have worked on before? Will they need training, for example to get up to speed with unfamiliar technology? How did it go the last time you attempted a project similar to this one?
Decide what tools you are going to use to communicate with the client and to track project progress. This will be a combination of what you are happy using, what the client is happy using and what you have available to you.
Outline your plan
By now you should have a clear idea of the who, what, when and how of your project. So get it down on paper. Literally. You are aiming to sketch something along the lines of a work breakdown, and you’ll probably need to adjust bits here and there as you work through the project.
Make sure you include:
- deliverables, milestones and the tasks needed to reach them
- the approval process
- timescales
- resources required
- your assumptions
- absolutes, such as concrete deadlines or fixed budgets.
The plan is still in outline form at the moment, and still liable to change but don’t worry – it’s all coming together!
Have a team meeting
You are the project guide, not the project implementer, so now is the time to take advantage of your team’s real world expertise. Ask them what they think of your plan. Find out which tasks are going to be dependent on the results of other tasks and which can run side-by-side. For example, on an IT project can UX designers and back-end developers work concurrently, and what information will they need to share? Meeting with the team now engenders a healthy atmosphere of open communication and provides team members with loyalty to the project.
Finish your plan
By now you should have all the answers you need – and if you haven’t then you probably need to rewind a bit and seek out answers to the remaining questions. You’ve got a sketch of your plan, a lot of notes and now is the time to turn it into the finished product.
Make sure you keep the important sections easy to read with clear formatting. Use corporate branding (include both your logo and your clients perhaps) and a clean layout.
Essential information to include is:
- Client
- Project title
- Version number
- Delivery date
- Deliverables
Within each deliverable create a breakdown of milestones and associated tasks. Assign ownership to each task by labelling it with the team responsible for completing the task. Use headers and indents to keep sections readable.
Add resources to each task to ensure someone is responsible for every task. Make sure every task has a start date and end date (even if the task is ongoing – keep the format consistent for ease of reading).
Don’t be afraid to add notes for clarity. It won’t hurt to be clear on your assumptions and expectations. Specify prerequisites (tasks that must be completed before this one can begin) and dependencies.
Include a Gantt chart or similar visual aid. Some project managers and teams prefer a calendar view, or a per-person list of tasks. If you are publishing your project using commercial project management software a lot of the cross-referencing of the project plan will be completed automatically, allowing you to focus on the important factors and less on the visual formatting.
Proofread
Check and double check what you’ve written then give your plan to someone who hasn’t been staring at it for the last few days and ask them to read it over. Far better a member of your team spots an error than your client – or worse still it’s never noticed until it has turned into a major scheduling headache.
Publish and review the plan
Share your shiny new plan with the whole team, and the client and invite comments and criticisms. Now is the preferable time for any major changes – not two months down the line when they might be more difficult to add and implement. Provide your team with a summary of the plan in prose, as well as the step-by-step document and time management charts, but keep it concise and to the point. That way people are more likely to read it in full and absorb the detail.
Now is the time to schedule a meeting with the client to go through the project plan with them, line by line if necessary, to ensure that they understand how the project will progress, and when they will start to see results. Try not to be defensive of their comments – you are a facilitator and if you have erroneously made any assumptions, or failed to take account of some other set of circumstances that impact on your ability to deliver on time, then it’s your responsibility to change the plan. Project plans are not set in stone – they’re living documents that change in response to the progress of the project.
That’s not the end!
A project plan is just that – a plan. It will, and should, change throughout the lifetime of the project so will need to be updated and rewritten over time, particularly for long or complex projects. Having a good plan, a clearly defined scope and a motivated team with the right skills and experience will give your project the best chance of success.
Having the flexibility to alter your plan, without having to start from scratch, is a hallmark of a good project manager. Yes, there will be some projects that keep you awake at night and putting in overtime because, regardless of what you’ve planned, projects are rarely straightforward. But starting the project with a well-thought out, well-researched and well-communicated plan ensures that everyone knows what they are responsible for, every task will get done eventually and no one is given work that they are unqualified or unprepared to complete.
Success in planning is planning for success. And every project manager wants their projects to be successful.
