A project plan gives you a way to structure and organize your project. It’s also helpful for tracking progress and ensuring that timelines don’t shift unexpectedly.
What is a Project Plan?
A project plan is an in-depth list of the tasks, resources, and management decisions required to complete the project.
What’s in a Project Plan?
A project plan should include, at the least:
- Scope: What the features of the project will be. This includes what the project will accomplish, and might also define what isn’t in scope.
- Tasks: What your team will need to do to deliver these features. They might be high-level if you’re using an Agile methodology, or quite low-level and detailed.
- Schedule: How long the project will run. This is typically an estimate; some projects will instead set a hard deadline and cut down the feature list to fit instead.
- Resources: What your team will need in order to complete the project. This might include subject matter experts, data, computer processing power, and specialty machines.
- Budget: The expected cost of the project, which should include the team’s salaries and the costs of any extra resources.
- Stakeholders: The people who have a vested interest in the project. This could include departments external to the project team, as well as customers, managers, and CXOs.
- Communication: How you’ll communicate throughout the project, what you’ll communicate, who you’ll tell, and the people responsible for each part. This might include reports, presentations, emails, and demonstrations.
- Risk: The possible risks that the project might face. This could include external, consequential, personal, technical, or supply risks.
Project Plan vs Project Charter
A project charter tells you the why. It lays out the problem you’re trying to solve, and the scenarios that your business is likely to face if it doesn’t solve them. It gives inspiration and motivation.
On the other hand, a project plan tells you the how. It details the solution and everything that you need to do and obtain to reach it.
Project charters and project plans are complementary documents. For best results, create both.
How to Write a Project Plan
Scope
Decide which features are essential to the project, and which are “nice to haves.” Start at a high level, with large components of your project, and then break these down into smaller component features.
For example, if you were building a car, you’d at least need wheels, a car body, and an engine. Without those features, your end product won’t be a car. So those are your primary features, but of course, to actually put them together into a workable design, you’ll need to drill down further. For example, your wheels need axels and tires. Your engine needs a fuel source and a delivery system, as well as an exhaust, and cooling options. The car body needs a windshield, windows, car seats, a steering system, speed regulation pedals, etc.
Your scope needs to be detailed enough that any scope creep – when the features of a project start to morph and increase – can be minimized by referring back to the scope.
It also needs to be agreed upon and signed off by all stakeholders. This is a key area of conflict in many projects, and the best way to handle it is by ensuring that your specifications are thorough and that everyone understands and agrees to it.
Tasks
While your scope is like a destination, your tasks are your map to getting there. Map out what your team needs to do to make your product features a reality. This needs to include not just research and development tasks, but also testing, quality assurance, and documentation tasks.
If you’re following an Agile methodology, you’ll most likely create these tasks at the start of each sprint rather than at the start of the project.
Schedule
There are two basic ways – and many variations – of setting a schedule for a project. The first is to estimate the time required to complete each and every task, then add up all this time, add a buffer, and make this the project time. The second is to set a time period, then work out which features and tasks can be completed within that time period. Whichever you pick, you’ll still need to be vigilant against scope creep and time blowouts.
When estimating the time it will take to complete a task, take into consideration:
- Whether you have enough information about the task to give a firm estimate.
- The estimate given by an expert in the task.
- Who will actually be completing the task.
- The risk factor in the task – how likely it is to contain unforeseen complications.
Bad estimates are often caused by not duly considering the above factors. For example:
- The person estimating the task doesn’t understand exactly what will be involved in the task and gives an estimate far too high or far too low.
- A manager estimates a task they’ve never performed based on how long they want the task to take.
- A comparative beginner performs a task that was estimated by an expert who assumed they would be completing it.
- Partway through a task, an employee discovers that the software in use does not provide the functionality needed to complete the task.
Resources
Making a list of project resources requires both imagination and firm control. It’s easy to go overboard and employ too many resources; however, it’s even easier to do the opposite and get too few. Counter both of these by brainstorming with the team who’ll be doing the work, then in a separate session, paring down the list of resources into essential, important, and nice to have.
Budget
A project’s budget can either be the start or the end of its planning stage. You might set a budget first, then manage the schedule, scope, and resources to fit. Alternatively, you might set the schedule, scope, and resources required, then figure out how much the project will cost.
Stakeholders
Create a list of people and departments who have a stake in the project. Get their feedback at key points during the project. Ensure that you have a communications plan in place to keep stakeholders engaged, informed, and on-side.
Risks
Every project contains an element of risk. Identifying risks won’t eliminate all risk from your project. However, completing a full risk analysis and mitigation process can help you ensure that you’re ready for the most likely issues and have a plan to deal with them.
Project Planning Tools
There are a lot of tools that you can use to plan out your project features and keep it on track and within scope. See the most common in our articles on project tracking tools and project management tools.
When to Edit a Project Plan
You should edit a project plan when:
- The timeline changes.
- The schedule is inaccurate.
- The scope changes.
- You have extra data that might affect the plan; for example, new risks have come to light because of changes in legislation.
- Your team changes.
The key point to keep in mind is that every element affects the others. If your scope changes, for example, you need to modify your project schedule and budget. If your schedule is found to be inaccurate, then you need to either change your scope or the people and resources assigned to the project.
Example Project Plan
Amber’s company needs to make accessibility updates to its Android app. This will be a feature-focused project; certain features must be added. However, the company works in an Agile methodology, so the project plan needs to align with that.
Scope
An accessibility audit has identified four areas in which the app lacks accessible design:
- Responsive design to allow for different screen and font sizes.
- Useful labels on screen elements.
- Keyboard controls.
- Captioning on all videos.
She prioritizes these areas in the backlog, so they’re given to the team in order of priority.
Tasks
At the start of the first sprint, the team receives the responsive design feature to work on. They come up with tasks for the sprint:
- Investigate the limits of the current design.
- Identify elements to be made responsive.
- Identify functions handling screen drawing and placement.
- Fix elements.
- Trace and fix functions.
- Create and schedule daily automated accessibility tests.
- Run manual accessibility tests.
Schedule
After talking to the team, Amber estimates a one-week sprint for each feature except the captioning, which she estimates is worth two sprints.
She creates a Gantt chart to track project progress and adds the main features in their priority order. As each sprint planning session occurs, she updates the Gantt chart with the tasks to be completed and tracks the team’s progress.
Resources
Amber talks to the team before beginning the project to discuss resources. They have a full team and most of what they need – except a platform suitable for testing accessibility issues in apps. So she lists that as a necessary resource and sets the wheels in motion to find a suitable platform before kick-off.
Budget
Amber lists all costs for the project, including her team’s salaries for the projected five weeks and the automated accessibility testing tool.
| Item | Amount |
|---|---|
| Team member salaries – 100% allocation | $60,000 |
| App accessibility testing platform | $1,000 |
| Existing SaaS platform licenses – ongoing – 6 users | $1,900 |
| Utilities and other misc | $1,100 |
| Total | $64,000 |
Stakeholders
Amber lists the various stakeholders for the project:
- Project owner
- CEO
- CTO
- Marketing department
- Project team
- Customer service team
- Customers
She knows that some of these are relatively uninterested in the project, while others are skeptical that it will make any real difference. Some stakeholders will be affected by the changes. She groups stakeholders into categories:
Convert
- CEO: doesn’t see a need for the project but is willing to accept the CTO’s word that it needs to go ahead. Mildly hostile but won’t actively block.
- Customers: don’t think it will make a difference. Some have been requesting change for years and are cynical.
- Marketing department: doesn’t see a need for the project. Might actively block any efforts to combine resources.
Enthuse
- CTO: doesn’t really care one way or the other; customers who need this seem too small a segment to worry too much about, but she knows that regulations in the US and EU mandate it.
- Project team: a couple of team members don’t really care about the project – they’re happy to do as directed, but won’t go the extra mile.
Affected
- Customers: they’ll have a different interface to use; one that will be easier for some but will require a cognitive switch for everyone.
- Marketing department: a more accessible app needs to be marketed accordingly; no point in making the app accessible and then marketing it in ways that its target market can’t access.
Inform
- Customer service team: the team understands the need for the project and will be on hand to offer information if needed. Its involvement in the project is fairly minor, and members of the team just need to know what’s happening so they can field customer support queries after release.
Communications plan
She puts together a basic communications plan for the project:
Before
| Week | Communication | Audience | Details |
|---|---|---|---|
| -1 | Individual phone calls or emails | Customers who’ve made accessibility-related complaints to customer service | Recruit people for a focus group who’ll answer questions from the team and look at early prototypes of the new version. |
| 0 | Kick-off meeting | Internal staff | A brief video of a real customer with vision issues talking about their difficulties with the app. Regulations around accessibility and the reasons for them. Stats on the number of disabled people making decisions about app purchases in our target market. Benefits of the project. |
During
| Week | Communication | Audience | Details |
|---|---|---|---|
| 1 | Meeting | Marketing team leader | Outline the accessibility issues that the project team will be working on and how marketing materials will also need to be modified to suit. Highlight that the increased accessibility can improve SEO and ad campaign effectiveness. Share other companies’ stats or case studies on how accessibility improvements increased ROI for marketing campaigns. |
| 1-5 | Weekly email update | All internal stakeholders | Include project progress and results from the focus group, including brief videos to boost the personal factor. |
| 1-5 | Weekly email updates | Focus group | What the team has been working on How their app will have changed. Instructions if needed. Walk-through video and text explanation. Ask them to complete a survey each week. |
| 2-6 | Release emails | Customers | Update customers on changes that are coming up a day or two before the release so they’re prepared for a difference in their interface. Explain why the changes were made and why they’re beneficial. |
| 2-6 | Demos | Internal | Show the CEO, CTO, project owner, and any other interested staff what’s changed in the app at the end of each sprint. |
After
| Week | Communication | Audience | Details |
|---|---|---|---|
| 7 | Project wind-down | Internal | Demo the finished version. Give stats based on survey results that show the early responses from the target market. List any next steps, including marketing materials. |
| 7 | Project wind-down | Focus group | Update on the progress made and thank them for their assistance. |
| 7 | Project wind-down | Customers | Write up the changes made and why. Explain the benefits to the focus group. |
Risk
Amber sits down with the team to talk through any risks that the team might face. With the small project size and time frame, the only major risk they identify is that the app accessibility testing platform might prove not to be fit for purpose. However, they have a focus group in place that should catch major issues if they can’t use the platform. So they plan to set up user testing through an online provider, using real people, if the need arises.
