Home - White Paper Index
To Create a Microsoft Project Schedule or Not	First published April 06
Neville Turbit - Project Perfect	Rating
(Download pdf version)

Overview

A good starting point is to define what a project schedule is. There are two key dimensions to explore – the “why” and the “what”. Firstly, to look at the “why”, a schedule is:

• A tool to assist you plan a project
• A tool to help you keep on track

These are quite different functions. They require a different level of effort to undertake. Whilst planning may be a few hours, or a few days of effort, the tracking can become a full time job for a large project.

Secondly, to look at the “what”, a schedule is a place to identify work in terms of:

• Tasks
• Milestones
• Resources

Tasks are a way of documenting the work you need to undertaken, who will do it, and the time each activity will take. Milestones on the other hand set markers on the road to completion.

Planning

There is unlikely to be any disagreement in terms of the need to plan before you start. Every project manager will say you need to have a plan no matter how large or small the project may be. A scheduling tool or Gantt chart is ideal in most cases to document that plan.

To look at the alternatives, what would you use? A list of tasks in a spreadsheet, or a Word document? Something scribbled on a white board? The project would have to be very small to avoid a schedule. If your tasks number less than 10 perhaps you could get away without a Gantt chart but beyond that, it is hard to imagine not producing a chart. Even if you use a spreadsheet, you will likely produce a Gantt chart of some sort.

Resource Planning

In addition to the actual activity planning, you have the facility to look at how you can resource the project if you use a scheduling tool. How else are you going to know what resources you will need to use? How will you know where the resource overloads will occur? It is possible to do the work manually but it is much more difficult.

Scheduling Tool for Planning

So if we look at the planning aspect, it seems fairly obvious that a scheduling tool is almost mandatory. It is going to make your planning much easier and more flexible if you have a planning tool.

Project Tracking

This is where the value of a scheduling tool is most often challenged.

• “But I know where I am up to. Why do I have to spend hours recording it in a tool?”
• “The task is always 90% complete. Who knows what percent is complete if you have only done the easy bit?”
• “Team members update their time spent and most are just guessing how far they are through a task. It might be right or it might be wrong.”
• “So I spend time to make all these changes. What do I do differently then?”

All these are real comments from real project managers. They reflect distrust from the project managers as to the information in the schedule, and a perceived lack of value for the time they spend inputting the information.

Predictability of Project Tasks

To address the first issue above, the project managers are saying some tasks are just not predictable with any degree of accuracy. In many cases this is true. There is often a “hope” that over the length of the project, the plusses and minuses will even out. Many failed projects started with hope and faith.

If the activity has been undertaken a number of times before, and has a high level of repeatability, the estimate can be one with a high level of confidence. For example, if the task is to create the formwork for the 25 th floor of a building, and you have already built 24 floors, the accuracy of your prediction is likely to be high. On the other hand if the task is to investigate possible ways to merge two billing systems, the predictability is fairly low. You don’t know what you don’t know.

In order to meet schedules, a project manager often will cut the scope to fit the time available. We have four weeks to look at merging the two billing systems. What can we do in four weeks? The task is timeboxed and the scope is adjusted to suit. At the end of the day you may not have investigated all options, or the investigation may be superficial. The schedule has however been met.

To come back to the use of a schedule, the project manager feels it is a waste of time because the estimate is not one that has a high degree of accuracy. It is a chunk of time that he uses to do as much of the job as he can.

Time to Update

If there is a lack of confidence in the schedule, it is not surprising that there may be a reluctance to waste too much time updating the schedule. The schedule will not suggest to the project manager that something should be done differently. A good PM will be on top of the schedule without needing to document it (for a small to medium project at least). For some, it is recording history rather than providing a forward facing view.

I should emphasise that this is not the situation for every project manager in every project. Most project managers use a schedule and find it of value. There are however a significant number who find in some situations, the situation above exists.

Tasks Recording

If many of the tasks are highly volatile, and there is a high degree of granularity in the way the project is structured, it also can be meaningless. Tasks lasting a few hours start to become an overhead to update. If you have four tasks estimated at four hours each, what value is there to record the times as six hours, two hours, three hours and five hours? It still took sixteen hours in total.

Milestones

I often quote the following example. If I get up at 6:00 in the morning, I may take 30 seconds to walk to the bathroom. I might take 2:35 mins to clean my teeth. I might take 10:20 mins to have a shower. I don’t plan my morning by tracking each task to the second. I know that if I am in the kitchen to make breakfast by 6:25 I am on time. I know that if I have finished breakfast by 6:45 I am on time.

We live our life by milestones, not by task duration. If we adopt the same approach to projects, we can be far more focused on juggling a few tasks to reach a milestone. We don’t become unduly concerned if we take an hour more than we expect to do a one day task if we know we will make it up in another task, or by working back an hour.

Time apart for Milestones

How far apart should milestones be? From personal experience I would suggest at least one a week. for the project. There is probably some more scientific answer, but it seems to me that people can juggle a number of tasks within the horizon of a few days to a week. If you make it longer, the juggling becomes too difficult.

If you don’t have regular milestones, you live on faith. Faith that it will all work out at the end of the day. In the example above, if I did not look at a clock until I walked out the door in the morning, I would not know if I was on track, and not be able to make any changes to ensure I met my deadline if something went wrong.

Back to the Schedule

So if you want to track your project from one milestone to the next, how do you set your milestones? I would suggest it is almost impossible to set milestones until you know what the tasks are, and how they hang together. In other words, you need the schedule to set the milestones.

If we divide the question of the usefulness of a schedule into planning and tracking, the schedule is certainly relevant for planning. Once the schedule is set, and milestones created, the usefulness of tracking tasks precisely is less important. In a general sense, if I need to carry out five tasks to reach the next milestone, I need to know approximately how long I have to do the tasks. If I allow one day for a task, and it becomes apparent it will take three days, I need to do something to stay on track. On the other hand if it will take an extra hour, it is not so important. I would hardly waste time adding an hour to the task, and squeezing something else on the Gantt chart.

Granularity of Tasks

I have seen schedules that had tasks like “Obtain requirements” lasting two months. It is impossible to know if you are on track at any point in time. If it were broken down into things like “Arrange Workshops” and “Interview X” it does two things. Firstly it forces us to think through the activity in enough detail to ensure we have thought of most of the work, and sensibly estimated time. Secondly it means we can establish milestones within the two months. For example one milestone may be “Workshops Arranged”. Another may be “Branch Interviews Complete”. If we have these milestones, we can quickly see if we are on track.

There can be no hard and fast rule for how granular the tasks should be. Common sense should be used. Tasks however should not be weeks of work. They should more likely be a few days at most. If you are getting down to a few hours, perhaps you are getting too detailed. On the other hand, if there is a task that will take a few hours, and it is important that it be remembered, and it is not part of a bigger task, include it. For example, you may want to put in a task to “Visit workshop venue to check equipment”. It may take two hours. It may be part of the preparation, but it is important it is not overlooked.

The Big Project

I have worked on projects where we have had a person full time managing the schedule. Was this a wasted effort? I believe not. The project was so big and complex nobody could hold all the details in their head. On one occasion, there were over 150 people, and multiple project teams. Each team had cross dependencies. A slippage in one area could cause a ripple effect through the whole project. I once described it as being like a hire car business. The renter comes into an office, is allocated a car, and has to return it by a certain time. If the car does not come back by that time, somebody else will miss out on their rental.

In a project of that size, we allocate a chunk of work, people take it away and do it, and return it by a certain time so the next person is not delayed. If it is not done by that time, a whole lot of reshuffling needs to happen behind the scenes. This cannot happen without a tool to make it happen. Nobody can have the breadth of knowledge to shuffle all the bits in their heads and do it quickly enough to react. So, in this case, we need to track the “check-in” time of each task. Painful as it may be, we need to know where we saved time, and where we lost time. We need to calculate the impact on future milestones. We need to constantly shuffle resources and effort to avoid future delays.

Historical Information

One other reason put forward for recording actuals is the view that it provides guidelines for future project planning. This is a noble ideal but in all the organisations I have ever worked in, I am yet to see this actually happen. Perhaps it is just me, but I am yet to see a project manager delve into past projects to find out how long something took. Certainly I have discussed completed projects when doing some planning, but rather to learn the bottlenecks the previous project encountered. It is a good idea, but requires a highly sophisticated organisation with the infrastructure to support prior learnings.

Earned Value

One point is worth mentioning. If the project is being managed using earned value, then you do need to track task times. Earned value relies on tracking actual time spent in order to calculate the parameters. If your organisation is using this measure, the discussion in the white paper will not take place.

Conclusion

We have explored a number of facets of using a scheduling tool. It is hard to deny there is value as a planning tool. The perceived lack of value is in the recording of actual time spent for small to medium projects. I have to admit to personally ignoring time spent in some situations and focusing on the milestones. I do however review the current and forward tasks to see if the estimates are still current. I know how much time I have allocated to immediate work and focus on how well we are going. Sometimes I may record it, but in other cases I may not. It depends on the complexity and the environment.

I am sure the debate will go on into the future. I hope however that this white paper will put some context into the discussion. There is no right answer across all projects. It all depends on the project, the company, the complexity and the skill level. Hopefully after reading this, you will be able to make a more informed decision as to the level of detail to capture.

To date, 13 people have rated this article. The average rating is 4.46 - Add your rating. Just select a rating and click the button. No other information required. Only one rating per person is allowed.

Create a schedule or not 1 2 3 4 5

Return to the top