A Project Scheduling Primer
By Steven DeSomer
There are some very basic concepts that must be understood before Project Management can be successful. Success, in this instance, is defined as:
- Finishing Projects On Time
- Finishing Projects within Budget
- Delivering a Quality Result
- The status of the project is known and communicated throughout its lifecycle
- The impact of external influences is easily determined
- The workload of all resources is known, and planning for their availability for future tasks was relatively simple
This is not to say that Project Management is an exact science. It is not. The most commonly used word in Project Management is estimate. However, using some relatively simple techniques, a schedule that closely resembles reality is possible.
It is the purpose of this paper to discuss some of those techniques. An emphasis will be placed on techniques necessary for managing multiple projects, of varying sizes, at the same time. The Planning, Analysis, Risk Management, Earned Value Management, Metrics, and other project management disciplines will not be discussed in detail. It would take primers of their own to properly cover them. This is intended to be a treatise on fundamental Project Management techniques.
In my experience consulting with organizations about Project Management, one of the most common mistakes made is managing projects as if they are unique entities. Even when sharing resources, this tendency is still prevalent. Another common error is deciding to “formally” manage a project based on size, which is, managing a project because it is large and just “winging it” on smaller projects. This paper will demonstrate why those techniques doom the Project Management effort to failure.
This paper assumes that an automated tool, such as Microsoft Project, is being used to manage projects. While these concepts apply whether or not a tool is used, with today’s complex projects it is very difficult to manage projects without one.
Preparing To Schedule a Project
In preparing a project to be managed, there are some specific steps to follow. These steps are appropriate no matter what the project’s size.
The first step in preparing a project to be managed is to break it down into its constituent tasks, a Work Breakdown Structure (WBS). During this process it is important to keep in mind that one of the purposes of creating tasks is to let you monitor the status of a project. That means being able to detect a problem, determine its impact on the project, and make adjustments as needed. If the tasks created are too small, you end up spending most of your time just trying to keep up with the project. If the tasks created are too large, then you frequently do not have enough time to make adjustments before the project is impacted. One method for accomplishing this is to never have a task greater than 80 hours of effort (person hours), and there should be some specific deliverable from each task. While not absolutely necessary, where possible, it is helpful to a task defined so as to require only one resource to be assigned to it.
As with all systems, the pieces of a project, the tasks, do not exist in a vacuum. They are related to one another. In many cases a chronological dependency exists, for example, Task B cannot start until Task A is completed. There are four types of dependencies.
- Finish to Start (FS) – Task A must finish before Task B can start. This is the most common relationship.
- Finish to Finish (FF) – Task B can’t finish until Task A finishes.
- Start to Start (SS) – Task B can’t start until Task A starts.
- Start to Finish (SF) – Task A must start before Task B can finish. This is seldom used as it is just opposite of FS.
When creating dependencies it is critical to understand that only the dependencies that represent real constraints should be entered. As an example, Testing cannot start until Coding has, at least, begun. That is a valid dependency. A common mistake is to create a dependency between two unrelated tasks because you know who is working on the tasks, and you try to order what they do. This is not appropriate, as it is not a real dependency. The second task could actually start at the same time as the first, if perhaps a different resource was assigned to the second task.
This is depicted in Figure 1 – Using Dependencies Properly. The figure represents various scenarios for a project with only 2 activities. In A and B Task 1 and Task 2 are both assigned to Joe for 100% of Joe’s time. In A, a dependency, represented by the arrow between the two tasks, has been entered that is not really necessary; as these tasks, for this example, are not really dependent on each other. In B there is no dependency entered. Once A and B have been scheduled, with Joe working on both tasks (he can only work on 1 task at a time because he is allocated 100% to each), the tool delays Task 2 in B. Thus the schedule in A and B are alike. In this scenario it appears there is no harm done.
In the next scenario, it has been determined that an adjustment needs to be made to shorten the project. It is decided that Joe will be replaced by Jane on Task 2. Once that is accomplished, the project is rescheduled. In C, the unnecessary dependency remains with the result being no change in the schedule. In D, the schedule is shortened because the resource constraint has been eliminated by assigning Jane to Task 2; but also because the artificial dependency is gone.
The key is putting in just enough information and letting the tool do the number crunching. Too many constraints limit the tool’s effectiveness. It should be noted that this applies to plugging dates into tasks, instead of allowing the tool to calculate them based on when a project must start or complete. Enter only those constraints that are absolutely necessary.
Assigning Resources to Tasks
The next step is to assign resources to the tasks. This is done now because it is important to include the resource in estimating the effort required to accomplish the task (described in the next section). Creating accurate estimates is a partnership between the Project Manager and the Resource. A team effort is necessary to insure that the project information is as accurate as possible. As the project progresses, it may become necessary to move resources, assigning them to other tasks. If this happens, the newly assigned resource must validate the estimate.
Most tools require that a resource be assigned to a task a percentage of that person’s time. One method for making these assignments is based on the complexity of the task. For example, the list below suggests some possible assignments. Please note that these are rough and can be fine tuned as the schedule is refined. These represent just some possible numbers. As the Project Manager becomes more comfortable with this process, and analyzes some historical data, the numbers can be adjusted to meet the needs of the Project Manager’s group.
- High Complexity: 75%
- Moderate Complexity: 50%
- Low Complexity” 25%
- Simple tasks: 10% or less
Estimating the Work Effort for Tasks
Estimating the work required to complete a task is one of the few times when a process is done in a vacuum. That is, each task’s estimate must be made without regard to what else the resource is working on, and where the task fits into the scheme of things. The estimate must represent effort (person hours), not duration. Duration can’t be determined in a vacuum, as other factors must be considered to determine it. The tool will calculate Duration using the effort estimate as well as some resource information. When estimating the effort for a task, the person doing the estimating should determine how many hours it would take to complete the task if the task was that person’s full time job.
How Duration is Calculated for a Task
The Duration is the calendar time needed to complete a task. It is calculated using the following formula:
Task Effort / % of Resource's Time Assigned = Duration
So, if a task is estimated to require 80 hours of effort, and a resource it assigned to the task 50% of that person’s time, the resulting duration would be 160 hours or four weeks. This example assumes an 8-hour day and 1 shift per day.
Using this formula, it is possible to adjust the duration by applying more or less resource to it. The task’s estimated Effort should not be changed unless analysis has proved it to be incorrect. Modifying the task’s estimated Effort, to adjust the duration of a task, is to be avoided at all costs.
The use of the word “workload” instead of “projects” is intentional. To this point we have discussed preparing a project to be scheduled. A Project Manager’s job rarely consists of managing just one project. Not only are there usually multiple projects that often share resources, but there are also fires to be fought, administrivia, quick-and-dirty projects, and the list goes on. A Project Manager’s job is often more like a juggler keeping several balls in the air. Unfortunately, there is often a tendency to act like the balls are laying on a table, and that picking up one ball at a time and tossing it in the air is the same as juggling. It is not. They all have to be handled together or it is not juggling, and it is not Project Management.
It is absolutely imperative that all work under the purview of a Project Manager be scheduled together. If not, then any information communicated about the schedule, such as dates and resource’s usage and availability, will be inaccurate. There are several ways to do this, but for our purposes, the remainder of this document will describe a method that requires the least guesswork by the Project Manager, and thus allows the tool to do most of the drudgery of calculation.
What’s a Project?
The question, “What is a project?”, surfaces in almost every detailed discussion of how to manage projects. In most cases the question is irrelevant. For the purposes of our discussion, it matters not at all. When scheduling projects, and determining resource availability, all work must be accounted for, whether it is associated with a project or not.
There are two types of work. There is work that can be scheduled, such as projects, and work that can’t be scheduled, such as continuity issues, putting out fires and the like. Both must be accounted for when scheduling projects.
Project Managers commonly ask the question, “I get requests that are only 1 or 2 days long and consist of 1 to 3 tasks, should I schedule those?” The answer is an unqualified YES. Why schedule them? Because tasks like that are work, like any other, and impact the other work being done. Even one request can have an impact, but realistically, few people have just one, and thus the impact can be substantial.
There are numerous ways to handle these “small projects”. The most common way is to collect them as one project, a “miscellaneous” project, as defined by the tool being used. That way they are easy to keep track of, and don’t fall through the cracks, and their impact on other work can be measured. That “Miscellaneous” project can be treated like any other, and scheduled with the other projects.
The work that can’t be scheduled specifically, such as “fires” and meetings, can be handled a couple of ways. One is to simply lessen the availability of a resource in the resource pool by the percentage of time the person spends on these activities. Another way is to create activities, perhaps in the “Miscellaneous” project, and assign resources to them. In any case, this work must be accounted for when scheduling.
Something to consider regarding unscheduled work is that, if you ask people how much of their time is spent on that type of work, their answer is almost surely incorrect. And, to compound the error, they usually guess low. All resources should keep logs of unscheduled activities for two weeks to a month. The log should simply describe the kind of activity, the date, and approximately how much time was spent, rounded to the next quarter hour. From this log one can determine what average percentage of time is spent on these types of activities, and provide a more accurate estimate to the tool.
Scheduling All Work Together
As mentioned above, all work must be scheduled together otherwise the resulting information will be inaccurate and unusable. In this section we will analyze the results of scheduling the work together and the results of not doing so.
In this scenario, we will have two projects on which Jane is working. Each project has two activities and Jane is assigned to each 60% of her time.
Project A above has been schedule based on Jane’s availability, with no consideration of work she might be doing elsewhere. Project B, below, has been handled the same way.
On an individual project basis, things look pretty good, as can be seen in the resource usage graphs. In the resource usage graph for Project A below, it can be seen that Jane is only used 60% of her time.
The resource usage graph for Project B below, show the same thing, Jane is used only 60% of her time.
However, if we put the two projects together, leaving them scheduled as they are, we can see the real result below.
The result is that Jane is really over allocated (120% for more than a month), and thus one or both projects will suffer. If both projects had been scheduled together, the following would be the result.
The tasks in Project B were delayed, but now Jane is not over allocated. Just as important is the fact that the Project Manager and Upper Management have more accurate information from which to make decisions. For example, if Project B should not be delayed, then what-if analysis can be applied to provide the managers making decisions with some viable options.
These concepts are not optional; they are the foundation for successful project management. There are various methods in which they might be implemented, but they must be implemented. There are other disciplines, as alluded to in the introduction, that will improve the quality of project management in your organization, but none of them will be useful without this foundation.
It should be remembered that Project Management is not an exact science. Project Management is done to help us see into the future. With proper vision and common goals, project management can provide a map to be a guide the organization. An old Zen saying says, “The map is not the territory”, and so neither is a project plan the project. The only date in a project that can’t slip, without negotiation, is the completion date. Progress should be measured relative to that date. Other dates in a project will move; it is the nature of the beast; it is why project management is attempted at all. When things go wrong in a project, such as a date slipping, the project management process provides a means to make adjustments so the completion date is not impacted.
Project management allows us to communicate timely and accurate information to all the players in an organization. Communication is the lifeblood of any organization. Since projects are driven by business needs and initiatives, it stands to reason that the status of those projects affects the entire organization, from top to bottom. This is because decisions are being made based on what has been done, what is being done, and what is going to be done. Without this information in an accurate form, the business will not be able to make the decisions necessary to make it successful.
This primer represents a beginning. It is a return to the basics. It is a way to look at project management and how it can help you do your job better, and how it can make your organization more successful.
Steven DeSomer is the owner of a one man consulting firm, Steven DeSomer Associates, Consulting. His charter is to improve the project management process for any company that requests his services. Steven simply tries to change the philosophy of an organization to understand the what, when and how of successful project management. Steven has been a project management consultant for 26 years. Steven’s blog can be found at http://blog.alsoand.com/.