A well-crafted project plan was once the pride of project management. But in the post-waterfall era of agile-everything, the humble project plan has got itself a bit of a bad reputation. So what went wrong for project planning, and is it still useful for project management?
In this post, we’re going to start with some project planning basics to explain ‘what is a project plan?’ and give an example of a simple project plan. We’ll then tackle the tricky question, ‘does a good project plan matter?’ We’ll share a handy project plan checklist infographic and give you a step by step guide to creating a project plan. What’s more, we’re including some great bonus content: a website redesign project plan template download.
What Is A Project Plan?
Before we get ahead of ourselves, let’s get on the same page with our understanding of a project plan. A project plan is a roadmap that shows the steps you need to take to get from A to B. It shows how you get from your current state to the desired future state.
A project plan shows the different phases of a project and the activities or tasks in each phase. Typically, it shows when a task begins, ends and the interdependencies between each task. A project plan can be as simple as a scribble on the back of a napkin, a few lines in excel, but is usually presented as a Gantt chart, and made in Microsoft Project, or one of the other Microsoft Project alternative planning tools.
Simple Project Plan example: The ‘Make A Cake Project’
Below is a simple project plan showing four phases of a rather laborious project we’ve concocted to make a cake. The project plan shows the process you need to go through to get from our current state (no cake) to our desired future state (eating cake). It shows us how long the process will take, and the order that the process will need to follow in order that you produce the cake properly.
The project plan shows, the different phases of the project, in bold as the summary tasks, (Initiation, Planning, Baking and Evaluate) and each of the subtasks with durations, start and finish dates, milestones (the black diamonds) as well as dependencies.
Sadly, this project shows that no resources have been assigned against any of the tasks so we’ve still got no one to actually make the cake; we’ll need to find someone to do that! Finally, at the top of the image, you can see Microsoft Project also gives us a timeline overview so you can see a 50,000ft view summarising the project, the phases, milestones and progress.
So on a straightforward project, creating a project plan is all pretty easy, right?
Three Inconvenient ‘Truths’ About Project Planning
So maybe a project plan makes sense for making a cake. But for all the project plan haters, let’s tackle the elephant in the room – aren’t project plans for a complex IT project just a waste of time? Hasn’t the bright new shiny world of agile done away with our need for project plans?
Here are some of the typical arguments against project plans:
- Project plans are pure fantasy – pipe dreams not grounded in the reality of the team or task at hand – which then become handcuffs for the project manager and team tasked with delivery.
- Project plans can artificially constrain a team’s ability to iterate and self-optimize – if you want people to do their best work, shouldn’t you remove the constraints that will hold them back?
- Project plans are perpetually out of date – What’s the point of having a plan if it no one sticks to it and it’s constantly changing?
The no project plan alternative that’s often touted as being more ‘agile’ is to simply set up a self-organizing team, give them a brief, get started on sprints and let them all work together to figure it all out themselves. They’ll be more motivated as they own the ‘plan’ and can keep delivering, testing and learning until the project is complete.
Why Project Planning Still Matters
But is that a viable alternative for our clients and us as project managers? Here’s why both clients and project managers still need to do proper project planning.
Why Clients Care About Having A Project Plan
If you’re working with clients, before you can start a project and get your client to release their budget, they’ll usually want to know a few pesky little details like:
- When is the project going to be delivered?
- How much will it cost?
- What exactly will be delivered?
- How will it be delivered?
If you opt for the no project plan alternative, it’s difficult to answer these seemingly basic project management questions.
In response to these questions, a typical response you might get is; ‘no one can know – it’ll all depend on the team’s velocity.’ That might be true, but clients usually need to know what they’re getting, when, and for how much before they’ll sign off on a project. So you can end up in a stalemate and the project doesn’t start.
Why Project Managers Care About Project Plans
It’s not just clients that care about project plans though. As a project manager, you need to know more than just the details the clients need to know about your projects. Once the project gets started, you’ll need that project plan to ascertain if the project is on track.
You need to know if the project is meeting the budget, timeline and quality criteria so that it delivers the intended results. You can’t know that unless you’ve got something to measure against.
7 Reasons Why A Project Plan Matters
Here are seven reasons why project plans are probably the single most important piece of project documentation.
A project plan:
- Clarifies the process and activities that will lead to the project’s outputs and deliverables
- Gives you information that enables you to estimate properly and define a project’s outputs and scope
- Enables you to visualise the entire project and see the interdependencies between tasks
- Helps you show who does what task, when and forecast your resource requirements
- Provides milestones for tracking project progress (and dates for client approvals)
- Enables you to baseline and track your project progress properly
- Enables the agreement of the all-important live date
A project plan should be much more than a roadmap though; to give a client a complete view of a project, it should be combined with an estimate and a statement of work too.
Going back to those inconvenient ‘truths’ about project planning. Proper project planning isn’t difficult but it takes time to do properly. And it’s not a one-time thing, you create a plan, and then continually refine that plan. Even if you are running an ‘agile’ project, you still need a clear direction – an idea of what you’re going to create, how you’re going to create it, and when you’ll know that you’re finished.
You need a project plan to show your approach – how you’re going to take a project from initiation, to project close – and the process you’ll take to get there. It’s important for clients to buy into the project process so that they understand the limitations and scope of the work. It’ll also help them understand if the proposed work will deliver what they want and if the process you’re proposing will get the results they’re paying for.
A project plan is critical to get everyone on the same page with what you’re going to do to achieve your project goals. A project plan documents the process and activities that come together to enable something amazing to happen.
The 5 Big Project Plan Brief Questions
But before you get started on creating the project plan, you need to understand the project’s brief – what you’re trying to do and achieve. Without understanding the project’s goals and brief, there’s no way to deliver them. As a minimum, you need to be clear on:
- Why? The project’s strategic goals.
- What? The activities (or process) outputs and deliverables.
- When? The deadlines and dependencies.
- How? The process or methodology.
- Who? The client and their team of stakeholders.
Usually, a good project kickoff meeting will help us produce a proper project brief because our project plan should always work toward achieving the project goals. If you don’t ultimately understand the point, or why you’re doing a project, you can end up barking up the wrong tree. You might not focus the resources on our project as well as you could – you might include in the process activities that are redundant, and you might produce some outputs which aren’t useful.
Project Plan Checklist Infographic
How To Create A Project Plan
Got that brief nailed? Now you can get cracking with creating a project plan. We’ve created this project management plan checklist as a handy guide to creating a project plan for any project – whether that’s a large cake, a large website platform, or even something non-digital, the principles and steps are the same.
With your project plan complete, you’ll be equipped with the necessary information to complete your project planning and the detail you’ll need to pull together a cost estimate, statement of work and get your project started.
Project Management Checklist:
In this project management checklist, we’ve simplified the process of how to write a project plan to ten simple steps. They’re the basics you need to master to develop your own project plan that works:
- Define Your Workflow – Make a rough plan. Sketch out the overall flow of your project from initiation to completion. Map out each project phase and the likely activities and tasks required in each phase to complete the project.
- Establish Your Planning Horizon – Are you being realistic? Work out how far you can accurately plan ahead. Plan in detail only for what you know, and make generous allowances for the rest of the project so you don’t over-commit yourself and your team.
- Break it down – Get into the detail. Break the project phases and tasks down into small sub-tasks, no longer than a few days each. It makes it easier to identify if any steps are missing, and easier for your team to estimate.
- Ask, don’t guess – Don’t make it up yourself. Give your team the context, a rough number to start with, and help them collaborate on estimating properly. Share assumptions, dependencies and work out who can do what, when.
- Question When Questioning – When your team gives you an estimate, keep asking ‘why’ and ‘how’ to help them think through their approach, identify any efficiency opportunities and ensure sure you understand what’s included.
- Allow Time For Amends – Amends or changes to a project are inevitable. Make time for review and amend cycles, both internally and with your clients.
- Plan For It Not Going To Plan – Projects never go to plan. Simply planning for the best case scenario or Plan A, isn’t good enough – you need to bake into Plan A, Plan, B and Plan C too.
- Finish Well – Finishing projects properly can be a tricky business.Make a robust plan and allow ample time for the closing phases of your project as you load content, QA, test, get approvals, make DNS changes, and deploy to production.
- Post-Project Review & Optimization – Going live isn’t the end of the project. Build into the project plan a phase for post-live testing and analysis to measure performance, make any optimisations required, and take note of all lessons learned.
- Milestones & Baselines – Keep your project on track using milestones so that the project team and client are clear about key dates. Monitor progress using baselines to keep tracking your progress against your original project plan.
1. Define Your Workflow
With the project brief ready, you can start work on the project plan with a loose sketch of how everything’s going to fit together – to define the workflow.
The workflow determines the overall project process, structure and defines at a top level the flow of work from initiation to completion – it’s the project management lifecycle, the high-level process of delivering a project and the steps you take to make things happen.
More often than not, there’ll either be an agency or client process that you need to adhere to in structuring your workflow that defines what stage precedes or follows the next. Typically agencies follow a pretty similar workflow through the project lifecycle where 5 distinct phases take a project from initiation to iteration. It’s an iterative, circular process in that the learnings from each project cycle generate the insights for the next.
The 5 typical agency phases are:
- Define – The strategic phase. Initiating the project and clarifying the goals, success criteria and a clear brief around the challenge that the project needs to be addressed.
- Craft – The design phase. Whether it’s information architecture, wireframes, technical specs, requirements definition or mockups, this is where the thing that’s going to be built gets planned out, prototyped and designed in detail.
- Develop – The build phase. Taking all the definition from the craft phase, this is where concepts and mockups come together to create something that works.
- Deploy – The go-live phase. Quality assurance, user acceptance testing, and user testing are often features of this phase before you get the green light to make the project public.
- Evaluate – The ‘Did that work?’ phase. After deployment, you need to ask the questions; ‘Did that do what it was supposed to?’ ‘Did we deliver it as well as we could have done?’ and, ‘What are the learnings that we need to take into the next project?’
There are countless variations to this. What we describe above loosely aligns with a PMBOK project management lifecycle of Initiating, Planning, Executing, Monitoring & Controlling and Closing.
Remember though, there’s no ‘right’ process. No, really there isn’t. Everyone tailors the naming and number of these phases to make their project management process seem unique and to highlight strengths within their agency.
Some agencies will simplify this to three phases (Define, Craft, Develop) or add additional phases but ultimately they’re the same. To get anything done you’re defining what you need to do, how you’re doing to do it, coming up with some ideas, designing, building, releasing, and then making sure it works.
Sketch out a plan
With the overall workflow and phases of work defined, you can start to make a rough plan. The point of the rough plan is to put a stake in the ground and give yourself and your team something to provide feedback on.
Sketch out the overall flow of your project from initiation to completion, working in one or two week time periods, and add in key dates that you need to consider such as kickoff meetings, and the required live date. Map out each project phase and the high-level activities and tasks required in each phase to complete the project.
Make it big. It’s helpful to start with a pencil (so you can easily erase!) and paper or a whiteboard so you force yourself to stay out of the detail. Doing it on a whiteboard also makes it easier to share with your team and get their opinion. If you get this bit right, it makes adding in specific tasks, milestones and dependencies afterwards much more straightforward. If you haven’
Go back to the project brief and think about the final deliverables for the project. Working back from them, work out the different activities that will need to happen in order to make that happen within each phase. Think about the groups of activity that need to happen within each phase – what are the phases within each phase?
At this stage, you’re not thinking about the actual tasks but how the tasks can be grouped together and the subsets of work within each phase. For example, within the ‘Craft’ phase there might be the following:
- Customer experience
- Design concepts
- Template design
- Design rollout
- Content strategy
- Content development
- Customer experience
When you’ve defined the workflow within each phase you can then begin thinking about adding in specific tasks. But by ensuring you begin with defining the workflow you ensure that you produce a project plan that aligns with your company process, and with the foresight of a 10,000 ft view, contains all steps needed to successfully deliver your project.
Remember: Think about your project plan’s audience
You want to produce a project plan that’s useable. Project plans are a great internal tool for project managers to estimate delivery of a project and keep track of the progress of a project. However, right at the start, as you’re mapping out your workflow, it’s important to remember that they’re often also an external tool for you to use with your clients.
So why are structure and workflow so important? Think about who is going to use and need to understand your project plan. Make sure right you structure the workflow and project in a way that your internal team and clients understand and agree with. If you don’t, you might yourself having to restructure your project plan and painfully re-link tasks and dependencies.
2. Establish Your Planning Horizon
Once the workflow has been defined, next begins the task of pulling together a project plan. As you’re creating the project plan you need to again revisit our inconvenient project planning truths and ask – ‘Are you being realistic?’
Before you take our rough project plan and dive into the detail it’s important you make an honest assessment of the project and work out how far you can accurately plan ahead. Planning out any further than that is pure guesswork that will only create a world of pain later. Plan in detail only for what you know, and make generous allowances for the rest of the project so you don’t over-commit yourself and your teams.
What is a planning horizon?
A planning horizon is your limit of predictable and accurate project planning – it’s how far ahead you can see clearly. The length of the planning horizon is usually dictated by the degree of external uncertainty (often clients): the higher the uncertainty, or unpredictability the closer your planning horizon will be.
You can see, and therefore plan anything up to, or before a planning horizon. But anything beyond the planning horizon is guesswork. There’s masses of uncertainty – you can’t see or know what’s there, so planning detail in projects beyond it, is dangerous.
How to manage your planning horizon
On bigger projects, it’s highly unlikely you’ll be able to plan out the whole project in detail because internal and external project dependencies create uncertainty. On a typical web design project, this will usually be due to dependencies within project phases. For example, until an information architecture is signed off by a client, it’s very difficult to know how much time will be required for wireframes, design, content development or build because you don’t know how many templates will be required or how big the site will be.
So what do you do? Plan in detail only for what you know, in the phase that you’re in, and make generous allowances for the rest of the project. In our example above – without the IA defined, you don’t know how many templates you’ll need but you can make a good guess (based on past experience) that it won’t require any more than 10 templates. You then take that number and work from it, making sure you include it as an assumption in our statement of work that you’ve based everything on a maximum of 10 templates.
You don’t have a project planning crystal ball
As project managers, we love having everything wrapped up, neatly in a box – and that’s the way clients like it too. It can be tempting to plan out the entire project in minute detail. But with any project, as soon as you start it, the plan will invariably require change as clients don’t supply assets in time, or approve things. You end up with project delays, scope additions, budget or timeline changes that can require significant changes to the project plan downstream. So to save ourselves from wasting time in fanciful planning, and mislead our clients into thinking you’ve got some kind of special project planning crystal ball that can predict the future, you’re better off just planning in detail as far as you can clearly see.
Become comfortable with saying, ‘We don’t know…’
As project managers, it’s often tempting to tell our clients and managers what they want to hear. It’s actually really easy to give good news – to tell them the timings that they want to hear. In the short term, it’s a good solution – the client gets the confirmation and reassurance that they’re looking for, and you, as a digital project manager, stop getting hassled. For a while all is good – but as soon as a project goes off track, it’s then too late to backtrack on your promised delivery date and you’ve suddenly created a lot of pressure for yourself and your team. It’s a short term bet that rarely pays off!
The lesson is this – if you can’t confirm your full project timeline, and your planning horizon doesn’t allow you to give a final delivery date – don’t do it. If there are too many risks, unknowns or external dependencies, you need to tell the client that you can’t confirm but that you can only give a ballpark range based on your assumptions and the project’s current velocity.
Remember: Broadcast the truth, don’t hide
It’s one thing to create a project plan for the current phase, and ballpark the rest of the project but unless everyone knows that’s what you’re done, then it’s totally redundant. When you’re sharing a draft project plan, make sure it’s clearly marked as a draft! And when you’re sharing a proposed ballpark delivery date, make sure you’ve caveated it properly with the necessary assumptions. In short, make sure that everyone knows that the timings you’ve done are only accurate for the stage that you’re in. Be transparent, and broadcast it.
3. Break It Down
Why are sub-tasks important?
The proverbial elephant is eaten one bite at a time, and it’s the same for our project planning. When you’re trying to accurately estimate how long a stage of a project is going to take, it’s important to split tasks into sub-tasks no more than a couple of days each. To do this, take a task, define all the sub-tasks that make the sum of that task, and for those tasks, do the same so that each sub-sub-task can be assigned an accurate estimate.
By breaking down the project into sub-tasks you’ll find that not only is estimating easier, it’s also much more accurate. Smaller tasks are more easily quantifiable and comparable for analogous estimating. Creating the sub-tasks makes it much easier for your team to estimate against as estimating against a small, clearly defined task is much easier than a large and vague task which invites lengthy discussions on how the project could be approached differently!
As a bonus, adding in a level of detail to our tasks makes it much easier for clients to understand the process and enables higher fidelity progress tracking so you can more accurately track progress throughout a project.
Sub-tasks help you understand your project better
Breaking the project down enables you to finesse the overall workflow and process. When you begin to break the project down, splitting bigger tasks into sub-tasks helps you think through and remember all the things that are going to need to happen within a project phase.
As you break the project down it helps us to think about exactly what you’re asking our teams to do. You finesse the process and get to think through each step that the project team will need to work through to deliver the final product. The process of breaking it down often helps you to find holes in your workflow and identify dependencies.
The process of breaking the project down might feel laborious but it helps you to fully digest and think through exactly what you’re trying to ask your team to do. Going through the due diligence of task dissection prepares you for sharing the project plan with the team, and gives you the confidence to put a stake in the ground to create a starter effort estimate when working through estimates with your team.
Take a task, for example, ‘Design of web pages’. Break it into as many sub-tasks as you can; look & feel development, master template development, other template development, page design roll-out and page asset roll-out. When you’re clear on the sub-tasks, go and work out the timings of each part to work out the total for the whole project.
This process makes it makes it easier to identify if any steps are missing, and easier for your team to estimate.
How to create a project plan in Microsoft Project
At this stage of the project planning, it’s worth moving away from your whiteboard project plan sketch into something with higher fidelity and detail. You also want a tool that will give you real-time ‘feedback’ of the impact of any adjustments – showing how the project plan moves as you adjust tasks.
This is the process of creating the project plan in your chosen project planning software, like Microsoft Project or Smartsheet. Remember your initial audience for this will be your project team, you need this project plan to help the team understand how you’ve progressed in your thinking for project planning from your whiteboard sketch and so you’ll need to take them line by line through the project plan to get them to verify your approach and estimates.
Want to know how to make a Gantt chart? Here are seven steps to creating a simple project plan to share with your team:
1. Configure the basic project information
2. Add tasks and subtasks
3. Create hierarchy with high-level project phases
4. Add task durations
5. Link tasks and add dependencies
6. Define roles and resources
7. Create a timeline summary
Remember: approval cycles
Before you forget, remember to consider internal and external approval processes and consider the approval approach as a task with sub-tasks itself. For example, think about your internal design review process – how many people review it and insist on amends before it gets shared with the client? And then for the client, from your kickoff meeting, you should know how many tiers of client approval there are – include each of them as sub tasks with defined review and approval cycles within each one.
4. Ask, Don’t Guess
Creating great project plans is a bit of a dark art. Essentially you’re predicting the future. Ideally, you’re not just guessing but basing those predictions on something – past projects, past performance, what you know about the technology, the project and the client.
Give the team something to work from
It can expedite the estimation process and be helpful for yourself and your team if you take an educated guess for task durations and dependencies. Giving the team something to work from rather than just a blank sheet of paper can speed things up dramatically.
Give your team the context, a rough number to start with, and explain to them how you got to that number – what did you base it on? Help them collaborate on estimating properly by going line by line through your project plan. Help them understand why you’ve planned it out the way you have. Share assumptions, dependencies and work out who can do what, when. This is the beginning of optimising the project’s critical path.
Be careful what you ask
But beyond just asking someone to estimate how long something is going to take to complete you need to help them understand the context around their estimation. It’s no good just asking someone how long something will take in isolation.
As they provide you with a timeline estimate, ask how they came to that number. You’ll often find that as you begin to tease out the details of their estimation, they’ll begin to think of tasks that have been forgotten and you’ll begin to get an understanding of dependencies around individual tasks.
Get a second opinion on your project plan
Once you’ve been given one estimate it’s always useful to verify the estimate and get a second opinion. Reduce the risk of someone being overly optimistic or pessimistic by getting a second or third opinion on someone else’s estimates. You’ll find that as you run the estimate by others, efficiencies or additional elements will also be uncovered.
It can be tempting to quickly nip around and talk to the different people that you need to, getting quotes from each of them. The challenge is that in doing that, you’re not effectively capturing the dependencies between each discipline. It could be that one department is inadvertently making an assumption from another department. Or it could be that they’ve forgotten something entirely and that by discussing it with another department, they suddenly remember elements that they should have included.
Harness the power of team planning. Get everyone together in a room and run through the project timeline together so that all dependencies and any efficiencies of potential parallel workstreams can be captured.
Get it in writing
People are forgetful. After everyone has had the chance to review the estimates on the project plan, send them a copy. You’ll be surprised how frequently they’ll change their mind or notice something when they see it a few hours later in their inbox. Conveniently, it also doubles up as a nifty little insurance policy for you too.
I can’t estimate this…
Sound familiar? ‘I can’t estimate the length of time for this because I don’t know XY or Z.’ When no one knows how long something might take because they’ve never done it before, you have to base it on something. So try and find examples from their own work which you think form the foundation of what needs to be estimated and help them work up from that. Build your project timeline first around the bits they do know and then extend it beyond, making sure you’ve heavily caveating your assumptions and dependencies.
Remember: Don’t skip the asking step
When you’re under pressure to produce a project plan the easiest thing to do is just to guess how long each of task might take to complete and leave it at that. That’s an option, but not a particularly clever one. Guessing will not only just give you a poor project plan, it’ll give you no foundation for discussions with the client, and there’ll be no one else to share the blame if you guesstimate incorrectly.
5. Question When Questioning
In the last section, we looked at the importance of asking questions and not guessing or making assumptions when creating a project plan. But how should you ask, and what should ask? Asking good questions is probably one of the most important and powerful project management skills – in this section, we’ll explore how you can effectively ensure you’re asking the right questions to produce rock solid project plan.
Being a friendly cynic
Beyond just asking someone to estimate how long something is going to take, you need to help them understand the context around their estimation. It’s no good just asking someone how long something will take in isolation. As they provide you with a timeline estimate, you need to begin to interrogate how they came to the number. You’ll often find that as you begin to tease out the details of their estimation, they’ll begin to think of elements that they forgot to include and you’ll begin to get an understanding of dependencies around individual tasks.
Keep it open and closed
So how do you ask the right questions? Keep in mind the end objective – discovering why things are estimated as they are, how they intersect and what tasks they are dependent on. It’s important to use a combination of both open and closed questions to understand how long each task is going to take and how the tasks intersect with other tasks.
Open questions are important because they lead to more than a one-word answer, they provide breadth and tend to start with, Where? What? When? Where? How? or Which? These are great questions to use to gain an understanding of the bigger picture as they give you detailed and better quality information, exploring ideas and opinions when you’re questioning someone – helping them to crystallise their thoughts.
Closed questions are important too – they ensure a very clear and narrow focus and usually provide one-word answers. They usually begin with: Could? Should? Would? Have you? Do you? These questions are important when you’re ratifying facts, clarifying a point or providing some direction to the information being gathered.
Try to identify possibilities and opportunities
If you don’t ask enough questions or are just intent on getting numbers for creating our project plans, you can end up missing opportunities to create efficiencies. Remember that it’s just as important to use the questions to identify efficiencies as it is to just produce a project plan. Try beginning with preliminary information and clarification questions, progress to more probing questions and then more onto identifying possibilities. By ordering in this way you’ll give whomever you’re questioning the opportunity to establish a solid base to think more creatively about possible future states.
What not to ask
As much as it’s important to ask the right questions, you also need to be wary of asking the wrong questions. Avoid asking leading or loaded questions where you suggest an answer or solution, ‘in’ the question. Questions like this will often begin with ‘Do you think that…’ or ‘Don’t you think that…’.
Remember too to keep it simple and, avoid asking multiple questions or linked questions at once – just ask one thing at a time. And try to avoid “Why” questions as they can sound critical. You can still get similar answers to that question by choosing a different way of asking a question. For example: ‘tell me about…’, or ‘what do you think are the reasons for…’
Play it back
Once you’ve asked your question, make sure you replay the answers you’re given to make sure you’ve understood properly. Remember, you’re going to need to understand each line on your project plan, its duration and dependencies.
Remember: Keep asking questions
When someone has given you an estimate for the duration of a task, you need to question it – be friendly, but cynical. Ask them if that includes time for any amends, feedback, or QA. Make sure that you know, when you’re asked, why all the elements in the project timeline are estimated as they are.
6. Allow Time For Amends
Amends or changes to a project are inevitable. So, make sure to allow time for internal and client changes as well as some larger scope adjustments. After all, has a project ever decreased in scope?
One thing often missed in creating project plans is allowing time for review and amend cycles. Amends or changes to a project are inevitable. But if there are too many they’re also very likely to cripple a project, extend the project timeline, utilise additional budget, and potentially impact the overall quality of the project.
Allow for client amends
This goes without saying. Clients like to change things, and put their mark on a project. So no matter how closely you think you’re aligned with your client on a project, you need to allow for amends. But how do you know how much time to allow for those amends?
Be clear about what’s in scope
Right from the start, it’s important to be aware of how many rounds of amends are contained within your scope of work. Chances are though you’ll be creating the project plan before you write your scope of work, so at the very least, ensure the two match up. So should you simply allow in your project timeline for what’s in scope?
It’s one thing to know what’s in your scope of work, but it’s important that you’re also pragmatic. The reality of client & agency relationships is that there’s usually a degree to which the client needs to be appeased, so even if something isn’t strictly within scope, it gets done anyway. As this is virtually inevitable, try baking it into the existing rounds of amends, by adding in additional time.
So how much time should I allow for amends and changes to the project?
The number of rounds of amends in a project is usually variable depending on the phase. Ordinarily, the number of rounds of amends on a project should decrease the further down the road a project it is. At the beginning of a project, while it’s in UX, expect 3 x rounds of amends on each deliverable; sitemap, wireframes and prototypes. It’s better to allow for these amend cycles up front, then have them later. Once in design, allow for 3 x rounds of amends on each deliverable; look & feel, and layouts. In development, everything should be locked down so allow for 1 x rounds of amends on back end and front end interface development.
Allow for internal amends
One thing which can often be forgotten is allowing time for internal amends. It’s sometimes the internal amends, especially in creative, which require the most time. Rather than listing these as line items on your project plan, simply bake this into the development time – it’s hard to explain to a client why they should have to wait or pay for your team not getting it right first time!
Allow for some scope changes
Remember that some changes, while out of scope, might become within scope due a change request. If at all possible, it’s worth allowing for this right at the start of the project. Yes, this is essentially adding fat to a project timeline, but if you can afford to, it’s better to do it at the beginning of a project, rather than having the additional scope added, and for whatever reason, being told that the timeline needs to stick to the original delivery date.
Once you’ve pulled together your idea of how much time should be allowed for amends, make sure you’ve got buy in from the whole team, especially creative! It’s essential that everyone knows what there are time and budget to amend, and what not.
7. Plan For It Not Going To Plan
Simply planning for the best-case scenario, or Plan A isn’t good enough. You need to bake into Plan A, Plan B and Plan C too.
Treading the line between optimism and pragmatism can be a difficult one when creating project plans. Creating a project plan which gives the flexibility to mitigate against unforeseen change is critical to project success. Simply planning for the best-case scenario or Plan A, isn’t good enough – you need to bake into Plan A, Plan, B and Plan C too.
Don’t stick your head in the sand
Being optimistic is nice, it’s fun, it’s easygoing. But it’s also a very quick way to shortcut project failure. You need to be realistic and anticipate for the fact that no matter how good a PM you are, projects don’t go to plan. Things always take longer than they should. Things are going to go wrong, people are going to be ill, you’re not going to get resource when you need it, the client won’t like the design, the client will change the scope and the developers will struggle for ages with Android 2.1 and a slew of ie8 bugs.
Turn over every stone – identify the risks
It’s worth sitting down with the team at the beginning of the project and exploring with them the parts of the project that make them nervous. There will always be something that’s making people slightly uncomfortable. It could be that there’s a new CDN, a new CMS, a new prototyping tool, or even just that someone hasn’t got the software they need or their computer is on the blink. Whatever the potential pitfalls and risks could be, you need to make sure you know each one of them so you can account for them.
Explore the alternatives and actively mitigate against risk
So how do you actively manage and mitigate against risk within your project timeline? The key is to throw aside your optimism and develop worst case scenarios. You should be asking yourself ‘What would happen if…’ and develop alternative timelines based on those scenarios. Together with your risk register, identify which risks are high impact and high probability and build your project timeline around mitigating against those risks becoming issues.
Remember the unknown unknowns and load on the fat
There are known unknowns and unknowns unknowns – the latter is much harder to mitigate against. Consequently, it’s more prudent to put away your optimism and be pragmatic and realistic about the reality of projects. There’s a high probability that something will come up in the project that you didn’t anticipate, nor had identified as risk (whether or not you’re at fault for that). So the only way to mitigate against this type of risk is to plan for it the only way you can – add in additional buffer to your project timeline.
8. Finish Well
Finishing projects properly can be a tricky business. Make a robust plan and allow ample time for the closing phases of your project as you load content, QA, test, get approvals, make DNS changes, and deploy to production.
You’d hope that the closing phases of a project always might be straightforward, but in reality, they’re far from it. The end of a project brings together all dependencies, some of which might not have been worked on in months, in order to complete.
Remember the hidden phase
Planning out the final phases of a live project can appear to be some of the most straightforward – finish it off and just get it live! It can also seem like one of the most unproductive; after the productivity and excitement of new ideas formed in UX, creative being birthed in design, the technical development and functionality being worked through in development, it’s easy to think of a project as being pretty much complete.
However, the final stages of a project can be the most complex as dependencies are fully realised so having a proper plan in place to make sure everything can be deployed live and the project closed properly is important.
Build in the closing dependencies early
The kind of things that can get missed off of a project in the closing phases are usually the things that are dependent on other things so can’t be auctioned earlier. Content, SEO, servers, hosting, database migration, DNS configuration and third party integrations all need to be built into the timeline and the specific dependencies defined so that there are no delays at the final phase of the project.
Finishing well means QA’ing properly
Part of finishing well is ensuring that quality control or assurance (QA) has had a chance to properly validate the site. Just because there are no clear deliverables from a client’s perspective, doesn’t mean it doesn’t take any time.
In order to QA properly, make sure you build into your project plan the development of test cases. The test cases will be used later to validate whether or not your project has passed. It’s best to create these test cases early on so they can be agreed with the client what constitutes a pass or fail.
Remember to build in external and internal approvals
When a project has passed QA, there will be a need to get final approval of the project’s deliverables. It’s always useful if you can then build in time for an internal approval cycle so that you can get the green light from all internal departments that the project is approved as complete.
There can also be snags in approvals; if the appropriate stakeholders haven’t signed off a project at the right points earlier in the project, you can find the whole project delayed at the final hurdle. To mitigate against this, build in the planning and implementation of these early on.
The external client approval can often be the most lengthy as usually a larger pool of stakeholders have to be included who feel bad if they don’t try and change something; ensure not only extra time for approvals is included, but additional time for amend cycles too. Try building in 3 x amend and approval cycles to give adequate time for all stakeholders to provide input.
Define your deployment strategy
Going live is rarely a simple switch. Remember to fully define the deployment strategy and define the steps required for deployment from the local environment, through staging, UAT, production and finally the steps to go live. Ensure you build in adequate time to migrate databases, make DNS switches and finally for caches to clear or load. As much as possible forward plan the deployment so that there aren’t unforeseen delays at the end of the project when everything keeps trying to load the project and can’t understand why it hasn’t updated yet.
9. Post-Project Review & Optimization
One of the most overlooked parts of a project is what happens when it’s gone live. In the euphoria and excitement of delivering a project, scheduling the effective close of a project is sometimes overlooked. All too often a project plan will end with a single milestone, the project live date. While a project might be live, it’s not over. In fact, the end of the first phase of a project should really just be signalling the start of the next phase. In this section, we’ll explore how you can ensure your project plans account for the complexities of the post ‘go live’ phases of a project.
Don’t stop smoking
Post live, ensure that there’s an additional post live phase of Quality Assurance (QA). If you don’t account for this up front not only will the client be surprised when everything’s not working perfectly, but you’ll find that your resources have already been reallocated to another project, and it can be difficult to get them back! When creating your project plan for the closing phases of your project, ensure you schedule smoke testing after the project has gone live, and additional resource to fix those sneaky bugs that only ever appear in production.
Be clear about when it’s over
It can be tempting to end your project plan with a convenient milestone, labelled Live. It feels good. The problem with doing that is that it’s not really accurate. There’s always going to be the post-live activity that needs to be accounted for, and planned. It’s important though to be clear where one project ends, and where the next one begins. The scope of work document should clearly define when a project is complete and all in-scope deliverables are delivered. Wherever possible, I’d suggest it’s important to allow the project to percolate before you schedule proceeding too quickly to an enhancements phase. Some of the biggest and worst mistakes to projects are made trying to make quick fixes to a project in the days just after it goes live.
Test and analyse
Schedule a code freeze. Instead of scheduling the inevitable period of knee-jerk post live quick fixes, try and be a bit more strategic. Build into the project plan a phase for testing and analysis to measure how the project is performing against the KPI’s. This phase will enable you and the client to ascertain the extent to which the project is getting results. Schedule within your project plan working sessions with client stakeholders, user testing focus groups and reviews of the analytics to identify any issues and explore opportunities to optimise the project.
Create a roadmap
When you’re clear about the issues and opportunities, scope out the updates and create a roadmap for the updates, creating a project plan to schedule the implementation. If you’re not careful you’ll end up with a mishmash of change requests with no particular structure. Instead, plan it out taking into consideration the client’s budget and the importance rather than the perceived urgency of the changes. Start by with any quick wins and plan out the bigger opportunities and enhancements so that the client knows what they can expect, when.
Optimise, analyse, repeat.
Got the roadmap approved? Now start implementing each of the enhancements. Be sure to keep scheduling into your project plan an analysis and optimisation cycle even after the initial roadmap is complete.
Review and take heed of lessons learned
If we’re going to become more effective project managers, an important step in every project is to learn from it. Post project reviews are essential. But if you don’t schedule it, it won’t happen, and memories fade quickly.
The post project review meeting to analyse what went well, what didn’t go so well, and what can be improved on for next time. Schedule review meetings to take learnings from everyone who was involved in the project, including the client. Ask yourself how this should shape future projects and make sure you share your learnings with the rest of the Project Management team.
10. Milestones & Baselines
We’ve now covered the basic elements of creating a project plan – but how do you create a project plan to keep a project on track?
Why bother with project baselines and project milestones?
It’s a fair question, are milestones and checkpoints really that important? Using project milestones ensure that when the project starts, the project team and the client are clear about the key dates the project needs to hit to stay on track. For clients who find it difficult to understand or read Gantt charts, project milestones are a great way for them to understand a project’s flow, and the key dates within the project – providing deadlines and cut-off dates to ensure a project stays on track. A project baseline can be useful for managing the client as they record the original timeline of a project so that any deviation from the original plan can be tracked.
Where to begin
In order to help you keep track of whether or not your project is running on schedule, add in milestones – a milestone significant event in a project that occurs at a particular point in time. They may indicate either the start or completion of a significant series of events. Create milestones in natural, important control pints in the project that will be easy for everyone to recognise – for example, ‘Client supply of copy content’ or ‘Complete UX Phase’. The project milestones identify major segments of work and an end date for each of them.
When your project plan is finally signed off, it’s time to baseline – the project baseline is simply a snapshot of your project plan at any given time. Baselines help you see what has changed on your project by giving you something that you can refer back to. Project milestones are simple – they ensure you stay on track, they’re a date that you have to hit whereas baselining enables you to track your progress against your original plan and should your project fall behind, it’s very easy to identify what aspect of the project caused it to run behind schedule. Check out a quick guide on how to do this in MS Project here.
A quick note on milestones – make them zero-day activities – a milestone should indicate when something is completed. Also, insert them into the project plan with predecessor and successor ties, ensuring they’re logic driven, not restricted to a particular date in the schedule.
Create regular baselines
However, you should create regular baselines, especially after a major change to your project schedule. For example, if you add in a new block of tasks, change the project scope to include more work or to take out tasks, or your key milestone dates change, then it is a very good idea to create a new baseline. If you are updating the schedule as a result of an approved change that has been through the change control process, then it is a good idea to create a new baseline.
Update your project plan regularly
Remember to update your project plan regularly. Your project schedule will change as tasks are marked as completed, new tasks are added, or dates change. It might be tempting to create a new project baseline every time you change something on your schedule, but that really isn’t a good idea. You’ll end up with far too many baselines and it will be difficult to know which one to use if you want to see what has changed.
11. Summary: Creating A Perfect Project Plan
In the past ten sections, we’ve covered a few of the basics of the project planning process – creating project plans. In this section we’re going to give an overview of a few of the key learnings from each of the sections which outline the basics of the project planning process:
Define your workflow
When creating a project plan, the temptation can sometimes be to start adding in all the tasks that you need completing. But before you add in specific tasks and project milestones, make sure you get the overall project structure right. This means first defining the workflow and what the different phases of work will be. If you get this bit right, it makes adding in specific tasks afterwards much more straightforward. At this stage, you’re not thinking about the actual tasks but how the tasks can be grouped together and the subsets of work within each phase.
Establish your planning horizon
A planning horizon is the is the amount of time that it’s feasible and viable to forecast into the into the future when preparing a project plan. In general, the length of the planning horizon is dictated by the degree of uncertainty in the external environment: the higher the uncertainty, shorter the planning horizon. It might not be at all feasible to plan out the whole project in detail, so plan in detail only for what you know, in the phase that you’re in, and make generous allowances for the rest of the project.
Break it down
With the workflow established, the planning horizon defined, the high-level planning needs to start to become more detailed – it needs to be broken down into as many small sub-tasks as possible. When you’re trying to accurately estimate how long a stage of the project is going to take, it’s important to split the tasks into as many constituent parts as possible. This means taking a task and defining all the sub-tasks that make the sum of that task, and for those tasks, doing the same so that each sub-sub-task can be assigned a specific timescale.
Ask, don’t guess
When you’re under pressure to produce a project plan the easiest thing to do is just to guess how long each of these constituent parts might take to complete. That’s an option, but not a particularly clever one. Guessing will not only just give you a poor timing plan, it’ll give you no foundation for discussions with the client, and there’ll be no one else to share the blame if you guesstimate incorrectly.
Question when questioning
Beyond just asking someone to estimate how long something is going to take, you need to help them understand the context around their estimation. It’s no good just asking someone how long something will take in isolation. As they provide you with a timeline estimate, you need to begin to interrogate how they came to the number. You’ll often find that as you begin to tease out the details of their estimation, they’ll begin to think of elements that they forgot to include and you’ll begin to get an understanding of dependencies around individual tasks.
Allow for amends
One thing often missed in creating a project plan it’s allowing time for review and amend cycles. Amends or changes to a project are inevitable. Clients like to change things, and put their mark on a project. So no matter how closely you think you’re aligned with your client on a project, you need to allow for amends.
Plan for it not going to plan
Treading the line between optimism and pragmatism can be a difficult one when creating a project plan. Creating a project plan which gives the flexibility to mitigate against unforeseen change is critical to project success. Simply planning for the best case scenario or Plan A, isn’t good enough – you need to bake into Plan A, Plan, B and Plan C too.
Planning out the final phases of a live project can appear to be some of the most straightforward – finish it off and just get it live! However, the final stages of a project can be the most complex as dependencies are fully realised and the importance of having a proper plan in place to make sure everything can be deployed live and the project closed properly is important.
Post project review & optimization
One of the most overlooked parts of a project is what happens when it’s gone live. In the euphoria and excitement of delivering a project, scheduling the effective close of a project is sometimes overlooked. All too often a project plan will end with a single milestone, the project live date. While a project might be live, it’s not over. In fact, the end of the first phase of a project should really just be signaling the start of the next phase
Milestones & Baselines
In order to help you keep track of whether or not your project is running on schedule, make sure your project is littered with milestones, so that when the project starts, everyone is clear about what progress looks like, and so that it becomes clear very quickly if the project is running behind schedule. Using milestones ensure that when the project starts, the project team and the client are clear about the key dates the project needs to hit to stay on track.
Bonus Content: Project Plan Template
To make it easier to understand how to create a project plan, we’ve created a sample project plan template that’s more than just a simple project plan template – it’s 140 line items detailed for a website redesign project. We’re sharing it for you to download, use and abuse. It’s created in Microsoft Project as a .mpp file, but you’ll also be able to upload it to web-based tools like Smartsheet too. One of the easiest ways to learn how to make a project plan is to start by editing another one. So end your search for a Gantt chart template, we’ve got it right here for you!
As a caveat, this project plan template will give you a head start, but you’ll need to tailor the project plan for your needs. This timeline is a hybrid approach, typically used in agencies for a website redesign. We’re sharing this to be indicative of a how a project plan timeline can be created, rather than trying to advise on a particular process. To that end, it’s over simplified – particularly in the Craft phase – you’ll need to tailor the process to your needs.
As you’re using the project plan template, make sure you change the client approval cycles – you may need more or less time to make amends and get it back to your clients. Finally, we’ve included US stat holidays for 2017 but you’ll need to add additional non-working days.
What Do You Think?
Do you think we’re missing something? We’d love to hear if you’ve got any thoughts on developing a project plan – why not join the conversation below?