Chapter 6 Review

Work Breakdown Structure: Break Your Project into Manageable Units of Work


The work breakdown structure (WBS) is a tool for breaking down a project into its component parts, the foundation of project management, and one of the most important techniques of PM. The WBS can take either a graphical or outline form, though the outline is more scalable for large projects.  The WBS helps to:

• Provide a detailed illustration of project scope
• Monitor progress
• Create accurate cost and schedule estimates
• Build project teams

The WBS takes the deliverables listed in the Statement of Work as the high level task which are then broken down into levels of summary tasks culminating in work packages that are assigned time and cost estimates. Work packages should include the Project Management activities under a Project Management summary task, and all work packages should sum to the total cost and time estimate for the full project. Ideally, work packages should be no smaller than 8 hours or longer than 80 hours, or longer than the time between two status points. This will help make the work packages easier to manage. Work packages should also be parsed and named according to activities that produce a product.

The WBS can be the most detailed and time consuming portion of project planning, however, done correctly it can save immense time and money be averting changes to scope later in the project.

Chapter 5 Review

Risk Management: Minimize the Threats to Your Project

All activities of the project manager can be reasonably viewed as risk management. Risk management is the means by which uncertainty is systematically managed to increase the likelihood of meeting project schedule, cost and quality objectives. Two types of risk impact a project: known unknowns (which can be prepared for) and unknown unknowns (which cannot reasonably be predicted). Project risk is the responsibility of the PM, while business risk responsibility lies with the project owner.
To successfully manage risk throughout a project, risk planning must be an ongoing process. As follows:

1. Identify risks through a systematic search for all factors that threaten project objectives
• Engage stakeholders in risk planning through brainstorming sessions and more structured interviews
• Use a risk profile to apply lessons learned from previous, similar projects and document the lessons learned on this project for future similar projects
• Continue to identify risks during detailed planning, scheduling and budgeting
2. Analyze and prioritize these identified risks based on the possible damage and probability of occurrence
• Define the risk with condition and consequence statements
• Prioritize using "expected value = probability x impact" formula
3. Develop response strategies to reduce the possible damage and/or the likelihood of each risk
• For any risk there are several possible response strategies:
• Accept the risk and choose to do nothing about it (low impact or low probability)
• Avoid the risk by chosing not to do that part of the project or doing a lower-risk alternative to meet project objectives
• Develop contingency plans 
• Transfer the risk (subcontract that portion)
• Mitigate the risk
• Record risk management strategies in a risk log
• Make sure someone is responsible for each risk
• Rank by risk severity and probability
• Remove risks that do not materialize
4. Establish reserve funding for these response strategies based on the probability and magnitude of the risk
5. Implement continuous risk management by reanalyzing and reprioritizing (and reevaluating responses) given new and revised information as the project progresses
• Monitor known risks on the risk log
• Check for new risks at regular status meetings (raises risk awareness of the team)
• Repeat major risk identification activities at preplanned milestones within the project
• When new risks are identified, prepare response plans and ensure sufficient reserves exist

Risk management is one of the most important skills in project management draws its power (like many other PM tools) from a systematic and methodical approach to identifying, measuring, prioritizing and responding to potential risks to achieving project goals.

Chapter 4 Review

Chapter 4: Write the Rules - Five Key Documents to Manage Expectations and Define Success


Project Rules are the foundation of a successful project. Agreement on the goals of the project among all parties involved, control of the scope of the project, and management support are the crucial factors that are defined in the following project documents.

Project Charter.  This document comes from the Project Sponsor (and the Customer, if possible) and announces that a project has begun while demonstrating management support for the project and project management. It establishes the PM's authority to make decisions and lead the project. It is distributed widely and comes first among these project documents.

Statement of Work (SOW). Lists the goals, constraints and success criteria for the project. Once written this document is subject to negotiation and modification by stakeholders, but once formal agreement is reached on its content it becomes the project rules. At a minimum, the SOW includes:

• Purpose statement (why are we doing this project?) - guides the project team's decision making and clarifies the purpose of the project for the customer.
• Scope statement - describes the major activities of the project in such a way that it will be clear if extra work is added later, and explicitly includes what is NOT included in the project.
• Deliverables (what is the project supposed to produce) - tells the team what it is supposed to produce including intermediate and end deliverables; product descriptions should be referenced in deliverables but deliverables does not reiterate the product description, if a detailed product description does not already exist then that should be the only deliverable for a project.
• Cost and schedule estimates - must be realistic and accurate.
• Objectives - defines the measures of success beyond producing the deliverables on time and under budget; objectives should be specific and measurable to provide a basis for agreement on the project.
• Stakeholders 
• Chain of command

Responsibility Matrix.  Precisely details the responsibilities of each group and major player in a project and shows cross-organizational interaction. Each item on the matrix of major activities and stakeholder groups is assigned a code: R (responsible for execution), A (approval authority), C (must be consulted), and I (must be informed). This tool manages the role of the project office, and, once accepted, gives the PM a written document to refer to in the event of a dispute.

Communications Plan. Establishes a written strategy for getting the right information to the right people at the right time; defines which stakeholders need what information (authorization, status change, coordination); and should include an escalation procedure; communications should be repetitive, multichannel and include informal communication.

Project Proposal. Launches the project and overlaps the content found in the SOW verifying earlier assumptions or developing topics in greater detail; results from a mini-analysis phase that assembles enough information to make the decision to formally launch the project. The Project Proposal contains, at a minimum, the following:

• Project goal - states the specific desired results from the project over a specified time period
• Problem/Opportunity definition - describes the problem/opportunity without suggesting a solution
• Proposed solution - describes what the project will do to address the problem/opportunity
• Project selection and ranking criteria - categorizes the project benefit to facilitate decision making regarding the allocation of resources across a portfolio of projects
• Cost-benefit analysis - summarizes the financial reasons for taking on the project, expected benefits compared to costs to quantify ROI; includes tangible benefits, intangible benefits, required resources (cost), financial return
• Business requirements - primary success criteria for the project in terms of what the business or customer will be able to do as a result of the project's successful completion
• Scope - list and description of the major accomplishments required to meet the project goal
• Obstacles and risks - know risks (might occur) and obstacles (certain to occur) that could cause disruption of failure
• Schedule overview - expected duration, significant milestones and major phases

These project documents provide a vital framework for understanding, communicating and negotiating the purpose and details of the project, and a means of achieving consensus among stakeholders while keeping scope creep at bay.

Chapter 3 Review

Chapter 3: Know Your Key Stakeholders and Win Their Cooperation

The first task of the PM is to identify stakeholders. Stakeholders must agree on project goals and constraints, and ultimately will judge success. They are less likely to be overlooked in planning when we identify them based on classic roles.

These role include:
Project Manager. The PM has the primary role of keeping all disparate groups moving in symphony; the PM should be sure to define all stakeholder roles including their own (which can be spread over multiple people). When leading the stakeholders, the PM should control who becomes a stakeholder, and be sure to manage upward.
Project Team. The team does the work and can include contractors, vendors and customers. It's important to distinguish between the core team and vital, but more peripheral team members when establishing a communication strategy.
Management. Management roles fall into three general areas as follow:

• Sponsor. The sponsor is the specific executive accountable for the project's success. The sponsor:
• Issues the Project Charter
• Assists in developing the Responsibility Matrix
• Review and approves the Statement of Work, Project Plan, Cost/Schedule/Quality Equilibrium
• Meets with the PM regularly to advise and monitor the project, maintain project priority, and help the PM overcome organizational obstacles
• Resource Manager. These are functional or line managers who control and assign people and resources and are likely involved in setting company policies. They should review and approve the Statement of Work and Project Plan. Resource Manager can also offer assistance in resolving HR issues as the Project Team is comprised of their employees.
• Decision Makers. These managers influence project decisions and represent organizational policy, processes and assets. These include:
• Managers whose operations will be affected by project outcomes
• Managers representing other stakeholders
• Manager(s) to whom the PM reports
• Anyone else with veto authority on the project

The Customer. Although difficult to identify in some environments, the customer is whoever pays for the project. The customer gets first and last word on product description, budget and success criteria. Customers supply requirements and/or funding.
Representatives of External Constraints. These include governing/regulatory agencies; financial organizations related to project financing; and individuals/organizations whose routine, property or profits will be affected by the project.

Identifying the stakeholders is essential to the success of all projects, and the breakdown offered by the text offers a simple and practical means to approach the question of who are the project stakeholders. In the context of my project, the stakeholders are clearly defined but viewing them through this role-based lens offers valuable insights into how project communication should flow.