Project Management's Neglected Tool
Every project manager knows the standard Work Breakdown Structure; however, the Project Breakdown Structure is just as important. Are you “flying blind” or “flying by the seat of your pants”? Project managers, teams and leaders, must avoid this dilemma by employing proven methods that allow us to successfully achieve a project’s goals and objectives. A basic template of all the minimum PM tasks are provided in this article’s content.
Do you know where you're going and how you will get there?
Have you ever heard the old expressions, "flying blind" or "flying by the seat of your pants"? If you haven't, they refer to performing activities, making decision, or trying to just function through life without a direction, plan, knowledge, or intelligent process. Project managers and the team cannot function productively in that manner. We, as project managers, project teams, and leaders, must have a purpose, direction, knowledge, and proven methods that allow us to successful achieve the vision, mission, goals and objectives for a project and its resulting product or service.
How do we avoid flying blind or by the seat of our pants? The easy and short answer is - through the use of Project Management Methodology. However, I'm not looking for such a simple wide sweeping brush stroke answer: I'm looking for the details. There's another old saying I'd like you to keep in mind throughout your project management endeavors: "The devil is in the details." The smallest unaccounted for or managed detail can result in frustration, turmoil, added work time to the schedule, rework, added costs or worse - failure to meet the product scope requirements. We must have the means to determine and account for all the tasks and activities that must be performed to properly manage the project during its lifecycle?
A Project Breakdown Structure (also known by the acronym PBS) is a top-down identification of the functions, elements and work activities/task required to MANAGE the project. It is oriented towards the PM function and not reflective of the work needed to create the product or service. Let's stop a second to clarify what is a PRODUCT Breakdown Structure versus a PROJECT Breakdown Structure. You may have seen or used what is referred to as a Product Breakdown Structure, and usually it is described as a tool for analyzing, documenting and communicating the outcomes of a project.
Some schools of thought state that the Product BS is the same as a Work Breakdown Structure (WBS); and, (they) further state, that the WBS is prepared after the Product BS. Proponents of this idea also imply that they the Product BS and the WBS must exist together in order to include all the product deliverables and work activities/tasks. I'm not a follower of that school of thought; a properly done and detailed WBS will always have all the product oriented pieces, parts, and work activities. The WBS is an international standard within the project and program management world. The WBS by definition includes all the "product" deliverables and sub-elements and work activities/tasks required to satisfactorily meet the project goals and objectives.
- Note: Soon I’ll present an article dedicated to the Work Breakdown Structure.
You may or may not be familiar with the many various breakdown structures that include Contractual WBS (CWBS), Organizational Breakdown Structure (OBS), Resource Breakdown Structure (RBS), and Bill of Materials (BOM). I only mention these to make you aware of the multitude of ways to use breakdown structures and to clarify - for the purpose of the remainder of this article, the acronym PBS will specifically refer to the Project Breakdown Structure.
Remember that Project Scope and Product Scope are two different animals: Project Scope is inclusive of all the work that must be performed in order to deliver the project; Product Scope, on the other hand, is specific to the delivery of all the features and functions required for that product or service. The completion of project scope is measured against the plan; while, the completion of the product scope is measured against the requirements. Remember this when you compile the objectives and plan for performance measurements.
Just as in a WBS, developing a PBS is an iterative process in that you and the team will usually create a straw-man concept of the main elements. A PBS is usually much easier to create than a WBS, because PBS's are generally similar from one project to another. They can be from a template and adapted from one project to another. Here is a case where PMI's PMBOK can be used to provide direct guidance on the content of the PBS. The "outputs" of the Process Groups and Knowledge Areas reflect many of the project management deliverables, elements and tools that must be produced to effectively manage the project. You will find a great layout of the relationship of the outputs to the processes at Table 3-1, page 61 of the PMBOK.
The bulk of the PBS is developed by the PM and the team members that are most directly involved in management, coordination and administration of the project. However, the remainder of the team, stakeholders and especially, the sponsor must have the opportunity to see and provide feedback on the PBS and be integral in the creation of the project schedule.
Sometimes the best way to explain something is by demonstrating what we are talking about. Let's explore an example of a PBS. It's not intended as a complete or all-purpose solution; however, it will give you the idea of where you need to go with this tool, and it just might be a reasonable starting point for your next project. Additionally, as pointed out in part one of the article series on PBS, the length of the material requires it to be published in three sections. Unfortunately, that means breaking the PBS into three sections, so don't forget to read the follow on articles of part two and three to see the entire PBS example and the included discussions and comments. So let's get started.
The order of the major elements of the PBS is a matter of choice. For our purpose here, part one will start with: Project Charter and Scope Management. In part two Project Team and the Stakeholders, Kick-Off Activities, Project Planning, Code of Account, Procurement of Materials, Equipment and Supplies; and in part three, we will finish with Project Schedule, Change Control, Communications and Reporting, Risk and Contingency Planning, Quality Control, and Close-Out Activities.
(Numbers shown in brackets [ - ] represent the PBS identifier number and their respective sub-elements.)
[0.0] Project Name: ABCD New Product
[1.0] Project Charter
[1.1] Project Justification
[1.1.1] Identify and gather all information relevant to the justification, examples: market demand, business change, customer request, technology advancement, legal or regulatory requirement, and or social need, as well as expectations for the project results in terms of the vision, purpose, goals and objectives of the resulting product or service.
[1.1.2] Create and store relevant project justification and measurements for success in the project management binder and or shared file folder(s).
[1.2] Develop/Complete the Project Charter: if you (the PM) haven't already received it from the sponsor or project authority.
[1.3] Review charter with sponsor/project authority(s) and have them sign it formally approving the funding and resources for the project.
[1.4] Publish charter to appropriate team members and managers/leaders. It's often quite practical to publish this on the company's project portfolio management webpage or other shared project file folder(s).
[2.0] Scope Management
[2.1] Project & Product Requirements
[2.1.1] Collect project requirements
[126.96.36.199] Develop PROJECT scope statement:
[188.8.131.52] Review with Sponsor and get it signed as approved.
[2.1.2] Collect product requirements
[184.108.40.206] Develop PRODUCT scope statement.
[220.127.116.11] Review with Sponsor and get it signed as approved.
[2.1.3] Design and Specifications Document (DSD): Soon I’ll be publishing an article dedicated to this critical task.
[18.104.22.168] Schedule design and specifications "capture" meeting.
[22.214.171.124] Invite appropriate stakeholders for the DSD capture meeting.
[126.96.36.199] Conduct design and specifications "capture" meeting. This may require multiple sessions over several days or weeks.
[188.8.131.52] Develop the DSD with the stakeholders and team.
[184.108.40.206] Review First Draft of DSD with stakeholders, clients, customer, sponsor and team, as appropriate, to verify the accuracy and its completeness. Make changes as appropriate.
[220.127.116.11] Verify or adjust content against the WBS: During the creation of the WBS it is not uncommon to have new or changes to the DSD as a result of identified work activities and tasks. This may result in a bit of back and forth reviewing and adjustments of the WBS to the DSD and the Project Breakdown Structure (PBS). The effect on the PBS will usually fall in the areas of (at the least) scope change, scope verification planning, change control actions, quality assurance and inspections.
[2.2] Project Breakdown Structure (PBS)
[2.2.1] Identify PBS development team: Usually the PM and the immediate team members or representatives develop the PBS since it reflects that management and administrative tasks for the project.
[2.2.2] Schedule PBS development sessions. Publish the schedule and agenda.
[2.2.3] Perform initial PBS development session. The PM creates a "straw-man" basic view of the "project management deliverables" and related tasks. This "straw-man" may be based on the company's standard project, program, or portfolio model, as in a standard template for various categories of projects and identifying the minimum requirements.
[2.2.4] Perform PBS work group meetings. Goal is to "drill-down" through all the deliverables, requirements, processes and functions down through to all work activities and task necessary to properly manage the project.
[2.2.5] Complete the PBS.
[2.2.6] Review and verify all expected deliverables required by the sponsor and or project authorities.
[2.2.7] Sign-off of WBS by Sponsor/PM.
[2.3] Work Breakdown Structure (WBS)
[2.3.1] Identify WBS development team members: of course this includes the PM, all team members, subject matter experts, functional managers, engineers, developers, primary users, clients, customers, and anyone who can contribute to the identification of all the deliverables, sub-deliverables, elements, work activities, tasks resources requirements, time schedule estimates and cost estimates for the project.
[2.3.2] Schedule WBS development sessions. Publish the schedule and agenda.
[2.3.3] Perform initial WBS development session..
[2.3.4] Perform WBS work group meetings. May require several meetings to nail everything down.
[2.3.5] Complete the WBS.
[2.3.6] Review and verify with sponsor and or project authorities all scope deliverables. Revise WBS if required.
[2.3.7] Sign-off of WBS by Sponsor/PM.
[2.3.8] Post/Publish for accessibility by the team.
[3.0] Project Team & Stakeholders: Identification and assignments may change as Scope is developed and defined.
[3.1] Identify Project Team Members.
[3.2] Identify/Assign Project Admin and Coordination Support.
[3.3] Identify/Functional Managers.
[3.4] Identify subject matter experts.
[3.5] Identify/Hire/Assign External Contractor(s)/Sub-Contractor(s).
[4.0] Kick-Off Meeting
[4.1] Schedule Kick-off meeting.
[4.2] Prepare Kick-off agenda and identify meeting material and resource requirements.
[4.3] Invite Stakeholders, Send out advance copy of agenda.
[4.4] Conduct project kick-off meeting.
[5.0] Project Plan
[5.1] Project Plan Binder (Hard Book and Folders).
[5.2] Project Plan Soft Folder [computer file(s)].
[5.2.1] Establish file naming convention: example: (Project Name) ABC_ (function name identifier) QC_ followed by predetermined numbering sequence, 100 series numbers for plans and schedules, 200 series for completed scope documents, 300 series for quality control, 400 series for change control, 500 series for risk management, 600 for cost management, 700 for procurement, materials and equipment, 800 for human resources i.e. team member assignments, stakeholder identification, contractors, etc., and 900 series for meeting records.
[5.3] Project Schedule
[5.3.1] Identify Project Schedule development team: this will include the PM, team members, project technical experts and may include the functional managers.
[5.3.2] Schedule - Project Schedule development sessions.
[5.3.3] Perform initial Schedule development session.
[5.3.4] Perform WBS Work Packages identification for all items on the WBS: All deliverables and subordinate elements must be some type of work activity/task necessary to achieve/complete those items.
[5.3.5] Perform Schedule work group meetings.
[18.104.22.168] First Objective is to identify all task relationships: what are the hard and soft logic associations and dependency issues regarding all deliverables, sub-deliverables or elements and, especially, work activities, tasks, elements since it is the WORK that must be built into the schedule.
[22.214.171.124] Second Objective is to sequence the work activities/tasks based on the relationships and dependencies identified in the first objective. Most common methods for this effort are the precedence diagramming method (PDM), arrow diagramming method (ADM), conditional diagramming methods, and network templates. All work activities/tasks must appear on the schedule. Every deliverable must have a least one work activity/task that demonstrates how that deliverable will be achieved.
[126.96.36.199] Third Objective is to identify all material, equipment and supply requirements that will result in project costs (and quantify the costs).
[188.8.131.52] Fourth Objective is to identify all human resource requirements that will result in costs, quantified by expense. Example. Worker "A" costs $30.00/hour and "B" costs $50.00/hr.
[6.0] Code of Accounts (COA)
[6.1] List of all internally provided materials, equipment and supply resources with costs.
[6.2] List of all externally provided (contracted/purchased) materials, equipment and supply resources with costs.
[6.3] List of outsourced human resources with costs.
[6.4] Complete code of accounts.
[6.5] Determine total projected project costs based on code of accounts.
[7.0] Procurement of Materials, Equipment and Supplies
[7.1] Review COA with procurement/contract office. In many businesses, procurement and contracting are handled by separate departments from that of the project management office.
[7.2] Coordinate with procurement officer for the purchase of materials, equipment and supplies.
[7.3] Verify the correct materials, equipment and supplies meeting the WBS, the Design and Specifications Document and Scope definitions have been procured.
[7.4] Identify any costs difference between the actual purchases and the planned estimates. Adjust the estimates against the actual, and analyze against the baseline. Determine impact of any discrepancies; will discrepancies result in an over-budget or under-budget situation. Identify action to be taken in either case - this is where your Risk Management Plan comes into play!
[7.5] Monitor costs and availability of materials, equipment and supplies over the duration of the project. Verify resources are available prior to the start of a work activity/task. The last thing you want is to have personal sitting on their hands or pulled off a task by a functional/line manager due to unavailability of the right parts.
[8.0] Project Schedule
[8.1] Identify stakeholders that will participate in schedule development.
[8.2] Schedule work group sessions for project task/time schedule development.
[8.3] Prepare "straw-man" schedule prior to the first group schedule. The straw-man schedule is created by the PM and a few of the Subject Matter Experts (SMEs).
[8.4] Conduct formal Work Breakdown Structure (WBS) meetings with project team, SMEs and other stakeholders (may require some functional/line managers). This usually takes several sessions with multiple working-drafts followed by a final draft for review by sponsor/project authority.
[8.5] Prepare and review final draft schedule with project sponsor and other stakeholders with authority over the project. If revisions are required, note the changes as revision items so that the PM can review them with the project them for the potential impact to the schedule in time, cost, and resourcing. May require a project schedule re-work meeting. Once revisions are completed, review the 2nd final draft with the sponsor; if the revised final draft is accepted, prepare the final formal schedule for the sponsor's signature.
[8.6] The PM signs the approved schedule. It is advisable, if practical, to have the functional/line managers sign-off on the final as an acknowledgment of the requirements since they will have to make the schedule happen.
[8.7] Post the project schedule in the PM Office, "War-Room"/Project Operations Room; where it is posted depends on the organizations set-up for managing formal projects.
[8.8] Publish the project schedule for all team members and stakeholders to access. Often times this is a shared-project file on the company's server or as a company webpage.
[9.0] Change Control Mechanism: I’ll provide more information on this topic; make sure to check back here at InfoBarrel.
[9.1] Change Control Process
[9.1.1] Develop Change Control Process.
[9.1.2] Develop/Publish Change Control Form.
[9.1.3] Develop Change Control Tracking and Reporting Tool. Often this may be a simple spreadsheet or database tool. It needs to be in a format that can be easily communicated to the stakeholders.
[9.1.4] Post Change Control Tracking in Project "War-Room"/Project Operations Room.
[9.2] Change Control Board (CCB)
[9.2.1] Identify Change Control Board Members. Depending on the complexity of the project, this may require several different SMEs with various skill sets in order to evaluate differing change requests, events, or actions. Sponsor and or persons with the authority over the costs and contracts must be on the CCB.
[9.2.2] Establish CCB approval and actions procedures.
[9.2.3] Develop a CCB results form.
[9.3] Change Control Actions
[9.3.1] Approved CCB actions.
[184.108.40.206] PM and project team integrate approved CC requests into project plan, schedule, adjust time and cost data, and resources. Coordinate with affected stakeholders and other parties that must make adjustments to the project work; this includes new purchases, rework, exchanges, etc.
[220.127.116.11] PM makes appropriate adjustments to Scope Documents (both Project and Product respectively).
[18.104.22.168] PM updates CC Tracking tools and posts in War-Room.
[9.3.2] Disapproved CCB actions.
[9.3.3] Follow-up/Other CCB actions.
[10.0] Communication and Reporting Plan
[10.1] Develop, design, and establish reporting formats and record keeping requirements. Procedures and requirements for project records/data management for hard-copy files, soft-file (electronic files) filing, such as posting in binders, posting in project "war-room", storage of physical records in filing cabinets, system folders, shared file folders, etc.
[10.2] Publish project reporting requirements and procedures.
[10.3] Regularly scheduled project performance review meetings with team.
[10.4] Regularly scheduled project performance review meetings with sponsor/project authority(s).
[10.5] Determine Email formal and informal content formatting for project information. This may or may not be an issue in some businesses; however, some companies have format requirements for internal versus external communications.
[11.0] Risk and Contingency Management Plan
[11.1] Develop a Risk Management Plan
[11.2] Identify and assess that potential of risk issues that may occur during the project lifecycle. Let's start with the most obvious - schedule progress or lack of progress. Have you fully worked up the lead and lag times in the schedule? Have you defined the Critical Path in the project? What and where along the critical path are the potential areas of risk? Sometimes, in more complex and cumbersome projects the PM and team might find themselves, for a lack of better terms, dealing with functional/line managers, workers and stakeholders that may be tentative and uncertain about the project or commitment to the project: you (the PM) should factor into your risk and contingency planning the potential of not having the availability of the right person at the right time, the right resources at the right time, and the right dollar figure at the right time. I'll write more on Risk and Contingency Planning in the near future.
[11.3] Evaluate the impact of potential risk issues on the project in terms of schedule/time, cost, resources, and quality/scope. There will be an impact - it's guaranteed.
[11.4] Develop contingency plans: These can be broken up into some generalized actions taken by the PM. Risk can come in many forms and result in, not just negative effects, but also potential advantages. The negative is obvious - however, the realization of risk events that result in a task being completed faster than planned, or with less resources than allocated, can provide the project with the opportunity for a schedule cushion or funding and resources that can be moved to a troubled task. Identify and take steps to mitigate the potential of a risk event occurrence. Consider these four categories of contingency planning:
[11.4.1] Schedule/Time Contingency Planning: It is best to start with schedule/time risk responses because these are the most common and have the potential to cause a need to adapt a solution that will also create a risk impact on all other categories. Review the project schedule, paying particular attention to the critical path and determine what options can be pre-planned; an example would be to add an additional human resource to a task to speed up the planned completion. Look to see if there are any tasks that can be re-sequenced to allow progress to continue while a task in trouble is being resolved.
[11.4.2] Cost Contingency Planning: Cost risk issues can be very tricky. They may be a result of personnel costs increased, materials/supplies/equipment costs increased, "Scope Creep" or Change Control actions that result in added features and functions to the project - adding cost to the project. And, though it doesn't happen often, the client/customer/sponsor decides to remove features or functions and reduce the scope of the project. Schedule risk can create a cost risk - good and bad: as mentioned before, if a scheduled task appears to be slipping its allocated time, it may require extra resources that will create a cost risk event.
[11.4.3] Personnel Contingency Planning: A critical activity is scheduled to start this morning and you get the word that the worker scheduled to perform that task has called in sick, what will you do? Employees get sick, go on vacation, are re-assigned or transferred, quit, or fired - it will happen, and those things will affect the project. Who do you (the PM) , or the functional/line managers have that can backfill the job? Can the activity be performed by fewer employees by giving them added giving them more time to complete it? OR is there an employee, though more expensive, that has the skills and proficiency to complete the task within the allotted time period? Survey the team members and the project's supporting work force to identify redundancy in the skill sets required for all the activities/tasks in the project - thus, adjustments to the work force will be enhanced.
[11.4.4] Materials, Supplies and Equipment Contingency Planning: Just as in the other three categories listed above, materials, supplies and equipment risk can result in an impact that is beneficial or negative to the project's progress. Review the project resource requirements and identify any potential risks for shortfalls. Assess whether there is a potential for change to specifications, availability of the preplanned resources. Identify resources that have long acquisition lead-times. Incorporate tasks in the project schedule for resource requisitioning and verification of design/specification requirements well prior to the execution of the work activity.
[12.0] External Resourcing. Many businesses have procurement and contracting offices. The PM will have to review external resourcing with the contracting officer/manager.
[12.1] Identify work to be done by external and outsourced resources such as consultants, contractors, suppliers, etc.
[12.2] Identify work packages to be farmed-out (for contracted and outsourced consulting services, contractors, businesses, temp-agencies, etc.).
[12.3] Develop scope-of-work statements/descriptions for each contract.
[13.0] Quality Control Plan. Although the Project Management Institute's (PMI) PMBOK differentiates between Control versus Assurance from a project planning (PBS) perspective, they can be rolled together under the Quality Control Planning. This is a matter of choice in organizing your project. As long as you know the difference between Control and Assurance you will be fine. I'll write more on Quality Management later, but for the moment I refer the reader to the PMBOK, Chapter 8, page 227 for PMI's explanation of the definition and role of the two topics.
[13.1] Quality Assurance (QA) Checklist and Plan for In-Progress Work.
[13.1.1] Establish QA checklist for all critical tasks - pay particular attention to ensuring that all scope and detailed specifications are being adhered to during the progress of the project. Incorporate QA reviews throughout the project schedule; you don't want to find yourself having to backtrack late in the project due to errors in the process. Keep in mind that quality issues are also potential risk issues. A good QA program will assist the PM in mitigating risk and "Scope Creep." More on Scope Creep in a separate article to be published later.
[13.2] Performance Evaluation Plan and Checklist for final completed product/service.
[13.2.1] Develop/identify the original projected performance measures for the project. These will usually be the baseline standards and any re-baseline data, to include information relating to causes of or for variations to the baseline.
[13.2.2] Schedule and perform periodic performance reviews. Always perform this assessment prior to a project status meeting. Always update the assessment after risk events, scope change, to include change control actions. In the case of change control, you will need to perform an assessment of the "impact" of a change control item before the CCB can effectively rule on a decision as to accept or decline the change.
[13.3] Product Scope Verification Plan and Checklist.
[13.3.1] Develop a plan that will allow the PM and the project team to verify the outcome of the project from a "Product Oriented View." This means that you are trying to verify that the project meets the deliverables requirements. This is not a quality performance review, but a "Content" review. This is done before a verification review by the client/customer/sponsor.
[13.3.2] Develop a plan that will allow the Client/Customer/Sponsor to verify that the outcome of the project (from a "Product Oriented View" has actually produced the projected deliverables. Again, this is not a quality performance review, but a "Content" review.
[13.4] Project Scope Verification Plan and Checklist.
[13.4.1] Develop a plan that will allow the PM and the project team to verify the outcome of the project from a "Project Oriented View." Have you (the PM) and the team delivered everything that was identified and agreed to at the outset and as a result of agreed upon changes to and for the project? Although the WBS represents what is "in scope" for the project, and by doctrine, if it's not on the WBS, it's not "supposed to be" in the project, that is not always the case. Sometimes the sponsor will want a formalized "packaging of all the project performance data, results, design, specifications, historical data-anything relevant to the project in order to retain this for future use and to justify expenses - as well as, use for measuring the success, value, and or failure of the product against the original expectations. This means that you are trying to verify that the project meets the deliverables requirements. This is also not a quality performance review, but a "Content" review.
[14.0] Project Close-Out
[14.1] Verify all contracts are paid up, and that there are no unresolved issues hanging over the project. If there are, then the project is not yet completed. This is also part of the "project" scope verification.
[14.2] Complete and publish all required project performance reports. These are items that if the requirement and known about early in the project, are actually part of the "project scope"; however, they are still usually, handed off at the project close-out, unless otherwise specified. This is done by the PM and the affected team members. Identify who is to receive these products and in what format: Project Binders, Folders, Engineering and Architectural Drawings, computer files, etc.
[14.3] Schedule and conduct a project after action review (AAR) with the team. Sometimes it's best to hold two separate AARs: first with only the team members and the second with only the client/customer/sponsor. The reason for this is that, if there is any potential for finger pointing or "bad-blood", the preference would be to air these issues out in a closed group and not have the team and the client/customer or sponsor participating or witnessing any potential arguments. It does happen, so best to keep things friendly.
[14.4] Close-out meeting. Schedule and publish a final project close-out meeting with all the project team members and stakeholders to include the client/customer and sponsor. This is an opportunity to review what was accomplished and thank everyone for their participation. Make this a positive experience. Depending on the size of the project and how successful the results of the project were, it's also not out of order to have a little glad-handing thank you party or luncheon. Use this time to build and maintain the teams morale - a PM and the sponsor may have to rely on those same team members in the next project. Remember that today's close-out team building is tomorrow's project kick-off team building.
[14.5] Post-Mortem review: The PM and the project team, after everything is all said and done, again verifies everything is complete, all documents and files delivered, bills paid, reports published and AAR lessons learned are captured, recorded and published.
As stated at the outset of this article, the project manager and the team must not fly blind through the project lifecycle; no "flying by the seat of your pants. Project managers and the team cannot function productively in that manner. Just as the Work Breakdown Structure provides a description of what the project is to "produce" in the form of a product or service, the Project Breakdown Structure provides a description of what the PM and Team must accomplish to effectively and efficiently manage the project. We, as project managers, project teams, and leaders, must have a purpose, direction, knowledge, and proven methods that allow us to successful achieve the vision, mission, goals and objectives for a project and its resulting product or service.