Project Management

Death by data suffocation

Project managers who try to cover every contingency with meticulous detail risk missing the big picture, according to this article from gantthead. Here is a project management plan that balances detail and deadlines.


By Jim Harris

Data and detail have long been elements that have tested the mettle of project managers. That same Work Breakdown Structure (WBS) that's supposed to help you can so easily kill you with stultifying detail if you can't get a handle on it. This article will help you set a project management strategy and avoid being suffocated by the sheer volume of project data thrown in your direction.

The dilemma of detail
How much detail should the project manager be concerned with? How much detail should the PM entrust to project team members? What level of detail are the stakeholders interested in reviewing?
Save $50 when you become a gantthead premium member.

To read more from gantthead, join now!
Registration for basic membership is free.


Do you need project plans, deliverable templates, presentations, checklists, or expert advice? TechRepublic members who join gantthead can upgrade to a premium membership for only $300—that's $50 off of the premium subscription. Visit gantthead today to find everything you need for success on your next project.

The dilemma starts when the project manager starts documenting customer requirements and determines the activities that will accomplish a successful delivery. This equates to an ever-present tar pit the PM must navigate around to preclude a demise in the quagmire of data and detail.

Adding to this difficulty is the PM’s mandate to detail the entire project to address senior management questions. In short, the PM defines a comfort zone of detail to permit a feeling of control over the project. The security blanket for this comfort zone is the WBS.

The WBS is a good management tool that both controls the project and presents a reliable and timely project status. However, when laden with detail, it becomes difficult to read and interpret, a drain on project resources to update, and a source of oppression to those who are managed by it. Keep in mind that the words "work breakdown structure" are not a title but a stated purpose. Let’s tell a story to illustrate this point.

Sam came to Software Designs, Inc., with a degree in computer science. His abilities and dedication to his work rewarded him with the admiration of senior management.

His trademark was his attention to detail, task organization, and formulating development plans. He knew every specific element regarding tasks he was assigned. Thus, he could provide his supervisors a highly detailed status report.

His reports hit on everything and made his supervisor’s reports look complete. Senior management was proud of Sam and recognized his ability to control his assignments. He was subsequently promoted to project manager within the project management office.

After a week or so, Sam was assigned his first project. Although it was not large, the project was significant. Based on Sam’s record of success as a planner and team manager, management knew he could handle it.

Time passed, and I found out the project to which Sam was assigned had been closed. I met with Sam and asked him how things went on his first project. Sam summed it up as a disaster.

A view from a new level
Sam recalled his first project. "I quickly realized that my new duties not only required the skills I had used in my previous job but new ones too. I needed to be concerned about a larger team with more activities executed by a greater number of supporting departments and activities.

“At first, I was numbed by this new environment, but I decided the more information I could document, the better informed I would be and thus in a better position to answer questions from the management team."

Sam assembled his project team and started outlining the project plan and building the WBS. He emphasized the need to identify and monitor every activity, and explained his detailed method of activity identification, showing them on the WBS. The team dissected the statement of work. The finished project plan was representative of Sam’s instructions.

"The finished plan and WBS were bigger than those I had developed before. But I was not surprised, considering the number of additional players and increased number of activities.

"However, the large amount of detail that was in the plan would be easy to track by using the automation project management system the PMO had for updating project status and the WBS. The completed WBS was an awesome document, but it provided a detailed picture of the activities and direction of the project."

Sam met with the senior management team to present his project plan and WBS. Impressed, the management team gave instant approval to proceed.

Project launch
"The kick-off meeting went without a hitch. I provided the team with a copy of the approved project plan and WBS. After the team meeting, I felt pretty good that all points were covered and the team members had a clear understanding of their responsibilities and project deliverable.

"At the first in-progress team meeting, the hardware team member reported the contracted vendor had an unexpected backorder of the main processor. The training member stated some of the supporting material for the student/user handbook would be delayed. They wanted to know what they should do.

“With the first management project meeting a week away, I pulled the team together and performed a detailed analysis of the issues and developed multiple alternative courses of action. It was my goal to address each contingency with a process and its impact on the plan now rather than later.

"Changes were made to the project WBS reflecting this additional information. Needless to say, both items grew in size. However, I wanted to reassure the management team that every element of risk was being considered, its impact identified, and most of all, the project was under control."

At the management status meeting, Sam presented the status of the project along with the process to manage the new identified risks. The management team was amazed at the depth he was addressing the project status and how much detail he was tracking. Sam took this as a compliment that he was doing well.

How deep do we go?
Sam realized he was responsible for more activities and functional areas but viewed this as just a simple expansion of his previous duties. As activities were completed, team members passed him updates. These updates quickly piled up in the "to do" basket.

Sam was convinced that once he had a handle on every functional element of his team, he could update the completed activities with no problem.

One day, he had a meeting with a software development team member to discuss the progress of a deliverable.

"I met with the software manager and asked her to show me her detailed development plan and status of each supporting module. After the presentation, I decided some of the information needed to be included in the overall plan and WBS for the next review meeting. My objective was to detail these activities so I would be able to answer management questions before they would be asked."

Sam told me every aspect of the software development effort was reflected in the updated project plan and presented to the project team prior to the management project meeting.

Sam recalled, "One team member asked why I was tracking in such detail. I assured the entire team that I had been successful tracking this level of detail before and asked the others to provide the same level of detail for their work effort."

The other team members responded, and the project plan books were amended with the updates. Sam found himself awash in information. His office walls were covered with the WBS and notations of changes to the original plan that had been approved but needed to be included in the plan and WBS. However, he confided he felt good about the level of detail at which he was managing the project.

All development activities were covered, and he felt in control. It was just a matter of taking the time to get caught up on the administration of the project.

The day of reckoning
"At the second management meeting, I presented the progress for each activity. Every action was documented and footnoted, showing responsibility and accountability.

“I had even managed to enter all the updates and changes that had accumulated since the last meeting. The presentation took longer than I had expected, but I was presenting information needed by management.

More on gantthead
Related downloads: Design Task/Milestones Checklist
Intranet Planning Project
Project Manager's Roles and Responsibilities
Responsibility Matrix
Related content: Project Management Department
The Project Manager Is the Keystone to Successful Delivery (also by Jim Harris)
Gentlemen, Start Your Templates by Dave Paradi
NOTE: Items in bold are available only to gantthead premium members.


“When I asked if anyone had any questions, I expected to get few, if any. What followed was unexpected. The questions that came from senior management and stakeholders dealt with the number of change orders processed and their effect on cost and project completion, resource consumption rate, client relations, status on contract changes, extra hour claims received by accounts payable, and a host of other topics.

“I was able to answer some of the questions, but my answers led to other questions. My response became, "I’ll get back to you on that." Suddenly, the room went quiet. Slowly, the managers began their silent exodus. Later that day, the PMO manager asked me to come to his office. He removed me from the project."

Sam’s hard lessons
I couldn’t help but feel sorry for Sam. In his previous position, he had developed flawless processes that were a credit to his attention to detail. That was fine in an environment having fewer supporting functional departments. Now, as a PM, his focus was to ensure final delivery on time and within budget. Sam found out the hard way that the WBS could be a meaningful tool to the PM to track the progress of a project—or it could be an albatross.

WBS do’s and don’ts
Take a broad view—Sam failed to recognize that as a PM, his focus and responsibilities had broadened to include managing a project, including change control, contract management, fiscal management, and project resources. His view of project activities had previously been focused on the how things were done rather than what was accomplished.
As a PM, Sam failed to complete the transition from orientation to detail to that of the broader perspective—the total project. Instead of addressing strategic activities, the project-level WBS got bogged down with details that needed to be tracked at the tactical development level.

Represent the project plan—The WBS presented at senior management review should reflect the strategic project plan and present all major activities and milestones that must be accomplished to fulfill the agreed deliverables. The project WBS must clearly illustrate the dependency of each major milestone and activity identified in the project plan that must be accomplished to achieve final delivery.

Track business milestones—Sam’s project-level WBS was confusing and provided little value when discussing the management aspects of the project. The project WBS should be simple in structure and convey the project’s progress to achieve established milestones. These are the same milestones and major activities established in the project plan to achieve the final delivery. The project WBS must convey what is to be accomplished to achieve this goal.

Show impact of deviations—The project WBS should be used to clearly illustrate the effect of proposed changes to the current baseline project plan. The project WBS is the basis of meaningful discussion that changes will have on the project timeline, fiscal and human resources, and achievement of the agreed final delivery.

The PM must think in business terms—Sam filled the WBS with endless minutia of activities. He failed to present a clear understanding of the project status and business challenges that would preclude a successful delivery. He collected so much information that he was unable to manage the volume of data. His project team wasted time reacting to his directives. Most of all, he lost focus of his primary mission—to manage the project.

Detail at the right level—The WBS is built with input from the various supporting functional departments. The detail they provide addresses the tactical actions necessary to produce specific deliverables for the overall project deliverable. The overall project WBS should be high level and address the progress of major activities. Lower levels of the WBS structure increase in detail and track the delivery of a major activity assigned to supporting functional areas.

In retrospect
Sam looked back on his first project and realized the following:
  • The PM must focus on managing the total delivery process.
  • The WBS is a PM tool tailored to support the appropriate level of the delivery process. The higher the management level, the more the emphasis of WBS information shifts to what major activities are being accomplished, rather than the detail of what is accomplished by supporting activities.
  • The project level WBS is the PM tool to generate discussion when evaluating proposed changes or additions to the plan.
  • Detailed tracking of activities should be entrusted to team members providing progress reports that update the project WBS.
  • Team members should be empowered to make decisions regarding their part of the overall deliverables.
  • Project managers are not the functional expert for all areas. Rather, they are expected to be the business expert of the project. Permit team members to address questions that may require explanation of detailed activities of their specific assignments.

Original publication on gantthead: April 27, 2001

Jim Harris has more than 30 years of managerial and technical experience in IT system planning, implementation, and operations in both government and commercial sectors. He is presently the director for the planning and program development of IT enhancements for a major U.S. airline and is a regular contributor to gantthead.


Don’t be like Sam
As a project manager, have you ever found yourself drowning in detail? As a team member, have you ever had a project manager that is too immersed in minutia? Post a comment below or send us an e-mail.

Editor's Picks

Free Newsletters, In your Inbox