5 steps to project scheduling

This is a guest post from Sam Palani. Find out more about him at his site or connect with him on twitter.

5 Steps to get your Project Schedule Correct

When I was asked to come up with a guest post for Stepping Into Project Management (SIPM),
I wanted to come up with something that was close with the central theme of the blog, which
is helping Project managers on starting their journey on the project management space. As a
newbie project manager (or for that matter even as someone who has been managing projects
for sometime) getting your project schedule correct early on is critical as this will be one of the
important baselines against which you would track your project execution.

I also want to call out one common myth / misconception here - A Project Plan is different from
a Project Schedule - no matter what they tell you. I will not go into details on this post, but to
summarize - A plan will include your strategy on how you will get there i.e. the end goal (scope)
whereas a project schedule is as the name suggests a schedule of tasks along with their

So it is critical that you get this correct as you take your first steps into project management.

Here are five simple but important steps that will help get your schedule correct:

Start with the WBS - First things first. Start with decomposing your scope into a work break
break down structure. While there are multiple rules around this, the general thumb rule is break
down your scope to work packages where each package can contain around 5-10 individual
tasks. Again this is a just a rule of thumb, the level of the WBS would largely depend on your
individual program or project. The idea here is to be able to tie back the individuals tasks that
will make up your schedule to the capabilities listed in the project scope.

Hint - Do not over do this to a level where you end up adding more complexity and management

Get your estimates on track - The next logical step is to estimate the individual tasks that
make up your work packages. How many resources you will need and how much time it will
take take for these resources to get the task completed. Avoid doing any fast tracking or
crashing at this stage. This is based on the assumption that you will be doing a bottom up
estimation, that is starting from the individual tasks and rolling up at the work-package level.

Hint - Make sure your estimation process & model is communicated and transparent to the
project stakeholders.

Analyze your dependencies - Most certainly your individual task will not be executed in silos.
They will have dependencies. These dependencies and constraints can be in different forms.
Example a task may have a dependency on a particular task getting started or completed as
well as there may be tasks that are constrained to start or end on a particular date.

Hint - Don't attempt to do this alone, get your SMEs involved in this exercise.

Calculate your critical path - Once your have your tasks,estimates and the dependencies in
place. You are now ready to to get the critical path. You either do this manually or through an
EPM software that you are using. It does not really matter. It is also likely that you may end up
with more than one critical path. You will need to pay attention to all the critical paths identified.
It is also important to note that during the course of the project your critical path might change
so your schedule is more of a living document and not static.

Hint - Often there may be tasks outside your critical path that will influence your project

Communicate - Now that you have done all the good work and have the project schedule
in place, publish it. Your project stakeholders including your team need to be aware of the
project schedule. The schedule would help little just sitting out there on your hard drive. again
a reminder that your schedule is a live document and gets revisited during the course of your
execution for instance every time you do risk assessment or change management

Hint - Include a link to your schedule in your project status communications.

So that’s it, you now have a schedule baseline against which you can monitor and control your


Anonymous said...

You've rightly said that traditional project management metrics are only important to the extent they support desired business outcomes. That's one of the reason's why my company has implemented a project management software to handle most project tasks across multiple projects. Right from resource allocation to task management and project collaboration. The software eases the entire project management process. Would you suggest any?