2-5-4 Work Breakdown Structure

2-5-5 Work Breakdown Structure Dictionary For a typical product, the WBS Dictionary should be completed before proceeding with any additional work. I have chosen to make an exception in this case and I will come back to fill in the WBS Dictionary at such time as I begin work on each work package. 0 Recursion Product The product to be built during the course of this project is a set of documents. It is expected that there will be about thirty total documents, but that number will be refined during the course of this project. These documents must be made available through an internet portal. 1 Methodology The Methodology is generally specific to a company. The Project Management Institute offers a framework in the PMBOK 2000. An industry will generally follow a life cycle – such as design, code, test and deploy. A methodology is the specifics about which document to use and what content belongs in those documents. 1.1 Guidelines The purpose for this document is to explain the methodology used on this project. The goal for this document is to include an explanation for each document and each section heading. The initial release of the Guidelines document will illustrate the layout and include just enough content to prove that the concept will work. The final release of the Guidelines document needs to include explanations for each document and each of the major sections within those documents. When the final release is ready, then the interim will be moved to the off-line archive. 1.2 Template Bundle The vision for this project is to first complete one set of project documents and then to strip the content from a copy of those documents to produce a distributable set of project templates. 1.2.1 Template Definition for Portrait The original scope of this project underestimated the work required to choose the proper document formatting tool and design a consistent text layout. Now that this work package has been identified, it has been added to the WBS. The scope for this specific deliverable is to create a blank portrait template using the designated format. 1.2.2 Template Definition for Landscape The content of some documents is best displayed in landscape mode. The deliverable for this work package is to adjust the 1.2.1 Portrait Template Definition into landscape mode. 1.2.3 Template Bundle After all of the documents have been created each will be copied and stripped of content to create a template for future projects. The bundle will be published on a web site for distribution and reuse. 1.3 Policies Bundle In addition to project templates, one of the key requirements for a transportable methodology is to predefine standard policies and procedures. 1.4 Distribution Package The final deliverable from this project should be an archive file that can be posted on a web site. This archive should contain the defined policies and working templates. The preliminary distribution will be via a web site. Documents will be uploaded and linked to the site as they are completed. The final distribution will allow users to choose to view or download a single document at a time or to download bundles of documents. The Scope for this work package is to create the user interface. Packaging the documents is covered in other work packages. 2 Scope The PMBOK 2000 defines the Scope Knowledge Area as: “Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully (1). It is primarily concerned with defining and controlling what is or is not included in the project.” 2.1 Product Description The purpose for this document is to describe the product in appropriate detail. This document, more than any other, should implement the PMI concept of “Progressive Elaboration”. The initial release of this document should describe the product adequately for the creation of a Project Charter. By the end of the project, this document should be so detailed that it can support the product release. 2.1.1 Product Description for Charter A prerequisite to the Project Charter is a working Product Description. This description may be somewhat vague as long as the meaning is clearly understood by those involved. This description will evolve during the life of the project. 2.1.2 Product Description for Release The final Product Description must be precise. This description must support the needs of all stakeholders, including the end users, support staff, marketing and legal. This is the description that must last the life of the product. 2.2 Project Charter The purpose for this document is to provide justification for the allocation of resources to begin formal planning for the project. While some resources are required to even create the Product Description and Project Charter, no other work should proceed until the review board has authorized this project. Note that this will be a static document. Once approved, there should be no further changes to this document. 2.3 Scope Statement The purpose for this document is to analyze the product that is the justification for this project. This document is a transition between the Product Description and the Work Breakdown Structure. The Product Description will evolve, through progressive elaboration toward a detailed description useful to the end user of the product. The Work Breakdown Structure will evolve into the tasks on the project schedule. Projects with a limited scope may combine two or more of those documents into one. Note that this document can be frozen once the WBS is defined because the WBS and the WBS Dictionary will become the primary reference for the product specific information needed by the project team. 2.4 Scope Management Plan The purpose for this document is to describe the techniques and procedures to follow to insure that scope changes are detected, reviewed, and then either approved or rejected by the proper authority. 2.5 Work Breakdown Structure The purpose for this document is to apply a structure to the list of Product, Major Components and Deliverables brought over from the Scope Statement. The goals for this process are to insure that all deliverables have been identified and to organize those deliverables into “work packages”. A “work package” is a bundle of tasks that can be assigned to a project team. The WBS should contain a schematic to illustrate the work packages and a WBS Dictionary. The schematic is a logic view of the product – not a physical view. For example, the WBS for a house might include packages like “clear ground”, “install utilities”, “pour foundation”. But, it might also include packages such as “obtain fi nancing”, “choose contractor” and “choose appliances”. The WBS must be maintained through the life of the project because it will be a primary reference tool for the project team. The WBS should also be carried forward through the life of the product since it clearly describes each component of the product. For most projects, it is important to fully defi ne the work packages before work begins. However, on research oriented projects, there are times when the initial WBS may have gaps. This particular project has aspects of a research project because I have not previously followed the PMI methodology on Risk or Procurement. Therefore, the WBS will be initially released without full defi nitions for each of those work packages. As the research is completed, the scope for each work package will be fully defi ned in an updated WBS. Before the end of the project, the WBS will be complete. 2.6 Formal Acceptance Formal acceptance is achieved when the customer signs a statement of formal acceptance. The initial deliverable will be a template stating the general terms for formal acceptance. There will also be a document that specifi cally states the terms for formal acceptance on each of the fi rst and second levels of the Work Breakdown Structure. The formal acceptance for each component will be placed in the on-line project archive. Usages of the 2-6 document include: Formal Acceptance Template Formal Acceptance on Scope Formal Acceptance on Communications Formal Acceptance on HR Formal Acceptance on Time Formal Acceptance on Cost Formal Acceptance on Quality Formal Acceptance on Procurement Formal Acceptance on Risk Formal Acceptance on Integration Formal Acceptance on Methodology Formal Acceptance on Product 3 Communications The PMBOK 2000 defi nes the Communications Knowledge Area as: “Project Communications Management includes the processes required to ensure timely and appropriate generation, collection, dissemination, storage, and ultimate disposition of project information. It provides the critical links among people, ideas, and information that are necessary for success.” For this project, the Communications KA has been pulled forward from it’s place in the PMBOK 2000. Communications must be one of the very fi rst processes that execute in order so that the activities can be coordinated. 3.1 Communications Management Plan The purpose for this document is to describe which communications need to be distributed to which groups at what intervals. On small projects it is expedient to combine this document with the Project Team Directory. Where there are privacy concerns, however, the two should not be mixed. Note that this is a critical document that must be maintained. In the event the project manager is absent, the substitute project manager should be able to quickly ascertain the communications requirements from this one document. 3.2 Project Report The purpose for this document is to provide a status update identifying progress and issues. This report is to be updated and distributed weekly to the Project Team. The content of this document consists of a Project Status Summary, the Project Milestones the Project Issues Log. The Project Report Template will defi ne the format to use for the weekly project report distribution. Then, the project manager will use the Project Report Template to create a weekly report outlining the project accomplishments, project issues and project status. 3.3 Project Archives The Project Archives is one or more repositories for document. Today most documents are electronic so the Project Archives may be a fi le server, a web server or a document management system. The deliverable is the process of setting up the archive and moving the documents into it. 3.3.1 Organization Policy on Project Archives The purpose for this document is to explain the project policy on document publication and document retention. The key criteria behind this policy are 1) accessibility to shared information and 2) compliance with legislation regarding document management. Note that this policy is intended to supplement the established corporate policies on document publication and document retention. In the event there is a confl ict between the project policy and the corporate policy, the most restrictive policy shall prevail. 3.3.2 Project Archives On-Line The Project Archives On-Line will be a web site maintained by the web site administrator. 3.3.3 Project Archives Off-Line The Project Archives Off-Line will be a fi le directory maintained by the project manager. 3.4 Change Requests The Scope Management Plan defi nes the formal process for evaluating, reviewing and then authorizing or rejecting change requests. 3.4.1 Change Request Form The purpose for this document is to explain the reason that a Change is recommended. Please provide the requested information with suffi cient detail that the Change Control Board can make the correct decision. 3.4.2 Change Request Log The purpose for this document is to record the status of the Change Requests that have been processed during the course of this project. 3.5 Lessons Learned The purpose for this document is to record key lessons that have been learned during the course of this project. The intent is to use these lessons to streamline future projects. Many of the items on this log will come from the Issues Log. Filtering, however, should be used to restrict the content of this document to those issues signifi cant learning occurred. 3.6 Performance Reports 3.7 Project Presentation The purpose for this document is to describe the project. The intended audience is individuals interested in participating in the project on either the peer review or customer review teams. 3.8 Project Closure 4 Human Resources The PMBOK 2000 defi nes the Human Resources Knowledge Area as: “Project Human Resource Management includes the processes required to make the most effective use of the people involved with the project. It includes all the project stakeholders—sponsors, customers, partners, individual contributors, and others...“ 4.1 Organizational Chart The purpose for this document is to identify and disseminate the reporting structure for this project. This document should be updated whenever there is a change in the structure of the project team. 4.2 Roles and Responsibilities Assignments The purpose for this document is to disseminate a common understanding of the responsibilities for each deliverable. The primary content of this document is the Responsibilities Assignment Matrix (RAM). The RAM consists of a 2x2 matrix listing the roles and the assignments. The junction of a role with an assignment is a cell which contains a designation of the responsibility this role has for this assignment. 4.2.1 Roles and Responsibilities Planning Release During Planning the team may not yet be formed and the full scope may not yet be defi ned. It is still important to release a RAM as early as possible. 4.2.2 Roles and Responsibilities Execution Release Once the project team has been formed, the RAM should be updated to refl ect the agreements on scope and responsibilities. Adjustments will continue throughout the life of the project, but the magnitude of those changes should be minimal. 4.3 Staffi ng Management Plan The purpose for this document is to defi ne the start and end dates for the project team staff. This document should also outline the staffi ng approach for this project. Key items to be defi ned are whether the project will use in-house staff, contractors or off-shore resources and whether the project team will be dedicated or shared resources. 4.4 Project Team Directory The purpose for this document is to facilitate communication within the team. The directory should list the names, titles and contact information for the entire project team. Distribution of the Project Team Directory must be restricted, however, to protect employee confi dentiality. 5 Time The PMBOK 2000 uses the term Time to include duration, sequencing and scheduling. According to the PMBOK “Project Time Management includes the processes required to ensure timely completion of the project“. 5.1 Activity List In general, an “Activity List” is a transitory document. Most projects are run with a project scheduling package – such as Microsoft Project, Primavera or others. In those cases, the activity list is simply an input into the creation of the schedule. Once the schedule is created, the activity list is discarded 5.2 Project Network Diagram The Project Network Diagram is a tool useful in planning and re-planning the Project Schedule. It is generally maintained by the person or persons responsible for the project schedule. It is generally not distributed to the project team because the Project Schedule provides the same information in a more user-friendly format. 5.3 Activity Duration Estimates Activity Duration Estimates should be prepared by the group responsible for executing the work. They are the experts on completing the work and are thus should be the experts on estimating the time required. The estimates are an input into schedule development and are a useful historic reference once the schedule is prepared. 5.4 Project Schedule The Project Schedule is a consolidation of information including the activity list, the activity sequencing, the activity durations and the role and responsibility assignments. The initial schedule, once approved, will become the baseline for the project schedule. Thereafter, the project schedule should only be updated when a schedule change is properly authorized. 5.5 Schedule Management Plan The purpose for this document is to defi ne the technique to be used to track schedule variance, detect changes and then authorize or reject those changes. The schedule management process must be tightly integrated with the scope management process. 6 Cost   7 Quality   8 Procurement   9 Risk   10 Integration   2-5-6 Revision History Date Author Description 5 Jul 2004 Robert Perrine Preliminary release. 6 Jul 2004 Robert Perrine Reformatted based upon updated style template. 7 Jul 2004 Robert Perrine Added Activity Duration Estimate to the WBS Diagram. 12 Jul 2004 Robert Perrine Converted from MS Word to Adobe InDesign 18-24 Jul 2004 Robert Perrine Continued to add content in parallel with completion of the Activity Lists and Activity Sequencing processes 17 Nov 2007 Robert Perrine Converted back from Adobe to html. I recommend against using Adobe products.