Those who know me know that I am a huge fan of Microsoft Project when it comes to project planning. It allows me to model schedules to see the impact of different scenarios and helps keep the project on track. But a piece of software, whether MS Project or the many others out there, is not the key to building a schedule.
 
There are really only 2 things you need to build a project schedule that is relevant and will improve the success of your project: the project team and curiosity.

The Project Team

Over the years I’ve seen many PMs plan out a project while sitting at their desk. They never talked to anyone, called anyone, or showed the results of their efforts to anyone. This is a sure way to create a schedule that is meaningless for a few reasons:
 
• The schedule is only a reflection of what the project manager thinks will work, forcing tasks to meet a date they or an executive want to hit.
• They’ll miss work they aren’t aware of. In many situations this means the team will be left scrambling to make up time or they’ll just miss their dates altogether.
• Nobody has tried to poke holes in their schedule to see where there might be issues. Schedules longer than a few lines always need a second set of eyes to make sure it all hangs together.
 
To avoid these pitfalls, talk to the team and get their input on how the project schedule should flow, how much time they’ll need to perform tasks, and what they’ll need to get their work done. The schedule should be a reflection of how the work will actually be done so that you know if you’re off track.
 

Curiosity

One thing good project managers have in common is that they are curious. Curiosity leads them to ask great questions – what do you need to do next? How is that related to the other pieces of the project? What do you need in order to achieve that date? Asking questions until you truly understand what the team needs to do is key to project success. It not only gets the tasks out of the team’s heads but it also forces the team to think through and uncover new tasks they hadn’t thought of.
 
In particular, challenge the assumptions that are being made. You’ll often find that assumptions are made to avoid having to work through difficult questions. It’s like the joke about the scientist and the economist who are on a deserted island trying to figure out how to open a can of food they have. The scientist puts together an elaborate scheme involving a system to launch the can in the air, building enough momentum that it will crack open when it lands on the sharp edge of a boulder 50 ft away. The economist says “That’s too complicated. Let’s assume we have a can opener.” Watch out for bad assumptions!
 

The Mechanics

I’ve heard many stakeholders say that they don’t appreciate a project schedule because it’s out of date before it’s published, or that the schedule doesn’t reflect reality. Once you have input from the team, the mechanics behind the schedule can often be daunting. There are 3 key things that cause PMs heartache when developing a schedule:
 
1. Level of detail – keep it detailed enough to be useful, but high level enough that you can easily update it. Rule of thumb: no task longer than a week.
2. Tracking resources – if you don’t track resources via your plan, you won’t know if you have enough!
3. Socializing the schedule – once you’ve drafted it, review it with the team. Get their feedback and adjust it. Then lock it in and hold each other to it. Review and repeat every few days, but no less than weekly.
 

Schedule as Servant

At the end of the day, the schedule is there to serve the project. If things change, and the work is going to be executed in a way that is different from the schedule, change the schedule. But if the work is falling behind, it’s time to call it out and see if you can either get back on schedule, or re-baseline the schedule and stop fooling yourself that we “hope” we’re going to make it. Hope has no place in project management.