Identifying and Managing Project Risk 3rd Edition Book Notes

Chapter 1: why project risk management?

Failed Project - the first Panama city canal. (Read: the path between seas. By: mcCullough).

The first canal project, 1800s, entailed negligible project management. Lead by Ferdinand de Lesseps, who had beforehand built the Suez Canal. He ignored technical engineer input and proposed a build plan that was voted infeasible by each engineer present at the original planning conference. The original cost estimate was $200million, but eventually $300million was spent on only 20% completion prior to the project being canceled. He would routinely conflate the completion percentage of the project. 20,000 lives were lost due to illness and lack of medical support to offset malaria and other area viruses. There was flooding, geology, and other challenges not properly managed. Proper communication would have also helped. Lesseps became infamous, as a result.

Chapter 2: Planning for Risk management

> planning for risk involves paying attention, when we don't watch correctly [or pay attention to the wrong "dashboard" elements], projects fail.

> three reasons projects fail: they are actually impossible (build an anti-gravity device -> the easier option would be to buy a helicopter), they are over constrained (ask a part-time Grad student to rearrange the university library by themselves), they are not competently managed (this last one is the only one that can actually be controlled)

> famous palindrome: a man, a plan, a canal. Panama.

> President Rosevelt championed the second (and successful) plan to build the Panama Canal. He used proper PM processes, and used the military to build the canal, as opposed to private sector due to its military importance.

Chapter 3: identifying project scope risk

> A great deal of project risk can be discovered at the earliest stages of project work, when defining the scope of the project.

> most damaging risks: changes to scope (most frequent) and scope creep (must damaging). In retrospect, scope creep often adds very little added value, and often delays the project so much that the item provides less value than the project without the item. 3 types: scope gap (starting without having all the necessary information), scope creep (changes in requirements, mostly due to poor planning), and scope dependencies (changes due to external forces).

> Topics for a typical deliverable definition process are: 1. Alignment with business strategy: how does the project contribute to stated high-level business objectives? 2. User and customer needs: has the project team captured the ultimate end user requirements that must be met by the deliverable? 3. Compliance: has the team identified all regulatory, environmental, and manufacturing requirements, as well as any relevant industry standards? 4: competition: has the team identified both current and projected alternatives to the proposed deliverables, including not undertaking the project? 5. Positioning: is there a clear and compelling benefit-oriented project objective that supports the business case for the project? 6. Decision criteria: does the project team have an agreed upon hierarchy of measurable priorities for cost, scope, and time? 7. Delivery: are logistical requirements understood and manageable? These include sales, distribution, installation, sign-off, and support. 8. Sponsorship: does the management collectively support the project, and will they provide timely decisions and ongoing resources? 9. Resources: does the project have the staffing and funding needed to meet the project goals within the allotted time? 10. Technical Risk: has the team assessed the overall level of risk it is taking? Are Technical and other exposures well documented?

> the straw man definition document: "how do you make a statue of an elephant? You get an enormous chunk of marble and chip off everything that doesn't look like an elephant." - rather than enter meetings with a blank document, prepare a sheet prepared with your "best guess" of meeting outputs and let the other party criticize it and revise all the areas that need corrections. Using such a document is an excellent way to generate scoping information, though it may be humbling to the original author. Embarrassing or not, preparing something that is "pretty close, but not exactly right" is far better at generating discussion than trying to develop topics at the same time as requesting for a response to them.

> Key ideas for identifying scope risk: clearly define all project deliverables, and note challenges. Set limits on the project based on the value of the deliverables. Decompose all project work into small peices, and identify work not well understood. Assign ownership for all project work, and probe for reasons behind reluctance. Note risk arising from expected project duration or complexity.

> The Panama Canal continued: John Wallace was the PM for the second start. He resigned due to the red-tape (and seven person commission) involved with making any decisions, as a year has passed and there was still no plan approved for the canal. Wallace was replaced by John Steven's. John Stevens was an engineer, not an operations manager, and that helped to drive design requirements. The commission was resolved by the US president, as well. Stevens was given full control and his main focuses were to develop the scope, set up infrastructure for the workers, and to support the medical research efforts to eradicate malaria as an issue amongst the staff. He is quoted saying "intelligent management must be based on exact knowledge of facts. Guess-work won't do." He helped to create the scope (in 1907): the United States would build a 50-mile lock-and-dam canal at Panama connecting the Atlantic and pacific Ocean, with a budget of $375 million, to open in 1915.

Chapter 4: Identifying Project Schedule Risk

> projects are rarely about perfection. Practicality is not particularly as motivating, and hardly as much fun, so complicated projects often diverge from the direct path and into the weeds.

> schedule risks fall into three categories: delays (most numerous, schedule slips that happen as a result of things outside the PM's control), estimates (most damaging, inadequate durations attributed to project activities), and dependencies (due to factors outside project).

> Estimation Techniques: Effective estimation techniques all rely on history. The priority goes: historical data, experts and expert judgment, experience based rules and parametric formulas, relative size or scale estimates, Delphi group estimation, otherwise further decomposition is needed.

> 3 kinds of estimation: duration (measured in work days), effort estimates (measures in person-days), calendar estimates (measures in elapsed time)

> estimation process: 1. Start with historical base estimate 2. Input project factors to produce duration estimates 3. Input resource factors to produce effort estimates 4. Input nonproject factors to produce calendar estimates

> questions to investigate worst case scenarios: what might go wrong? What are the likely consequences should any issue arise? Is the involved staff experienced in this area? Have we had problems with this kind of work before? What kinds of activities does this project depend on that's outside our control? Are there aspects of this work that we don't understand well? If we were betting money on this, how would it change?

> In schedule estimating, it's often more enlightening to replace all your initial estimates with worst-case estimates to see what happens. And remember, if your analysis is only based on known risks, and there are significant unknown risks, even your worst-case schedule may be optimistic.

> risks discussed in the chapter: long-duration activities, significant worst-case estimates, high uncertainty estimates, overly optimistic estimates, all critical path activities, multiple critical paths, convergence points, external dependencies and interfaces, deadlines beyond the planning horizon, cross-functional and subcontracted work

> Key ideas: determine the root cause of all uncertain estimates. Identify all estimates not based on historical data. Note dependencies that pose delay risk, including all interfaces. Schedule risky activities early in the project. Ascertain risks associated with multiple critical paths. Note risks associated with lengthy projects.

> Panama Canal 3: planning 1905-1907. Stevens spent virtually all of his time among the workers asking questions. His single-minded pursuit was thorough project planning. Once Stevens broke the work down into easily recognizable pieces, the canal project began to look possible. Each part of the job now looked like something that had been done before, rather than appearing completely ambiguous.

Stevens quit in 1907 mainly due to a lack of necessary hydraulics experience and a lack of enjoyment of the weather. President Rosevelt replaced him with a military officer that couldn't resign without facing UCMJ action, LTC George Goethals.

Chapter 5: Identifying Project Resource Risk

> Resource Risk represents 30% of the items in the PERIL Database and account for more than 25% of overall project impact.

> 3 categories: people, outsourcing, and money

> most impacting resource risks: poor output, staff member loss, money limitations, temporary (sick/holiday) people loss, context switching amongst staff, motivation

> motivation issues was the smallest subcategory (at 5%) but had an impact of 9 weeks. These are generally a consequence of diminishing interest in long-duration projects or of interpersonal interactions

> outsourcing risks: nearly 1/3 of resource risks. Late or poor output - work done at a distance is out of sight, and problems that may be detected with efforts within the organization may not surface as an issue until it's too late (the "cake boss" surprise/reveal).

> Money risks: when funding is a problem, it is a big problem and contributes to the problems with other risks

> black swans: these are large impact, hard to predict, rare events. Example, the SME was let go because they were too expensive. Layoffs caused an immediate restructure.

> staff acquisition: whenever a key part of your project depends on access to a single specific person, note it as a risk.

As a general rule, people who are among the best at what they do typically work three times faster than the average, and up to ten times faster than a novice.

> outsourcing risks: although outsourced staff may express loyalty to complete the project as mentioned in the contract, they inevitably have more risk of continuity and turnover than internal staff - especially with longer projects. In general, writing to establish good working relationships with outsourced partners is Prudent in risk management

> effort estimates: any plan that shows a lower percentage of effort in a given phase than is typical had probably failed to identify some necessary activities or underestimated them. When making predictions, having personal experience in similar projects is typically better than relying on published reports from elsewhere- which is good encouragement to start saving files as reference.

> 3 broad categories for projects: 1. Thinking: planning, analysis, investigation, charter establishment, initial design, proposal generation, requirements analysis, specification, and preparation for the business decision. 2. Doing: the work that generally defines the project, development, and creation of the project deliverables. 3. Checking: testing the results, searching for defects, correcting problems and omissions, approval, and project closure

> Fred Brooks ("the typical man month): "a typical software project is 1/3 analysis, 1/6 coding, and 1/2 testing." As an alternative, break larger projects into sequences of shorter, less-ambitious tasks - adopting Agile methods

> cost estimates: use PERT for both schedule and time ((optimistic * (4 * most realistic) * pessimistic) / 6 )

> Key ideas:

identify all required skills you need for which you lack named committed staffing

Determine all situations in the project where people or other resources are overcommitted

Find all activities with insufficient resources

Identify uncertain activity effort and cost estimates

Note outsourcing risks

Gain funding approval early for needed training, equipment purchases, and travel

> Panama canal: for the second round building the canal, finding wasn't as much of an issue as retaining people to do the hot, humid, and dangerous work. LTC Goethels realized that the project needed continuity and motivation and loyalty not to him but the project. He started a weekly newspaper, the canal record, to highlight individuals & project accomplishments, and important dates & reminders. Medals were also created for those that stuck with the project for at least two years (many still wearing them proudly at old age). He also held weekly "open-door" sessions that were often attended by hundreds of people. President Rosevelt chose to visit during a rainy season and even worked along side the laborers to demonstrate support (no other president left the country on a like trip previously).

Chapter 6: Managing Project Constraints and Documenting Risk

> the principle objective of reviewing the plan is to quickly find defects and omissions, deal with unmet constraints, and seek an improved plan.

> analyzing constraints: often times, your planning process for projects only reveals how much trouble you're in. Your primary goal in managing project constraints is to minimize the difference between the project objective and your project plan.

> managing opportunities: when risk management seeks to understand what might go badly in a project, opportunity management looks for what might go better. It asks what similar but superior projects/ products might be possible

> scope: deliverables for high-tech projects are set using two kinds of input, user/Market demand and technological possibilities - most relies primarily on the first. Opportunity management is about merging a deep understanding of user needs with the technical capabilities available to meet the deliverable- not necessarily the one originally envisioned. "If you are going to lose an argument, change the subject" - is the idea that if the original idea isn't supported, rebut with a better, more realistic one

> risk identification techniques (pg. 155): brainstorming, retrospective analysis, scenario analysis, assumptions analysis, SWOT analysis, expert interviews, reverse root cause analysis, bowtie analysis

> creating a risk register:

a clear risk description ("if [cause], [risk] could occur, resulting in [consequence].")

Probability assessment

Impact estimate

Overall rating

Impact description, including when the risk is most likely to occur

Risk owner

Triggers/ Other indicators that signal risk occurrence

Response summary

Contingency or recovery summary

> Key ideas:

Minimize differences between project plans and objectives

Understand and clearly document project priorities

Explore project opportunities

Use priorities to identify project alternatives

Identify and explicitly remove unnecessary project scope

Determine risks and costs of proposed plan revisions

Minimize unknown risks through brainstorming, analysis, and research

Thoroughly document project risks

> Panama Canal:

New technologies, methodologies, and approaches were developed in building the canal. The one mentioned was about the railroad & conveyer system that enabled the digging and shuttle of the dirt from the canal site to its offload area that increased efficiency by hundreds of percent and maintained operations around the clock.

Chapter 7: Quantifying and Analyzing Activity Risks

> often, what separates an impossible project from a possible one is isolating the most difficult work early on, so it receives the attention and detail required to deal with it.

> qualitative vs quantitative: the first is the basis for rank ordering risks, allowing you to select the most significant ones to manage. The second strives for greater precision, and supplies the data necessary for sizing schedule and budget reserves on risky projects

> effective risk management depends on understanding bias (selection,recency,judgment biases, for example) and on working to overcome them throughout the risk identification and assessment processes.

> loss × likelihood = the characteristics of risk

> when estimating risks: the illusion of precision can be a source of risk in it of itself; making subjective information look objective can result in unjustified confidence and questionable decision-making

> idea (include in dashboard): a risk matrix that has a scatter-plot of each risk item overlaying it.

> in any event, quantitative assessments of risk impact depends on credible three-point project estimates

> Key ideas:

Assess probability and impact for each project risk

Understand and work to minimize biases

Use qualitative risk analysis to prioritize risks

Apply quantitative risk analysis techniques to better understand the significant risks

When using PERT or related techniques, keep things simple

> Panama Canal: the most severe risks with the canal were diseases, mudslides, the constant use of explosives, and it's technical challenges. Disease caused many to quit, including the two previous PMs. Mudslides caused rework costs to skyrocket. Unreliable and unstable explosives caused risk to many lives. The technological challenges of the lock-system itself caused extreme risk due to its size and need for strength - that hadn't been done before. Each of these mitigations will be outlined in the next chapter.

Chapter 8: Managing Activity Risks

> risk management can be a potent tool for transforming a seemingly doomed project into a merely challenging one

> root cause analysis: the process begins with listing the risks and their descriptions and then to brainstorm the sources for the risk (scope, schedule, resource). Use diagrams to visualize the process.

> there are three categories of project risk: controllable known risks, uncontrollable known risks, and known risks. All risks listed in the risk register are known risks either under control or not. It is possible to plan a response to any known risk - at least, in theory. The unknown risks are best planned for by setting up reserves (either by increased schedule, increased funding, or both).

> with risks, you either deal with the causes (if able to identify them before they happen) or you deal with the effects (of they arise before adequate time to prepare)

> develop a response for risks in your register for any of the following reasons:

They are significant risks for which you have a cost effective response

They are risks with high or unknown impact where a response is justified, regardless of assessed probability (remember, black swans do happen.)

They are minor risks that have simple, low-cost, effective responses

> accept risks in the register for any of the following reasons:

They are significant risks to which no response can be found

They are significant risks where a response is identified but thought too costly

They are minor risks that do not warrant attention in advance

>> Dealing with Risk

> avoid scope risks:

Identify the MVP, avoid over-designing (gold plating)

Negotiate and clearly document all interface deliverables expected from other projects

Avoid untested technology when practical

Plan to design using standard, modular, or well-understood methods

Buy instead of make

Be willing to leverage work done by others

> avoid schedule Risk:

Reduce the number of critical paths

Modify the work to have fewer activity dependencies

Schedule the highest uncertainty dependencies as early as possible

Avoid having the same staff working on two successive or concurrent activities

Decompose lengthy activities further

Reschedule work to provide greater flexibility

> avoid resource risks:

Obtain names of all required project roles

Get explicit availability commitments from all project staff (and their managers)

Work to limit commitments by project staff to other projects. Explicitly document their commitments

Use the best people available for the most critical activities

Educate team members to use more efficient methods, and do it early in the project

Use mentoring to build teamwork and establish redundancy for critical skills

Upgrade or replace older equipment to make work more efficient

Automate manual work when possible

Locate and gain access to experts to cover all skill areas not available on the project team

When you use outside services, use the same suppliers that you (or others that you trust) have used successfully in the past

Establish contact terms that are consistent with project objectives

>> mitigation

> mitigation strategies for scope risks:

Explicitly specify project scope and all intermediate deliverables, in measurable, unambiguous terms including what is not in the deliverable. Eliminate wants early- make them Explicitly a part of the scope of drop them

Gain acceptance for and use a clear and consistent specification change control process

Adopt iterative or Agile methods to manage scope based on user feedback and current priorities

Build models, prototypes, and simulations, and get user and stakeholder feedback

Test with users early and often

Schedule Risk-prone, complex work early

Obtain funding for any required outside services

Translate all project documents into relevant languages

Minimize external dependencies risk

Consider the impact of external and environmental problems

Keep all plans and documents current

> mitigation strategies for schedule risks:

Use expected estimates when worst cases are significant

Schedule highest priority work early

Manage external dependencies proactively

Before adopting a new technology, explore possibilities for using older methods

Use parallel, redundant development

Be conservative in estimates for training and new hardware

Break projects with large staff into parallel efforts

Partition long projects into a sequence of shorter ones

Schedule project reviews

Reschedule work coincident with known holidays and other time conflicts

Track progress with Rigor and discipline, and report status frequently

> mitigation strategy for resource risks:

Avoid planned overtime

Build teamwork and trust on the team

Use expected cost estimates where worst-case activity costs are high

Obtain firm commitment for funding and staff

Keep customers involved

Anticipate staffing gaps

Minimize safety and health issues

Encourage team members to plan for their own risks

Delegate risky work to successful problem solvers

Rigorously manage outsourcing

Detect and address flaws in project objectives promptly

Rigorously track project resource user

>> Key ideas:

Determine root causes

Avoid, mitigate, or transfer risks with adverse consequences whenever feasible

Develop contingency plans for remaining significant risks

Document risk plans and keep data visible

Monitor all risks in your risk register

Prevention is better than cure

Use Bow Tie Analysis to visualize risk causes & preventions to risk consequences and their recovery methods

>>Panama Canal:

> the risk of disease was managed by Dr. Gorges. This was due in large part to the funding that supported him (estimated at roughly $10 for every mosquito killed).

> the risk of mudslides involved what felt like, the deeper the digging, the more the sides would sink and the center would rise; like a fluid. The Contingency was the least desired - planning for more digging, because the digging created more digging.

> the building of the locks required more cement than of any project previous - to counteract things like the mudslides

> the mechanics were solved with creativity and enginuity - for example, the doors of the locks are filled with water to account for necessary mass to hold the water in each lock section, rather than built of pure concrete

> to account for a knowledge gap of electrical systems that were required for the operation of the canal, George Goethals contracted General Electric (GE). This close-knit private industry and government industry relationship serves as a model for many future large projects (such as the Manhattan project).

> after disease, the next largest cause of death and injury in the project was the use of dynamite. Although there were no single Contingencies developed to resolve this risk, proper safety was reinforced throughout the project

Chapter 9: Quantifying and Analyzing Project Risk

> the overall assessment of project risk provides concrete justification for necessary changes in the project objective, so it is one of the most powerful tools you have for transforming an impossible project into one that can be successful

> aggregated schedule Risk will invariably directly affect costs:

Work that takes longer than expected nearly always requires additional effort and therefore funding

Slippage of activities and milestones often results in expediting, crashing, or other resource- consuming tactics for following work, in an attempt to recover the schedule

Doing work later than it was originally scheduled may entail additional costs, including contact fee adjustments, replacement of time-sensitive resources, extended use of facilities or specialized expertise, reschedule of travel, and others

Penalties and other direct financial consequences may be caused by deadline delays

> there are 3 types of metrics:

Predictive: use current information to provide insight into future conditions - typically the least reliable. These include the initial ROI estimate on a project, and the output of Monte Carlo and PERT analysis

Diagnostic metrics: designed to provide current information about a system. This is based on earned value

Retrospective metrics: these report on how the process worked. These can be used to calibrate and improve the accuracy of corresponding predictive metrics for future projects

>> predictive metric examples:

>Scope and scale risks:

Size based deliverable analysis (component counts, major deliverables counts)

Project complexity

Volume of expected changes

Number of planned activities

> schedule Risk:

Project duration (calendar time)

Total length (sum of all activity durations if executed sequentially)

Activity duration estimates compared with worst-case estimates

Number of critical paths in network

The ratio of activity dependencies to activities

Maximum number of predecessors for any milestone

Total float

> Resource Risk:

Total effort (sum of all activity effort estimates)

Total cost (budget at completion)

Staff size

Activity cost estimates compared to worst-case scenario

Number of unidentified activity owners

Number of staff not yet hired or assigned

Number of activity owners with no assigned backup

Expected staff turnover

Number of geographically separate sites

> financial risk:

Payback analysis

Net present value

Internal Rate of Return

> overall risk:

Number of risks identified in the risk register

Quantitative and qualitative risk assessments

Adjusted total effort (comparing baseline with other similar projects, adjusted for significant differences)

Aggregated overall schedule Risk (or Aggregated worst-case duration estimates)

Aggregated resource risk (worst-case cost estimates)

>>Diagnostic project metrics:

> scope risks:

Results of tests, inspections, reviews, and walk-throughs

Number and magnitude of approved scope changes

> schedule risks:

Key milestones missed

Critical path activity Slippage

Cumulative project Slippage

Number of added activities

Early activity completions

The ratio of activities closed in the project compared to the number expected

> Resource Risk:

Excess consumption of effort or funds

Amount of unplanned overtime

Earned value (a running accumulation of the costs that were planned for every project activity that is currently complete)

Actual cost (a running accumulation of the actual costs for every activity that is currently complete)

Planned value (a running accumulation of the planned costs for every project activity that was expected to be complete up to the current time

Cost performance index (the ratio of earned value to actual cost)

Schedule performance index (the ratio of earned value to planned value)

Cost variance (the difference between earned value and actual cost, a measure of how much the project is over/under budget

Schedule variance (the difference between earned value and planned value

> overall risk:

Risks added after project baseline setting

Issues opened and issues closed

Communication metrics, such as volumes of email and voice-mail

The number of unanticipated project meetings

Measured impact on other projects

Risk closure index (ratio of risks closed in a project divided by an expected number based on history)

>> retrospective project metrics

> scope:

Number of accepted changes

Number of defects (number, severity)

Actual size of project deliverables analysis (components, deliverables)

Performance of deliverables compared to project objectives

> schedule risk:

Actual project duration compared to planned schedule

Number of new unplanned activities

Number of missed major milestones

Assessment of duration estimation accuracy

> Resource Risk:

Actual budget compared to planned budget

Total project effort

Cumulative overtime

Assessment of effort estimation accuracy

Added staff

Staff turnover

Performance to standard estimates for standardized project activities

Variances in travel, communications, equipment, outsourcing

> overall risk:

Late project defect correction effort as a percentage of total effort

Number of project risks encountered

Project issues tracked and closed

Actual measured ROI

>> Key Ideas:

Survey contributors and stakeholders for risk assessments

Use worst-case estimates, Contingency plan data, or Monte Carlo simulation analysis to estimate project uncertainty

Estimate project scale in effort months

Establish and use project metrics

>> Panama canal:

When John Stevens arrived at the canal he mentioned there were three diseases: yellow fever, malaria, and cold feet (nerves). The worst of the three, he said, was cold feet. Dr. Gorges handled the first two, stevens handled the third one. He did this by breaking up the project into incremental, manageable pieces. After stevens' analysis, each component was broken down into a task that had been done by projects before. Stevens is known to have mentioned,?"there is no element of mystery involved, the problem is the one of magnitude, not miracles." When it looks like miracles are necessary, people tend to give up, and that skepticism may very well make the project impossible.

Chapter 10: Managing Project Risks

> this chapter builds on the foundation of the previous chapters, discussing how to effectively use risk and project data to influence necessary changes, to clearly communicate project risk, and to adopt ongoing risk management practices that detect new risks promptly and minimize problems throughout the project

>> metrics:

> metrics are objective; if they are evaluated by several people, each person should get the same result. They are also easy to understand and collect

> document each metric and its parameters. Include information such as the name of the metric, the intended objective, data required, measurement units, measurement frequency, the method for collecting the data, any formulas used, the target acceptable range, and the metric owner.

> politically, the most difficult situations on complex projects are from the changes requested by sponsors and management. Although it's never easy to say no to the people you work for, the existence of a documented process that has been approved to manage the project change is a vital step, and clear, data supported descriptions of the consequences of requested changes are necessary

> 4 responses to change requests: approval, approval with modification, rejection, and deferral.

> effective change processes avoid having too many decision makers required for approval to ensure prompt response to change requests, and they provide named backups who can act when a designated approver is not available.

> Key ideas:

Hold a project kick-off meeting and create a team charter

Select and use several project metrics

Determine required project reserves

Negotiate and commit to credible project objectives

Manage scope and control specification changes

> Panama Canal:

The debate was still strong during Steven's time to build a sea-level dam. Stevens used a full arsenal of data driven graphics, negotiation with Senators, and a great deal a perseverance to convince congress of the infeasibility of a sea level dam. It worked, and Steven's plan to build a lock and steel door system instead.

Chapter 11: Monitoring and Controlling Project Risk

> adding contributors to a late Project is often not helpful (for a while), as the new individual needs to be caught up to speed before they may actually contribute any progress. Disciplined Monitoring and Controlling finds and fixes problems while they are still small, so the project avoid serious problem in the first place

> projects become late one day at a time. Failure to detect this as soon as possible allows schedule and other risks to remain undetected, grow, and ultimately overwhelm the project

> 2 kinds of data: capital D and lower case d. Capital D are facts and figures. Lower case d is rumors, and anecdotal information. Both are useful. Hard data reveals trends, soft data may provide early warning of coming causes to trends.

> thanking people for bad news is never easy, but if you routinely punish team members for providing honest data, you will quickly stop hearing what you need to hear- and project risks will escalate

> if trends information indicates a problem and you take no action, the trends is likely to continue to grow. As it gets later in the project, the options diminish and the changes required to reverse the trend become more extreme and less likely to help.

> modern projects are successful not because they are easy; they succeed because the people care about them. Anything that interferes with this raises project risk to insurmountable levels.

> a typical project archive contains:

Project definition documents

All versions of all planning documents used

Each project status report

Other periodic project reports and communications

Risk register and issue logs

A change control history

When the project is completed, the post-project retrospective and lessons learned documents are also added

> Key ideas:

Collect status dogmatically

Monitor variances and trends frequently throughout your project

Respond to issues and problems promptly

Communicate clearly and often

On long projects, conduct periodic risk and project reviews

Be skeptical whenever assuming leadership of a project. Conduct a quick, thorough review to initiate changes and to "make it yours"

> Panama Canal:

The canal was ultimately successful because they revised their plans to deal effectively with problems as they emerged.

Technology of steel production meant shops could be built bigger, which resulted in the redesign of the canal to accommodate the bigger ships.

Dry seasons meant less water available to fill the locks for ships to pass through, this caused the re-design of the water reservoir to only used an amount of water necessary for the size of the ship using the lock.

Goethels minimized risk through intense management of all changes and if causes that could impact the project.

Chapter 12: Closing Projects

> using a continuous cycle of measurement, small modifications, new measurements, and comparative analysis, you can discover new ways to improve processes.

> project closure often involves:

Formal acceptance of completed project deliverables

The final written report

Closeout of all project contracts, documents, and agreements

Acknowledgement of contributions

A post-project retrospective analysis to capture lessons learned

A celebration or event to commemorate the project

> even if the project was not successful, it is good to get people together and Acknowledge what was accomplished.

> retrospective meeting goals:

Improving future projects and minimizing their risks. It is a backwards-looking and comprehensive, mining of the history of the whole project for ideas to keep and for processes to change going forward.

> consider sending an anonymous survey (example provided pg 326) prior to the meeting to guide the discussion

> Key ideas:

Thoroughly and accurately document the project results

Recognize accomplished and thank contributors

Conduct a project retrospective and *use the recommendations

Review your risk processes and update your data archives

> Panama Canal:

The first sea vessel crossed the canal on August 15, 1914 - it was overshadowed by the break of WW1.

it finished six months ahead of schedule and finished with $23 million to spare. However 30,000 people died, primarily from having the TNT.

If asked to name a successful engineer to model, choose Goethels.

Chapter 13: Program, Portfolio, and Enterprise Risk Management

> the focus of Program risk management is dealing with complexity. Portfolio risk management is primarily concerned with achieving financial goals. Enterprise risk management shifts attention to the longer-term health and viability of the organization as a whole.

> project risks that should be "promoted" to the program risk register:

Project risks that are significant enough to be program show stoppers

Project interfaces and cross-dependencies

Novelty or substantial technical complexity (architecture, systems engineering) that could result in integration problems or defects

Potential conflicts involving individuals or other resources needed by two or more of the projects

Significant work done by outsourced or distributed project teams

Similar project risks identified in several projects that in aggregate represent large overall impact

Projects that are inherently risky overall

Any risks that could persist as possible problems past the duration of the project where they are identified

> the most significant Program risks:

Interdependencies and interfaces between projects

Complexity and potential deliverables issues

Staffing problems, motivation issues, and funding commitments

Any significant program-level risks

> important: have a risk register. More important: have a monthly risk review meeting and integrate risk discussions into weekly check-ins. Most important: investments in building strong relationships and trust amongst the staff, where there are no issues of coverage and courage to identify risks. Where it matters little of a person's title or role; everyone pitches in to get things done. The atmosphere of one for all and all for one is the most effective tactic for managing risk and ensuring a successful program

> portfolio planning includes prioritizing amongst a mix a projects. Typical project categories include:

New basic research and development

Revolutionary products, processes, or new markets

Next generation/ new platform to replace an old offering

Evolutionary improvements to an existing product or service

Maintenance, support, or infrastructure

> in portfolio analysis, there will always be some way to accommodate an additional small project. Failing to consider and plan for the large, often strategic, at the outset of the portfolio process can result in a portfolio entirely consisting of small projects - in which fails to be able to support the larger projects.

> enterprise risk management focuses:

Safety and security

Fraud and financial liability

Casualty loss and disaster preparation

Organizational reputation and brand protection

Intellectual property management

> general plan for risk response:

Establish a well defined, rapid escalation process, particularly for cases where there were any potential safety or health consequences

Quickly involving all people who would play a role

Maintaining effective and visible communication with all parties

Identifying one individual responsible for all external communications and management of a consistent single message for each situation

> look up the Committee of sponsoring organizations of the Treadway commission (COSO) for defined frameworks and standards for managing enterprise risk

>> Key ideas

Manage risk well in every project

Understand and manage program-level risks, particularly those that involve cross-project dependencies, resource contention, and program "showstoppers"

Minimize portfolio risk through use of appropriate criteria, including risk and unbiased assessment of project opportunities (Value at Risk analysis)

Determine relative risks for projects and programs, and use risk correlation analysis to lower project risk

Manage enterprise risk through dogmatic monitoring and periodic maintenance of the project portfolio

Understand and comply with your organizations policies and standards for enterprise risk management

> Panama Canal: increased traffic through the now complete canal resulted in over-draining of water from the Gatun Lake. As a response, there was a secondary water source project that enabled water to be drawn from further up the Chagres River. This is an example of continued risk management especially after completion of the Canal years prior.

Chapter 14: Conclusion

> Henry Ford quote, "whether you think you can do a thing or not, you are probably right"

As a principle, do enough planning and risk management to convince yourself that the project is possible. When people are confident that they do be successful, they persist until they find a way to get things done.

> Success in projects requires three things (not scope/schedule/cost): planning, diligent tracking, and expertise