How to Plan a Project in 10 Easy Steps

Planning a project is complex as there are so many variables that can take you and the team off track. I’ve learnt the hard way from making mistakes and on many occasions by not doing enough planning to give my projects the greatest chance of success.

After over 16 years of working in Project Management, I’ve learnt that it’s less about trying to plan for every possible scenario, as you’ll never start the project if you do, but more about setting up the frameworks and understanding of what you need to do and how you’ll do it.

I've created these ten steps to help you structure how you plan a project from day one. Each step includes additional tips and approaches that you can take and adjust for your project.

The guide is written assuming you’re having collaborative planning workshops, but there is no reason why these steps couldn’t be done either remotely or over a longer period of time.

The time it takes to work through these ten steps will vary depending on the size of the project, the team and the availability of your stakeholders. On a smaller project with a smaller team, with everyone in the same room, you could run through all of these steps in one to two-day workshops.

For larger-scale projects with multiple teams and decisions makers, you’ll need to plan for this across multiple workshops across a week.

I've always learnt the most when things haven't gone to plan, so these principles and this guide are to help you not make the same mistakes.

Here’s what we’ll cover.

My Five Project Management principles for success

Before we jump into the ten steps, these are my five key principles that I use as a Project Manager.

Projects like life, never go exactly as you plan, so the more you can learn from others and to help plan for when things go wrong, the more likely your project will be a success. 

Don't be afraid to fail and or share what you don't know (principle 3), as being honest, matched with good communication on why what you're doing it, often results in a more positive outcome.

Principle 1: Kill all assumptions  

Kill all assumptions, that's it. Assumptions will come back to bite you so kill them off before they do!

Regularly ask yourself the simple question “Have I assumed that will happen, or do I know it will happen?” Lot’s more on killing assumptions in step 5.

Principle 2: You don’t need to know everything  

You think you need to know everything but this is why we work in teams and-and that’s why they're called teams. Share the workload and utilise the different skills within your team to get the best possible results.

Principle 3: Be transparent with what you know and what you don't know  

Sharing what you know can help your team, but not sharing what you don't know will hurt them. Create a sharing environment where this openness is encouraged.

Principle 4: Always be thinking about what could go wrong

Always, well nearly always, be thinking about what could go wrong. It's in our nature to think of the smooth path as it's less stressful, but it's up to you as the Project Manager, to have that ‘What could go wrong” mindset.

Use this mindset to ask more questions until you’ve done everything you can to reduce the risks of anything going wrong. 

Principle 5: Go deep and find the true why

Don't just define the roles and responsibilities of the team and stakeholders, but go deeper by finding out their goals, strengths, weaknesses, experiences and fears.

Some team members like to keep themselves to themselves, but they might have some nuggets of information that could be of huge value to the project.

‍

Step 1: Defining the Vision and Direction

Although all ten steps are important, this one is the most critical of all. If you are not aligned both as a team and with your client’s stakeholders, its doesn’t matter how well you plan your project, it will come crashing down further down the line if it’s not what’s needed.  

This is the step where you have to think very carefully about the questions you ask and don’t be afraid to ask tough questions, such as

“Why are you doing this?”

or

“What do you want to achieve from this?”

If the stakeholders can’t answer these questions, then you’ll almost certainly be going to have problems on the project, so push to get them.  

‍

THE PROCESS

1. Gather the stakeholders through a clear and concise brief. Set the scene with a pre-defined agenda articulating the activities you’ll run through and outcomes required from the session.  
2. At the start of the workshop, run through the planned activities and outcomes required, adjust and pivot where needed. Make sure the agenda is visible on the wall along with the outcomes for the session. Refer back to these to help keep the focus on what you want to achieve.  
3. Write up the vision early and put it up on the wall in large text so it’s visible. Don't expect to have the perfect written description straight away, but you must align with what the stakeholders want to achieve from day one.  
4. Discuss the key outcomes for the project. Outcomes are the results of the project once it’s in the user’s hands, not the deliverables of the project. Also focus on the outcomes for the stakeholders personally, for their business as well as their customers.  
5. Ask the tough questions, "Why are we doing this?”, "Who is this for?”, "What does success look like?”, “What are the impacts of not doing this?” and "What could stop us from doing this?”  
6. By the end of this process, you should have one statement describing the vision and several key outcomes for the project.  

‍

Step 2: What are the key Milestones?

After step 1, you’ll know the direction in which the project needs to go (the vision), the outcomes you want to achieve and a good idea of the overall ‘why?’ you’re doing this.

Next, you need to create the milestones of the project to allow you to build in its structure which you can then build the plan around. Think of these as the foundations, as without them you'll have many independent tasks without a clear endpoint.

Starting with milestones is a great way to begin planning a project as it stops you going straight into the detail, this can then sometimes result in losing the interest and focus of the attendees in the room.

THE PROCESS

1. First, start by asking the attendees in the room, what are the biggest milestones they can think of. They might not be the final ones you go with, but once you start putting them on the wall, it triggers more thoughts and ideas on what these need to be. The simplest ones to start with are: “When does the project start?” and “When does it finish?” followed by "What do you need to create?” and "By when?”. For example: “The initial concept design” or “The app ready for internal testing”. Is there a mid-project funding review, or a board meeting in which the project team will have to contribute to?
2. Next look at what are the milestones that will keep the project on track. This could be a full team risk assessment session or a collaborative product testing session with the business to maintain buy-in.
3. Once you have a number of milestones up on the wall, make sure everyone knows what these milestones mean and also what the impact of not hitting these milestones will have on the project. Also, whoever created a milestone needs to verbally explain what it is to avoid any misunderstanding.
4. Now discuss the risks around each milestone. What could prevent them from being met? You already know the impact of not hitting them, but what are the risks to stop you from hitting them? Assign owners to each risk with an action.
5. The last step is to agree on the dates for each milestone. You’ve probably already done this, but make sure everyone is an agreement on these dates and that they’re achievable.

‍

Step 3: Building the Plan

This is where you begin to add the detail around the milestones. What are the main activities you need to complete that will allow you to deliver against each project milestone?

The activities you add here, are really dependent on the type of project you’re planning for, so I haven’t added any specific examples.

THE PROCESS

1. You should by now have the project vision up on the wall and below that the high-level milestones with dates against them. Next add the dates for each week from start to finish, or if it’s a short project of only a few weeks, I would advise adding the days of the week as well.
2. Next look at each milestone and begin adding the main activities you will need to complete to meet each one. The majority of these will be sequential if you’re working with a Waterfall methodology, or if you’re using an Agile approach, the plan will contain more of where you would like to be on the timeline at each stage.
3. Once you’ve laid out the majority of the key activities and tasks for your team, add in anything that will happen outside of the team. This could be for work by 3rd parties, stakeholder approvals, creation of some marketing material. It really depends on the project type, but essentially anything that the project needs that won’t be completed by the immediate project team.
4. Once you have completed step 3, stand back and check the order and tidy up how it’s laid out on the wall to make it easier to read. This is key for step 4.
5. Now run through the weeks and months again to add any additional tasks you can think of.
6. Expect to add more tasks that come to light as you go through the remaining steps.

Don’t worry about trying to add absolutely everything as you’ll never finish, just create enough for a logical plan that works for the team

Step 4: Dependency Mapping

Dependencies are the relationships of the preceding tasks to the succeeding tasks. Tasks may have multiple preceding tasks and multiple succeeding tasks. The most common dependency relationship is a finish-to-start relationship.

Dependencies mapping doesn’t mean you link every single task. If you ask yourself what has a dependency, you could find one for every task and milestone on the wall.

This approach is all about finding out which are the key dependencies and planning for them. So the big ones, if there aren’t met, will either block the project’s progress or have a major impact on it.

THE PROCESS

1. Using the plan on the wall, first highlight and link with a marker, sticker or post-it the biggest dependencies. For example, a budget review session planned on the 1st of next month links to the team being able to continue to work on the project.
2. You then take this dependency and discuss what can you do to ideally remove it, or how to mitigate it. This could mean adding new tasks to reduce the risk impact of this dependency.
3. You can then look at how could you remove this completely. You have the stakeholders in the room, do they have any options to put a contingency budget in place now?
4. Check if you can remove dependencies by changing the order of the work.
5. Highlight dependencies that sit outside of the team. You’ll probably already have these following step three when you looked at the 3rd parties, stakeholder input etc. These are highlighted as they have a greater risk because you have less control over them.

‍

Step 5: Killing all Assumptions

Assumptions are project killers, they’re the easy route to take when planning as if you say

“I assume Dave is doing that”. You’ve assumed your job is done, no checking, planning or risk mitigation.

You better hope that Dave is doing that task though. Otherwise, you have the question when something goes wrong,

“Did you check that with Dave?”

When you find out that he hasn’t done it, it reflects badly on you as the Project Manager and also it impacts on the project and team morale.

You have to create a no assumption mindset as a Project Manager and coach the team to develop this too.

It’s okay to initially have some assumptions as there is no getting away from that, but the key is to raise them and turn them into action or remove them through discussion.

THE PROCESS

1. Take a step back from the plan you’ve laid out on the wall and ask “What have we assumed?” and pick a couple of key activities or milestones. For example, you may have placed a stakeholder review at a critical part of the plan, did you assume this will just happen? Probably yes, but make sure there are actions so this does happen.
2. Have you assumed anyone in the team can do a particular task? Do you know for certain they can do it or have done it before, or will you need to discuss it with them to verify?
3. Have you assumed any actions that are dependent on 3rd parties are achievable by that 3rd party? Do these 3rd parties even know about the project?
4. As you go through this exercise, make notes on the assumptions raised and discussed. Then adapt them into questions you can ask in future workshops or team meetings to help facilitate assumption killer sessions.
5. Any assumptions you don’t know the answer too, make sure they have an action to get the answer.

‍

Step 6: Risk Management, What could go Wrong?

"What could go wrong?” is the question everyone needs to be comfortable asking. Often as a Project Manager, you feel you should be in total control and know everything, but in reality, this won’t be the case as it must be a team effort to deliver a project successfully.

You need to feed this ‘what could go wrong approach’ into all of your planning meetings and catch-ups.

I’m not saying you have to literally say “What could go wrong?” every time, as your team will probably start to get a bit fed up with you, but you can adapt it into different questions depending on the scenario.

In a planning meeting: “Is there anything that could stop you from finishing this task?” In a daily stand up: “Have you got everything you need for those tasks to finish them?”

In a project health check review: “Is there anything that could stop us finishing this project?”

THE PROCESS

1. As this is the initial planning session asking “What could go wrong with this plan?” is a great way to start the risk management discussion. You need to get the conversation flowing to generate as many as possible worse case scenarios.
2. On the wall, map under high, medium and low the different scenarios that could derail the project. You can set a timer for 10 minutes and ask everyone to add as many risks as they can under each risk level.
3. When the timer is up, talk through each one so they’re all understood. The general rule is, if you put the post-it note up on the wall, then you need to explain it.
4. As you talk through each one, ask and check if the risk is added under the right risk level.
5. You’ll naturally discuss mitigation for each risk as you run through them, but if you have a lot of risks on the wall, just focus on mitigation for the high priority risks if time is an issue.
6. Now make sure you assign owners and dates either for the risk to be reviewed or completed.
7. Then place the high rated risks on the project plan wall space to really show the impact against the project.
8. Make sure you’ve also covered the risks raised in Step 2: What Are The Key Milestones and update the plan where needed.

‍

Step 7: What Reporting is needed?

Reporting on a project often doesn’t have enough of a focus as it’s deemed a given that we’ll just create the usual reports. For example, a weekly progress report, an updated plan etc.

There is nothing wrong with these report types, but what is usually missed is the real “Why?” behind each report and the outcomes the report hope to achieve. This can result in too much reporting, which can slow the team down or prevent them from working on high project value actions.

As it’s the start of a project, when you run through the report types that could be or will be created, the bulk of attendees are likely to want to receive everything as they feel they have to say this. In reality, this means the wrong people are getting the wrong reports and at the wrong time.

What’s needed is a greater review of who needs the reports and why and when. The process below explains how to do this.

THE PROCESS

1. The first step is to ask the attendees what different types of information would they like to personally receive during the project and place these insights on the wall. It doesn’t matter if you have loads of options at this point.
2. Then ask what information does their business like to receive during the project. This is the information they typically report on as part of their job. Put these on the wall.
3. Next ask everyone what information needs to be shared that, without it, the client can’t do their job. Mark these with a BC (business critical).
4. Next ask the question, “If we only report on these BC’s, would that be okay? “You’re asking as you want to make sure you get the fundamentals agreed and do it well. Additional reports can be shared, but make sure you get the BC’s right first from day one and expand from there.
5. Now separate these BC reports out from the list and ask, "Do you have a template for these BC reports you to have to use internally?“
6. If yes, review that reporting structure and look to replicate it for this project. This saves time for the client as they don’t have to copy over information. This is always appreciated. Also, include the format/file type as well as the font used. The font changing is a real last-minute pain!
7. Now ask who is the report for within the client’s business, their boss, CEO etc...? Depending on who this is, ask questions around what they’re really interested in and what’s important to them. This is so you can shape the report for the greatest impact and value for the recipient.
8. Discuss when these BC reports are needed so you can align with their internal reporting process. Ask when is the best time to share it with it them so they have time to review before their own internal status meetings.
9. Double check who receives this report. Be clear on who you’re sending these too, and if they’re not available (holiday) who’s the backup?
10. Ask if there is any file size or external links restrictions that may stop you from sharing it?
11. Once you have all of these reports on the wall, finish with double checking they're all needed, or if there are any that could be combined or simply shared through F2F updates.

‍

Step 8: Creating the Communication Plan

The communication plan is very closely linked to the work you’ve completed when discussing reporting in the last step. The only difference here is you’re focusing on the when rather than the what.

Another area of communication planning that differs from the reporting plan, is making sure you’re communicating progress and risks at the right time and to the right people.

THE PROCESS

1. First, start by brainstorming on the wall all the names and roles you need to be communicating any type of project information too. So who needs to be kept informed of anything on the project no matter what it is. This should be very similar to the reporting plan but could go wider within your clients business
2. Now with all those roles, sort them so they’re linked when it comes to seniority and who reports to who. You do this as in some cases the communication will happen automatically between an employee and his manager, so you don’t need to duplicate the communication in this plan.
3. Now create a timeline on the wall and depending on the length of your project this will vary. Assuming the project is a quarter-long (3 months), I would create the following:
4. A week view to show any communication that is happening daily
5. A month view to show any communication that is happening weekly or monthly
6. Then a full quarter view to show communication at the start, middle and end of the project
7. Next, place the names and roles from step 1, onto the timeline based on when you think they’ll need some form of communication on the project.
8. Once you have the names on the timeline, under each one make a note of the report title types you created in step 7 (What Reporting is needed?)
9. Next, discuss how you’ll manage ad hoc communications. This is communication for unexpected updates such as a major issue on the project that needs to be escalated. This doesn’t need to go on the timeline. Create a flow of how this communication will happen and to whom.
10. The final step is to stand back and look at the flow of communication and ask yourself “Is this enough, too little or too much?” To help with this, ask questions such as “If we hit a major issue, do you have a communication plan that can react quickly to this and to the right people?” Or “Does this communication involve the right people at the right time to keep them involved and help the team when needed?”

‍

Step 9: Creating the Team Environment

Without a close knit team, you’ll struggle to solve larger problems once the project is in flight. You’ll also see more problems get escalated, rather than the team themselves solving them before they even become visible.

Team building in this step isn’t about ‘raft building’! It’s first about creating the right environment from the start so your team can thrive, begin the project with a positive mindset and build a strong team over time.

To do that you need to consider the following steps to give the team the best possible start to the project. Just by having this conversation is a good start as you’ll be highlighting the importance of the team environment to everyone in the room.

In some cases, when doing the planning described in this guide, you might not even have the full project team in place yet. If you don’t, this is a great opportunity to discuss the benefits of having the team co-located. Even if you do, you can still follow these steps.

THE PROCESS

1. Start by reviewing the advantages and disadvantages of where the team is located and place these on the wall. For example, if the team is split across two offices, could this result in a high amount of communication on messenger apps, which then could impact productivity? Or, if the stakeholders are sitting at desks next to the team, do you need to be wary of too many check ins?
2. Once you have a wall full of advantages and disadvantages, vote on the top 3 which could have the greatest impact. So negatives for disadvantages and positive for advantages.
3. Once you have the top three, you then need to discuss how to make sure the advantages not only happen, but you literally take advantage of this situation by looking at other benefits the top three might bring.
4. Now review the top three disadvantages and discuss how you can either reduce their impact, or see if they can be turned into advantages.
5. You also need to look at how the team can present their work regularly to the wider stakeholder group. Make sure they have access to the stakeholders, so the team not only take greater responsibility for their work, but you empower them to do this as well.
6. Discuss the softer side of building a team through social events and small perks like acknowledging when the team or individuals have to work late. Can you get a pre-agreement that you’ll pay for pizza or that they can come in later the next day?
7. Agree on how the feedback loop will work to make sure the team are not just being listened too, but the issues they raise are being dealt with through retrospectives.
8. Review the team’s workspace as this is where they’ll be spending the bulk of their working life for the next few months. This might sound small, but making sure on day one that the team have decent chairs, monitors, clean desks and all the required plug extension leads and adapters goes a long way. This is the minimum a team should expect when they first start.
9. The last step is to cover what day one and week one will look like for the team. These kick off sessions need to be a mixture of inductions to getting to know each other, the project, and planning.

‍

Step 10: What Tooling do you Need?

Tooling on a project can have a really big impact on the teams’ productivity, morale, ability to report accurately and the communication plan you’ve agreed. In some cases, it can hide real problems that don’t come to light until it’s too late.

Creating and planning the tools you need is often overlooked as most companies have tools in place that either everyone assumes you have to use, or you’ve been told you have to use them.

The following procedures describe what you need to do to verify you have the right tools in place. If you don’t, make sure you’ve communicated the risks involved.

If you’re starting from scratch and you can plan the tools you can use on your project, then lucky you! This is the perfect chance to make sure the tools don’t define how you work, but define how you want to work first, then find a tool or tools to support this.

THE PROCESS

1. By this stage, you’ve planned out your project in a lot of detail and you’ll have a very good idea of not only the plan, but how the project team are going to work together. Under each step of the plan, such as reporting risks management, communication etc.. Now create a new section called tools. This could just be a post-it note with simply tools written on it.
2. Now under each section write down the tools you think you need to be able to deliver against this plan. These tools need to cover everything, e.g. email, Jira, a messenger app, file storage tool, etc.. Put down as many as you can think of that you might use or need, plus a few you would like to use even if they’re duplicated.
3. Then as a team mark the ones you think are absolutely critical for the project with a red tick or sticker, anything that will make them stand out and discuss why.
4. Discuss the tools without the critical flag. Can you remove these completely from the project? These might be tools that are part of your client's business, but I’m not saying you need to inform the business they’re no longer needed, it might just be for this one project they don’t apply.
5. Next look at the tools you’ve marked as critical and ask questions such as “Does this tool need to be digital?”, “Can we manage this by speaking daily or put this useful project information up on the project wall space?”
6. Now review your critical tools again and see how you can simplify their use by only using the must-have features. This is to set expectations early on how the team will use the tools. Focus on what the team really needs and the benefits to the project.
7. If you have any have tools that you feel are going to hinder the team, but have to be used because it’s company policy, make sure this is raised in the workshop to highlight the potential risks. Then agree on who will share these risks so the stakeholders are aware.

‍

Wrapping Up

Planning a project is tough, and it takes time, so use this guide to make sure you're covering as much as you can with a focus on what really creates value.

It's natural to fall into the trap of trying to think of everything, but you never will so focus your plan on what's really important for you, your client, its users and the project team.

Remember to utilise the team around you and don't be afraid to ask questions. The more you ask, the quicker you'll learn and in the long run, deliver a more successful project.

Keep notes of anything you learn or the processes you take to get to a result. The simple act of writing it down instils it in the brain, and next time you need that information, you'll have it to hand.

Please do take this guide and adapt it for your project and look for ways you can improve the processes described.

‍