CHAPTER 9
Time Management in Practice

VALIS HOUSTON, PMP, ACACIA PM CONSULTING

“Plan the work, work the plan.” This simple phrase can be your guide through many difficult times in a project management career. The Project Time Management Knowledge Area should be applied with the support of a project scheduling tool. Of course, it can be done with 3 × 5 cards to gather information and then organized in a spreadsheet. However, the spreadsheet will only communicate the proposed plan. Once the project starts and the dynamics of a project ensue—dates slip, unplanned scope is added, resources are suddenly unavailable—managing from the spreadsheet will probably become quite frustrating. The plan will no longer be a tool to provide project tracking and oversight. At that point, you will have lost control of your project.

DEFINE ACTIVITIES

For any project manager just coming on board a project, the critical first steps are to learn about the people involved—both stakeholders and project team members—and to understand the issues that currently exist and exactly what the project is expected to deliver. These steps are forerunners to Define Activities.

For the steps described in the PMI standard under the heading Define Activities, you must have a clear understanding of the activities that are outlined in the Work Breakdown Structure (WBS). This will become important as you identify the interdependencies among activities, as well as the type of resources that should be assigned to each of the activities. Start from the beginning, not the end, and resist the temptation to focus too heavily on dates. Although later it will be necessary to come back and look at how the “realistic” plan fits into the needs of the business, at this stage it is important to find out what your people believe are the necessary tasks required for project completion. This can also help to provide the ammunition that you need to fight for a date based on the effort involved.

Such activity definition can be done relatively easily in a project scheduling tool such as MS Project. Using this tool will make it easier to accomplish the remaining tasks of Project Time Management. However, this task can also be done with sticky notes or 3 × 5 cards. Give a descriptive title to the task and a brief definition, along with notes gleaned from the team. Detailed notes will be helpful, as you will come back to these notes throughout the project. There is a “notes” section for each task within MS Project to capture this information, or use the back of the 3 × 5 card.

At this point, it is not imperative to have the entire team available, as the focus is not on creating dependencies. The leads for each area (in an IT project these might be the Requirements Lead, Development Lead, Test Lead, Lead Architect, etc.) can provide enough input to develop the activities. Essentially, this initial meeting answers the question: What specific actions need to happen to deliver the product defined in the scope statement?

Keep milestones in mind, both external milestones to clients or upper management, along with internal milestones for the team.

Be cautious about identifying tasks that are too broad in scope; for example, “develop Web site” or “create design document.” Dig into the details; push to understand what must be done and how it ties into other activities. If you know something needs to happen, but neither you nor your team lead can put your finger on it, create “placeholders.” Keep these “to be determined” placeholders in the plan until you have fleshed them out fully. As you continue to refine the plan (and even after the plan is finished), you may expect to come across activities that were “forgotten” or “unknown” at this early stage of the project. Expect the plan to change.

SEQUENCE ACTIVITIES

After developing an understanding of what needs to be done to make your project a success, the next step is understanding the dependencies among the activities. A network diagram (which can be created in a scheduling tool such as MS Project) visually displays how the work in a project comes together. Your project’s network diagram will help to flesh out the relationships between tasks within a team and dependencies of work between teams. As you focus on the workflow, look for areas where work can be done in parallel. If you do not have a project scheduling tool or are uncomfortable using it at this point, the 3 × 5 cards and/or sticky notes that you used in Define Activities can be placed on a wall or white board to facilitate team discussion.

Focus first on those tasks within a particular team of the project, that is, developers, testers, etc. Questions such as, “What happens after task X?” and “What do you need to get started with Task Y?” move the discussion along. Push for a healthy discussion on what is needed for each of the activities to get started. Are Activities X and Y needed for Z to start? Are there dependencies from outside this immediate team or even from outside the project that are required? For example, do the testers require access to test data that is created by another part of the company? Balance the push for details with the risk of documenting too much detail. One helpful guideline is to base the amount of detail on the complexity and length of the project. High complexity with a large variety of unknowns equates to the need to gather more detail. On a small project of a few months’ duration, you can capture tasks of as little as a half-day duration if they are critical ones, but going into greater detail than that is not recommended. Remember that this will become your plan, and the tracking and oversight of the project will be your responsibility and become administrative overhead for your project team to report out on. Do not make the plan overly burdensome to yourself and your project team.

Ask if tasks can start sooner, as opposed to a “Finish-to-Start” relationship, although this can be a tricky area. Performing tasks in parallel could potentially result in overallocation of resources and/or cause more rework than necessary if a problem occurs with the first task. Nonetheless, if the project is strapped for time or if during the course of the project you find the project falling behind, knowing what tasks can be started before its predecessor is complete can be a practical problem-solving strategy. Identify these tasks, even if you initially elect not to perform them in parallel.

Beware of overlapping dependencies—tasks that have a Start-to-Start or Finish-to-Finish dependency. These can prove to be a choke point in the timeline if resources are waiting for work to be completed; they can also be a cause for communication breakdown among team members. You probably will not be able to avoid such activities, as they are inherent to all projects, but be sure to add a note that it can be a risk area and needs to be watched carefully.

To determine the sequence of events, bring in a few experts/leads from each subteam to discuss the dependencies, paying special attention to what is being completed when. Again, as this will become your plan, do not be ashamed if everyone else in the room seems to understand and you do not. Keep asking until the sequence of events is clear. Start tying together activities that come out of these discussions. As you did within teams, push to understand if one team’s activities can be started before another team’s activity is complete. Is it possible, for example, to overlap Development and Integration Testing? Can completed modules be delivered to the Integration Test environment so that Integration testing can get started? Or is there something that precludes this from happening? Again, use the questions, “What happens next?” and “What do you need to get started?”

If there is disagreement among the subteam leads, document any dissenting opinions. If the majority of the team can agree and any additional risks are documented, that should suffice. If not, as the project manager, the decision is yours to make. Investigate the issue further, but do not let issues during planning linger. Again, if necessary create placeholders in the plan for these unknowns and continue to push forward. Remember, the plan will change, so strive for the 80 percent solution.

ESTIMATE ACTIVITY RESOURCES

You cannot create a plan without taking into consideration the most important aspect: the people.

For each defined activity, the project manager will need to understand the type(s) and quantity of each skill set required. Typically, Estimate Activity resources primarily concerns human resources—the project team—but it could also refer to equipment resources. For example, if your project is producing a film, how many of a certain type of camera will be needed? Will these cameras only be available during the mornings because another film will use those same cameras in the afternoon? Along the same line of thinking, you need to know if you will be able to fill all the necessary activities with a name from your project team. If your Team Lead needs more time to ascertain resource availability, assign a generic, yet descriptive, resource to the task: “Sr. Java Developer” or “Jr. Tester” should suffice until the Team Lead can provide an exact name. Be sure to highlight this activity, as you will need to come back to it to assign a specific resource. If after reviewing the team’s capacity the resource to fill that slot is not available, this is a red flag that you may have more on your hands than the project team can handle. Raise this issue early and try to obtain the necessary skill set from within your organization or, if feasible, from outside the company.

At times, it becomes necessary to assign a resource without fully knowing the details behind an activity. Do not let this be a reason to NOT assign a resource. Someone must be responsible for every activity. Push accountability down to the lowest level possible; ensure that these decisions are not done in a vacuum, but—at a minimum—with the support of the Team Lead for those resources.

Be sure to document any resource constraints that will impact effort, such as a shared resource who only has 60 percent of her time available for your project or a resource who is assigned 100 percent on your project but does not work on Fridays. Be sure to also capture holidays, vacations, and administrative time that will need to be allowed for during the course of the project. (This can be done in MS Project under the “Change Working Time” dialog box.) Individual resource constraints can be applied as well as modifying the base calendar from an 8-hour day to a 7-hour day. (If you are not using a scheduling tool, this exercise can also be captured in a spreadsheet.)

Three pieces of information are needed to develop a schedule: The actual activities, resource estimating (knowing who will be working on those activities), and the duration of the activities. Do not take Estimate Activity Resources lightly, as not digging in and understanding the constraints and availability of your resources can have serious repercussions on the timeline that may not become known until it is too late.

ESTIMATE ACTIVITY DURATIONS

At this point, it begins to become apparent how all this planning results in a timeline. For each activity, the Project Manager needs to understand how much effort is required. Be careful to separate “duration” from “effort.” For example, an activity with an effort of 10 days will take 12.5 days (duration) if the assigned resource can only give 80 percent of his time to your project. On the other hand, if the same 10-day activity has two full-time resources assigned, it is possible for it to be completed faster, with a duration of five days. This is why the Estimate Activity Resources task is so important.

Estimate Activity Durations is not a one-time task. Plan to perform this exercise iteratively, at key points in the project—what the PMBOK^® Guide refers to as “Progressive Elaboration.” This simply means that as we learn more about “what” we are building (Requirements) and “how” we are building it (Design), we are able to refine these estimates and further define a timeline that is more accurate and more attainable.

Early on, the project manager will be asked to let upper management know when the project will deliver results. Progressive Elaboration will allow you to provide a more precise date on when the project will actually be delivered, but not until the project is sufficiently well along. This is the dilemma that faces many projects: committing to a date without having enough information about scope and resources. Although you will likely be told that these dates are just for planning purposes and the team will not be held to them, this is seldom the case. What can help is to instead provide a range of dates, and commit to providing better estimates as further information makes itself available, along the lines of +/- 200 percent after Inception phase (Deliverable = Scope document), +/- 75 percent after Requirements (Deliverable = Requirements document), +/- 25 percent after Design (Deliverable = Design document), and so on.

There are quite a few estimating tools and techniques available, ranging from parametric estimating and Wide-band Delphi to 3-point estimating (Most likely, Optimistic, Pessimistic). Each company uses techniques that reflect the experiences (positive or negative) that they have had with these tools on past projects and also reflect the maturity of the company’s project management processes. Regardless of the technique utilized, having historical information on past projects will help determine if the inputs and outputs of this tool or technique make sense. It is important that you only lean on project information that is truly similar to your project.

Bottom-up estimating, paired with one of the techniques mentioned above or commonly used at your company, is the recommended approach as it focuses on the low-level details that can only come from your project team. The Project Time Management chapter of PMBOK^® Guide states: “When a schedule activity cannot be estimated with a reasonable degree of confidence, the work within the schedule activity is decomposed into more detail.” Stress to the project team that these tasks will be worked by them and they will be held accountable for these estimates. Push for as much information as is appropriate at that particular phase of the project. If you have finished Design Reviews and the Development Lead is not able to provide estimates to a number of activities, then you need to go back to Design.

MS Project allows for the creation of columns in Gantt view in which you can assign “Duration” and “Effort.” If using a spreadsheet, you can also update it similarly.

Be sure to keep all the documentation used in this process. As you progress through the project and refine the estimates, this documentation will help remind the team why they made certain decisions. This will help to further refine your estimates with the new knowledge that has been gained. It will also help to build your company’s historical database or, if one does not exist, become the first project to go into a historical database.

DEVELOP SCHEDULE

You have defined all the activities and documented all the predecessors and successors, a Resource Calendar is in hand, and you have allocated the proper duration for each activity. Now you are ready to create the schedule.

Remember that the schedule is meant to be updated and refined throughout the project. This first iteration will become the baseline. Unless something major in the project causes you to rescope and change the baseline, this baseline will become the “square and level” by which progress is tracked.

When creating the schedule, start with external and internal milestones. All activities should support these milestones. Then apply your activities being sure to properly create Summary Level Tasks. Summary Level groupings are best done by subteam, even if it does not flow chronologically. As shown in Figure 9-1, Test Planning is being done during the Design phase, but it is still grouped under the Test Summary Task. This will make it easier for your subteams to quickly find activities related to them and for management to follow interrelated activities.

It is also a good idea to group milestones together and at the top of the schedule. This will provide easy access when you have to give an executive overview of your plan.

Now comes the step in which you apply the time constraints you documented during Sequence Activities. “Start no earlier than” or “Start as soon as possible” will help to create a dynamic plan that will change as a reflection of tasks completing earlier or later than scheduled. This is where the spreadsheet loses its appeal and project management software becomes a necessity. Keep in mind to apply any Lead and Lag times that you discovered during Activity Sequencing.

A number of scheduling techniques are available. Critical Path is probably the most widely used and is the underlying technique behind MS Project. Also gaining in prominence has been Dr. Eli Goldratt’s Critical Chain method (see Chapter 28 for a more detailed discussion of Critical Chain). Be sure that the technique you choose is supported by your project management software.

Do not forget to apply the Resource Calendar with its holidays, vacations, shifts, and so on. It is possible for key resources to become overallocated; for example, Joe Developer is assigned to four 8-hour activities on the same day, resulting in a 32-hour day. Resource Leveling is moving these activities to provide a “best-fit” to keep resources from being overallocated or to execute activities when key resources are only available at certain times. Be aware that Resource Leveling, although necessary, could result in extending the schedule.

What about replanning? Often you will be asked to expedite the schedule, while keeping the scope intact. Techniques such as Crashing (trade offs between cost and schedule to determine how to obtain the greatest amount of compression for the least incremental cost) and Fast Tracking (normally sequential tasks done in parallel) are high-risk techniques that, in an effort to deliver faster, can increase cost, increase the probability of rework, and increase the threat of missing the earlier date. When these requests come down, try to work on them with as little interruption to the project team as possible. It always seems that these requests come at the worst time, when taking team members off current work to look at a potential replan of the schedule will assuredly result in missing deadlines on the current work. Instead, pull as few Team Leads as possible to look at replanning. If you are comfortable and have enough knowledge of the project, you can perform this exercise yourself. Have a seasoned project manager review the result to catch any errors in the replan. Try to encapsulate the project team away from these interruptions and keep them working towards the baselined schedule until it is ultimately decided that a replan is necessary.

Congratulations: You now have a project schedule. Review it once more with the team to get buy-in on the Schedule baseline, as this is foundation for Project Tracking and Oversight.

CONTROL SCHEDULE

With a baseline schedule in hand, you are far from finished. You will have to keep it current in order to track progress, to facilitate the inevitable Change Requests, and to assist in providing project status.

FIGURE 9-1. EXAMPLE SCHEDULE

In the hands of a mature organization with the proper organizational structure in place, Earned Value is a valuable asset. Even if your organization does not utilize Earned Value, take the time to understand its concepts and try to apply them, even if in a piecemeal fashion. For example, if the cost accounting structure is not in place, you can still graph out the number of Planned Test Cases over time versus Actual Completed Test Cases. Acknowledging that this is not true Earned Value because Cost is not factored in and you will not be able to extrapolate CPI or SPI, these types of simple graphs can be used to support your intuition about how things are going, and to visually communicate to the team and stakeholders the progress of the team, in this case, that Testing is ahead of or behind schedule. (See Chapters 10 and 10A for more on Earned Value Management.)

Probably the hardest aspect of Control Schedule is gathering actual progress from the team. Gathering progress is not the problem; rather, it is the subjective sense that “we are at 90 percent” for over half the duration of the task that can be frustrating, not only to management leaders who hear each week that “we are still at 90 percent,” but also to the developer struggling to complete the task. Be wary of this trap. This is a sign that further decomposition of the task might be necessary to gain better insight into what has been completed and what work still remains.

Receive the Progress Reporting template from management or create one that is judged satisfactory to management and make sure your team is aware of the activities that are being reported to management. At a minimum, key deliverables and critical path items should be represented on your Status report. Be sure to include Start and Finish dates and whether that task is ahead or behind schedule.

If using MS Project, the Tracking Gantt view is recommended. This will show the baseline vs. current task start/finish dates. It will also provide percentage completes for both the Activity and the Summary Task level. This view can quickly show which areas of the project are falling behind and by how much. Continue to ask questions to get a better feel on how much of the activity has been completed and how much is left. Along with asking percentage complete, also ask if the activity will be completed by the baselined end date.

Control Schedule is one of the most important roles in the project. While controlling, continue to be alert for areas in the plan that require refinement. Be on the lookout for schedule slips and take immediate corrective action. Track against the baseline and be prepared for Change Requests.

Continue to research and try out the various techniques and tools described in this Chapter. You are not limited to only one, and only one might not be the best fit for your project. And lastly, remember that you must diligently “plan the work,” as this will become the measure of your success and then, just as aggressively, “work the plan” to ensure the project’s success.

REFERENCES

¹ Project Management Institute, A Guide to the Project Management Body of Knowledge, Fourth Edition. PMI: Newtown Square, PA. (2008).