Each week, project management veteran Tom Mochal provides valuable advice on planning and managing projects. He first describes a common problem scenario, based on a real-life situation, and then offers a solution, using practical project management practices and techniques.

The dilemma
My second meeting with Bob covered a familiar topic—the level of detail needed to manage the workplan. Bob is the program manager for a series of projects to support a major reorganization in the finance division.

“I have three projects going on right now, and another in the planning stage,” Bob said. “I feel like I need to know what’s going on in the underlying projects, but I’m struggling right now.”

“What are you doing so far?” I asked.

He explained that he held a weekly program status meeting with the project managers, and that he also met with the project managers and clients as needed. He told me he wanted to consolidate individual project workplans to keep track of the work at a lower level, and this is where he encountered problems.

“The status meetings are a great way to keep everyone informed of the progress of all the projects,” I noted. “What problems are you encountering with the workplans?”

“Each project manager has enough information on the workplan that they can manage the projects effectively,” Bob said. “However, when I try to roll the information out to a master workplan, all sorts of inconsistencies and errors occur. Project managers have different names for the same tasks, some workplans are more detailed than others, resources look overallocated—it is all very confusing.”

“How important is it for you to have a consolidated workplan?” I asked. ”Do you need to track the progress of the projects at that level?”

“Well, I guess I’m trying to determine the best level to manage the work,” Bob admitted. “I thought I needed to keep track of the details, but it’s harder to get done that it seems.”

I could tell that Bob was a little frustrated: “I have some good news for you, Bob. You don’t have to manage the project at that level.”

Mentor advice
Project managers need to build workplans at a level that is sufficient to manage the underlying work. If your project is a part of a larger program, it’s redundant to try to manage at this same level of detail at the program level as well. I recommend that the program keep track of the projects by tracking the milestone dates, which represent the completion of one or more deliverables and should give you enough information that you can track a project’s progress.

For instance, one of the projects in Bob’s program is to consolidate two distinct billing applications onto one common system. There might be 200 activities in the workplan and a dozen or so milestones, set after the following events:

  • Determination of which billing system will remain
  • Analysis of how to consolidate systems
  • Approval of the transition and training plan
  • Data conversion testing
  • Final user testing

To effectively manage the overall program, Bob first needs to make sure that each project has proper milestone dates assigned in the workplan. He must feel confident that if he manages by milestones, he’ll have an accurate view of the progress of the project. Then, he needs to diligently track and manage the work at the milestone level.

When Bob builds his workplan, he needs to include the detailed activities that are performed at the program level. He also needs to include the major milestones from each project.

In his status meetings and status reports, he can track progress at the milestone level. If milestone dates are missed, he will have cause for additional follow-up. If the milestones in the project plan are accurate, and the projects are hitting the assigned milestone dates, and if he continues to meet regularly with the project managers and the major clients, he should feel comfortable that the work is proceeding as planned.

On Bob’s program, he has three projects that are in progress today. Each one has hundreds of activities but a much smaller number of milestones. When he reviews the progress of the projects, he can more easily see what the dates for the milestones were.

The example above has a milestone for the approval of the transition and training plan. If this milestone is due to be completed on February 15, Bob can determine if that milestone was achieved by February 15. This will be much easier than tracking the 15 detailed activities that might be required to achieve this one milestone.

Problems at the detail level
I worked for a company that managed a Y2K program at the detail level. At any given time, 10 to 20 projects were going on. All the projects were using a consistent tool, which gave them the capability to combine the project workplans into a consolidated program workplan. That was when the fun started.

Although the project managers tried to be diligent, the combined workplan had to be edited before it made any sense at the program level. The same problems that Bob encountered cropped up.

For example, a constant effort had to be made to make sure people called similar activities by similar names. Project managers were called when tasks were past their due date, only to be told in many cases that the project manager had just neglected to update the task.

On the Y2K program, two full-time employees were assigned to make sure that the program’s detailed workplan accurately reflected the status of the work on the program. To me, this was a waste of effort. I think the better approach is for the project teams to manage their work at the activity level, and for the program manager to manage the work at the milestone level.

Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching the IS division on project management and life-cycle skills. He’s also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep.