As a reminder, or if you haven’t read the first two parts of this article, unfortunately, it was necessary to break this up into three separate articles, with this example Project Breakdown Structure (PBS), the first half being covered in the first two articles; here in part three we will finish the example. In part one, we explained the: what, why, how, who and covered the PBS’s relationship to the work breakdown structure – and how they differ, as well as the difference between a PBS (Project) versus a Product Breakdown Structure (PBS). For our purposes, the PBS is project oriented.
As I said previously, sometimes the best way to explain something is by demonstrating what we are talking about; thus, in part one we started with major PBS elements of Project Charter, Scope Planning; in part two, we continued with the Project Team and the Stakeholders, Kick-Off Activities, Project Schedule, Code of Account, Procurement of Materials, Equipment and Supplies. Now we can finish up with some of the meat and potato elements that can make or break the project.
(Numbers shown in brackets [ – ] represent the PBS identifier number and their respective sub-elements.)
[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 For more on Change Control Management follow this link to read a two part article on this topic.
[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 in Part One, a project manager and the team must not fly blind through the project lifecycle; no “flying by the seat of your pants. 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. 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.
Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition, © 2013, Published by Project Management Institute, Inc., 14 Campus Boulevard, Newtown Square, Pennsylvania. Table 3-1, page 61 and Chapter 8, page 227