Putting together your project schedule is probably the most important thing that a project manager can do. It’s the basis of what you need to be able to manage your project effectively. In other words, without a schedule you will have a tough time getting your team on the same page as you, and getting the work done! Here are 5 planning mistakes that new project managers sometimes make when putting together a project schedule.
1. Forgetting milestones
Project schedules need milestones. A milestone is a point in time that marks the completion of a set of tasks or phase. They are useful for tracking and reporting, and they highlight important dates. Some examples of milestones are:
- Requirements gathering complete
- Testing starts
- Board meeting approval due
- Deadline for project budget review
- Client sign off achieved
They aren’t tasks that take several weeks or days; instead they represent a fixed point when something is done or should be done.
Scatter milestones throughout your project plan at logical places like the end of phases and on key dates. Aim for a milestone a month as a minimum, but work out something that is sensible for your size of project – some months you might have none, for example, but in other months on a large project you may have several phases or workstreams finishing at the same time.
2. Not linking tasks
Project schedules are made up of tasks, but some tasks have to happen in a particular order. You can’t, for example, paint the interior walls of a house until the roof is on. Or you could, but it wouldn’t be particularly sensible!
Dependencies are the links between tasks. There are a number of ways that you can link tasks so that they start together, end together or start or finish one after the other. You’ll have to choose the best way to make the tasks link together in a logical sequence, but once you’ve done that your project management software will take the strain and can calculate the new dates for you.
If you don’t link tasks, you’ll find that your schedule won’t be accurate and is likely to finish sooner than your project work in real life! So it is worth spending some time to establish the logical order for your project activities.
3. Not working with your team
You can’t put the schedule together yourself, although many project managers try to do this. You’ll always fail, and you’ll always build a project schedule that the rest of the team don’t buy into. Use a tool like Seavus Project Viewer to make it easy for everyone to see a draft schedule, and then work with them to flesh it out and add more tasks.
Creating a collaborative plan with all your team members involved is the best way to make sure that you don’t forget any tasks. The people doing the tasks will also be best placed to tell you how long things are going to take. One risk of not involving the team members is that you’ll make up estimates that sound realistic to you, whereas they would estimate based on their experience on other projects. In other words, you’ll end up with better buy in and a more accurate schedule if you include others in your planning.
4. Not managing change
Project requirements change, and that has an impact on the schedule. However, many inexperienced project managers won’t take the time to update their project schedule, instead trying to stick to the original dates. That’s impossible. You can’t do more work as a result of a scope or requirements change and still manage to complete all the work on the same date (well, there are ways to try to do this, but that’s the topic of a different article!). You need to focus on what is achievable, and that normally means making changes to your schedule to accommodate the change.
You can choose to keep the dates the same and drop out other tasks to make space for the new requirement, but whatever approach you take to managing change, it’s important that you update your schedule to reflect the current situation. If you don’t, your schedule won’t be a useful tool for managing the project, and instead it will become a historical document reflecting what you thought you would do.
5. Not taking baselines
If you want to record the historical perspective, that’s where baselines come in. You can take a project baseline at any point in the project. A baseline is a snapshot of your project schedule at any given moment. It’s useful to take a baseline at the beginning of the project so you have something to compare back to, and then after any major schedule change. Then if you need to refer back to a previous version, you can do so easily.
Don’t create a baseline after every single schedule update or you’ll have hundreds of them and it will become really hard to know which one to use as a comparison!