조직은 프로젝트를 얼마나 잘 관리하든 그들이 요구 사항을 제대로 수행하지 못하면 성공하지 못할 것이라는 점을 점점 잘 알고 있습니다. 그러나 좋은 요구 사항을 갖는 것은 무엇을 의미합니까? 비즈니스 분석 업계는 어디로 가고 있습니까? 이 프레젠테이션은 비즈니스 분석에서 이러한 뜨거운 주제를 다룹니다.
Death by Data Suffocation
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 PMs 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).
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. Lets 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 supervisors 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 Sams 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 Sams 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.
"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, "Ill 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."
Sams Hard Lessons
I couldnt 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 projector it could be an albatross.
WBS Do's and Donts
Take a broad viewSam 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 prospectivethe 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 planThe 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 milestonesSams 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 projects 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 deviationsThe 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 termsSam 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 missionto manage the project.
Detail at the right levelThe 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.
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 ProjectManagement.com
Already Signed up? Login here.