Death by Data Suffocation

Jim Harris

Data and detail have long been elements that have tested the mettle of project managers. 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? 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 work breakdown structure (WBS).


Trending Articles

Your Second Day as a Project Manager

by Mike Donoghue

The first day is in the books—successful or unsuccessful, you are now in “Day 2” of project management. Sure, some of the polish has worn off, but guess what? Those challenges you faced on the first day are still there.

The Future of Self-Empowered Teams

by Andy Jordan

The self-empowered team is a cornerstone of agile project management, and the benefits are well-established. But the mechanics and makeup of these teams, from shared skills to stability, will have to adjust to evolving business environments.

Australia Gives Back

by Carleton Chinner

Late last year, project managers across Australia got together to give a day of service to the community in the best way a project manager can—by using their PM skills. Learn some takeaways we can all use in our careers.

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, the words "work break down 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, 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 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 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. 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 prospective—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.     
  • The project manager is not the functional expert for all areas. Rather, s/he is 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.

Want more content like this?

Sign up below to access other content on

Sign Up

Already Signed up? Login here.

Related Content

Reviews (4)

Login/join to subscribe

"Brevity is the soul of lingerie."

- Dorothy Parker



Vendor Events

See all Vendor Events