Business Framework for Risks

I

Project Risk Management

Project Risk Management

El Bruce T. arkley

NswYork Chlcago San Francisco Lisbon London Madrid Mexico City Milan New Delhi San Juan Seoul

Singapore Sydney Toronto

Cataloging-in-Publication Data is o n file with the Library of Congress.

Copyright 0 2004 by Thc McGraw-Hill Companies, 1 n c . N rights reserved. h i n t e d in the United States of America. Except a s permitted under the United States Copyright Act of 1976, no part of this puhlication may be reproduced or distributed in any form or by any means, or stored in a data base or retrieval system, without the prior written permission of the publisher.

ISBN 0-07-143691-X

The sponsoring editor for this book u a s Larry S. Huger a n d the production superuisor was Sherri Souffrance. It was set in Century Schoolbook by International Dpesetting a n d Composition. The a r t director for the cover was Handel Low.

Printed a n d bound by RR Donnellq.

This book was printed on recycled, acid-free paper containing a minimum of 50% recycled, de-inked fiber.

McGraw-Hill books are available a t special quantity discounts to use a s premiums and sales promotions, or for use in corporate training programs. For more infor- mation, please write to the Director of Special Sales, McGraw-Hill Professional, Two Penn Plaza, New York, NY 10121.2298, Or contact your local bookstore.

Information contained in this work has been obtained by The McGraw-Hill Companies, lnc. ("McGraw-Hill") from sources believed to be reliable. However, nei- ther McGraw-Hill nor its authors guarantee the accuracy or completeness of any information published herein, and neither McGraw-Hill nor its authors shall be responsible for ally errors, omissions, or damages arising out of use ol this informa- tion. This work is p~uhlished with the understanding that McCraw-Hill and its authors are supplying information but are not at,ternpting to render engineering or other professional services. If such services are required, the assistance of an appropriate professional should be sought.

To the over 3,000 hard working, adult graduate and undergraduate students at Dewy Uniuersity/Keller Graduate School of Management-Atlanta, and at The University College, University of Maryland, who have provided me over the past 30 years with wonderful opportunities to learn from them-undoubtedly more than they learned from me.

Contents

About the Author xi Preface xiii Acknowledgments xv About This Book xvii

lntroductlon

What is Risk? Risk, Process, and the Myth of Control A Way of Thinking

Chapter 1. Preparing the Organization: Building a Risk Management Culture

Prepare the Organization Risk: The Organizational Culture Issue A Culture of Risk Management Competence Llnk Corporate and Project Planning Training and Development in Risk Project Experience Learning Organization Strong Functional Managers Address Quality Building the Culture Keane's Risk Process Risk Analysis and Mitigation Addressing Risk with Scenarios Performance Incentives Taking Risks:The Risk of "Blinders" Personal, Project, and Organizational Risk

Chapter 2. The Business Risk Framework

Portfolio Management Organization Strategic Statement One- to Five-Year Strategic Objectives Comments on Risk Analysls

viii Contents

Chapter 3. Doable Tools: Applying Tools Strategically

Customer Requirements Work Breakdown Structure Task List Network Diagram Time-Based Network Diagram Gantt Chart A Risk Story:Tradeoffs in Risk Project Manager's Roles and Responsibilities in Risk Management Work Breakdown Structure, Again! Project Financial Perspectives More Background ProjectTools Project Control Systems

Chapter 4. Demystifying Risk: U s i n g t h e PMI PMBOK

Demystifying Risk-PMBOK Risk Management Planning Risk Identification Qualitative Risk Analysis Quantitative Risk Analysis Risk Response Planning Risk Monitoring and Control Summary of Risk Management Process Build a Risk Management and Planning Process A Note on Microsoft Project PERT and Risk Matrix Terminology Risk Response Contract Management

Chapter 5. Making Risk Policy: A Risk-Based Program Management Manual

Program Management: Roles and Responsibilities Program Planning, Scheduling, and Resource Management Defining the Program Management Process and Risk Process

Chapter 6. R l s k Matrix Samples

Steps in Preparing a Risk Matrix Summing Up: Risk Matrix Examples

Chapter 7. A Case in R i s k a n d Microsoft Project

Part 1: Portfolio Project Selection and Risk Introduction to Parts 2,3, and 4 Part 2: Project Planning and Risk Part 3: Establishing the Risk-Based Project Plan Baseline Part 4: Project Review for Progress, Risks, and Earned Value

Contents ix

Risk and This Case The Solution Organizational Structure Possible Conflict and Resolution Conflicting Schedule Plant Readiness Project Cost Risk Analysis in Project Selection Huntsville: Risk-Based Scheduling Risk and the Huntsville Project: Journey in Risk

Chapter 8. Customer-Driven Project Management,TQM, and Risk

Customer-Driven Risk Management Portfolio and Program Management Value of Customer-Driven Risk Management

Chapter 9. Strategic Planning and Risk-The Eastern Case

Commitment and Partnership Eight Strategies Overview Strengths, Weaknesses, Opportunltles, andThreats Eastern's Strategic Plan Communicating Strategy and Risk Postscript to the Strategic Plan Acqulsltion and Merger

Chapter 10. Risk Lessons Learned and the Project Rlsk Audlt

ProJect Audits How to Do Risk Lessons Learned Review Project Audit

Appendix A. Cost and Risk Exercises-How Do Risk and Cost Work in a Real Project Setting?

Sample Questions More Questions on the Risk Management Process and Cost

Appendix B. Risk-Based Project Schedule

Appendix C. Demystlfying Business and Project Risk Management: A Checklist

Bibliography

About the Author

BRUCE T. BARKLEY h a s over 30 years of experience in program and project risk management in both industry and government. The coauthor of a suc- cessful book on project management, Customer Driven Project Management: Building Quality into Project Processes, Second Edition, Mr. Barkley has succeeded in making risk management clear and practical i n a field t h a t has become highly techni- cal and quantified. Mr. Barkley has consulted in lsroiect risk management and serves a s faculty A - - member with DeVry University (Keller Graduate

School of Management) in the Atlanta area. He is a graduate of Wittenberg University, University of Cincinnati, and the University of Southern California, has previously taught project management at t h e University of Maryland University College, and served as a senior executive in several federal agencies in Washington, D.C. He lives i n Atlanta with his wife Cathy of 44 years.

Preface

This is not your father's risk management book-it is not your conventional treatment of project risk management. Rather than treating project risk as a narrow project and task-specific, "process" issue, risk is seen here a s the out- come of bad project selection, bad business planning, and bad company-wide cul- ture. Readers will experience a refreshing new perspective on project risk t h a t centers risk management on:

The business, enterprise-wide level

Good business and project planning and management practice

Building a healthy organizational culture t h a t recognizes risk a s the conse- quence of bad planning

Chapter 1 will offer new insights on building a risk management culture, while Chapter 2 deals with project selection using weighted models, financial return, and other risk information. Chapter 3 provides more useful tools, and Chapter 4 includes a broad interpretation of the current Project Management Institute PMBOK (Project Management Body of Knowledge) risk management section. Chapter 4 illustrates a good project management manual to offset risk while Chapter 6 illustrates a basic risk tool-the risk matrix table. Chapter 7 covers the use of Microsoft Project to calculate a "risk-based" project schedule. Chapter 8 revisits risk and quality management. Chapter 9 is another practical exam- ple of enterprise-wide, strategic risk planning i n the Eastern case. Chapter 10 addresses how to document lessons learned in risk management.

Appendix A i s a useful set of exercises and problems-with answers-n risk and cost management, Appendix B is an example of a risk-based schedule using MS Project, and Appendix C provides a checklist to demystify business and project risk management.

Acknowledgments

The author would Like to acknowledge the following sources for this book:

The Universal Avianics Systems Corporation, Instrument Division, for valu- able experience in supporting and managing product development projects and processes, and writing program manuals and policy documents and conduct- ing analyses i n the program management office.

The Alumax Aluminum Company (now Alcoa, Inc.), where the author was a project management and organizational development consultant, for valu- able experience and case material in strategic planning a n d SWOT analysis in a manufacturing work setting.

Keane, Inc., for valuable insights into how a successful, major software devel- opment and information company handles risk. Keane is one of the largest and most successful software services in North America, a company that has been a t t h e forefront of project and risk management since the company was founded in 1965. Keane continues to offer such services and h a s trained thousands of client participants. The author used some of Keane's concepts in this book as examples of quality risk management.

Adult students and faculty a t DeVry University and Keller Graduate School, Atlanta, where the author serves as senior faculty member and curriculum manager for project management, for valuable stories, cases, and exercises i n project and risk and cost management, which serve a s the basis for material in the book. Special thanks to MBAstudent Jerel Hayes. His work on "Good Flight and Airlines" i n chapter 2 and other student material have been used liberally in the book.

About This Book

Project risk management is a n art, not a science. I have always been skeptical of scientific and overly quantitative answers to complex social, organizational, and project outcomes, especially when customers, products, and markets are involved. I think risk can be stewarded and managed by good planning and analysis, but in the end it is often the g u t feel of a project manager t h a t turns a project i n the right direction and overcomes risk.

We tend to look for ways to control business and project outcomes t h a t some- times simply cannot be controlled. I t is a s if there is some underlying need to explain why things go "south" in a complex endeavor or project in systematic terms, and as if the world of human systems operated in a predictable and con- trollable way. We seek answers for all failures to fix them, yet we often do not know what factors were important. We assume t h a t a system is in place and if the system fails we want to find out why it failed. When a business or project fails, we conclude that "somehow this failure could have been avoided if we h a d just studied and analyzed the risks a bit more, perhaps drilled a little deeper into the inherent impacts and probabilities."

Such a n approach assumes that risks and failures operate in a predictable way, t h a t the factors t h a t lead to risk events and failure can always be identi- fied, catalogued, and controlled, and t h a t more analysis will uncover t h e secret to the mystery. The principle is t h a t we should be able to identify what might happen, what the probabilities are, what the impacts are, and how to respond. I t assumes that we can find attribution, t h a t we can attribute failure to key events or circumstances. I t is true t h a t the root causes of project failure are rarely a mystery--they often have to do with business performance, market con- ditions, leadership bias, and lack of support. They rarely have to do with tech- nological f a i l u r e t h e engineers will usually find a way-it's the organization t h a t cannot stand success.

The problem is complicated by the variety of definitions among stakehold- ers of failure a n d success. One person's failure is another person's success. A project which overcomes technology risk can deliver within budget and sched- ule and be termed a success by the project team, but it is possible that this same deliverable cannot be manufactured, or t h a t the customer is not happy with the

xviii AboutThis Book

outcome, or that the business itself fails for reasons that have nothing to do with the project.

The drive to mystify risk assumes t h a t there is always one true risk involved in every factor, task, or project, and t h a t to solve the risk mystery we have to go to extreme limits to identify and quantify t h a t risk. This makes the subject more complicated t h a n it needs to be-and assumes t h a t is within our grasp to capture all the mot causes of risk. Somehow if we can establish t h a t the risk of failure of a team task to integrate a n information system is 66 percent rather t h a n 24 percent, we can make decisions based on a n unreal confidence i n sci- ence to predict things like t h e economy.

What is missing here is t h e fact that businesses and ~ r o i e c t s are human. not - - " mechanical systems. Despite our increasing propensity to consider the study of organizational and ~ r o i e c t efforts in business to be a science rather than a n art, - - " human behavior is often unpredictable and counterintuitive. Despite our under- standing of complex systems we cannot identify all the factors that contribute to risk and success even if we all agree on the definitions of these terms.

I n addition, technical professionals and engineers have developed their own language and values, which sometimes complement but often conflict with good project risk management. The people and communication issues in engineering and product development are not unique, but they are accentuated by a work- ing "axiom" of engineering project management-engineers communicate through channels and thought processes sometimes a t odds with cheaper, faster, better. But they are inherently good risk managers. Engineers and technicians are often conflicted i n a project management setting by time, cost, and organi- zational constraints t h a t require them to take shortcuts to good engineering and risk management. They are challenged by risk and typically want to get it right, rather than getting i t on time and a t lowest cost. For instance, the measure of mean time between failures (MTBF) is often applied to electronic and technical equipment, and tests are designed to ensure t h a t products perform under stress a t the intended MTBF. MTBF is a risk indicator; the risk of failure is quanti- fied by repeated tests and documentation. Thus a quantitative probability can be applied to its future performance. But i n most circumstances MTBF is not applicable or suitable because user settings and environments cannot be con- trolled to really predict all the circumstances a product will experience. And the customer may not be interested--or will not pay for-a certain level of MTBF. But engineers typically would like to get MTBF down to zero if they can-an application of six sigma thinking--even a t t h e cost of on-time delivery and budget.

Another complication i n project risk management is the resistance to change in the project management or supplier team a s well as in the customer's organ- ization. Typically, a complex project a n d its outcomes trigger the need for orga- nizational change, thus surfacing the resistance of those who do not see the value of change. For instance, a new electronic product produced through a product development project can alter the priorities of the customer's organization a s the new product is phased into marketing and sales. The priority on this new

AboutThis Book xix

product can upset a n ongoing dynamic in the organization long supported by the old, replaced product. The risk here is t h a t employees will resist change and undermine new product delivery unless the following factors are in place:

1. Top management support

2. Clear vision

3. Incentives to accept change

4. Incentives to take risks

5. Clear communication

6. No walk the talk

7. What Daryl R, Connor, founder and CEO of ODR, calls the Long View, a total, in-depth understanding of the effect the project will have on the organ- ization

All this said, I am optimistic that there are useful tools to manage project risk and that these tools lie i n core business and project planning and management processes. I believe t h a t project risk can be stewarded but not always controlled through good planning and scheduling and critical thinking. Through the appli- cation of risk management tools outlined and illustrated in this book a s part of the planning and control p r o c e s e a n d separate from it-risk can be managed.

The book is designed for general reading in business, program, and project management, and for training and academic courses in project management and risk. The approach is to broaden and simplify the risk concept a t the same time, offer useful tools and best practices, integrate risk into the strategic, business, and project planning and control processes, and to offer exercises and cases for learning purposes. The book shows how to apply the PMI Body of Knowledge on risk, but goes beyond it in many respects.

Figure 1 shows the simple steps of risk management that underlie the book, a sequence of topics t h a t align with the chapters.

There is a simple logic in this book t h a t provides the structure and sequence of chapters (Fig. 2). First, prepare the organization and its people for risk man- agement as part of the business, then identify risks a s part of business plan- ning, integrate the process into project planning and control, then make it simple by using templates, and finally, learn what works.

Here is the logic in more detail.

First, prepare your organization or it wont work. Risk management does not work unless everyone does it all the time and when management expects it to be done right.

Second, get started with good businessplans. Risk management does not start with projects; it starts with how the business is structured and planned.

Third, risk is not science; it i s art. Risk tools are simple planning aids and easy to apply. Don't overdo it and don't overquantify the process.

xx AboutThis Book

Prepare the organlzation: Build it into the culture

It starts with the business itself: Risk is embedded in the business

Use doable tools: Use project risk tools, they are easy

I Demystify PMBOK: Learn PMBOK, but don't stop there I I Use manuals to make risk pollcy: Make policy with risk manuals I

Use easy forms: Forms make it easy I I t i s hard t o do without MS project: Use PM software - it works

Products create risk: If you make a product, you have risk

Risk Is customer-driven: Risk starts and ends with the customer

Risk makes strategy useful: Risk is the reason you plan strategy

1 Find out what works: Focus on what works, not what doesn't 1 Figure 1 The simple steps of risk management.

Fourth, theprofessional Project Management Institute Body of Knowledge on risk is helpful from aprocess view, but has limited applicability. Make sure you know the PMBOK, but don't stop there.

Fifth, making riskpolicy i n a simple manual. Help project managers manage risk with a simple manual.

Sixth, see how others do it. See the value of cases and exercises.

Seventh, use templates to make it easy. Use forms already available.

Eighth, it's hard to do risk without M S Project. You can do risk manually, but project management software makes it easy.

Ninth, you have to do risk i n product development. Whenever you produce products, you have risk.

Figure 2 The logic of risk.

- Prepare the organization for risk

- --, Starts with business planning

Use risk matrix -+ worked templates

- Integrate into project planning

AboutThis Book mi

Tenth, risk is customer-driven. You have to get in the shoes of the customer before you really understand risk.

Eleventh, risk makes strategic planning useful. Risk is the only reason to do strategic planning; here is a case where risk is integrated with long-term planning, along with a presentation format.

fluelfth, after the fact, learn what worked. Don't focus on mistakes; focus on what worked!

Introduction

The demystification of risk involves a whole new perspective on a business- wide process t h a t has been looked a t for many years a s a separable, quantita- tive, and project specific exercise. The overkill i n quantification comes from the attempt to replicate scientific, mathematical models of probability, but most proj- ects do not need such rigor. The issue in project risk management is simple awareness of risks and intense management. As Fig. 1.1 indicates, this book changes the paradigm for risk management while recognizing the value of cur- rent approaches.

Setting u p for risk management means preparing t h e organization and not the project first. The issue is establishing the value of risk analysis a s part of the normal project planning process.

Fin

di

ng out where risks are is built into the work breakdown structure (WBS) and scheduling process; risk is a n input to risk-based scheduling.

Dimensioning risk is qualitative, ranking and ordering, usually not quanti- tative.

Corrective action is not preparing separate task-based contingencies and kicking them in when necessary, but rather building them into the baseline schedule.

Postmortem audits by outsiders are rarely helpful because they are not accepted and do not reflect the insights of those who did the work; lessons learned meetings are far more helpful.

What Is Risk?

Risk, which is uncertainty that has been defined, is a simple concept, a way of thinking through and planning a program or project. There are many treatments of risk in the literature, but most tend to overdo the quantitative tools and under- state the softer, more people-oriented issues in risk management. This book stays with the middle ground, touching all aspects of risk hopefully in a readable way.

The demystification of project risk involves some new assumptions about project planning and control.

First, risk has been narrowly treated in the context of projects and project tasks, but the sources of risk are more appropriately addressed a t the business and industry level first. The prevailing notion about project risk management

2 Introduction

Setting up

Find out where major

risks are

Dimension risk

Corrective action

Postmortem

Risk management today: Risk management tomorrow: separate processes dernystify embed, and integrate

Figure 1.1 Demystifying risk management: today a n d tomorrow.

has been the assumption t h a t knowledge of internal, project-oriented planning and control issues was most important i n forecasting and managing risks and costs. This assumption has driven the subject of project risk management i n directions that focus on internal project tasks and risks. But business analysts increasingly find t h a t emerging external business issues often have a much greater impact on the future of their organizations-and on project success- t h a n any internal issues. Thus the roots of project risk lie i n the forces acting on the company, and the customer, a s a whole.

Second, and a s a consequence of the first point, project risk cannot be sepa- rated from business planning, project selection, planning, and control. It is inte- gral to these processes. Risk is the core planning challenge a t the heart of business development and later, project management. The separation of risk management process from the rest of the broader business and project man- agement paradigm is the wrong approach to the subject because it implies that somehow risk is largely internal to a project and therefore controlled by the proj- ect team. Since project risk is business risk, the whole business strategic plan- ning, marketing, and risk analysis process is directly relevant to project risk. Risk applied to a business framework produces SWOT (strengths, weaknesses, opportunities, and threats) analysis and other outputs that support identifica- tion of project risks. These risks include competition, unanticipated technology change, market shifts, business finance, workforce issues, and changes in t h e customer base.

Third, risk management is largely a leadership and management challenge first, not fundamentally a quantitative process a s portrayed in texts on t h e

lntroductlon 3

subject. Organizational culture drives the approach to risk. Risk is actually qualitative and intuitive and brings out the most creative juices of project process. It is risk that generates the passion of business achievement; to over- come risk is to overcome a competitive challenge a n d create opportunity. Overcoming risk equals business success.

This book addresses the process of identifying, analyzing, and responding to business and project risk in order to minimize the consequences of adverse risk- based events. The PMI PMBOKprocesses of risk planning, identification, quan- tification, response planning, and control are covered, a s well as risk factors, contract types, assessment techniques, tools to quantify risk, procedures to reduce threats to project objectives, and contingency.

Risk definitions

The Software Engineering Institute defines risk management a s "Asuccessful risk management practice is one i n which risks are continuously identified and analyzed for relative importance. Risks are mitigated, tracked, and con- trolled to effectively use program resources. Problems are prevented before they occur and personnel consciously focus on what could affect product qual- ity and schedules."

You can see t h a t this definition is fairly broad and describes a process t h a t goes through the whole project life cycle. The definition addresses the way proj- ect team members think and act i n the planning and organizing process.

There are five principles underlying the definition of risk in this book:

1. Risk is any uncertainty in a project plan t h a t you can potentially control, or a t least track. This means t h a t there are many risks i n any project. The trick is to identify the most critical risks-the ones t h a t could make or break your project-and control them. Overcoming a risk-that is being able to complete a project or project task despite the risk--creates opportunity. The other side of risk is opportunity-if a business is better, faster, a n d cheaper in produc- ing its products and addressing customer needs and reducing the risk in the process a t the same time then the payoff opportunity is market share and business growth.

2. Risk is integral to the business and the project planning process; therefore don't think of risk a s something different or separate from management. Risk is why you do business and plan project- if there were no risk, t h e r e wouldn't be a project. And addressing risk simply means that you are always looking around you to find things that can go wrong in defining and scheduling work.

3. Focus only on the high-risk, resource-consuming tasks because you can't focus on all of them all the time. Assessing risk is a question of rank-ordering risks and keeping your eye on them. While we will exercise some quantitative tools in this course, such a s probability analysis, these tools have very selec- tive applications when you have a very complex project and you have back- ground d a t a on technical probabilities.

4 Introduction

4. Monitoring risk is a question of identifying key risk milestones or points in the project schedule where risk decisions need to be made. These milestones would mark whether a piece of equipment worked, or a key resource was available, or a key technology in a new product worked a s designed.

5. Planning a response to risk involves understanding the project and impacts of various corrective actions midstream. You create risk scenarios and sched- ule impacts. An "expected" scenario is the best guess a t what actually will happen, a "pessimistic" scenario is the worst case, and an optimistic scenario is the "best case."

Risk, Process, and the Myth of Control

There is a natural tendency to study risks a s separate problems, to see risk a s one shot points-in-time when risks are systematically identified, assessed qual- itatively and quantitatively using sophisticated mathematical models, and controlled through conceived contingency plans. But real-world experience teaches us t h a t risk is, in truth, a n inseparable aspect of the whole project life cycle and its daily irrationality and interpersonal dynamic. I n a way, risk events are a result of bad planning. In that sense, risk can be seen as a continuous series of individual and collective decisions in planning and managing a project. The process is not mystical and quantitative; it is organic a n d intuitive. You head off some risks while creating others-you mitigate a technology risk with infor- mation on impacts, and address the potential disease, but there may be risk i n the cure a s well. Some risks occur despite mitigation, while others do not, despite being ignored. Sometimes neglected risks never happen.

Many decisions add up to a successful management of risk. The tyranny of small decisions adds u p to success or failure. Thus risk is part of the planning cycle-planning is designed to reduce risk, but i n fact the role of planning is to see risk coming and to address it in the plan.

Risk and quality are a s cost and benefit. Quality may be defined a s the ext.ent to which the road taken (the process) conforms to the proven road already taken successfully. To know your process a n d follow it consistently is to produce a quality product. This suggests t h a t if you know the correct process, you can pro- duce quality a t minimum risk and cost, simply because you know how the process works.

But if the process and product are new, the cost of quality increases a s you incur costs of waste, redundancy, and inspection/appraisal. Risks unattended create costs because they imply repetition, error, and delay. But these costs a r e not simply costs of delay and schedule; they are costs of actions, contingencies.

For example, in the design and production of a complex, electronic, digitized avionics instrument, there is a n inherent risk a t every step in the process:

1 . Customer requirement. There might not be a "customer" per se, or if there is, the customer has no idea what is needed. Thus customer requirement itself

Introduction 5

is a risk and t h a t is why we spend time trying to identify requirements. Requirements analysis is a risk reduction tool. Each time we assume t h a t we have the requirement down and choose not to test i t out with the customer- or each time we do test it out but the customer falsely assures us that the specification is correct-we add incrementally to the totality of the customer requirement risk. Checking with the customer is not the simple solution, a s the customer changes expectations; risks t h a t they may be unrealizable change, sometimes for the better. In other words, as the customer is educated on risk, the customer is liable to make decisions, which lessen his or her risk and sometimes the risk the project itself faces.

2. Concept. The concept might be flawed because it is not feasible. Innovation in project concept leads to creative vision of what is possible, but it might not be possible or even desirable in the eyes of the customer or the key stake- holder. Thus there is inherent risk in designing a concept but there is also opportunity. The more options are presented to the customer in the concept stage, the more the probability t h a t one or another will delight the customer, a t least in principle. Thus innovation applied in the concept stage is a risk mitigation step in the sense that i t is in this stage where ideas and visions can be addressed without substantial cost.

3 . Design. The design might not meet the requirements, or the design might be feasible in production and assembly. Design, putting a concept into a drawing or rendering, involves a myriad of steps t h a t are inherently risky; from misstating tolerances to choosing unavailable components, to design- ing correctly to a n inaccurate requirement or specification.

4. Prototype. The development of the prototype may not be aligned with the requirements, so testing the prototype does not assure success either in con- formance to specifications or customer satisfaction. I n building a physical model of the product a n d testing it, there is inherent risk t h a t the prototype is not representative of the (unexpressed) expectations of the customer, or t h a t the prototype is not exactly like the product t h a t is to be manufactured. Or the costs of the prototype may not be accurate so t h a t when the time to produce i t arrives, the company cannot afford i t a t the price used in justi- fying it.

5 . Production. The product process might not be consistent with the time and resources needed to put the product together and produce it in volume.

I t is important to see risk as a tradeoff with benefits, opportunities, and pay- offs. In other words, risk is the reason for investment-to seek out profitability by reducing uncertainty and gaining benefits in terms of customer value and profitability. The following matrix (Fig. 1.2) illustrates the tradeoffs involved in categorizing and selecting projects for a business portfolio.

6 Introduction

High

Low High

Quadrant I

Hlgh risk Low benefit

Quadrant 111

Low r~sk Low benefit

-

Figure 1.2 RisWbenefit template.

Quadrant II

Hlgh r~sk High benefit

Quadrant IV

Low rlsk Hlgh benef~t

Quadrant I: High risk, low benefit

Projects which fall into this quadrant are not worth doing simply because there is meat uncertaintv about outcomes and little foreseeable oavoff. Of course, com- - - " panies typically support a Limited number of exploratory R&D projects, some of which can move from this quadrant to the next when unexpected payoffs are uncovered.

Quadrant II: High rlsk, high benefit

Projects here are major investments with high risks of failure, but with outcomes t h a t could substantially improve market share, company growth, and prof- itability. A good example of such a project would be a n investment project in the field of space exploration.

Quadrant Ill: Low risk, low benefit

Projects in this quadrant are not worth doing simply because there is no fore- seeable payoff, even though the cost or risk involved is minimal. An example would be a superficial landscaping improvement to a plant location when the permanence and viability of the plant itself is i n question.

Introduction 7

Quadrant IQ: Low risk, high benefit

Here the projects are very attractive because for minimal risk there is a poten- tial high benefit. An example would be installation of a proven technology in man- ufacturing t h a t promises to double productivity of a current plant or facility.

A Way of Thinking

Risk is a way of thinking f r s t , a balanced worldview t h a t looks critically a t busi- ness, program, and project decisions in terms of both sides of t h e question. I n this book, we will explore various ways of embedding this way of thinking into the organization so that risk and benefit tradeoffs are part of all key decisions.

Demystifying Business and Project Risk Management

Risk management involves a whole set of activities t h a t are embedded into the project planning process. Appendix D summarizes the kinds of risk checklist actions t h a t are covered in this book.

Chapter

Preparing the Organization: Building a Risk Management Culture

Building a culture of risk management is primarily a process of developing people in your organization who think and plan projects effectively, and who are supported by company systems that encourage them to think and plan effec- tively. That involves looking constantly at what could go wrong and knowing the difference between theoretical risk and practical risk. Theoretical risk is risk that could happen; practical risk is risk that is likely to happen. Experience helps to differentiate the two.

Prepare the Organization

If the organization does not address risk i n the way work is done, risk man- agement will fail. Defining culture a s the way work is done in the organization, if risk is integrated in the way work is done (e.g., project plans incorporate a risk matrix as defined later in this book) risk planning becomes a n expected part of planning. If risk is given lip service but not backed up, then risk management will be superficial and ineffective (Fig. 1.1).

The best way to illustrate risk is to tell a little story about what happens when risk is not in the organization's culture. See if you can relate to the following story.

"I got the customer's approval to do the Schneider program," Lakeisha told Bill. Lakeisha and Bill were project managers a t Project Associates, - - - Inc., a software and information technology company. "I've got 4 months to deliver the program to Schneider, including a new hardware platform, software code and documents, and a training manual. I think it's going to be a blast-the biggest issue to me is the software. The hardware is a no- brainer."

10 Chapter One

Train people to see risk

Establish vision of Write manuals Develop online risk risk based decisions . Use risk to help select training program Connect to business . Use risk to help manage * Use electronic template success Identify acceptable for training and cases

methods

Figure 1.1 The process of preparing the organization.

Lakeisha had delivered her last project, the Mires program, well ahead of schedule. Bill, on the other hand, had not done well in his last project and was late and over budget. Lakeisha was eager to show t h a t her last performance was not a fluke and t h a t she knew what she was doing. She always harbored little lack of confidence under pressure, but always came through. There was a subtle competition going on between the two, but they worked well together.

"I wouldn't get too excited just yet," Bill told her. 'You know I was going to do t h a t program, but I got sidetracked and the boss gave it to you. I've seen the specification for the program, and there are a lot of risks. I think you've got a t least 6 to 7 months of work with the current team to produce the deliverable as I see it. And t h a t is i f you don't have any problems with platforms, software, people, our old testing equipment, and good old unreliable software systems, our contractor. Are you going to go with the same team you used last time? Planning any risk assessment and contingency-you know, those scenario things?"

'Yes and no. I am going to use the same team, I think, but I don't have time for t h e risk stuff this time. I t isn't a required part of t h e project plan, especially if you have been there before as I have. Been there, done that. I will use a schedule from our last project for Smothers, which was a good r u n and we kicked butt. I have looked a t the risks and the big ones are i n the software graphics package and online training package. I've got a plan to shrink the schedule to 4 months by crashing some stuff and outsourcing. I read a n article on outsourcing last week and the story included a great company t h a t does just what I want them to d o - o r almost. That is going to cut my schedule by 2 months. This project h a s to be on the fast track from the word go. I am going to write a cost plus

Preparing the Organization 11

contract with them because procurement says that is the template they like to work with."

'Well, I hope you know what you're doing," Bill said to Lakeisha as they crossed i n t h e corridor. "I have seen a lot of people get burned by contractors and you know t h a t t h e hardware for this deliverable is new and will require some long lead times on parts."

"Cool it Bill. I've picked a reputable contractor," Lakeisha said. "I checked his references-actually I just talked to a friend who works there- and I am sure t h a t the contractor will do a great job and will accept most of the risk. I told him I would make progress payments on the cost plus contract only if he was on schedule and he agreed. He said he would put more people on t h e job if it turned out to be more complicated than he thought it was. I will just keep a n eye on him. I understand t h a t his is a risky business and some risks are inescapable. But what a n opportunity to show what we can d-think of the plus side of this thing if it goes! When I have this much to do in such a short time I'm not going to waste the team's time on risk games and risk matrices. I know what I want and I know what the risks are."

Bill thought she should be more careful, but liked her spirit. He and Lakeisha had been over this ground before. He had learned some lessons on risk i n his previous project, which failed because he was hit by a n unanticipated shortage of key technical people and a surprise glitch in getting parts for the hardware platform. He had been reading about a new theory of "constraints," which focused on resource and equipment availability risks and not just critical path issues. But he had learned not to argue with Lakeisha when she had already decided what she was going to do.

Lakeisha met with the contractor and gave him the specification before her procurement office could get the scope out and signed, but they didn't have a problem with t h a t and she didn't have time to go through formal signatures anyway. I t turned out t h a t the contractor, Mag Company, was headquartered in New Delhi, India, but had a local office. Their procurement people had said the specification made sense and that they would get on it right away-they too felt t h a t it could go ahead without a signed contract. They needed the work.

Six weeks later, Lakeisha called the local Mag Company project manager, Abdur Manat, to check on progress. "Everything is going great," he said. "But we have been working on a high-priority project for another company who came in just last week with a heavy job due yesterday, of course. So I have not made a s much progress as I had hoped." Lakeisha responded, "Maybe I ought to have a schedule from you, particularly on the tough pieces of the work you see as potential problems." Abdur replied, "But I

12 Chapter One

still have 3 112 months to do 2 months of work, so I don't see any problems. Did you send me those specs on the hardware? By the way, did you say t h a t the customer wants online training-what's that?"

Lakeisha hesitated but disguised her concern i n a positive expression. "That sounds fme," she responded. "Let me know if you need anything. I'll be back i n touch in another 6 weeks, and then we can talk about integration."

For the next several weeks, Lakeisha spent most of her time trying to put together the spec

ifi

cations for a n online training program for the contractor, a task she hadn't anticipated. She also inquired on the lead times for the new hardware, but the design people were busy on other work.

Six week later, Lakeisha called Abdur to check on progress. "The last project took me longer t h a n I expected," Abdur said. "I've gotten into the graphics work and looked a t your hardware requirements, and I've been working like crazy, but now t h a t I have taken a closer look a t it, I think there's a t least a good 3 months of work on this job, particularly on t h a t online training stuff you sent me--I will have to sub t h a t out."

Lakeisha almost choked on t h a t one, Her stomach told her she was in trouble and she murmured to herself. That would make the total development time for the Schneider project 6 months instead of 4 months. "Three months!" she said, "you have to be kidding. I need the software code in 2 weeks to begin integration. You were supposed to be done by now! I am not paying your last invoice."

Abdur responded, "OK, but you already paid our last invoice--your accounting office has been very efficient. We just got the check, along with a nice holiday greeting." Lakeisha knew this was not her day.

"I am truly sorry," Abdur said, ' b u t this isn't my fault. There's more work here than we could have ever done and more t h a n you estimated i n your schedule. We found t h a t the software code doesn't work in your hardware and we haven't been able to figure out why. And your team people aren't available to talk to. I will finish it a s fast as I can."

I t turns out t h a t Abdur delivered the software in 3 months, but the project took another month after t h a t because of integration problems with the in-house team's code. I n the end, the Schneider program took over 7 months rather than t h e 4-month estimate. Lakeisha concluded t h a t Bill a n d t h e company h a d "sandbagged her" by palming off a bad project t h a t he was not able to handle and t h a t had inherent big risks.

What is missing in this organization is a risk-based business culture. Lakeisha was treating the project i n a careless and superficial way. She acts a s if she is the only agent of project success. Her company has isolated her i n a narrow proj- ect manager role without support systems, incentive, and training. A company

Preparing the Organization 13

t h a t lets a project manager perform t h a t way is a company t h a t does not under- stand its own culture.

Risk: The Organizational Culture Issue

While risk is traditionally seen as a n analytic activity (identifying and assess- ing risks in the project task structure, and applying decision trees, sensitivity analysis, and fine-tuned probabilities) the essence of risk management is the way your organization treats risk and the way you and your team think about the project. The challenge for the organization is teaching and training project leaders and team members to think i n terms of risk and to internalize the risk management process into their daily work. They are the front line of risk man- agement. The assumption behind this approach is t h a t risk management is "something I want my people to do in the normal course of their work," not some- thing I want a specialist to do later in the project a s a separate audit exercise. Risk is a way of visualizing the project and its successful outcomes and seeing potential pitfalls. You can't see risks if you are not looking for them.

So the successful management of risk is usually the product of a successful organization that has instilled into its people the importance of careful planning. Careful planning involves a core competence--the capacity to dimension uncer- tainty and risk, to integrate risk identification and assessment into program and project planning, and to build and sustain a support system for risk manage- ment t h a t provides essential information when it is needed. But how does a n organization build risk into its daily work, and how do executives use their leadership and institutional leverage to further good risk management?

A Culture of Risk Management Competence

The successful risk management organization has five basic competencies:

Active training and development i n risk planning and management

Strong linkage between corporate planning and project planning, particu- larly between business analysis of threats and opportunities, and analysis of project risk

Deep project experience i n its industry

Capacity to document project experience and "learn" a s a n organization

A workforce of strong functional managers who address product quality a s a risk reduction issue

Link Corporate and Project Planning

Strong ties between corporate strategic planning, including market analysis, and project planning ensure t h a t the business "sees" its technological risks early i n its business planning and is able to anticipate and dimension the risks i t will

14 Chapter One

face in designing and implementing projects t h a t carry out its strategies. For instance, a telecommunications firm t h a t performs SWOT (strengths, weak- nesses, opportunities, threats) analysis in its field may uncover a potential threat in unanticipated breakthroughs in telecommunications cable technology. Addressing contingencies a t the corporate level to address these potential break- throughs (opportunities created from analysis of threats) helps the business sup- port its selected projects t h a t involve such new cable systems.

Training and Development in Risk

Training and development programs t h a t address risk identification, assess- ment, and response can help build professional competence in handling risk issues i n real projects. Such training would include a curriculum in:

Building a WBS (work breakdown structure)

Identifying risks in the WBS

Producing a risk matrix

Project Experience

A company t h a t "sticks-to-the-knitting," a s Tom Peters called i t i n Search for Excellence, is in a better position to recognize and offset risk simply because i t s workforce is likely to have a better handle on the technology and process risks inherent in its core business. Whenever a business departs fundamentally from its core competency areas, it stands to experience unanticipated problems, which develop into high-impact and high-severity risks.

Learning Organization

Alearning organization, a s Peter Senge describes it, is a n organization that does not reinvent the wheel each time it plans and implements a project. This means t h a t lessons learned from real project experiences are incorporated in docu- mentation and embedded i n training programs so t h a t project managers learn from past experiences. Communication is open i n such organizations, leading to a process by which project experiences are "handed" down to next generation project teams.

Strong Functional Managers Address Quality

The existence of strong functional management ensures t h a t the basic func- tional competency of the company i n areas such as engineering or system devel- opment is backed up by technology leaders i n t h e field. Key processes like product development a r e documented and product components controlled through with disciplined configuration systems. This means t h a t the risks of

Preparing the Organization 15

product quality failures t h a t result from product component variation are min- imized in methodologies such a s six sigma simply because t h e company can replicate products and prototypes repeatedly for manufacturing and production without variation.

Building the Culture

Organization culture can be defined a s the ')revailing standard for what is accept- able in work systems, work performance, and work setting." A risk management culture can be defined as the revai ailing standard for how risk is handled." An - organization with a strong risk management culture has policies and procedures that require its workforce to go through disciplined risk planning, identification, assessment, and risk response project phasing.

Amature organization does not treat risk management as a separate process, but rather "embeds" the risk process into the whole project planning and con- trol process. Risk is an integral part of the thinking of its key people. In the same way that the quality movement matures to the point that quality assurance and statistical process control processes become institutionalized into the company rubric, risk assessment tools and response mechanisms become an indistin- guishable part of a company mosaic in a mature organization.

Sustaining the culture of risk management is considered a major function of corporate leadership in the risk-planning phase. Although most organizations do not enter the risk-planning phase a s a distinct step in the project planning process, best practice addresses potentially high-risk tasks, assigns probability implicitly t o t h e process, a n d develops optional contingencies t h a t may or may not be documented in a formal risk matrix. This is typically not a myste- rious, mathematical process, but rather a n open, communicative process in which key project stakeholders, team members, and the customer talk about uncertainty and identify key "go or no go" decision points. They often know where t h e key risks a r e in t h e project process because t h e project itself is grounded in addressing a risk t h a t the customer is facing.

Keane's Risk Process

A good example of a strong risk management culture is found a t the Keane Company.

Keane connects and integrates risk with cost and schedule estimating, e.g., identifying project risks and determining actions to minimize the impact on the project and to improve project estimates. I n other words, Keane thinks i n terms of risk as a guide for cost estimating, scheduling, and defining mitigation actions.

The process starts with a n estimating process t h a t takes much of the guess- work out of estimating. Keane has established a set of guidelines, techniques, and practices to pin down estimates and to ensure t h a t customers and stake- holders clearly understand associated risks. Keane emphasizes communication on the relationship between a given project estimate (project schedule and cost

16 Chapter One

estimate) and how the estimate has handled risks and risk mitigation. Their experience is t h a t project success does not depend a s much on completely mit- igating risk a s on communicating risk up front so t h a t stakeholders can make judgments and decisions along with the project team a s things happen.

I n building the culture for risk management, Keane warns its people about the hazards of estimating:

Making sure they know the difference between negotiating and estimating. Estimating is the calculation of schedule and cost given the tasks a t hand; negotiation is working out differences between the estimate and a customer or client schedule and cost.

Understanding the variations in technical skill i n how those variations can impact estimates.

Being objective about your own work.

Adjusting to the lack of a n estimating database.

Being too precise before it is needed, understanding the timing for order-of- magnitude, ballpark estimates, versus the need for more detailed budget and definitive estimates.

Understanding the limitations of work measurement.

Looking a t untracked overtime in building estimates from past work.

Keane advises its people to ask the question "who is a t risk?" before you ask the auestion. "what is a t risk?" This is because the issue of risk is hamed bv those who are affected by it, not by some arbitrary quantitative formula. Different proj- ect stakeholders have different ~ersnectives on risk and estimates. and indeed

A A

their perspectives change during the life of the project. It is best that risk assess- ment be guided by those who will suffer the consequences of risk and who will bear some or all of the cost of risk mitigation.

The role of the project plannerlmanager during this process is to inform the process with parametric data. Keane has found t h a t in many cases the person asking for the estimate is more a t risk t h a n other stakeholders, or the project manager, really understand. This is because the person asking is going to use the estimate to make business critical decisions. For instance, if a client for a new information system is facing the possibility t h a t a new system cannot handle the estimated user load on it projected for peak periods, then t h a t client must make a decision either to limit the user universe or upgrade the system. So the estimate of risk is key to the client decision process and will affect client success.

Keane integrates cost and risk to better understand how risk effects project schedules. By training its people to identify risks from broader business and industry data and to schedule risk planning and management activity into the project baseline schedule, the company delivers a n important message to its people.

Preparing the Organization 17

Addressing Risk with Scenarios

Keane is a good example of a projectized company t h a t uses risk scenarios to - ~ - .

get its project teams to anticipate risks in the planning process. I t encourages the development of issue or scenario statements that pose potential problems- variations from the plan-in a project and generate queries about the issue. For instance, Keane might encourage a project manager developing a new project information system to build the following question into a n early project review session: What challenges does this new system create for the customer and what is the likelihood of these challenges becoming project "show stoppers," what case we do about it now?

Performance Incentives

Any organization building a risk-based culture must provide incentives for inte- grating risk into the project planning and control process. The incentive for handling risk is top management support and resources. Top management sup- port comes when project management identifies and anticipates business risks t h a t save the company time and money. Project managers who manage risks effectively are likely to be more successful in acquiring additional resources because they tend to have backup and contingency plans ready when risks occur.

Taking Risks:The Risk of "Blinders"

One of the major risks i n any project is the tendency of its key project decision makers, especially the project manager, to overestimate what they know and underestimate what they don't know. The risk is t h a t key people will "take risks" but not manage risk. This means t h a t the beginning of good risk man- agement is the capacity to know what the organization and its people can do and what they cannot do.

The field of organizational behavior contributes a tool called the J o h a r i Window t h a t is helpful in analyzing personal tendencies of project managers to take risks rather than manage them (Fig. 1.2).

The Johari Window, named after the Fust names of its inventors, Joseph Luft and Harry Ingham, is one of the most useful models describing the process of human interaction and behavior. A four-paned "window," a s illustrated below, divides personal awareness into four different types, a s represented by its four quadrants-open, hidden, blind, and unknown. The lines dividing the four panes are Like window shades, which can move as a n interaction progresses.

A typical project manager might go through the following thinking process per- sonally to test what he or she knows:

1. The "open" quadrant represents both things t h a t I know about myself and t h a t others know about me. For example, I know my name and so do you, and

18 Chapter One

1 Known to self 1 Not known to self

Known to others

kl I

,r$l >4' . * . c - q

!

Not known to H~ddcn ' Unknown other

3 4

Figure 1.2 The Johari Window,

you know some of my interests. The knowledge t h a t the window represents can include not only factual information, but my feelings, motives, behaviors, wants, needs, and desires. Indeed, any information describing who I am.

The risk here is t h a t what is open to some coworkers may not be open to the customer or a project sponsor. So it is important that a project manager get to know the customer and key sponsors or stakeholders a s people. The focus is customer expectations; if there is an open process on expectations then the chances of managing risk are high.

2. The "blind" quadrant represents things that you know about me but I am unaware of. So, for example, we could be eating a t a restaurant, and I may have unknowingly gotten some food on my face. This information is i n my blind quadrant because you can see it, but I cannot. If you now tell me t h a t I have something on my face, then the window shade moves to the right, enlarging the open quadrant's area.

The risk factor here is that there may be variables that a competitor or cus- tomer knows about the organization t h a t the project manager may not know. For instance, a current supplier to the project may have failed i n delivery of a similar component to a competitor, but the project manager is unaware of the situation.

3. The ''hidden'' quadrant represents things t h a t I know about myself and you do not know. So for example, I have neither told you nor mentioned any- where on my website, what one of my favorite ice cream flavors is. This infor- mation is i n my "hidden" quadrant.

The risk here is t h a t a project team member may not be entirely open in divulging important information about their expertise and experience.

4. The "unknown" quadrant represents things that neither I know about myself, nor you know about me. For example, I may disclose a dream t h a t I had, and

Preparing the Organlzatlon 19

as we both attempt to understand its significance, a new awareness may emerge, known to neither of us before the conversation took place.

The risk here is t h a t there are factors a t work t h a t are unahticipated both by the project manager and the customer. 1

Personal, Project, and Organizational Risk I I

There is something very personal about the issue of risk. In many companies, taking risks is rewarded in principle, but failure in taking risks has its impli- cations despite the company rhetoric. What the company is reallg saying is, "Go ahead and take risks, but take them only if you think you can succeed and pro- duce value for the customer and the company. We will support you with data

l and information. Don't take risks frivolously."

For the business and project professional, risk is first a personh issue because project risk is directly associated with personal risk. If a project manager fails to see and control risk, that project manager faces the prospect of being associated with a failed project, So the way a project team faces risk has implications for each team member personally-and for the team dynamics involved i n a given project.

The way the company protects its employees and officers from risk is key as well. If the company is positioned to absorb the cost of failure then the program or project manager is more likely to take the risk. Thus the propensity to accept risk and manage it successfully is partly a function of organizational support- if my company supports me, I will address risk and make the best decisions I can, but I will want to let my top management know the risks a s I see them so t h a t if the risk is not successfully controlled, it will have been acompany-wide decision, not a personal one.

I n sum, the model is this-the organization must position itsLlf for risk and must empower and enable its business and project people to address and take risks, but there must be a n open, organization-wide process for addressing and absorbing risk. If these conditions don't exist, the project manager is not "incen- tivized" to address risk and will avoid risk, often a t the expense of opportunity.

1 Chapter

The Business Risk ~ramework

I t is important to see risk as a business-wide challenge. ~ t d r all, business enterprise itself is a risk and that is what makes success and payoff satisfying to the business entrepreneur. Project risk is simply a microcosm of the overall business challenge and the fate of every project lies first in thecapacity of the parent company to create conditions for success. As we have s k d , project risk starts with the business itself, its market position and business viability, its part- nerships and vendor relationships, and the economic risks thebusiness itself faces, as well a s customer and client risks.

The author learned a valuable lesson in project risk management working with a leading electronic avionics product company-a product development and manufacturing company t h a t used project management systems a t the division level but had no project management systems in the corporate '8ead-shed."

As the support project management office, my role was to aseure that there was support to the project managers and a clear project management policy and process and that standards were enforced, a s well as serving a s a n assistant proj- ect manager i n several functional areas such as procurement and cost capture. The work was in a regional facility in the East, while corporate was in the West r u n by a single owner and a small corporate staff largely without corporate pro- gram management competence. I

This major producer of avionics equipment had several prbduct develop- ment projects going on in the engineering plant involving mechanical, software, and electrical engineers, supported by a procurement and acquisition a n d accounting staff, a n d a n HR office. The product involved embedded software and regulatory requirements for avionics equipment, and much of the process was testing and retesting prototypes against standards. I n addition to t h e work underway, the regional facility had been awarded (by the owner's deci- sion) a system program from another region t h a t had not been successful with a system upgrade. New staff were hired to staff the project out, with the bless- ing of corporate. At the same time it was authorizing this hiring process a t our

facility, corporate was experiencing downturns in sales a n d marketing efforts and consolidating facilities to reduce costs. But the owner made the decision and - we implemented it.

Later the same year the company had to conduct a major downsizing, cutting many of those same staff hired to r u n the new program, plus other valuable and high performing engineers. The reason it had to downsize was t h a t the corpo- rate investment source was unwilling to forward additional funding until the company cut costs.

We learned t h a t project risk cannot be separated from business risk in gen- eral, and t h a t the effectiveness with which a company identifies broad threats and risks in its business planning will establish the conditions for successful management of project risks.

Project risk is inherently business risk and cannot be disassociated with the overall risks and threats faced by the business a s a whole. Thus project risk man- agement must start a t the perimeter of the business and its relationship to its market environment. As the business identifies its threats, competitors, and risks, it provides the basic wherewithal to identify project risks. There is a n inex- tricable linkage here between the threats a company faces in technology, or labor availability, or product development, and the threats a project team faces in pro- ducing a deliverable designed to implement the business plan and strategy.

The lesson is this: risk is a vertical process, not just horizontal, t h a t is, risk happens u p and down t h e organization a t the same time it happens in project planning management processes over time. Risk is multidimensional and mul- t i s ~ a l e d s ~ n d r o k e t h a t can affect you without warning if you are not i n the inside. And risk does not often come in recognizable clothes, but rather sneaks up on you through the side door. Very often the key determinant risk is out of your control as a program manager, or even a s a general manager, because risk stems from central leadership more than it does through project processes.

The "risk a s part of t h e business framework" concept i s diagrammed in Fig. 2.1.

The challenge, given various project descriptions in a wide variety of fields, is to integrate broad business strategic planning and analysis of threats and risks with project risk management.

Knowing the business you are in helps anticipate risk inherent in the busi- ness. If I a m the project manager of a software development project in a soft- ware firm, I know from past experience and good corporate strategic planning t h a t one of my risks-as a business--is going to be the "integration and debuf process, t h e time a n d effort to make sure a new computer program or code works on the user's hardware platform. I can almost bet t h a t this task will be one of my risks in any such project. I can differentiate that very distinct risk from a general uncertainty about whether there will be any demand for the prod- uct once it is ready. I can "work" the risk in my project, the uncertainty about market demand can also be worked; but I can't control it.

The risk in this software development process can be identified, defined, and ranked-a process we c a l l qualitative risk assessment. If I wanted to quantlfy the

The Business ~ i s k ~ r a r n e w o r k 23

Business Planning !

Figure 2.1 Business framework for riek.

probability t h a t a debug problem will actually occur and create a hajor schedule slippage andlor quality issue, I would do a quantitative assessmknt of probabil- ity. That process might result my estimating that there is an 80percent proba- bility of a debug problem not getting f i e d within my estimated and scheduled ''most likely" task duration of 3 weeks. Then I might identlfy twd alternative* a worst case and a best c a s e b a s e d on various assumptions andplug them into my schedule using the "PERT" tool. I

Thus the reason t h a t project risk starts with the business itdelf is that any project that comes from the business pipeline, or portfolio of projects, is typically aligned with the business competencies and capacity. The busidess leadership has chosen a project because it believes t h e payoff of a projedt is worth the investment i n overcoming the risks inherent in doing the projedt. The product or service to be produced by the project is key to the success of the business in its industry niche (Fig. 2.2). 1

Portfolio Management 1 I

The following is a case in portfolio management by Jerel Hayes. Let's say that a new business, Good Flight Airlines, is a new cjnsumer airline

i n its formative stages. It is being organized to take advantage of a specific gap in the low-cost international travel market. The gap in the availability of low-cost international service in and out of DeKalb-Peachtree Airport (PDK), Atlanta, Georgia, coupled with the demand for passenger travel on selected routes from PDK indicates that a new entrant airline could be-expected to capture a significant por- tion of current air travel. The airline will initially provide scheduled service to des- - - tinations in Mexico. Initial focus cities will be Monterrey and Mexido City. Initially two Canadair CRJ 700 regional jets will be leased from International Lease Finance Corporation (ILFC) or GE Capital Aviation Services. I

reouirements

I Business plan and strategies I

I SWOT Strengths, weaknesses, opporlunities. threats 1 I Use business risk and aggregate planning in selecting projects I

Develop risk based, aligned, and financially viable projects 1

Figure 2 2 Business framework pyramid.

I Project planning

Organization

The airline will hire a n experienced management team, full-time pilots, mechan- ics, flight attendants, and baggage handlers. Reservation agents will be out- sourced. Initial plan includes leasing terminal space a t PDK.

Build in contingencies WBS

Strategic Statement

Walk the talk

Risk based schedule

Good Flight Airlines is to hire innovative people dedicated to delivering the best flying experience to smart travelers, every day. Good Flight will be the first low-cost international regional airline in the United States and will strive for profitability in 2 years. Good Flight will open up new markets a t smaller regional airports in proximity to larger international airports in cities with a high con- centration of people of Hispanic descent.

One- to Five-Year Strategic Objectives

Objective 1: To obtain required DOT and FAAcertifications on or before J u n e 25,2004

Objective 2: To commence revenue service

Objective 3: To raise sufficient seed and bridge capital i n a timely fashion to financially enable these objectives

The Business RiskFramework 25

Objective 4: To commence operations with two Canadair CRJ 900 regional jet aircraft in month 1, four by the end of month 4, and six by t h e e n d of month 6

Objective 5: To add one aircraft per month during year 2 for total of 18 a t year 2 end !

Objective 6: To form a marketing partnership with Airtran ~ i k w a y s

Each of these objectives has inherent business risks associated with it. I

Objective 1. To obtain required DOT and FAAcertifications o n o r before J u n e 25, 2004. I

Risk. That FAA certifications will not be obtained because df factors out of the control of the program manager, change in requirements, FAA delays, and the like. This is a good example of a business-wide risk t h a t is addressed through a general contingency plan involving close and regular contact with FAA offices. But in the end this risk event could be pivotal. I

I Objective 2. To commence revenue service on or before J u n e 25; 2004.

Risk. That revenue service cannot be commenced because of regulatory, equipment, or financial factors.

Objective 3. To raise sufficient seed and bridge capital in a timely fashion to financially enable these objectives.

Risk. That capital cannot be raised for t h e project; funding is critical. Contingency involves a wide sweep of potential financial backing.

I

Objective 4. To commence operations with two Canadair CRJ $00 regional jet aircraft in month 1, four by the end of month 4, and six by the end of month 6.

Risk. That operations will not commence a t the level specified because of the lack of adequate aircraft support.

I

Objective 5. To add one aircraft per month during year 2 for a toial of 18 a t year 2 end.

Risk. That one aircraft per month is not possible because of equipment or financial factors. I

Objective 6. To form a marketing partnership W i t h A i r t r a n ~ i r k a y s . Risk. That the partnership cannot be consummated b e c a u s e b t r a i n chooses

not to enter into a binding relationship with one regional airline, because of the restrictions the partnership would create on other marketing opportunities it is pursuing. I

Program of projects 1 Good Flight Airlines is a new low-cost international consume4 airline in its formative stages. It is being organized to take advantage of a spekific gap in the

26 ChapterTwo

low-cost international travel market. The gap exists in low-cost service out numerous markets in the United States.

The following program of projects outlines our initial objectives:

Program area 1

Start-up program. The start-up program of projects includes all program and project activities focused on commencing revenue service. The keys to success of the start-up program include obtaining the required government approvals, securing financing, hiring experienced management, and marketing--either dealing with channel problems and barriers to entry or solving problems with major advertising and promotion budgets. Targeted market share must be achieved even amidst expected competition. Product quality, safety, services delivered on time, costs controlled, and marketing budgets managed are to be reflected in the business plan (Tables 2.1,2.2, 2.3).

Project 1: To obtain required DOT and FAAcertifications on or before May 11, 2004

Project 2: To get airline certified (air carrier operating certificate)

Project 3: To commence revenue service on or before J u n e 25,2004

TABLE 2.1 Net Present Value (NPV)-Program Area 1 Program Area 1 S t a r t - u p program Candidate Project-Project 3: To commence revenue service on or before J u n e 25, 2004. (Cash Flows i n Thousands of Dollars)

Year Capital cost Sales Net income Discount rate W

* Initial seed capital is to be attracted via a convertible debenture sold by private placement. This round of funding will have premium conversion privileges versus later rounds and bridge capital. The company has plans to proceed to a public offering prior to initiating revenue service. The expected proceeds from the private placement are expected to be $300,000 at seed stage, $3.5 million in bridge fundine. and $10 million in I.P.O. proceeds (pmiected at $6 per share). Management cannot assure that 1 P.0. &ll be availnhle a t rhn rimedesired and at the price iuugllt.

t Sales fieurcs are hnsed ilpnn lnad fncrors of 55 percent irl year 1 and 62 percent in year 2. Second revenues are expected &J exceed $216 million dollars with additional aircraft and expanded

routes.

The Buslness ~ i s d Framwvork 27

TABLE 2.2 Weighted Scoring Model-Program Area 1 Program Area 1-Start-up program

Category Weight Project 1 ~ r o j e d t 2 Project 3

Criteria support objectives 20 3 3 Good rate of return 20 3 3 Good net present value 20 2 2 3 Meets budgetary constraints 20 3 2 3 High probability of completing project 10 3 2 1 3 Good profita

bi

lity potential 10 3 21 3

Project 1: 20(3) + 20(3) + 20(2) + 20(3) + 10(3) + 10(3) = 280 Project 2: 20(3) + 20(2) + 20(2) + 20(2) + 10(2) + 10(2) = 220 Project 3: 20(3) + 20(3) + 20(3) + 20(3) + 10(3) + 10(3) = 300 Based upon the weighted scores, Project 3 is the best. 1 =Unfavorable 2 =Satisfactory 3 =Favorable ~

Program area 2 I Operational program. The operationalprogram includes all p r o d a m and project

activities focused on starting commercial revenue service (Tables 2.4, 2.5, 2.6). I

Project I: To raise sufficient seed and bridge capital in a tirhely fashion to financially operate our first revenue flight I

I

Project 2: To commence operations with two Canadair Cm 700 regional jet aircraft i n month 1, four by t h e end of month 4, a n d six by t h e end of month 6 I Project 3: To hire experienced management team, pilots, flight attendants, a n d baggage handlers; outsource aircraft maintenance, fueling, a n d food service I Project 4: Purchase CMS reservations system; preferred over dutdated Sabre or Apollo legacy system I

Program area 3 ~ ~ s r k e t analysis program. The market analysisprogram includes ail program and

project activities focused on evaluating performance on a month-to-month basis-initiating new services to future destinations, terminating unprofitable routes, and meeting our growth objectives (Tables 2.7, 2.8, 2.9). 1

Project I: Media executions will use local media, which is high& targeted and cost effective on a cost-per-impression basis. I

Project 2: Analyze traffic data to ensure profitability. ~ n a l ~ z e local interna- tional traffic data to realize new markets for operations. I Project 3:Air operations and reservations will be centralized and cost effective.

TABLE 2.3 Risk Matrix-Program Area 1

Task Risk Probability (%) Impact Severity Contingency plan

F i n g US DOT appli- cation

Pass DOT fitness test part 1

Pass DOT fitness test part 2

Pass DOT fitness test part 3

FAA preapplication statement of intent

Lncorrect data on DOT application

Application incomplete or missing required information

Sufficient business and aviation experience

Review of operating and financial plans

Applicants history of compliance record with DOT rules and regulations

FAA preapplication not on file before US DOT reviews application

Markets served, frequency of flights, aircraft type inconsistent with first year revenues and expenses

25 Delay projected commence- ment date

25 Delay projected commence- ment date

25 Delay projected commence- ment date

10 Delay projected commence- ment date

20 Delay certification

30 Delay certification

Showstopper

Showstopper

Showstopper

Very high. Would have to realign management team

Medium

Showstopper This will cause DOT to reject application

&submit application with DOT

Ensure management team experienced

Ensure seed and bridge funding are in progress or completed

Backup funding programs

Should not pose a problem with intensive background check of management staff

Ensure that this application is filed first

Ensure that application is in alignment with financials

Project 4: Ongoing distribution strategy--establish own website with reser- vation, purchase, and payment capability.

Project 5: Promotion strategy--employ public relations firm for both con- sumer and financial purposes.

Project 6: Implement sales forecast and sales strategy.

Project 7: Add one aircraft per month during year 2 for a total of 18 a t year 2 end.

The Business Risk; Framework 29

TABLE 2.4 Net Presentvalue (NPV)-Program Area 2 Program Area 2-Operational Program

(Cash Flows in Thousands of Dollars)

C a n l d a t e Project-Project 2: To commence operations with two Canadau C aircraft in month 1, four by the end of month 4, and six by the end of month 6.

Month Capital cost Sales Net income ~ i s c o u l l t rate PV

1 330* 9200 12 % 2 330 9200 12% 3 495 9200 12% 4 660 9200 12% 5 825 9200 12% 6 990 9200 12%

1 (330) 92001. 92001. ,8929 7920 2 (330) 9200t 92001. ,7972 7071 3 (495) 9200 9200 .7118 6196 4 (660) 9200 9200 ,6355 5427 5 (825) 9200 9200 ,5674 4752 6 (990) 9200 9200 ,5066 4159

N W : 35525

*!\ircruft n.111 he ohmlned on a d r y leuse basis (without fuel) from one of wvera1 nircrari lessors at all uu~roxirnate rokr of $lti5.000 ver ~nonth. Cenrrallv. first and last month's lease Dn\'lllClltS un. . - . . ". required in advance. Lease is usually a 5-year operating lease and most often qua&e; as an expense item to the lessee.

f Sales figures are based upon 7 cents per auailable seat mile (ASM). We will achieve our target of 7 cents or less per available seat mile by a combination of cost saving measures: I

Flight crew utilization of 60 percent above industry average. I Pilots and night attendants will be deployed an average of 85 h per month versus An industry

average of 50-60 h. The company will realize additional savings in the insurance and benefits area by b r t u e of having

fewer crew members. I El~rninatin): meal x e n ~ r e in-flight will save approximately $3.00 per smt, per flight. Upcrating orre aircraft rype will rcsulr in lower rriwling ct~?ts for flight crow.

Analysis of business value I Selection of projects was also based upon the following m a n d a t ~ r ~ l t a s k s required to operate revenue flights: I

I

Prepare a comprehensive economic a n d market specific feasibility study

Develop required operations and maintenance manuals and standards

Recruit, hire, and train executive and operations staff, for both dermanent and temporary positions I Guide airline through proving runs 1 Provide all airline documentation (ticketing, IATA codes, combuter reserva- tion systems, schedule filing, accounting systems, a n d revenue management systems) I Choose facilities and equipment location 1

30 Chapter Two

TABLE 2.5 Weighted Scorlng ModeCPrograrn Area 2 Program area %-Operational program

Category Weight Project 1 Project 2 Project 3 Project 4

Criteria supports objectives 20 3 3 2 3 Good rate of return 20 3 3 3 2 Good net present value 20 2 3 1 2 Meets budgetary constraints 20 3 3 3 2 High probability of 10 3 3 2 2 completing project

Good probability potential 10 3 3 2 2 -- -

Project 1: 20(3) + 20(3) + 20(2) + 20(3) + lO(3) + lO(3) = 280 Project 2: 20(3) + 20(3) + 20(3) + 20(3) + 10(3) + 10(3) = 300 Project 3: 20(2) + 20(3) + 20(1) + 20(3) + 10(2) + 10(2) = 220 Project 4: 20(3) + 20(2) + 20(2) + 20(2) + lO(2) + 10(2) = 220 Based upon the weighted scores, Project 2 is the best. 1 =Unfavorable 2 =Satisfactory 3 =Favorable

TABLE 2.6 Risk Matrix-Program Area 2

Task Risk Probability (%) Impact Severity Contingency plan

Unable to obtain Seek other 25 Delay projected Showstopper Seek other aircraft lenders commencement financing fmancing date options

Aircraft Adding 25 Delay projected Medium Identify similar availability 120 additional fleet expansion aircraft by days lead time aircraft a t manufacturer, for additional desired rate which require planes no cross training

Aircraft Delayed 15 Delay projected Showstopper Ensure aircraft registration first revenue registration

flight filed with governing body ahead of schedule

Aircraft interior Delayed 10 Delay projected Showstopper Should not pose reconfiguration commencement a problem if to company date aircraft are specs leased in

timely fashion Aircraft "proving Range, weight, 20 Delay start High Proving runs run" on initial and similar of service should be routes problems completed ahead

of start of service date

Aircraft painted Delayed 30 Delay start of High Ensure that in company service date livery is applied livery prior to aircraft

delivew

The Business ~ i s k ~ r a m e w o r k 31

TAELE 2.7 Net Presentvalue (NPV)-Program Area 3 Program Area 3--Market Analysis Program

a n d cost effective on a cost-per-impression basis.

. Candidate Project-Project 1: Media executions will utilize local media, which LS highly targeted

(Cash Flows in Thousands of Dollars)

Year Capital cost Sales Net income Discount rAte PV

1 180* 11oooo 12% i 2 240 216000 12% 3 300 240000 12% 4 360 250000 12% 5 430 260000 12%

1 (180) l l O O O O t 109820 1%; ~ 94676 2 (240) 2 l6000f 215760 172004

3 (300) 240000 239700 ,7118 170618 4 (360) 250000 249640 ,6355 ( 158646 5 (420) 260000 259580 ,5674 147286

NPW 743230

'Marketing is targeted locally. The advantage of a local and highly identifiable makket is that media selections can be limited in scope. There is no need for a national media program to launch Good Flight Airlines. The most effective media is expected to be outdoor billboards especially in Spanish. Other media will be local spot TV and highly visible programs such as local news and sports. Specifically Hispanic TV programming and newspapers will also be targeted. Advertising on MARTA trains and buses is also an option. Advertising also includes billboards, TV programming, and newspapers in Mexican cities the airline will service.

Contingency plans !

Program area 1-Start-up program

Candidate project (project 3): To commence revenue service. The risk matrix showed jeopardy and risk to the start-up pro d am because of

the application process to obtain the required U.S. Department of Transportation (DOT) and Federal Aviation Administration (FAA). The FAA preapplication statement of intent, FAAformal application, FAAinspection, and the DOT appli- cation to apply for air carrier certification need to be fded in somb semblance of order. The FAA preapplication statement of intent needs to be oh file with the local Flight District Standards Office prior to submitting the DOT Application for air carrier certification. Required filing fees must accompany all applications. Incomplete and erroneous data will result in applications being rejected from both agencies. This will lengthen the application process. The (normal appli- cation process takes from 6 months to 2 years. The FAA application requires a fitness test of the a i r carrier including financial strength and executive man- a ~ e m e n t experience. Also, the FAA requires inspections during and after the application process including the proving flights. The provinglflights ensure t h a t the carrier can operate safely. The contingency plan for thesd risks are t h a t

32 Chapter Two

TABLE 2.8 Weighted Scoring Model-Program Area 3 Pmgram area &Marketing program

Category Weight Project 1 Project 2 Project 3 Project 4 Project 5 Project 6 Project 7

Criteria 20 3 3 3 2 2 3 3 supports objectives

Good rate 20 3 2 3 2 3 2 2 of return

Good net 20 3 2 2 2 2 2 2 present value

Meets budgetary 20 3 2 3 2 2 2 1 constraints

High probability of 10 3 2 3 2 2 2 1 completing project

Good profitability 10 3 2 3 2 2 3 3 potential

Project 1: 20(3) + 20(3) + 20(3) + 20(3) + 10(3) + lO(3) = 300 Project 2: 20(3) + 20(2) + 20(2) + 20(2) + 10(2) + 10(2) = 220 Project 3: 20(3) + 20(2) + 20(3) + 20(3) + 10(3) + 10(3) = 280 Project 4: 20(2) + 20(2) + 20(2) + ZD(2) + 10(2) + 10(2) = 200 Project 6: 20(2) + 20(3) + 20(2) + 20(2) + 10(2) + lo@) = 220 Project 6: 20(3) + 20(2) + 20(2) + 20(2) + 10(2) + 10(2) = 220 Project 7: 20(3) + 20(2) + 20(2) + 20(1) + lO(1) + 10(3) = 200 Based upon the weighted scores, Project 1 is the best.

applications submitted to the governing agencies need to be checked a n d rechecked for completeness and accuracy.

Program area 2--Operational program

Candidate project (project 2): To commence operations with two Canadair CRJ 700 regional jet aircraft i n month 1, four by the end of month 4, and six by the end of month 6.

Leasing or purchasing aircraft is the most difficult task i n this program. Obtaining the required seed and bridge funding to finance the first two aircraft is vital to the success of this program. To dry lease aircraft (without fuel) most companies require the first and last month's payment. Also, to acquire new air- craft 120 days lead-time is required. Purchasing brand new aircraft will double or triple t h a t timeframe. Aircraft registration, interior reconfiguration, livery application, and proving runs need to be completed prior to entry into revenue service. Various financing options need to be investigated along with a contin- uous search for investors. The tasks required after obtaining aircraft can be scheduled accordingly based upon delivery.

Program area 3-Market analysis program

Candidate project (project 1): Media executions will utilize local media, which is highly targeted and cost effective on a cost-per-impression basis.

The Business RiskFramework 33

TABLE 2.9 Risk ~atrix-prooram Area 3 I Task Risk Probability (%) Impact Severity contingency plan

Identify sources in the market that might cause lower profits

Focus on long- term profitability, not short- term windfalls

Know what level of risk you are comfortable with

Be willing to increase the number of skills in your marketing toolbox

Develop an integrated management approach to your business

Sources that will lower profits include competition, higher airport fees

Government regulations can affect prices

Inability to control market forces and d i i c u l t y in predicting those forces make marketing a n inexact science

Successful marketers are continually updating their abilities by learning new skills

Marketing decisions should not be made independent of other airline business decisions

25 Lower revenues that projected

Lower revenues if long-term not planned regardless of profitability

Revenues could fluctuate up and down initially until a more precise marketing plan is implemented

Competition and "not knowing" could affect passenger bookings

Financial plans can be affected due to the legal nature of marketing

Medium

Medium

Medium

Very high Could impact financial statements

Medium

I Build to-be expected risks into financial plan

1 Marketing strategies t h a t dependon price chasing have not been shown to be

1 consistently profitable

Marketing involves understanding your level of risk tolerance; i t also involves a good

I understanding 1 of your current

financial position

Hire outside marketing firm

1 Marketing 1 ;,","lv"%" contractual agreements

The marketing program has the following risks which are s o h c e s t h a t will lower profits--competition and higher airport fees. Government regulations can affect prices. Marketing strategies t h a t depend on price chasing have not been shown to be consistently profitable. Inability to control market korces and dif- ficulty in predicting them make marketing a n inexact science. Marketing

involves understanding your level of risk tolerance. I t also involves a good understanding of your current financial position. Successful marketers are con- tinually updating their abilities by learning new skills. Hiring outside market- ing firms can help. Marketing decisions should not be made independent of other airline business decisions. Marketing decisions involve contractual agree- ments t h a t have important legal consequences.

Other issues

Southwest Airlines is one of the most successful airlines in aviation history. When Southwest enters a market, it stimulates traffic by significant amounts, competes aggressively with t h e majors, a n d h a s never once claimed it h a s been the object of predation. I t ignores travel agents and avoids flying into slot- controlled airports and other factors t h a t the DOT and the General Accounting Office (GAO) consider vital to accomplishment. The current crop of start-ups has less than a 5 percent probability of becoming another Southwest. New entrant airlines don't need help failing-they do a pretty good job on their own.

New entrants choose their routes and markets poorly. The average duration of the current crop of start-ups on a city pair where they retreat from the market is less t h a n 6 months over the last 5-year period.

New entrant airlines price below their costs. The RASM-CASM (revenue per available seat-mile subtracted by the cost per available seat-mile) shows t h a t new entrants consistently price below their costs. At their current price levels there is little hope that their break-even load factors will improve or t h a t they will become long-term viable airlines.

New entrants often hire executives with demonstrated records of failure. Over 97 percent of the carriers filing for Chapter 10 bankruptcy during the 1990s had senior executives who had been involved in a previous Chapter 10. Over 75 percent had executives who were involved in two bankruptcy filings, and over 50 percent have had executives who have been involved in a t least three bankruptcy filings. 15 percent of the carriers filing for Chapter 10 bank- ruptcy during the 1990s had senior executives who had been involved in a t least four bankruptcy filings. One person has been involved in five airline bankruptcies.

According to the airlines themselves, predatory practices by major airlines are not a factor in new entrant failure. The reasons most cited for bankruptcies are because of operational plans, excessive debt, escalating costs, inadequate traffic, and economic downturns.

Southwest offers the advantage of high-frequency service to its customers. Southwest also h a s one of t h e highest average aircraft utilization ratios in the world. This ratio is a good measure of productivity. I t shows how well the carrier uses scarce and expensive resources. As aircraft utilization goes up,

The Business Risk Framework 35

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3

Flgure 2.3 Average aircraft utilization. 1

unit costs go down. Marginal revenue also increases a s a direct result of improvement in aircraft utilization. See Fig. 2.3. I This frequency allows Southwest to charge low fares consistent with low costs

derived from productive assets. This is why Southwest makes money consis- tently. You would think this model would be imitated by the stalk-ups, but it is not. This is in strong contrast to the start-ups that come into man$ markets with low frequency. Low frequency causes unit marketing and station costs to be high as scarce resources are inefficiently utilized. Southwest has a t least three times the frequency into markets t h a t the start-ups have. It seems t h a t high fre- quency is what consumers want.

I This is the most impressive fact about Southwest-they carkfully manage and control their growth. One of the problems with the fast growth scenario is that management is unsure of costs and their pricing polici6s are not sus- tainable. The former chairman of People's Express blamed the downfall of his airline to the lack of revenue management. ~ One more comparison shows t h a t the start-ups are flying much longer routes t h a n Southwest. The average stage length of current start-ubs is about 33 percent longer, which is t h e reason why their yields are so low. This reflects once again on poor route selection. If new entrants were able to fly shorter segments a t the same price level they now have, they would rhore likely get the revenue they need to succeed. ~

36 Chapter-

The constant changes i n operational plans by the current start-ups, which include changes i n management with new entrant airline executives, whose average corporate life expectancy is less t h a n 2 years. This last figure seems systematic of t h e problems t h a t start -up airlines and businesses have i n common. Poorly managed companies with constant turnover.

Comments on Risk Analysis

Demystifying risk in the portfolio process starts with the proposition t h a t risk is one aspect of the strategic planning process and selection of programs and proj- ects. As this case illustrates, the risk matrix process and separate risk scores a r e inputs to a decision to proceed t h a t includes financial a n d alignment (weighted scoring model) issues t h a t themselves involve risk. Such decisions cannot be reduced to quantified equations and mathematical relationships, or t o so-called scientific calculations of risk probability and expected value. The point is t h a t all front-end business planning is risk planning.

--

Chapter

Doable Tools: ~pplying Tools Strategically

There is a practical way to integrate risk into project planning And control and there are project tools that effectively support risk management.Once risks are identified a s business risks, risk assessment and management a r e integrated into the project planning process. The purpose of this chapter is to illustrate the process. The process described below embeds risk into many of the traditional project planning and control steps, simplified and "demystified" fok practical use.

Organizing a project from scratch a n d integrating risk involves seven basic steps: I 1. Customer requirements

2. Work breakdown structure

3. Task list with estimated durations, linkages, and resources

4. Risk matrix

5. Network diagram

6. Time-based network diagram

7. Gantt chart (schedule)

We will use a building project as our case. The deliverable i n khis case is a n office building and the customer is a real estate property manader.

I Customer Requirements I

Requirements a r e customer-driven and so are risks. A customer!driven project has the best likelihood of success simply because the process foiuses continu- ously on defining and redefining customer needs, requirementsi, and expecta- tions first and then defining the scope of work. 1

The customer requirements document is the project manager's definition of customer requirements, developed from information gleaned from the customer. The customer requirements document is not the same a s the project deliverable document or scope of work. The requirements document addresses the cus- tomer's business setting and needs and expectations for a project solution.

The scope of work or deliverable document is the project firm's plan to address risk in the production of a solution to the customer need. This document is used to anchor the project tasks, but it is aligned with the customer requirements- and constantly realigned during the progress of the project.

I n our case, the customer-a property manager-has a "vision" of success, which must be captured in the customer requirement document. This is not simply a building design and specification, but a description of the customer's vision of how the building will look and perform for its tenants, and produce prof- itability for its owners.

Work Breakdown Structure

First level: the deliverable

The first step in defining the work necessary to produce the deliverable is to complete a work breakdown structure (WBS) from the top (the deliverable) down to the third or fourth level of tasks. You do this in outline form. The top of the WBS is the first level of this organization chart of the work. I t represents t h e final product or service outcome of the project, performing to specification and accepted by the sponsor, client, andlor user. In our case it is the building itself. The '%building" a t the top of t h e WBS implies a finished product accepted by the user or customer.

Second level: summary tasks

The second level across the organization chart of the deliverable includes the five or six basic "chunks" of high-level work t h a t serve as the basic components of the project-the summary tasks which are integrated a t the end of the proj- ect to complete the job. For our building project these chunks of work might include the architectural drawing, building supplies, ventilation systems, water, and electrical systems. (For a software project these chunks might include hard- ware platform, software, interfaces, training program, and financing. For a health management system they might include the clinic population, health information system, medical personnel, space, and equipment.)

I t is important to see summary tasks not only in terms of producing the deliv- erable but also in terms of activities to address risk and contingency needs. This is where risk and contingency planning starts-in identifying and describing risks and what contingencies need to be scheduled.

Third level: subtasks

The third level includes a breakdown of the summary tasks outlined above into two or more subtasks, which would be necessary to complete to produce the

DoaMeTools: ApplyingTools Strategkally 39

second level summary task. For our building project, under thesummary task "architectural drawing," this might include three tasks-get a d architect, pre- pare preliminary blueprint, and check against standard b l u e p i n t template.

Fourth level: work package I The fourth level is another level of detail a t t h e real tasking ldvel-the work package. These are the individual tasks assigned to team members. For instance, breaking down the summary task "get a n architect" to the fourth level, we iden- tify nine work packages-build list of candidate architects, devdlop criteria for selection, screen candidates, interview candidates, conduct reference checks, compile candidate information, distribute candidate information, convene meet- ing, and conduct process of selection. I I t is this last level t h a t is used t o create t h e t a s k list and ide tify risks, t h e actual work assignments t h a t will be necessary to schedule and the risks t h a t the work will not make schedule, cost, and/or quality requiremdnts. These are the "schedulable" tasks and these are the tasks t h a t involve ril; each faces some constraint or resource problem t h a t could create task failure. a The resultant WBS outline (can be shown as a n organization c art) looks like this: I

The building I

Note t h a t risk actions are designed into the task structure fdr tasks which have been identified a s high-risk in the development of a risk mhtrix.

1. Architectural drawings a. Get a n architect

(1) Build list of candidate architects (2) Develop criteria for selection

(a) Risk action: involve the customer i n developing criteria (3) Screen candidates

(b) Risk action: conduct a peer review on candidates to i n project team

(4) Interview candidates, conduct reference checks

offset biases

(c) Risk action: confirm references with second opinion (5) Compile candidate information

I

(d) Risk action: scrub information to assure credibility (6) Distribute candidate information (7) Convene meeting (8) Conduct process of selection

b. Prepare preliminary blueprint c. Check standard blueprint template

2. Building supplies 3. Ventilation system 4. Water system 5. Electrical system

40 Chapter Three

Of course, in this case we have filled out only one summary task to the fourth level; all levels are filled out i n a real project. The concept is t h a t all the proj- ect tasks a t the lowest level of the WBS "roll up" to produce the deliverable.

Task List

The task list includes the fourth level of the building project referenced. This step defines the "work for several purposes:

To serve a s t h e basic definition of the "work" of each task, consistent with the definition of work in MS Project (Work = duration x resource) To serve as the basis for the network diagram--each task will be an arrow in the network diagram

To serve a s the basis for identifying risks-the first opportunity to identify high-risk tasks

Tasks are listed and durations for each estimated by the task manager who will be accountable for t h a t task, along with dependencies (predecessors) and assigned resources (Table 3.1).

Next is a risk matrix, the fundamental risk template that captures the essen- tial risk information in a project (Table 3.2).

Network Diagram

Having identified the basic tasks of this summary task, you now build a net- work diagram of this summary task, which is later integrated with other sum- mary task diagrams to create the whole project network, a s follows.

TABLE 3.1 Task List

Duration (total estimated Predecessor (linkage

ID Task elapsed time) (weeks) or dependencies) Resources

A Build candidate list 6 0 HR specialist plans department

B Define criteria for 3 0 Project manager and selection architectural drawing

task manager C Screen candidates 50 A Architectural drawing

task manager D Interview candidates 30 A, B Pmject manager E Conduct reference checks 25 B HR specialist F Compile information 36 C HR specialist G Distribute information 3 F HR specialist H Conduct selection process 3 E, G Project manager

Doable Tools: Applying Tools Strategically 41

TABLE 3.2 Risk Matrix 1 Risk Impad Probability P x I Contingency

Task defbition (1 to 10) (1 to 10) (1 to 100) 1 plan

Build list of List does not contain 8 8 64 Focus oh industry-leading candidate high-quality, architdct and negotiate architects available architects a contr'act

Develop criteria Criteria do not 8 2 16 Forget criteria for for selection include key selection and go fmd the

factors of success best architect in the field, a s in above

Screen candidates Screening process 5 1 5 Forget screening and does not uncover pursue;best in class weaknesses or architect availability issues

Interview candidates, 10 5 50 ~ o n ' t inLerview any conduct reference more candidates checks

Compile candidate 10 1 10 Don't cohpile candidate information information

Distribute candidate 9 2 18 Don't distribute information information again

Convene meeting 5 10 50 Have meeting, but focus on one target contractor

Conduct process of Sole soukce selection I

Start with a network template. Always start your network diagrdmming with a template or model of the "typical" network, and adjust it to the project you are planning. Atypical template looks like this (Fig. 3.1), with three paths and par- allel activities ending i n one task.

Then tailor your model to your project a s shown i n Fig. 3.2. '

Project paths 1 A, C, F, G , H = 6 + 50 + 35 + 3 + 3 = 97 weeks (critical Ijath)

I

A , D , G , H = 6 + 3 0 + 3 + 3 = 4 2 w e e k s

B, E, H = 3 + 25 + 3 = 31 weeks

Figure 3.1 Generic network diagram. I

Rgure 3.2 Tailored network diagram. (The ''dummy" arrow con- necting Aand B is not a task but a link. This arrow shows that A and B are interdependent with D. D is dependent on both A and B, not just A).

Time-Based Network Diagram

Here you simply place the network diagram on a time-based graph. Draw the length of the arrows representing each task to equate with their actual dura- tions a s aligned with the bottom calendar of 97 days. Note t h a t Fig. 3.3 shows float, or slack, the dotted lines t h a t represent t h e flexibility in what time slot you determine to do the noncritical path tasks, Note also t h a t the path, A, C, F, G, and H, a continuous arrow with no breaks, represents the critical path.

Analysis of early and late starts and slack

I n order to determine what slack you have in the project plan to move tasks t h a t are not on the critical path do a n analysis of early and late starts and early and late finishes, and slack, a s shown i n Table 3.3.

Project paths

A, C, F, G , H = 6 + 50 + 35 + 3 + 3 = 97 weeks (critical path)

B, E, H = 3 + 25 + 3 = 31 weeks

L I 0 97

Weeks

Figure 3.3 Time-based network diagram.

DoableTools: Applying Tools Strategically 43

TABLE 3.3 Earlv and Late Start Analvsis 1

Task

Build candidate list Define criteria for selection Screen candidates Interview candidates Conduct reference checks Compile information Distribute information Conduct selection process

Duration (total estimated Early start

elapsed time) (weeks) (week) Late start

Early finish

Late finish Slack

Gantt Chart I

The final Gantt chart (MS Project) takes the task list information entries and builds a bar chart representing the whole project graphically, based on linkages and durations (Fig. 3.4).

This process, from initial requirement through the Gantt chart, is the core process of project risk management. This is where risks are captured and iden- tified, a s part of the project planning process. 1

Flgure 3.4 Gantt chart. 1

44 Chapter Three

A Risk Story:Tradeoffs i n Risk

Let's say t h a t a n electronics firm is facing a major decision in the use of a n inte- grated printed wiring board (PWB) as part of its avionics instrument product line. The risks i n that decision are inherent to the business itself and to any new product project. The background is instructive to the issue of demystifying risk and cost management.

The firm can gain a $500 price reduction from a new supplier if it chooses to purchase the new PWB t h a t is assembled a s a single unit, which appears to per- form better than the old PWB, which is assembled from parts. But there are risks in the decision because a t the same time t h a t the new PWB can perform more effectively and meets government certification requirements, it has never been installed i n a revenue aircraft and thus is still considered i n the field to be in test. Thus there is some concern t h a t customers will stay with the old PWB simply because of the current safety record of the old PWB in use.

Another complication i n the project is the fact t h a t the firm's manufacturing unit workforce is raising major concerns about the new PWB. The firm's pro- duction assemblers would not have a job should the firm go to the new PWB, simply because assembly and bonding of the card would no longer be necessary. The union representing 20 bonders has threatened legal action if any bonders are terminated because of this decision. Thus there is added risk and uncertainty in a major nonmonetary factor-workforce objection.

This is a good example of a project risk that is intertwined with a company- wide business risk-the probability of disruptive union action triggered by a major product development risk decision. If the project manager is accountable only for the delivery of the product prototype, then the risk of union action is of little interest in making the product decision. The project manager will proceed with the new PWB circuit board because it offers benefits i n performance and cost reduction, and will take his or her chances with the marketingissue because he or she is not responsible for sales or cash flow. However, if the project man- ager is accountable for the whole cycle-product development, manufacturing, and successful marketing-then the PWB decision is liable to go the other way. The manager may not want to endanger the success of a proven product because of possible union a n d workforce disruption t h a t could stop t h e production process.

Thus definition of the project (is it simply producing the prototype or is it get- ting the product manufactured and assembled and marketed?); its organization (who is responsible for what i n t h a t cycle and who do they report to?); and assignmentbf responsibility to the project manager (how is the project manager's performance going to be evaluated?); can all create the conditions for how trade- bffs of risk a i d cost are made.

Further, the business itself is vulnerable because of the precarious position of the manufacturing workforce. Without any alternative way to use the bon- ders, the company has no contingency for moving the bonders into other valu- able roles and functions, thus a key product enhancement opportunity is lost.

Doablelools: Applying Tools Strategically 45

The risk demystifying message is this: no amount ofquantitatiGe analysis and probability estimates will make this project management decision easier to make unless t h e organizational and accountability issues are1 resolved first. Even then the critical decision is subjective. The actual decisions are liable to be made in conversations among the project manager, the program manager, and stakeholders, and the "rank ordering" t h a t results will develop a priority t h a t will be clear to all. ~

Business and project risk 1 Thus project risk management does not start with the project; it!starts with the business itself. As indicated before, i t is quite apparent t h a t niany of the key forces in creating project risk are external, not internal, and a r e uncovered early in business strategic planning and environmental scanning. Many of t h e key factors i n the success or failure of any project are the broad business fac- tors for success and failure and the process of selecting the project in the first place.

The first step i n project risk management is understanding the b m a d approach to the business you are in, the market, the strategy, the viability of the business organization and support system for project management, and t h e outcomes of SWOT analysis-strengths, weaknesses, opportunities, and threats. This is not a mysterious process t h a t can be performed only by select corporate planners and sophisticated modeling. The process simply requires t h a t the busi- ness purpose and strategy be made clear, and t h a t the risks and threats faced by the business are integrated into all project plans and systems.

I Market. Market analysis involves the investigation into potentikl markets and business opportunities. Projects interface directly with marketing in the sense t h a t projects are designed t o produce products and services t h a t are consistent with the marketing plan. Marketing generates accelerated product develop- ment by spurring product concepts and making "deals" with Customers and clients to deliver to their needs.

Projects implement buslness marketing and strategic objectives. Therefore, whether or not the marketing analysis is formal and documented, projects are typically conceived to implement the purpose and direction of t h e business. "Projects are what business does to improve." I t is also possible that businesses take on projects to enter new fields and develop new business opportunities so the interrelationship between business strategy and project selection is actu- ally reciprocal.

I Client setting. The client setting is important because the boundakies of risk and uncertainty are set in the business setting itself. For instance, if a business is an exclusive provider of a particular product or component, the risks are less in any project involving t h a t product or component t h a n they wduld be if there

46 Chapter Three

were no exclusivity. Abusiness t h a t is meeting a n increasing demand for a par- ticular product but facing major competition will try to reduce costs and enhance price while maintaining quality and service. I n t h a t setting, a product devel- opment project t h a t increases performance and cost is liable to be rejected a s "risky" in the context of that business setting.

Strategic statement. Business makes strategic statements, either formally through written statements of strategy for investors, shareholders, and employ- ees, or informally through the actions they take. It is important to recognize that most businesses operate with informal strategies, which are housed in the heads of its leaders, but nevertheless these strategies are clearly driving key business decisions. The t r u t h is t h a t most strategies are not written.

But a project manager dealing with planning decisions, risk, and cost must understand the business stratem-whether it is written down or not-and fit -- the project into t h a t strategy because the risks the manager faces in the proj- ect are directly linked to the assumptions and conditions behind the strategy.

Strategic objectives. Strategic objectives are, in effect, statements of risk con- tingency-indications t h a t the business sees key challenges i n entering the marketplace and has developed a n approach to addressing risk and uncertainty. Thus the whole strategic planning process and sets of statements of objectives is aimed a t uncovering and addressing risk and uncertainty, in a sense, t h a t downstream will provide the risk framework for projects designed to imple- ment them. This way of looking a t risk broadens the perspective of those who plan and direct project initiatives and also provides a useful way to "alert" proj- ect teams a s to the risks and uncertainties that they face.

SWOT analysis: risk identification

Project risk identification, assessment, and management starts not with a proj- ect, but with business planning. Risks are typically identified i n the broad busi- ness strategic planning and thinking t h a t goes on to direct a company toward its potential markets and customers and toward appropriate products and serv- ices. Demystified, risk planning is a business function t h a t identifies barriers and challenges for the company a s it enters a market. The results of broad busi- ness planning provide the wherewithal for individual project risk assessment, which narrows down business risk into project risk. This translation is only pos- sible if the business actually has a planning process-not necessarily a formal documented process but a way of thinking about the future of the company and its markets.

Strengths. The company looks a t its competencies and its core capabilities and identifies its current ~erformance advantape. its differentiators. These stren&hs - . - are a n important signal to the project manager of its history in overcoming risks a n d uncertainties i n earlier improvement a n d product development

DoableTools: ApplyingTools Strategically 47

Weaknesses. The company looks a t its weaknesses in terms of its inability to overcome risk and uncertainty in past initiatives and i d e n t s e s internal improve- ments t h a t it must make to address them.

I Opportunities. Opportunity is the converse of risk; there is no ridk if there is not opportunity on the other side. The reason a company is undertiking a project is to "jump out" i n the market to generate demand for its products and services and to face the possibility t h a t it will fail because of competit'ion or because demand was not there in the first place. Thus a project is a risk contingency, which, if overcome, becomes a n opportunity. I Threats. Threats are risks, simply put. I n other words, threat$, such a s com- petition, technological change, economic crisis, and financial difficulty, all con- stitute the risk factors t h a t the business faces and thus the risk factors t h a t individual projects face a s well.

I Weighted scoring model. We use the weighted scoring model t o select projects based on their relative scores against strategic objectives, b?t what we are really doing in this process is evaluating contingency plans to address risk inherent in various candidate project plans, costs estimates, and cash flow fore- casts. I

Customer and client risks ~ Client risk management issues. I t stands to reason t h a t the clientfaces risks and the business and project objective is to remove or reduce the rikk faced by the client. For instance, if I am developing a n electronic instrument t h a t provides a safety margin in an automobile, I am directly serving the client's interest in reducing risk associated with the automobile. While that is a simple and not very profound finding, it is surprising how easy it is to lose sight of the fact theproj- ect risk management is inherently the process of managing customer risk.

I

Project deliverable impacts. A differentiator for any project t e a m i s the capacity to anticipate impacts of project deliverables in terms of risk and cdst and to offset them. That is what projects do fundamentally.

Partnering in risk management. Partnering i n risk management aims a t spread- ing risk and uncertainty out among the stakeholders so t h a t no one will bear a n inordinate cost should the risk impact success. Thus partnering proves t h a t risk is shared between project company and client, between supplier and cus- tomer.

I Project risk management: processes I

Selecting the right projects. Projects are selected for a company pbrtfolio of proj- ects based on several factors including risk and cost. The review of risk a t the

48 Chapter Three

selection process involves "order of magnitude" thinking about a project, for example, a t the broadest level what are the factors involved in project success and failure and what are the probabilities of their occurring in this project? How can they be offset?

The analysis of risk in project selection involves three basic issues:

Financial risk. What is the rob ability (0, 25, 50, 75, or 100 percent) t h a t the project estimates for financial performance are accurate? What is the risk of cost variance a t the end of the project?

Schedule risk. What is the probability t h a t t h e task duration estimates are incorrect and that the project will experience negative schedule variance?

Quality risk. What is the probability t h a t the quality of the product or serv- ice, either in terms of the product specification itself or customer satisfaction, will not be delivered?

Managing by projects

Project life cycle. Risk is inherently tied to the timing and life cycle of the proj- ect because risk probabilities and impacts change over t h a t life cycle. A minor, low-ranked risk a t the beginning of the initiation stage can become a highly ranked and severe impact risk later in the project life cycle if not attended to. On the other hand, risks too early attended to can create needless effort and cost before their real implications for project success are fully known. Thus the effec- tive project manager finds the appropriate "window" for risk response. That window is the decision point, or range, in the project where the risk contingency must be implemented to avoid schedule and cost impacts.

Initiation. The initiation stage is where the overall project risk is conceived, dimen- sioned, and described to develop a n "order of magnitude" grasp of project risk. The kind of thinking and conversation t h a t ensues in this phase addresses thepoten- tial of a new product or initiative, the prospect of customer and market demand, and the competitive a n d risk issues inherent in a n endeavor still in its initial con- ceptual stage. At this point, the project manager and the planner are dealing with broad, "macro" issues such as described below for a variety of projects:

1. For a software project, whether the software deliverable would be new and untested or simply a n enhancement or recurring production of software already in place on a similar platform. This project-level risk assessment improves on any business-wide strategic, marketing, technology, and envi- ronmental scanning information already available. I n addition, t h e com- pany's capacity to deliver the product to meet customer requirements is also reviewed to ensure t h a t t h e risk of overcommitting the company and its resources is avoided. This where the tradeoffs are made between risk and opportunity, between cost and payoff, inherent in a new project, where its con- ceivers play with a n d qualify their misgivings and excitement about a new

DoableTools: ApplyingTools Strategically 49

effort. I t is here t h a t major business risks are first identified and linked directly to the likely outcomes of a particular project or product development process. Conditions and factors of success are rolled over to their worst case counterparts and potential customer requirements are reviewed to focus in on whether a customer would know what he or she really wants and needs- and act on it in the marketplace. I

2. For a construction project, whether the building product is within the capac- ity and resources of the company, whether t h e customer knows the require- ments, and what kinds of seasonal and other challenges lay ahead. Major risks i n any construction project lie i n t h e economic and social setting of t h e proposed investment and require analysis of a series of indicators around building vacancy rates, prices, and forecasted trends i n demand.

3. For a telecommunications project, the broad issues of customer requirements, infrastructure and support, clarity of specifications, material costs, and other related cost issues are reviewed. The telecommunications risks and threats lie i n the technology itself and the prospect of life cycle performance before being overtaken by another more effective technology. Cash flows are derived from best and worst case scenarios involving alternative telecommunications system life cycles.

4. For a health services project, the initiation phase brings out health technol- ogy and service developments, clarity of customer requirements, nature of the health services clientele, and probabilities of government assistance and reg- ulatory activity. Early views of health services investments are fraught with the risks of technological and regulatory change, thus initiation requires a heavy dose of research and subjective judgment about change, Risk is a func- tion of change since it is dimensioned uncertainty about whether a given effort will change a system or its performance as predicted and planned. The risk is that the intended change will not occur as predicted and further that what- ever change occurs as a result of the project will create negative consequences for the client and the client's system, whatever it is. I

5. Finally, the concept of order of magnitude costing applies heie because it is in this phase that a prospective project cash flow is estimated along with costs. I t is here t h a t the initial level of profitability is estimated a t a moss level, using whatever parametric indicators are available for the given industry. For instance, for a n avionics instrument, the prospect of successfully marketing - - - a new digitized instrument for a business aircraft is based on a n industry working standard t h a t it takes about 18 months to develop a new instrument and 5 years to recover costs. I

Planning. Planning includes the development of project plannihg documents, scope of work, customer requirements document, schedule, budget, risk man- agement plan, product development process, and project monitoring plan. The significance of the planning process for risk management is t h a t risk is best addressed i n the planning process simply because it allows time for assessment

and contingency plans to be integrated into the baseline project schedule and budget.

Execution. Execution is the implementation phase once a baseline schedule is completed. Execution begins when work is authorized to begin and the project schedule is underway.

Control. Control is the project-monitoring phase during which performance indi- cators are monitored and the project is controlled by corrective action. The sig- nificance of control for the risk management process is t h a t risk is built into earned value determinations. Earned value indicates variances from schedule and cost estimates, indications that risk may be a t work in a project. Investigation of root causes involves first focusing on risks and risk events t h a t were antici- pated i n the project planning process.

Closeout. Closeout is the termination phase in which a project is closed along with financial books.

Scope. The scope of work describes the work to be performed to produce the deliverable. Scope addresses customer requirements and deliverables, approach to producing the deliverables, and estimated schedule and cost estimates.

Time. Scheduling determines the project life cycle and delivery date for the deliverables. Time is a n outcome of the planning process, not a n input (despite the tendency of customers to dictate delivery dates without understanding the project process).

Cost. Cost is capture bottom up and top down. Bottom up estimates fixed a n d labor costs from individual tasks a t the work package or level of effort, and rolled up. Top down applies parametric indicators, such a s plan your building around $40/ft2 as the industry standard for this kind of building.

Rlsk planning. Project planning and risk planning are related in the sense t h a t project planning documents and deliverables incorporate risk and risk contin- gencies. But risk planning has taken on another slightly different meaning i n the new PMI PMBOK document. Risk planning is seen by PMI aspreparing the organization a n d its support systems for risk management. This emphasis gives special attention to the need to build the cultural underpinnings and support systems for risk management before top management can expect its project teams to address risk.

Risk planning involves the following outcomes:

1. Development of a risk management policy andprocedure system. This involves the "institutionalization" of risk management into the policies, manuals, and procedures of the company. While stated policy does not always influence actual work setting behavior, it is important for the company to go public with risk as a priority management ethic.

DoableTools: Applying Tools Strategically 51

2. 'Walk the talk"programs-urientation of top management tothe integration of risk into day-to-day work a n d communications. This involves assuring that top managers actually address risk in their project review meetings, cus- tomer communications, and performance reviews. I

3. Daining a n d developmentprograms for risk. The company d u s t have a risk management training program backed up by manuals and web-based train- - - - . . ing in risk assessment and response. I

4. Network a n d web-based information system development forpioject risk infor- mation management. Since a company will want to address risk consistently throughout its project portfolio, a network should be earmarked for support to project managers, providing risk templates, forms, and data formats.

5. Project management office support. A separate staff servds project man- agers with standard and best practice, project review formats, monitoring data and analysis, and risk management services. I

6 . Standard work breakdown structures. The more the company can move toward a standard work breakdown structure, the easier it is to inculcate risk management practice into the scheduling and execution processes. Standard WBS formats will provide for risk contingencies and risk-based scheduling using MS Project PERT analysis or other software tools. I

Quality. Quality is addressed i n the project planning system fir& by assuring a firm grasp of customer requirements. This involves making sure the customer's needs and expectations are documented in the requirements dodument since in the end the customer actually determines the quality of the project outcome.

Second, quality is addressed in the application of quality assurance and qual- ity control processes, I S 0 standards, and process improvement initiatives. Quality can be defined as the response to risk in the sense that quality issues stem from high-risk projects and project tasks. Therefore, it is important to address quality through the risk management process to produce a project system that protects against quality defects, variances, and high appraisal and inspection costs.

Human resources. The human resources element of projecd management involves the development of proficient workers and h i g h - p e r f ~ ~ m a n c e teams, focusing on strong support of the human resources staff. This means t h a t employees who are comfortable with their work settings and employee support systems are more likely to seriously address good planning practice and protect the company from risk. As employees become more disengaged from the human resources function, they are liable to be increasingly alienated from the company and therefore be less interested in protecting it.

I Communications. Risk is communicated in the project planning Arocess through regular exchanges on risk in project reviews and task assignments. But the essence of risk communication is the ability to keep all stakeholders informed on risks so that they are not surprised by shifts to contingency plans, which push out schedules and increase costs and budgets. i

52 Chapter Three

Procurement. In any contracting system the contract is designed and managed with the purpose of minimizing risk and maximizing risk-sharing arrange- ments. This means t h a t fixed price contracts are favored over cost reimbursable contracts in most cases because fixed prices shift the risk to the contractor.

Integration. Integration involves the mixing and matching of project compo- nents and parts to create the whole. Technically, integration is a systems func- tion, but in terms of risk management the integration function means t h a t risk is embedded in the process. For instance, in producing a product the company incorporates technical checks and balances in the system to offset the likelihood t h a t product quality has been compromised.

Triple constraints

I n a way, t h e so-called triple constraints of quality, schedule, and cost are not really constraints, they are outcomes of constraints. Constraints are resources, technology, risk, and project processes. People make i t possible to produce proj- ect deliverables by managing these constraints to optimize schedule and costs while meeting quality and performance requirements.

Project Manager's Roles and Responsibilities in Risk Management

Leadership. The leadership function in risk management includes all the core leadership skills, e.g., vision, team development, giving purpose and direction, along with a strong sensitivity t o risk. Leaders ask questions, but do not nec- essarily provide answers. The role of the leader i n a risk management process is to ask the right questions, pose the right issues, and inspire the project team to come up with solutions and opportunities. Risk provides the leader with a con- ceptual framework for posing project issues in terms t h a t can be incorporated into risk planning, matrices, and assessments.

Motivation. The classic role of motivating is actually a process of integrating indi- vidual leadership with a project work setting in which motivation is self gen- erated. I n other words organizational leadership cannot be very effective i n motivating a project team unless the leader has designed the work itself to be challenging to the team. I t is the work t h a t motivates teams, not leaders alone. So it is the work t h a t needs to be designed to be challenging. And since oppor- tunity and challenge come from risking yourself together to overcome a risk, project teams typically are motivated by risk t h a t is manageable.

Keeping risk manageable. Leaders keep risk manageable by framing a project t h a t is feasible but t h a t stretches the project team enough to represent a mean- ingful barrier. Overcoming t h a t barrier then becomes the source of recognition and achievement and more motivation to go on to other challenges.

Doable Tools: Applying Tools Strategically 53

Facilitatorhlanager. The facilitating gift is the capacity to guidd a team to high performance by orchestrating the dialogue without dominating it. This means t h a t facilitators must stay engaged with the team and keep tHe team moving by raising issues and challenges, but keep disengaged from thk solutions and outcomes a s much as possible. Solutions and outcomes are to be addressed by t h e customer in the context of customer requirements; the facilitator is inter- ested i n spurring the team to a high level of achievement, but not necessarily interested in guiding the resultant solution. I

Work Breakdown Structure, Again!

Description, purpose, and use In decomposing a project. The reaAon a WBS is a necessary part of risk management is t h a t the WBS defines the risks in a proj- ect a t a level t h a t the risk can be identified, described, and assdssed. Thus you can look a t the WBS a s the structural support for risk management in the sense t h a t it "rolls out" the work so t h a t everyone can see the work in small enough chunks to ascertain the risks inherent i n completing it. If a WBS;misses a major chunk of work, it may also miss a major chunk of risk, so it is important for the WBS to define all the work.

I I

Activity definition. Activities are project tasks that create outcomes, consume resources, and must be scheduled. Activities are differentiated from milestones, which are points in time, which mark significant endpoints or intermediate products of activities. Defining the activity-not just identifying it in a one- liner-thus is a critical step in risk management. The more detailed the activ- ity the more clear the risks inherent i n the work will be.

I Resource planning. Resources are constraints and t h u s are the generators of risk. According to the theory of constraints, resources are the major sources of project failure or success. Using the "article chain" concept, the project manager is advised to trim estimates down to "bare bones" so that buffer time can be doled out when necessary, and to concentrate only on the key constraints i n the proj- ect. Inherent i n the theory is a major criticism of micromanaging all tasks as if they were all of the same importance. Isolating the few high-risktasks gives the project manager focus. I

I Cost estimating. Cost estimating is a bottom-up and top-downprocess, but it begins with the WBS and builds labor and fixed costs a s part of the scheduling process. At the heart of the cost estimating process is t h e definition of t h e work, with work equaling resources multiplied by time. I n other words, a task might be defined as a "five person week job," t h a t is, given the nature of the defined work it is estimated t h a t i t will take five people 1 week to do th$ task-a 200 h job-if they are all working full time. If less than five people are working on the task, or some are not full time, it will take longer, thus the duration and resource levels are traded off with each other. The work itself and its aefinition stay

54 Chapter Three

constant unless changed by a new estimate of the work. Costing out a job t h a t has been defined to this detail is relatively easy since it includes the cost of full time staff working for 40 h.

How does risk figure into cost estimating? Risk is a driver of cost since its impact is to extend the work beyond the expected duration to a more pessimistic duration based on the potential occurrence of a risk and the time and cost of implementing a contingency action. Thus cost and risk are associated with each other; various levels of risk create different costs.

Budgeting. Budgeting is t h e allocation of available resources to projects based on priorities. While cost estimates a r e useful inputs t o budgeting, the company decides where to put its money based on itsportfolio analysis, using cost estimates.

Progress reporting. Progress reporting is accomplished through earned value, e.g., schedule and cost variance, as well a s by risk assessment.

Coding of work breakdown structure (WBS) elements. The estimation of cost from the WBS includes the cost of all tasks and risk contingencies built up from the bottom of the WBS.

Relationship to cost accounting. Risk impacts on project cost are captured i n the budget and since the WBS is coded to t h e task level, the cost of all risk contin- gencies should be documented in the cost accounting system.

Activity-based costing. The purpose of activity-based costing is to measure costs and therefore profitability based on the cost of time. This leads to accuracy in cost tracking as well a s measuring resource capacity excesses and constraints. I t also helps decide what costs contribute to profitability. The costs of risk mit- igation are attributed to appropriate project tasks and subtract from project mar- gins.

Relationship to responsibility matrix and organizational structure. The responsi- bility for risk is shared in a matrix between functional and project managers. The responsibility for process and technical risk is with the functional depart- ment and t h a t for deliverable schedule and cost risk is with the project man- ager. The organizational structure should be clear on roles and responsibilities so t h a t risk accountability can be assured.

Estimating

Estimating is the process of estimating schedules and costs based on a pro- posed deliverable specification. There are different types of estimates:

Order of magnitude/conceptual. Order of magnitude is '%allpark" estimat- ing, getting a handle on the general cost based on all task work and expected risk mitigation costs. This estimate is general and helps to scale the project

DoableTools: Applying Tools strategically 55

initially a s complex and big, mid-sized, or small-in the condext of the com- pany's capacity and past work. I Budget/parametric. Parametric costing depends on the availdbility of param- eters for scaling costs, e.g., t h e costlsquare foot of building a health clinic building.

Definitive/detailed. Definitive is a detailed costing based on hdividual work packages and levels of effort a t the individual and team level. This is the final budget against which cost variance is measured, including overhead and gen- eral and administrative costs. I Project type/irzdustry. The estimating process differs dependikg on the indus- try. Estimating a construction project is typically a t the definitive and detailed level while estimating a n information technology project is often a t the budget and parametric level because of uncertainties and risks. I

Time

Activity duration. Activity duration estimates are based on inforAation from the assigned team member, parametric data, and can be in three dimensions- expected, optimistic, and pessimistic-for PERT analysis. ~

I

Expert judgment. Expert judgment is used in providing order of hagnitude and parametric budget estimates.

Analogy. If there is a n analogous project to the target project, then analogous cost data are used, as in parametric costing. 1

I

Productivity rate. Productivity rates are useful i n estimating t h e impacts of risks on costs and schedule because of the rate a t which deliverable compo- nents and pieces of work can be produced. For instance, if a giv'en report typi- cally takes 1 week to design, prepare, and publish, then two reports can be done in 2 weeks or less. I Contingency tlme. Contingency plans take time and fmancing, soestimating the cost and schedule impact of contingencies should be part of the i-egular project planning and scheduling process. 1

Risk-based scheduling ~ Calculating a risk-based schedule: PERT analysis. We deal w i t h M S Project in more detail in Chapter 7, but here is a summary of risk-based scheduling.

MS Project h a s the capability of calculating a risk-based schedule and task durations using the PERT tool. This is based on estimated expected, optimistic, and pessimistic task durations.

The purpose is to use risk assessment and analysis informatibn to calculate a risk-based project schedule i n Microsoft Project. The risk-based schedule is

56 Chapter Three

calculated from your original project schedule, but uses your weighted esti- mates of three possible task durations (expected, pessimistic, and optimistic) to come up with a new project schedule. The new schedule is calculated for indi- vidual tasks and "rolled up" to the whole project.

The risk-based schedule is usually a better schedule estimate t h a n your orig- inal one because it reflects your best estimates of what could go wrong (risk) and what could go right (controlling risk).

Procedure

1. Prepare your regular project schedule using Microsoft Project using your best estimates of task durations and linkages. This project schedule does not reflect any risk assessment.

2. Prepare a risk matrix using the work breakdown structure (WBS) and the project schedule and rank all project tasks in terms of risk, designating them "high, medium, or low." a. A high-risk ranking shows a high probability (>50 percent) of the risk

actually occurring, and t h a t the risk will have a relatively severe i m p a d on schedule, cost, and/or quality.

b. A medium-risk ranking implies less probability (<50 percent) of happen- ing and less schedule impact

c. Alow-risk ranking implies very low probability ( 4 0 percent) that the task will occur and low impact.

3. Select the five highest-risk tasks (or more if you have more tasks t h a t pres- ent risks t h a t you want to reflect in your risk-based schedule).

4. Calculate the risk-based schedule: Your objective now is to calculate a risk- based schedule by taking each of the five highest-risk tasks and calculating a risk-based duration for each. Using Microsoft Project, here are the steps: a. Pull the PERT Analysis Toolbar up from 'View." b . Highlight one of the high-risk tasks on the Gantt chart. c. Go to the PERT Entry Form and enter your duration estimates for t h a t

task for three scenarios+xpected (use the duration in your original sched- ule), pessimistic (worst case impact if risk occurs), and optimistic (best case, all risk controlled with no impacts).

d. Then use the PERT Weight button to set the weights for each scenario (weights reflect the probability t h a t a given risk and impact will happen). Microsoft Project uses a total weight scale of six points; your job is to divide t h e six points up among three scenarios--expected, pessimistic, and optimistic. Note t h a t the Microsoft Project "default" is 4 for expected (based on the high probability t h a t the actual duration will fall some- where between t h e two extremes) and 1 each for pessimistic and opti- mistic. But you may want to change those weights based on your estimate of t h e relative probability t h a t a given scenario is going to happen.

e . Once you have entered weights, go to the PERT Calculation button and calculate the risk-based duration for t h a t task, based on your inputs.

DoableTools: Applying Tools Strategically 57

f. Now click the PERT Entry Sheet and you will see the nelwly calculated, risk-based duration for the task compared to t h e three scehario durations (expected, pessimistic, and optimistic).

g. Now repeat this procedure for the remaining high-risk taiks. h. The resulting "rolled up" schedule is now a risk-based sche'dule, reflecting

a new project duration. I

Dependencies 1

Risk and activity sequencing. I t is important t h a t the project schedule reflect the correct linkages. There is considerable risk inherent i n these linkages since i n a complex project these linkages change. Dependencies identified a t the beginning of the project sometimes disappear as team members consult and collaborate before the tasks begin. And, conversely, some tasks not initially linked develop dependencies because of unanticipated developments in the project. I

For instance, one design and one integration task might be initially linked because of the obvious need to design before a system is integrdted. But a s the team collaborates, it is probable t h a t integration starts beforeldesign is com- pleted and may go on in parallel. The risk is that because of Murphy's law (work expands according to the amount of time available to do it) the original task durations may be too long but are never changed. On the other hand, two proj- ect tasks, such as design and reporting progress, are not originally linked but later become interdependent because of a n unanticipated request for a special report to a stakeholder on design review results. I

cost I

Direct and indirect costs. Direct costs are costs of labor and other costs applied to the project by those who add value to the deliverable. Indirect costs are sup- port costs--overhead and general and administrative costs. ThB risk inherent in costing is t h a t the overhead and G&A costs are underestimatbd and the cus- tomer is surprised with invoices t h a t exceed the expected costs.;

Fixed and variable costs. Simply put, fixed costs are costs of capital, equipment, and space, and are entered a s fixed costs into MS Project in building the proj- ect cost estimate. Variable costs are direct costs of labor, those 'that vary over time. The risk in fixed cost is the probability of misestimating k ixed costs and the possibility t h a t while fixed costs can be prorated over the life cycle of the project, cash flow is drained when the costs are actually incurred.

Basis for estimates I I

Internal accounting records. There are inherent risks in using internal account- ing records a s the basis for estimates. Each project is different and unless the project was exactly like the one under review, there is a high probdbility t h a t past

records will not be a good guidepost. On the other hand, internal accounting records are useful on the actual cost of labor and capital equipment.

Project team knowledge. There is risk i n assuming project team knowledge about costs t h a t may not be relevant to the new project. The best approach is to seek team insights, but to temper them with the perspective of a project manager.

Estimating manuals and databases. For deliverable components, estimating man- uals can be useful a s parametric guides, but again the risk is t h a t manuals will not have accurate data.

Construction. I n the construction industry, there are many sources of risk and cost data, from such organizations a s The National Association of Home Builders. Parametric data are available on construction unit costs ( $ / s q ft) and supply and contractor risks and contract types.

Software development. Software development creates a unique set of risks and costs associated with this business. Since software development involves cre- ative work in design and coding and faces major challenges in integration and platform options, the business does not have reliable cost and risk data and expe- riences major project delays.

The Software Engineering Institute is the major source of practical method- ologies and risk and cost data. SEI defines a successful risk management prac- tice a s "one in which risks are continuously identified and analyzed for relative importance. Risks are mitigated, tracked, and controlled to effectively use pro- gram resources. Problems are prevented before they occur and personnel con- sciously focus on what could affect product quality and schedules."

The lack of focus on risk in software development has created major delays and cost overruns because of the lack of top management support, failure to gain user commitment, misunderstanding requirements, lack of adequate user involvement, failure to manage end-user expectations, changing scope, lack of technical skills, new technology, and staffing inadequacies and conflict.

Typical risk and cost issues are grounded in technology issues, e.g., two com- puters having different architectures t h a t interpret a designated protocol dif- ferently.

Learning curves. As a n organization gains competence in a given project arena, project life cycles are shortened. Performance time and experience can be rep- Eesented by a learning curve relating the direct labor required to experience gained in past work.

Parametric estimating. Parametric estimating, t h a t is estimating based on unit measures, such a s $/sq ft, creates risk in t h e sense t h a t these a r e median

Doable Tools: Applying Tools dtrateglcally 59

measures from a wide variety of similar projects and are not relikble for unique projects. 1

Issues

Poorly defined project scope. Since there is no industry standgrd on what i s involved in a scope of work, the quality of t h e scope is typically measured against the number of changes or scope creep the project experiences. Risks and costlschedule impacts are widespread in most project areas, particularly i n software development and system developments. PMBOK States t h a t the scope of work should include all t h e work necessary to complete the product to meet specifications, e.g., t h e WBS is a core element i n t h e PMBOK frame- work. To t h e extent t h a t t h e WBS covers all the work and by rdference all the components of the product, a n d risks a n d costs a r e estimated from t h a t WBS, the scope of work is the major anchor and stability factor in project planning and control. The potential for scope creep is a major generic rikk i n any proj- ect, and the best contingency is to assure t h a t a WBS is prepared t h a t i s thor- ough from the perspective of the project team, stakeholders, top management, and the customer. 1

Major omissions in taskdactivities. If tasks are left out of the WBS And scope, then adding them requires a change order and rescheduling and rebddgeting of the project. Project managers cannot accept major additions or changes based on new work unless the project team is clearly a t fault in missing a n important piece of work. I

Optimistic timelcost estimates. The natural tendency is to be optimistic i n esti- mating schedule durations and costs, thus the risk is t h a t the schedule is not risk-based. To offset that tendency, the project manager should use the outputs of t h e risk analysis process and risk matrix content to estimate a "pessimistic" duration option in the MS Project PERT analysis and then to cdlculate a risk- based schedule on t h a t basis. The difference between the expected and pes- simistic durations is a 'buffer" i n the sense t h a t the term is used i n the theory of constraints t h a t should be controlled by the project manager. 1

Project Financial Perspectives

There is risk i n the misuse or inaccuracy of financial analysis tdols, and more importantly of the inputs or assumptions used in the application of those tools.

Concepts associated with interest rate; time value of money; s3mple interest; compound interest; discount rate; minimum acceptable rate of return (MARR); present, annual, and future worth (PW); and various rate of return and tax methods should be peer reviewed by a n internal or external accounting con- sultant before being applied to projects. The risk is t h a t rules of thumb and industry practice may be ignored. 1

60 Chapter Three

Evaluation tools and techniques. Projects can be evaluated by several tools, including break-even analysis, payback period, replacement analysis, economic life, and feasibility studies. But the real issue i n project evaluation is the longer term viability and value of the deliverable in meeting business and financial objectives, and the risk is that short-term, internal corrective actions during proj- ect delivery will be short sighted and focused on narrow schedule a n d cost issues, and not on long-term success.

Project budgeting

Budget inputs. Budget inputs include the risk management plan a s well a s the traditional project tools such a s WBS and schedule. The risk i n budgeting is the same as the risk experienced i n scheduling-the tendency to be too optimistic. One way to address this issue is to perform a PERT analysis on a task using dollars instead of time units and to calculate a risk-based budget using that tool.

Preparation approaches

Top-down (strategic, tactical). Risk and cost are approached in a similar way, first from the top-down approach to develop "chunks" of risk and cost associated with various large packages of work, then to proceed to bottom up to refine the estimates.

Bottom-up (WBS-based). "Bottom-up" means taking the lowest level of the WBS (at least four levels down), estimating cost and risk, then rolling the budget up and preparing a risk matrix to rank risks with direct impacts on cost.

Iterative (combination of both). The iterative approach simply assumes t h a t both approaches are helpful in developing a project budget and risk plan.

Estimates plus contingency

Refine estimates. Estimates are refined a t the definitive level (from the budget- ary level) by relating costs to specific measures and task durations, and to arrive a t a n estimate t h a t can be used to propose a budget to a sponsor or investor.

Risk considerations. Risk is integrated into the refining of estimates by calcu- lating a risk-based budget and schedule and comparing it to the original esti- mates, and making sure t h a t all contingency plans have been estimated and integrated into the baseline schedule.

Issues

How much contingency. Contingency can be seen i n the framework of critical chain theory so t h a t the costs of the pessimistic option, both time and money,

DoableTools: Applying Tools Strategically 61

are earmarked a s contingency funds and tapped by the projeht manager for allocation according to need. 1

Who controls contingency. The project manager controls contingency to avoid a multitude of contingencies being built into every task estimate, thus subopti- mizing the project. 1

Management reserve ! Proiect financing. There is substantial risk in the financing of a project, and more importantly in the financing of the parent company. Issues such as internal resources, commercial credit, equity issues, venture capital, government grantslsubsidies, and capital rationing govern the viability of thecompany itself

l and its capacity t o finance a project up front. To share risk, many companies are It going to earmarked venture funds for new product developmen so that spon-

sors' funds are bounded by a project to avoid cross subsidy. I

Insurable risk. Insurable risk is risk t h a t is determined to be idsurable on the open market and which is not self funded. Insurance is a vehiclle to share risk and to outsource risk t h a t has a high probability and impact severity.

I

Identification of project risks. Project risks will surface in a number of ways. I

Internal. Internal risk is risk t h a t is organizational and systeh-related, and t h a t poses challenges to the company itself to support successfid project man- agement. I

Technical. Technical and technology risk can be managed u s d reliability and testing methods, which must be built into the project itself. Tt'chnical risk is handled by embedding testing in the design and development of the product.

Nontechnical. Nontechnical risks are personnel, organizationh, and process risks which are faced by the project manager. Some would say nontechnical risks are the most endemic since they stem from individual andworkforce per- formance.

External. External risk is risk generated by the environment ahd the market, and can be anticipated through environmental scanning and strakegic planning.

Legal. Legal risk is the probability t h a t a project will generake legal action focused on the deliverable or proprietary information.

Risk event. A risk event is the triggering action, milestone, or task output that generates the risk and evidences that a n anticipated risld is occurring.

Predictable. Predictable uncertainty becomes risk because it! can be antici- pated, dimensioned, and mitigated.

Unpredictable. Unpredictable risk is uncertainty t h a t cannot or managed.

be anticipated

Probability of occurrence. The probability of occurrence is estimated by the proj- ect manager, or rank ordered in terms of ranges of probability, such a s 25, 50, and 75 percent.

Potential consequences. Consequences of risk are captured in the risk matrix not only in terms of impacts on schedule, cost, and quality, but also in terms of external consequences, such a s change in company competency or market share.

Impact assessment techniques. Impacts are estimated by tools, which develop scenarios of future impacts through use of expert judgment and sometimes sim- ulations.

Sensitivity anafysls. This analysis looks a t how project outcome is sensitive to various changes in schedule, cost, and quality, usually by trial and error.

Expected value. Expected value is the value of one path of decisions versus another, and is calculated by estimating the probabilities of various decisions and the profit margins outcomes of those decisions, then multiplying them and comparing various decision paths.

Decision tree. A decision tree is a tree diagram t h a t outlines the various alter- native paths a t key points when the project manager must decide between con- trasting decisions.

More Background

I t is traditional to address project management in terms of time, schedule, a n d cost, and to focus on the Gantt chart as the key planning and control tool. Yet this emphasis on managing and sequencing tasks does not do justice to project management as a decision process. Project decisions are made (or not made) reg- ularly on the basis of cost, risk, procurement and contracting, and other issues t h a t can have major impacts on project success but which are not addressed i n the traditional Gantt chart. The critical success factor for a project can often be the timing and nature of decisions made on the basis of risk and uncertainty and cost. These decision points in a project can figure importantly in the suc- cess of the project because they determine how risks and costs are handled and they narrow options.

Further, the timing of key decisions sets the conditions for what tasks a r e critical and what tasks become redundant as a project unfolds. But traditional project tools do not serve project managers well i n this area, especially in flag- ging key decisions i n terms of the project schedule and showing impacts a s they are made. The risk process as described i n the PMI PMBOK stresses risk plan- ning, identification, assessment, and response. But this model does not help

project managers anticipate key decisions and assess the costs dnd benefits (or expected value) of making one decision or another when key tradeoffs have to be made. I

Project TOOIS i The combination of three analytic tools helps to illustrate the point: (1) decision tree analysis, (2) expected value, and (3) the traditional Gantt chart.

Decision tree theory 1 The decision tree helps to identify key decisions and evaluate exbected value of key decisions based on the analysis of risk and costs associated with each branch.

There are two components to the decision tree-a decision and B risk or uncer- tainty. The decision is shown a s a box with one arrow for each option available i n the decision. The risk or uncertainty is represented by a circle and a n arrow for each state of risk. The arrows for risk must contain the outcome in dollars if t h a t state occurs, along with the probability of it occurring.

Note t h a t the sum of all probabilities around the risk circle J u s t add to 1.0. Therefore, the states must represent all possible conditions. Tliese conditions are strung together to give a picture of the decision to be made. With the addi- tion of a method for making a decision using the decision tree called the expected value, we can make our decision and have a method for presenting the results in a consistent manner. I

An illustration of a decision tree analysis of risk I Pat is a project manager with a local contractor who has submidted a proposal to install a telephone trunk line between Macon central station land Kathlyne, GA. P a t has just received a n option on 1000 acres of right-or-why property a t $100/acre. If P a t purchases the option and the project is not selected, there is a 60 percent chance t h a t she can sell the property a t what it was brought for; otherwise she believes t h a t there is a 60 percent chance she can sell i t a t $gotacre. Pat has another option to wait until the project is awarded to purchase t h e property. However, there is a 20 percent chance t h a t t h e property will increase to $120/acre. P a t feels t h a t there is a 60 percent chancd t h a t the com- pany will be awarded t h e project. The original proposal, based on $1001acre, netted the company a profit of $100,000.

I n building the decision tree for this problem we need to establish what deci- sions need to be made. I n this case, t h e decision is to either '%up now" or 'buy later." Then we need to establish what the uncertainties a r e in the problem. I n this problem, there are two uncertainties; the first is the same no matter which option we choose. That is, whether we win the contract. There is a 60 percent chance t h a t we will win the contract. Therefore, there is a 40 percent chance we will not. The second uncertainty is different depending on thb option being

Price to purchase land 96,000

Win contract? 57,600

Decision 58,400

Figure 3.5 Pat's decision tree.

Win contract? 58,400

evaluated. That is, i f we buy now and lose the contract, there is a n uncertainty a s to the price we can sell the land for to recoup our expenses. If we do not buy the land and win the contract, then we have to purchase the land. There is a n uncertainty a s to the price we can buy the land for a t this point. The answer is calculated i n the same manner above using expected value. When you have uncertainties t h a t are chained together the expected value starts a t the right- hand side and works left. You calculate the expected value around each uncer- tainty. The resulting expected value replaces the entire uncertainty in the next uncertainty. The resulting decision tree of Pat's decision process is shown i n Fig. 3.5.

Using the decision tree, we start with the upper decision alternative of "buy later." At the left-hand side we see that the expected value of purchase price of land is 100,000(0.8) + 80,000(0.2) or $96,000. The entire uncertainty can be replaced by $96,000. Then the next uncertainty expected value can be deter- mined a s 96,000 (0.60) + 0(.4) or $57,600.

Following the same procedure, we can calculate the lower alternative of "buy now" with a result of $58,400. The tree can now be collapsed to the following decision:

DoableTools: Applying Tools Strategically 65

We choose between a n average profit of $57,600 for '%uy later' or $58,400 for '"ouy now." Based on this, we would like to get a s much profit a s possible, so we would choose 'buy now."

. !

Issues I Simulation. Simulations create mathematical models using kky factors in a future scenario and calculate outcomes based on various assumptions and input values. For the estimation of risk and impacts, simulations are dseful when the project complexity is such t h a t t h e interaction and impact of many factors cannot be handled manually.

Expert judgment. Expert judgment is gathered through Delphi dechniques and focus groups who brainstorm to express their insights on a given risk problem.

Response planning I Prioritization. In prioritizing risks, the project manager develops a sense of where response planning is most needed. Risks are ranked in the risk matrix and assessed, and then the level of response planning and contingency is aligned with the relative importance of the risk.

Amount at stake. The amount a t stake is actually a calculation hf the expected value of a given risk decision; it is the dollar loss should a risk not be controlled, or should a n opportunity not be exploited. 1

I Response strategies !

I

Avoidance. Avoidance is a viable approach, neglecting thk risk, which sometimes "goes away." I

I Transference. Transference moves the risk to another party, a s & insurance or

contracting. I

Mitigation. Mitigation planning takes the risk on squarely anh provides the project manager with a direct corrective action. 1

Acceptance. Acceptance is the approach t h a t essentially plansfor the risk to occur and plans for covering the cost and schedule impacts. 1

Monitoring and control ~ Risk response audits. Risk response audits are used to look back $t how a given project or project risk has been handled. A project audit looks d o r e broadly a t how the project was managed across the board. i

66 Chapter Three

Periodic project risk reviews. Risk reviews are incorporated into project reviews, not in separate sessions. The project review agenda includes risk analysis and planning data and poses risk decisions to be made.

Earned value analysis. Earned value monitors schedule and cost variance a s indicators of risk impacts.

Communicating risks. Risks are addressed in business and project reports, which anticipate risks, explain contingencies, and pose decisions to be made which may shape the risk impact.

Project Control Systems

Cost/schedule integration

Information flow and ties to WBS. Baseline schedules are developed from t h e WBS and schedule and cost data are related to particular tasks. Since costs are directly associated with tasks, each task can be assessed in terms of cost and schedule impacts.

Network plannlng and schedule development. Scheduling is the most important function of project managers and risk determines the amount of "buffer" t h a t is withheld by the project manager based on the probabilities of risk occurrence and contingency action.

Project cash flows and commitments. Cash flows committed out beyond customer agreements or contracts represent separate risks, thus cash flows are aligned with work performed and scope boundaries.

Reporting responsibilities. Project managers report risk and cost information to top management, stakeholders and customers; functional managers report tech- nical and technology risks and costs to top management.

Issues

Cost, schedule, performancelquality tradeom. Decisions which trade off schedule, cost, and qualitylperformance factors can be guided by the risk impacts of each option. I n other words, when a project manager decides to delay a task outcome because of quality considerations, the determining factor might be the risk t h a t the quality outcome cannot be achieved even with more time provided by a task delay.

Integrated change management. Change management is the process of accom- modating to a change request by reviewing all internal and external impacts, reviewing the risks of change, and integrating the change across all appropri- ate interfaces.

DoableTools: Applying Tools Fhrateglcally 67

Corrective action I Crashing. Sometimes the project manager must direct new reso/urces to a proj- ect to make up for unanticipated impacts of risk events, thus crashing t h e proj- ect. The risk of quality impacts of crashing can be found in the tendency for "haste to make waste."

I Phasing of deliverables. Phasing deliverables i n a different way may help to relieve the tensions of a project task delay or failure.

Modification of scope, schedule, budget. Sometimes a scope or s d e d u l e must be altered because of schedule or cost variance, but there are inherent risks in doing so. I

, Chapter

Demystifying Risk: Using ihe PMI PMBOK*

Demystifying Risk-PMBOK 1 It is not only important to know the PMI PMBOK guide on r i d management but also to simplify t h e process to match i t with reality. T h e P M I PMBOK defines risk management a s the "systematic process of identifyhg, analyzing, and responding to project risk." The concept aims a t maximizing the probabil- ity and consequences of positive events and minimizing the probability and consequences of adverse events to project objectives.

It is important to see the PMBOK as a guide, not a manual. m i l e the fol- lowing discussion is guided by the PMBOK (2000 edition), the reader will quickly see that each section is framed by a reality check-the author's personal and pro- fessional view of best practices i n the real world of faster, better, a n d cheaper. The discussion presupposes a separate risk management plahning process, which serves a s a n ideal. In practice, risk planning occurs a s ah integral p a r t of project planning. I

Tne PMBOKframework is very useful as a process guideline, but in view of devel- opments in enterprise project management, multiproject environments, project and portfolio selection, and the new appreciation for the interfaces of project manage- ment with other organizational systems, the PMBOKis only a start^ Table 4.1 con- trasts the current PMBOKon risk with future needs.

Process. We are learning t h a t while process focus is important/ it misses the opportunity to integrate risk into current business a n d project planning and management actions. Process focus is useful for ensuring quality knd discipline, but has limitations in practical work settings. I

I * A Guide to the Project Management Body ofKmwledge, 2000 edition, Project ~ d g e r n e n t ~nstitute.

70 Chapter Four

TABLE 4.1 Comparison of Current PMBOK Standards on Rlsk with Future Needs

Process focused Management focused Separate procedure Integrated into project planning and control Single project oriented Portfolio, multiproject oriented Emphasis on quantitative Emphasis on qualitative and

professional judgment Focused on methods and procedures, Focus on training and enabling not people people to manage risk

Assumes inputs to process exist Realistic picture of inputs Not related to cost Integrates risk and cost Not related to quality Integrates risk and quality Ignores business wide risk Initial focus on business risk strategy Does not incorporate contingency into planning Integrates risk into the scheduling process Ipnores risk as opportunity Connects risk control to opportunity

Separate process. The propensity to breakdown the project planning and control process into components misses the actual dynamic in real organizations where everything goes on all the time. Risk has not proven to be useful as a separate process, but rather effective only if integrated.

Single project. Risk is no longer looked a t as a single project issue; most risk is associated with broader issues, such as the business itself and other projects i n the company portfolio.

Quantitative. Overemphasis on quantitative tools and mathematical models suggests risk management a s a science rather than art. Most risk management actions are full of judgment and margins of error, which make quantitative tools ineffective and intimidating.

Focus on methods, not people. The risk process is essentially a thought process, a way or style of management t h a t is ingrained in the way people work and solve project problems.

Overemphasis on methods and undervaluing of the human element limit the application of the current PMBOK.

Assumes inputs. The assumption in any process focus is t h a t the inputs will be there, but in many cases t h e necessary inputs a r e not there because the whole concept of separate risk management process is flawed when looked a t i n practical terms.

Unrelated to cost. Risk and cost are inextricably intertwined and therefore it is difficult to look a t risk without looking a t the costs of control and costs of impact.

Unrelated to quality. Risk a n d quality are also inextricably connected. Since risk has a n impact on quality, many risks are associated with feasibility, not schedule--some projects may not be capable of meeting customer standards and specifications in the first place.

Demystifying Risk: Uslng the @MI PMBOK 71

lgnores business risk. Project risk i s first identified a n d mhnaged a t t h e businesswide level, through strategic and business planning.

Separate contingency planning. The current PMBOK describds contingency planning a s a separate process, but i n order to be effective contingency actions need t o be incorporated into baseline schedules a n d budgets. The project manager ensures t h a t the schedule has buffers and contingency tasks built in.

lgnores risk as opportunity. The other side of risk is opportunityLthe ability to control risk creates opportunity because t h e competition canhot. Thus any project aimed a t capturing a market share is designed to createopportunity.

Table 4.2 provides a n overview of the current PMBOK risk prlocesses.

Risk management planning. Deciding how to approach and plan the risk management activities for a project ~ Risk identification. Determining which risks might affect the droject and doc- umenting their characteristics I

Qualitative risk analysis. Performing a qualitative analysis of risks and conditions to prioritize their effects on project objectives ,

TABLE 4.2 PMBOK Rlsk Management Processes i 11.1 Risk management planning 11.2 Risk identification 11.3 Qualitative risk analvsis

.1 lnputs

.1 Project charter

.2 Organization's risk management policies

.3 Defined roles and responsibilities

.4 Stakeholder risk tolerances

.5 Template for the organization's risk management plan

.6 Work breakdown structure

.2Tools and techniques

.1 Planned meetings

.3 outputs

.1 Risk management plan

.1 Inputs

.1 Risk management plan

.2 Project planning outputs

. 3 Risk categories

.4 Historical information

.2Tools and techniques .1 Documentation reviews .2 Information gathering techniques

.3 Checklists

.4 Assumptions analysis

.5 Diagramming techniques

.3 Outputs

.1 Risks

.2 Triggers

.3 Inputs to other processes

.I Inputs i

.1 Risk managemekt plan

.2 Identified risks

.3 Project status 1

.4 Project type

.5 Data precision 1

.6 Scales of probability and impacts

.7 Assumptions 1

.2Tools and techniques

.1 Risk probability and impact

.2 Probabilitylimpact risk rating matrix 1

.3 Project assumptions

.4 Data precision ranking

.3 outputs I I

.I Overall risk ranking

.2 List of prioritized tasks

.3 List of risks for additional analysis and management

.4 Trends in qualitative risk analysis results

(Continued)

72 Chapter Four

TABLE 4.2 PMBOK Risk Management Processes (Continued)

11.4 Quantitative risk analysis 11.5 Risk response planning 11.6 Risk monitoring and control

.l Inputs .I inputs .1 Inputs

.1 Risk management plan .1 Risk management plan .1 Risk management plan

.2 Identified risks .2 List of prioritized tasks .2 Risk response plan

.3 List of prioritized risks . 3 Risk ranking of .3 Project communication

.4 List of risks for additional the project .4Additional risk risk analysis and management .4 Prioritized list of identification and analysis

.5 Historical information quantified risks .5 Scope changes

.6 Expert judgment .5 Probabilistic analysis

.7 Other planning outputs of the project .ti Probability of achieving the cost and time objectives

.I List of potential responses

.8 Risk thresholds

.9 Risk thresholds .10 Common risk causes . l l Trends in quantitative and qualitative analysis results

.2Tools and techniques .2 Tools and techniques .2 Tools and techniques

.1 Interviewing .1 Avoidance . 1 Project risk response audits

.2 Sensitivity analysis .2 Transference .2 Periodic project risk reviews

.3 Decision analysis .3 Mitigation .3 Earned value analysis

.4 Simulation .4 Acceptance .4 Technical performance measurement

.5 Additional risk response planning

.3 outputs

.1 Prioritized list of quantified risks

. 2 Probabilistic analysis of the project

.3 Probability of achieving the cost and time objectives

.4 Trends i n quantitative risk analysis results

.3 outputs

.1 Risk response plan

.2 Residual risks

.3 Secondary risks

.4 Contractual risks

.5 Contingency reserve amounts needed

.6 Inputs to other processes

.7 Inputs to a revised pmiect plan

.3 outputs

.1 Workaround plans

.2 Corrective action

.3 Project change requests

.4 Updates to the risk response plan

.5 Risk database

.6 Updates to risk ident

ifi

cation checklists

Quantitative risk analysis. Measuring the probability and consequences of risks and estimating their implications for project objectives

Risk response planning. Developing procedures and techniques to enhance opportunities and reduce threats to the project's objectives

Risk monitoring a n d control. Monitoring residual risks, identifying new risks, executing risk reduction plans, a n d evaluating their effectiveness throughout the project life cycle.

These processes interact with each other and with t h e processes in t h e other PMBOK knowledge areas. The way they interact is key to integrating risk

Demystifying Risk: Using the PMI PMBOK 73

management with the basic project planning and control proces$. Here are the salient points of integration.

Risk Management Planning

Risk management planning for a particular project is inextricably connected to how thc organization prepares for dealing with risk and uncertainty in its busi- ness dcveloprnent and strategic planning, in its information technology invest- ments and management of network communications, and in its organizational - - structure. No project manager faces risk a l o n e i t is a company-wide issue and i t is quite likely t h a t there are data and information on project risk in the com- pany files. I

A company prepares for risk in projects by assessing t h e overall risk i n strategic planning. Then, in i t s development of a program of projects, or port- folio, t h e company assigns risk to a general program or product line a s part of its decision to proceed. Templates for risk identification and assessment are available. I

A project management office is sometimes available to support risk manaae- - - - - ment by providing for information templates, project review data and agendas, research findings, and historic information on various risk subibcts.

To address risk effectively, there needs to be a n informatibn technology capacity i n the company to ensure t h a t risk documentation and tracking can be achieved within the network and the software assets available. This means a way to organize risk data, for team members t o communicate risk informa- tion quickly, a n d for project managers to present risk data in acceptable for- mats. I

Finally, if the company is not organized to address projects ir! some kind of project structure, project risk will get the same kind of attentioh other project issues, such a s cost and schedule, g e t v e r y little. In a matrix structure, for instance, risk is addressed in the functional department in t e r d s of processes a n d equipment to address risk through testing and monitoring technical processes. At the same time, the project manager is attuned to risk when sched- ules are delayed because of events or developments grounded i n risk.

This does not need to complicate the up-front risk process. ~ d k is still a rel- atively straightforward concept ofplanning a n d controlling for things that could go wrong. That risk management planning is tied to business planning and strategy need not suggest t h a t this linkage complicates the acdievement of a good risk management process. In fact, it makes project risk management easier in the sense t h a t business planning itself provides a precursor to project risk. If I a m in the avionics business, and I design and produce avionics equipment for business jets, and my overall business plan identifies major threats to prof- itability and success, such a s the global availability of cheap LCD monitors or the pending change in air traffic regulations affecting avionics, then my indi- vidual projects begin with a major challenge in those two areas. As a project man- ager in that scenario, I enter the project arena with a built-in, up-front view that

74 Chapter Four

I must keep my eye on both these factors and plan and schedule contingency and risk mitigation actions as part of my project plan.

The PMBOK process view emphasizes the inputs and outputs of the risk process. This is a useful perspective on risk even though it does not really deal with integration of risk management into the project planning a n d control process. The PMBOKis based on the highest level of "maturity" i n a n organi- zation, a scale t h a t is embodied in the PMI maturity model. Thus the PMBOK process is idealized in a mature organization, and rarely found in all its dazzling performance dimensions in a normal business environment.

Inputs to risk management plannlng

Project charter. The project charter is a n ideal project planning document t h a t includes the business need and product description. I n reality, this document is often neglected because the content for the business need is still in conceptual stages. And since a t this aoint the deliverable is often undefined and unsaecified. theproduct description is not a t the level of detail of a configuration management document. But the deliverable is defined in werformance terms a t the scale possible, given the understanding of what is being designed and built.

Organization's risk management policies. If the business has a set of risk management policies and procedures, they would be used i n risk planning. However, many businesses do not have such policies, nor will they; rather they apply risk tools as an implicit part of the project planning process. Approaching this process input with a healthy skepticism one can see the value of writing down policies and procedures, but in today's fast moving companies this is rarely done. The point is t h a t a nimble midsized business of today that has articulated its approach to risk would expect each employee and certainly its management to embody t h a t approach in the basic project management process-without a bureaucratic statement of top-down policy.

Defined roles and responsibilities. One would hope t h a t t h e basic roles a n d functions of the project manager and functional manager is documented, but again this is often left undefined i n order t o allow a n a t u r a l process of negotiating a n d working out roles between functional quality and project delivery interests.

Stakeholder risk tolerances. The PMBOK is not very helpful in illustrating this input. Stakeholder risk tolerances are evidenced in the modern business as "world views" of certain important people in t h e process, such a s sponsors, customers, investors, top management, and regulators. A risk tolerance for a n electronic instrument might be framed a s a technical tolerance (e.g., mean- time-between-failures), or a performance tolerance (e.g., must perform in below zero temperatures), or a drop-dead limit (e.g., we investors will not proceed with this project if by this time next year there is no first article production unit because of the anticipated rapid change in market conditions). Tolei-ances are

Demystifying Risk: Using the PMl PMBOK 75

often grounded in expectations, thus it is important for a project manager to see such tolerances and evaluate their intensity early in the project.

Work breakdown structure. Certainly, a WBS is necessary 4s a basis for identifying risk, but the WBS must be comprehensive and show all tasks before the risk identification process can really be effective. If the WBS misses some important work that is highly subject to failure then the WBS is not a good input to risk management planning.

Issues not addressed in PMBOK ~ Some risk issues are not addressed squarely in the PMBOK b u t are important in gaining a full understanding. I

Building a risk-based organizational culture. Building an organization that protects itself from project level risk a n d uncertainty through good organizational planning and management requires strong leadership. As a project manager you have to first feel t h a t you are expected by your management to anticipate and deal with risk and t h a t you will be supported i n taking the time and investing the cost involved in building a good risk planning and control process. Risk management starts a t t h e top leadership level with clearly articulated vision and mission t h a t incorporates an uncompromising commitmentto quality and excellence. I n so doing, t h e leadership commits also to a risk management process to reduce the probability of failure and to promote total quality in product design and production.

I

Program and portfolio management. The management of risk i n a multiproject environment, and the role of risk i n selecting and maintaining a portfolio of balanced projects are not really addressed in the PMBOK. Yet the selection of . . the right projects for the project pipeline inherently involves risk management. Projects with high risks must be identified before they enter th8 approved list - - - simply because a portfolio of high-risk projects endangers the lonlg-term growth and profitability of the enterprise. I

Interface management. Good risk management is dependent on the availability of effective support a n d interface services to project managers. Risk cannot be seen simply a s a project management issue; it is a n accounting a n d cost issue, a procurement issue, and a n information technology issue. Cost data -. must be available to project managers to assess cost impacts; contract officers must be attuned to risk and risk sharing issues in managing contractors and supply vendors; information technology administrators should sbe the need for web-based, easily available risk matrix templates and calculations software.

Risk and cost integration. For some reason, the relationship of Aost and risk is lost i n the daily routine of project managers, yet it is in cost hnd "expected value" that future impacts of risk decisions can be made. contingency plans add

76 Chapter Four

to project cost estimates and when there are clear decisions t h a t must be made and crossroad tradeoffs to be decided, there must be a support system available on making those decisions.

Tools and techniques for risk management planning

Planning meetings. Planning meetings are important and can be fruitful, but they can also be a complete waste of time unless they are focused and deliver results. Setting agendas, facilitating meetings, and writing good follow-up notes are all useful tools.

The PMBOK treatment of risk management planning does not cover some of the most important risk management planning tools, namely:

1. Business plan. The grasp of the business plan helps a prospective project manager get a n early start in project risk management planning. Such a plan, or a business strategic plan, will provide strategic information, e.g., SWOT (Strength, Weakness, Opportunity, and Threat) data and information.

2. WBS. The WBS is a n early indication of t h e potential risks i n any project, and planning for project risk requires a t least a n outline of the WBS to see the basic components of work involved. Risk management planning requires the project manager to anticipate how risks will be handled by looking a t the WBS, or building one.

3. Information a n d network systems. A major risk management planning tool is the company network and information sharing system and data already available on similar projects in the past.

Outputs from risk management planning

Risk management plan. The plan outlines the approach to how risks will be handled in the project. Frankly, many companies do not need a separate risk management plan, but they should integrate risk information into the project scope, WBS (definitions), schedule, and budget. As a threshold, if the project under consideration is more than 300 tasks and budgeted a t more than $5 million, a separate risk management plan is called for.

The plan includes:

1. Methodology. It is not clear from the PMBOKwhat the "methodology" of the plan is, b u t ~ i t appears that the concept says you should have a methodology. For instance, a n electronic instrument production firm should use safety and reliability tools, such a s mean-time-between-failures, to test its prototypes to avoid the risk of performance variation and failure.

2. Roles a n d responsibilities. Here t h e plan addresses who is responsible for what in a functional and project management context. Here would be where the role of a program management office would be described.

Demystlfying Rlsk: Uslng the PMI PMBOK 77

3. Budgeting. This is a budgeting exercise to estimate the coet of risk man- agement. Frankly, it would be more important to spend time analyzing the cost of the risk event. The cost of risk management is a program management cost category, a s in quality assurance and project review.

4. Timing. This addresses when various risk management actions will be taken in the project schedule, such a s risk analyses, preparation of contin- gency plans, and response plans.

5 . Scoring a n d interpretation. This portion of t h e risk madagement plan addresses tools, such a s the weighted scoring model (aligns plrojects in proj- ect selection with business strategy, places priority weights onvarious strate- gic objectives, and scores each project against the strategic bbjectives) and cash flow, rate of return, and net present value. i

6. Thresholds. Thresholds address the criteria-rules of t h u m k f o r acting on risks or to reduce risks, such as deploy preventative contingency and response plans for risks which could delay a project by more than 10 percent of the total project duration unless the risk is reduced i n the first quarter of the project.

7. Reporting formats. This provides guidance to the project manhger on the for- mats, e.g., email, MS Project team reporting, hardcopy spreadsheets, for project reports to stakeholders. !

8. Dacking. This provides guidance on what risks will be trdcked and how, such a s the acquisition of microchips for a n electronic instiument will be tracked with the contractor on the basis of earned value. 1

Risk Identification !

Risk identification should be part of the project planning process1 not separated from it. Risks are identified i n the development of the WBS and in estimating durations and resource needs.

Inputs to risk identification 1 I

Risk management plan. To the extent t h a t a risk management plan is produced, i t is a n important input to identifying risks. But since most companies will s t a r t t h e process of handling risk with t h e WBS a n d the t a s k list, t h e identification of risk usually s t a r t s i n earnest i n t h e review and final production of t h e generic WBS. I t is here t h a t t h e project manager reviews every task for its potential for failure. Identifying r i s k involves a lot of discussions with team members and stakeholders. For instance, if a technical t a s k i n t h e WBS, say achieving a given mean-time-betweed-failures i n a product component, "sticks out" initially because of t h e challenges of completing it t h e n it is t h e subject of much discussion a n d contingency planning early in the project. I I

78 Chapter Four

Project planning outputs

Project charter. If there is a charter, the charter should be helpful in identifying risks and confirming the judgment of the project manager on where the project vulnerabilities are.

~ 6 s . The WBS is t h e basic source of risk identification activity since i t embodies all the work of the project, or should. The WBS should be four levels down to give enough detail to the project profile to see project risks.

Product descrlption. The product description will be embodied in a configuration management document, or in some documenffdrawing/specification t h a t defmes the product from a performance and component perspective. This will occur i n the design phase a t some point when the deliverable has been fully fleshed out.

Schedule and cost estimates. The schedule and project budget (part of the schedule in MS Project) will be a good source to confirm risks, but first the project manager must prepare a risk matrix a s described earlier. The risk matrix identifies the task, the task risk description, and the impact (schedule, cost, and the like).

Resource plan. While there is typically no formal resource plan, there will be a sense of the personnel, equipment, capital, space, and technology needs of the project. Ideally, this resource plan is in one place, for example, in MS Project andlor in a planning document of some sort. But a t this point, if all the resources needed for t h e project a r e not clear, it is not critical. What is needed here is a clear idea of t h e "bottleneck" resources-those resource issues t h a t could represent a barrier to achievement of t h e project. These bottleneck resources might be a critical software engineer who is already spread too thinly i n current projects, a piece of testing equipment t h a t is critical to meeting quality control thresholds, or a work space or station t h a t i s being shared with other projects.

Here also is the beginning of the application of the theory of constraints. Simply put, the theory states t h a t the focus of attention in planning and con- trol should not be the whole project and all its tasks, but rather the one or two major resource constraints. The project manager protects against t h e risks inherent in these resources by tapping time and cost from the original esti- mates and withholding them for allocation when they are needed.

Assumption and constraint lists. The assumption list is a convenient way of indicating the controlling assumptions, e.g., the assumption t h a t a sole source contract with a foreign supplier for a key product component will last through the project life cycle. In practice, these assumptions are well known by the project team and stakeholders, but it pays to document them and revisit them in project review sessions and to treat them a s risks with contingency plans.

Risk categories

Technical. Technical risks have to do with product, process, or "technique" issues involved with designing and producing the deliverable.

Demystifying Risk: Using the PMI PMBOK 79

Project management rlsks. Project management risks address the things t h a t can go wrong with the project planning and control process and with expected support services from the information technology source bnd a project management office, if the organization has one.

Organizational risks. These are the "soft" issues t h a t a project fades, which have to do with organizational behavior and dynamics, e.g., conflicts, sdarce resources, personnel performance problems, and company-wide crises, such a s lack of . . financing or a downturnin share value. A key organizational ridk is the lack of top management support, which will be evidenced with the neglect of the project i n the company "head-shed." I

External risks. External risks are the business and global risks inherent in any business, such as economic downturns, trade difficulties affecting the deliverable, and the impacts of communication in multinational companies.

Historical information. Historical information would includd past project documents, "lessons l e a r n e d reports, and industry information abailable on the competition, on demand and market issues, and on the company's performance on similar projects in the past. 1 Project files. Project fdes would be available trom the company's Ale system, but in practice project managers rarely look back even though it would make sense to do so. I

Published information. This would include manuals, articles, publications on the deliverable.

Tools and techniques for risk Identification I Documentation reviews. The key document in risk identificatioh is the WBS. Other documents would include past project reviews and similar product performance information. I

Information gathering techniques. These would include web-based information, electronic files with product information, and Internet research1

I I

Brainstorming. Brainstorming is simply having meetings with $ey people who know something about the project and generating ideas and options without judging them. Brainstorming generates ideas and does not filter them.

Delphi technique. Delphi is brainstorming with key experts whb go through a systematic process of providing their views, reviewing each other's ideas, and coming up with a scenario based on the integration of their views.

i Interviewing. Interviewing key stakeholders, past project manakers, and task managers helps to uncover "subtle" information t h a t has not been documented.

80 Chapter Four

Strengths, weaknesses, opportunities, threats. Here we look back a t the business planning processes for strategic analyses, especially including threats and opportunities.

Checklists. Checklists are typically prepared by a documentation specialist for various project and product documents. Checklists often key into potential- failure points in past projects and thus are very useful in identifying risks.

Assumptions analysis. The key source of assumptions is rarely captured in one document, but the concept of focusing on assumptions is important. A project management office is typically in charge of documenting assumptions.

Diagramming techniques. Flow charts and diagrams, such a s decision trees, are useful in identifying the various options and decisions, including expected value.

Cause and effect. "Root causes" of risks can be identified through fish-bone diagrams and other such meeting techniques.

Influence diagrams. Diagrams that indicate cause and effect, and influence of key factors, can help in identifying risks.

Outputs from risk identification

Risks. The output of risk identification is a better sense of risks over time. I n truth, the clarity of risks increases a s time goes on in the project life cycle.

Triggers. Triggers of risk include those indicators or signals of risk events t h a t become clearer in the risk identification process. For instance, in a contract negotiation in the outsourcing process, a contractor refuses to sign the contract because of a schedule requirement for delivery of a key supply or piece of equipment before a key project milestone.

Qualitative Risk Analysis

PMBOK separates the risk analysis process into two parts: (1) qualitative and ( 2 ) quantitative. Qualitative connotes a better description of the risk, i t s dimen- sions and its characteristics; quantitative involves getting a finer cut on risk by applying mathematical and other quantitative tools. I n practice, companies rarely split the two. The point of risk analysis is to drill down on potentially high- risk tasks to get a more detailed picture of their impacts.

Inputs to qualitative risk analysis

Risk management plan. The risk plan again is useful.

Identified risks. Acompleted risk matrix is required before risk analysis proceeds.

Dernystlfylng Risk: Using the $MI PMBOK 81

Project status. The timing of risk analysis is important because the risk impacts, particularly in terms of schedule and budget, will change depending on when they are analyzed. The later in the project cycle, the clearer the impacts will be.

Project type. It is important to dimension the risk here; a projedt producing a n electronic instrument for a sophisticated aeronautic application will get a different look t h a n a project to construct a standard building. 1

I

Data precision. The accuracy and precision of data are i m p o r t a h ; if you know t h a t a given reliability test has a proven failure rate then the results must be tempered accordingly. I

I Scales of probability. Probability is a subjective judgment unlesA the product is tested many times to develop a statistical mean. I n most projects,the probability of a risk occurring is the result of thinking through how many times this kind of risk has occurred in past similar projects, combined with "gdt" judgment of the project manager and key stakeholders. I

Assumptions. Again, the assumptions are rarely listed, but the4 are apparent in the analysis process.

I

Tools and techniques for qualitative risk analysls I Risk probability and impact. Using the risk matrix, the project manager has already ident

ifi

ed risks and will assign probabilities to all high-inipact risks. For most risks, these probabilities are subjective and simply communicate a sense of confidence that the project manager has about the risk in question. Generally, probabilities should be stated in three forms, 25 percent, 50 percent, or 75 percent, suggesting little change of the risk occurring, substantial chance, or high chance, respectively.

I Probabilitytimpact risk rating matrlx. The rating or risk matrix n o b is fine tuned in the analysis process, with more data and more attention. 1

I

Project assumptions testing. Testing assumptions involves taking time to review key assumptions and confirming t h a t the assumption is right and t h a t t h e probability assigned is i n the right ballpark.

I I

Data precision ranking. For most projects, this step is not useful! If the product is highly complex and must meet detailed performance specifications then the data precision ranking indicates how precise the test data are compared to a common standard. I

Outputs from qualitative risk analysis I

Overall rlsk ranking for the project. Once the qualitative process is finished, two rankings are produced: (1) how the project's overall risk is ranked compared to

82 Chapter Four

others (may be completed in comparing and selecting a portfolio of projects) and (2) how individual risks rank within the project, usually limiting t h e list to five or less.

Again, this process is related closely to the theory of constraints. Aproject typ- ically faces only a few major bottlenecks or risks, and it is the job of the project man- ager to accurately uncover those few critical risks during qualitative analysis.

List of prioritized risks. The list of prioritized risks is incorporated in a project report to stakeholders along with supportive information including the risk matrix and contingency plans.

List of risks for additional analysis and management. A residual list includes other risks t h a t could turn out to be more important than they appear.

Trends in qualitative risk analysls results. Some review of the credibility of the process will uncover past analyses and how their results played out in real terms.

Quantitative Risk Analysis

Inputs to quantltatlve analysis

All the inputs to qualitative analysis are relevant here, plus expert judgment. Expert judgment comes from technical experts who have knowledge a t the tech- nical level on the risk i n question. For instance, here is where a project man- ager brings i n a safety and reliability expert contractor to advise on variability thresholds i n testing prototype parts.

Tools and techniques for quantitative risk analysis

Inte~lewlng. Again, interviews are useful with key experts on defined task risks.

Sensitivity analysis. Sensitivity analysis determines how much project outcomes, e.g., schedule, budget, and quality are sensitive to particular risks. For instance, it may turn out t h a t although a risk is only medium probability and impact, it could alter the final deliverable in a measurable way in terms of quality control.

Decision tree analysis. Decision tree analysis aims to uncover expected value of taking one path or another when a project "crossroad" decision must be made. I n t h e case already discussed, a decision on whether to purchase land i n anticipation of winning a contract brings with it a set of expected values for going one way or t h e other.

Simulation. Simulations are mathematical representations of scenarios involving key project risks. This might include a n equation that specifies what happens to a n information technology scheme when its capacity is challenged by demand, e.g., -- shut downs, performance failures, and the Like.

Demystifying Risk: Using the PMI PMBOK 83

Outputs from quantitative risk analysis I Prioritized list of quantitative risks. Quantitative analysis usually places more content on the already produced list of risks from qualitative analysis. New data are presented on high risks from the analysis.

I Probabilistic analysis of the project. Here the probabilities are workeh to a finer level of detail based on more analysis. Aprobability set a t 25 percent phase might be fine tuned here to, say, 38 percent with more analysis of past projects and simulations, and perhaps

I

Probability of achieving the cost and time objective. Afinal probabil& is determined for meeting the project schedule and budget goals. i

Risk Response Planning 1 Appropriately, the PMBOK places high priority on a response blan t h a t miti- gates risk. That response plan is grounded in the contingency plans already developed in preparing the risk matrix. The key point about r e d o n s e planning is to outline corrective action and to incorporate those actions i n the baseline schedule so that they will not later be considered add-ons or changes to the proj- ect. They might later be identified with the "pessimistic" estimates of dura- tions in the PERT analysis in MS Project.

i Inputs to risk response planning I

Risk thresholds. Risk thresholds help to identify acceptable ranges for risks to occur without deploying contingencies, e.g., if this work is not done in the estimated time then we will give the team 3 more weeks before we act since the task is not on the critical path. They come h m customers, stakeholders, and tekhnical experts.

Risk owners. Risk owners are those stakeholders who are accountable for acting on risks, or a t least reporting on risk activity. If there is no designated risk owner, a risk could be unattended long after it is identified because of the tendency to avoid controversy and accountability for risks t h a t cannot easily be controlled.

Common risk causes. Common to all industries are a set of commbn risk causes, such as government regulatory change, bad marketing information, faulty safety a n d reliability equipment, a n d lack of proven competencies in particular personnel categories.

I Tools and techniques for risk response planning i

Avoidance. One approach to a risk is to avoid it and hope thah it goes away. Sometimes it does. I

Transference. Transference involves turning a risk over to a ribk owner, e.g., assigning a contractor the job of responding and providing incentives for risk reduction. I

84 Chapter Four

Mitigation. This is t h e corrective action option leading t o deployment of a contingency plan.

Acceptance. Sometimes it pays to accept a risk and deal with it directly rather t h a n transferring it, avoiding it, or mitigating it. 'Ziving with" the risk means plugging in schedule and budget reserves assuming t h a t the risk cannot be controlled and working around it.

Outputs from risk response planning

Risk response plan. Although a formal, written risk response plan is not always feasible or wise because of the cost and effort involved, it is the learning and thinking process t h a t follows from good risk response planning t h a t gives it value. Once through with the process of defining risks, planning to respond, and folding the results into planning documents, such a s the schedule and budget, a project manager "owns" those risk responses and h a s incorporated them into the plan. The lack of a separate, documented risk response plan is not a good indicator of the fact t h a t risks have not been considered. I t is more important t h a t risks are incorporated i n the project schedule and estimates made from "expected, optimistic, a n d pessimistic views," which a r e driven from risk analysis.

Residual risks. Residual risks are risks t h a t continue to exist after corrective action. Sometimes residual risks are created in taking a corrective action t h a t was not anticipated in the original project planning process.

Secondary risks. These are lower level risks that have less impact but which can grow in importance if neglected.

Contractual agreements. The type of contract used in outsourcing work involves some explicit assumptions about risk transference. For instance, a f x e d price contract is superior to a cost reimbursable contract in transferring risk to a contractor to control a given risk in performing contracted project work.

Contingency reserve amounts needed. Sometimes a project must be protected with a reserve fund, or insurance program, so that the company is not financially exposed from a given risk even though it is mitigated.

Risk Monitoring and Control

The PMBOKplaces emphasis on monitoring risks and controlling them, but this process is again a n integral part of the project review and control process.

Inputs to risk monitoring and control

I n addition to the common inputs addressed above, the new inputs to monitor- ing are communication and scope change.

Demystiiing Risk: Using the PMI PMBOK 85

Project communication. Communication means exchanging &formation on anticipated risks so t h a t people who have a stake i n the project can assist i n mitigation and can adjust their expectations for the project. Communication always helps to reduce the uncertainty and "surprise" factor i n dealing with customers, clients, and stakeholders.

Scope changes. As the project is progressing and work is getting hone, there may be new information uncovered in the risk management process that requires a change in the scope, schedule, budget, or quality standards in tde project. Thus scope change is a logical outcome of monitoring and seeing risks impact the project.

Tools and techniques for risk monitoring and control I Project risk response audits. A project risk audit looks back a t how effectively project management processes in general were handled and hbw well project risks were monitored and mitigated.

Periodic rlsk reviews. Risk review occurs in the normal project ieview process, not as a separate process. A standard project review agenda alr+ays includes a section on risks. I

Earned value analysis. Schedule and cost variances alway$ indicate t h e possibility of risks being a t work if the project is not performihg as planned. Corrective action when uncovering major earned value variances over 10 percent would include a review of risk contingencies and impacts. I

I Technical performance measurement. Technical issues could be a t work i n a project t h a t is slipping or meeting insurmountable obstacles. ~

Outputs from risk monitoring and control 1 Workaround plans. The so-called workaround plan is a manifestation of the risk mitigation process. Workaround is a contingency t h a t should be identified i n preparing the risk matrix. Workaround sometimes takes advantage of innovative, creative options to overcome a project risk, and is often the result of "out-of-the- bod' thinking t h a t can be generated in a brainstorming session.

Corrective action. Corrective action is the action taken when thk project is not performing according to plan-schedule, cost, and quality. 1

I

Project change requests. In monitoring, the need to fundame&ally change a project scope or key deliverable occurs often, thus triggering a change request.

I Updates to the risk response plan. Updates to the risk response ~ i a n result from lessons learned i n the monitoring process. 1

86 Chapter Four

Rlsk database. The risk database is a documentation of risk information t h a t will be useful i n corrective action and future projects.

Updates to risk identification checklists. Updates to risk identification checklists help keep tabs on best practices i n risk mitigation as they are generated.

Summary of Rlsk Management Process

Identlfy and categorize risks

Identifying risks is not a science, it is an art. I t does not require a sophisticated, mathematical exercise, although some measurement may be useful to dimension the risk.

Given a project description including project goals, work breakdown, schedule, and resource assignments, identlfy and categorize potential risks using various - tools including risk assessment, brainstorming, peer review, and document review.

Here we develop the basic skill of reviewing a project scope, work breakdown, and schedule, and identifying risks from the tasks and processes. The reader goes through a risk matrix, which lists potential risks, defmes them, categorizes them, estimates impact on various project performance outcomes, such a s sched- ule, budget, and specification, and might include reference to a contingency plan-a plan to take a n action if a "worst case" actually happens.

Assess risks

Assessing risks is part of the planning process, not a separate, quantitative, or qualitative exercise.

Given a project description and identified risks, apply various quantitative and qualitative analysis tools, including sensitivity analysis, to determine the effects, outcomes, and consequences of identified risks.

This is where we will apply tools and methods to assess impacts and conse- quences of various risks on project success. You can use a variety of tools. Sensitivity analysis tries to figure out how sensitive the project is to a given risk and there are a variety of approaches to sensitivity analysis.

I n the real world, project managers don't do sophisticated probability analy- sis to get the probability of something happening to 88.54 percent. The margin of error is so large in trying to determine the probability t h a t you are lucky to get in the ballpark. The real issue is saying, "Here is a potential risk. Is the prob- ability of it happening 25 percent or 85 percent? If it's 85 percent, I better do something about it."

Risk assessment tools. Here we get into the application of risk assessment tools. Risk assessment is the process of analyzing project risks to learn more about them, to quantify probabilities when it makes sense, and to help decide what to do about them. We will learn about qualitative and quantitative assessment. Qualitative assessment focuses on describing risks, ranking them, and making sure they are fully understood. Quantitative assessment applies probability

Dernystifying Risk: Using the PMI PMBOK 87

and other analytic tools, such a s decision trees, to pin down the extent of risk and risk impacts.

We will apply some quantitative tools. While risk management is not prima- rily a quantitative exercise, it sometimes helps to quantify t h e risk and its impacts to get a better handle on it.

Risk assessment involves two basic functions: (1) qualitativelrank ordering risks so that you can decide which are the most important to tackle and (2) quan- titative-doing more quantitative analysis to pin down risks so t h a t risk response can be predicated on quantitative measures, such as the probability that something will happen and have the anticipated impact, and so that stake- holders can be assured t h a t risks have been analyzed. I

The goals of risk assessment are a s follows: I

1. To increase the understanding of the project-the more I kndw about risks, the more I know about the project 1

2. To rank-order risks in terms of severity and impact so t h a t I know which to address first ~

3. To serve as the basis for identifying alternative approaches t b response and risk management and integrating risk into the risk management process

4. To offset the normal tendency to be optimistic in project planding-the basic human trait of expecting the best will take over unless you i e i g h it against a risk analysis t h a t forces you to identify impacts and worst cdse, pessimistic scenarios.

Rlsk qualification 1 Risk qualification involves listing risks and using a risk matrix to determine how risks should be categorized and ranked according to their impacks on schedule, quality, cost, and overall success of the project.

Risk quantification I

The tools for risk assessment we will address are: I I

1. Probability. Probability analysis is the process of developink a measure of how likely a risk is to (a) occur and @) create the impacts anticipated. We want to be able to say t h a t not only is this risk liable to happen, but there is a 50 percent probability t h a t it will happen. A 50 percent pkobability t h a t it will happen combined with a 50 percent probability t h a t i f it happens it will have the impact identified, creates real urgency to respohd, as opposed to a risk that has only a 20 percent probability of happening.^

Remember that the initial determination of the probability 'that a risk will occur is typically not very scientific, t h a t is, there is usually no database available to actually calculate probability from a statistical perbpective. Much of risk assessment is based on prior experience and a full detaliling of project tasks and components so t h a t they can be understood. I

88 Chapter Four

TABLE 4.3 Risk MatrixTemplate

Risk item Description of Impact (technical, Severity (high, Rank Contingency plan risk schedule, cost, medium, low) (what is planned

quality) to offset the risk)

2. Sensitivity. Sensitivity analysis involves analyzing how sensitive the proj- ect is to a particular risk, t h a t is, quantifying linkages between a given risk and the "ripple" effect it could have on the project from a schedule, quality, cost, and overall performance perspective.

3. Decision tree. A decision tree helps to describe the flow of project decisions to points where there are tradeoffs based on risk. That is, i t clarifies where you have to make decisions based on a risk and other factors, such a s cost and quality. For instance, a n important leg of a decision tree on planning a project task may be to '%uy or make" a particular component, t h a t is, to con- tract-out or to build in-house. The risk implications are different for each. Thus risk is a part of making t h a t decision.

Rlsk matrlx template

The risk matrix is a very valuable but simple tool to manage the risk "portfolio." Table 4.3 shows a risk matrix template. Chapter 6 contains more examples.

Build a Risk Management and Planning Process

Building a risk management process is largely a "sellingi' challenge, not a tech- nical task. Building support systems for risk management is part of the process by which the organization matures a s a n organization.

Given a project description and ranked list of risks, describe the steps i n the project risk management process and develop a risk response strategy includ- ing avoidance, transference, mitigation, and acceptance, and develop a risk response plan.

This has to do with responding to the risks we have identified with a process and risk response plan. This is where the project manager produces a strategy- a way of addressing the risk identified. For instance, for the software debug process referred to above, I must develop a plan to avoid the risk andlor respond, and it might include alerting the software developer to the risk and getting a direct estimate of his or her view of impacts, a s well a s a n approach to offset- ting the risk-perhaps assigning another developer to the job or putting more effort into debug or even subcontracting out a support function to anticipate debug problems during in-house design.

This covers front-end, company-wide risk management system planning a s well; you not only have to describe a risk management system, but you need to install it into the organization a s a way of doing business. The assumption goes like this: If your company or agency is going to identify and manage risks, it must have the capacity to use the right systems, tools, and formats to do so and it must

Demystifying Risk: Using the $MI PMBOK 89

have a well-defined process as well. So you have to establish a risk planning capacity and process. This new process was added in the most recent version of the PMI's PMBOK to address "getting your company ready" to do good risk management. I n sum, we address organizational capacity a s the ability of the company or agency to develop a company-wide risk managementprocess to help project managers mitigate (offset) project risk and develop and idplement a risk response and communication plan.

Rlsk management plan I

The risk plan does not always need to be documented; it is the thought process t h a t counts.

The risk management plan will include the following sectionA. which will be submitted to the project manager. I

Risk management policies and procedures define the way the company or agency intends all its project managers to approach risk. The combany or agency in effect says to the project manager, "here is the way we want to ensure con- sistent approaches to risk management across the company, and k y o u stay with these guidelines, we will support you even if the project does not produce exactly as planned." I

Here we address the project risk management process. The bdsic steps in the project risk management process, which are mirrored in the structure of our course, are:

Risk response: includes the development of a risk management plan, contin- gency plans, and reflects risk i n the project scheduling and resource assign- ment process I Risk monitoring a n d communication: the step t h a t provides for regular reviews and interchange among key stakeholders and customers on risk, changes in risk, and risk-related developments I

Risk planning: the step t h a t prepares the organization for risk with support systems and defined roles and procedures, setting a high priority on risk management as a n integral part of the project management process

Risk identification: the step t h a t identifies risk and ensures t d a t all risks are "on the table" before more detailed assessment is undertaken'

Here is where the company defines the roles of project mandgers and team members, such a s project engineers or software developers, in defining and con- trolling risk. Since risk assessment is a n analytic process and since risks change over time, the management of risk takes time and effort. So jobs t h a t involve risk management must be defined a s such, and team members must be enabled to charge time to risk management. 1

Risk assessment: the step t h a t assesses risks, analyzes them, risks in terms of probability

and quantifies

Risk scheduling: the practical application of MS Project, PERT analysis.

90 Chapter Four

Work breakdown structure. Remember, a good risk management plan starts with a well-defined project deliverable accomplished through a WBS. The WBS presents the outline of the project deliverable. Thus, if i t is comprehensive and does not omit major components and work packages, it lists the potential sources of risk.

Risk identification

Here is where we address the risk identification process. It starts with a full under- standing of the project and a comprehensive project plan. Risks are identified from the work breakdown structure and baseline schedule. Risks are categorized in terms of technical, technical and equipment processes, quality, organizational, people resources, project management processes, or performance risks.

Tools for risk identification include brainstorming (group thinking out loud), Delphi technique (bringing experts together), interviewing, checklists, assump- tions, and process diagramming techniques. They may also include drawing on lessons learned from similar projects in the organization.

We want the reader to get: (1) a full understanding of how a company or agency equips itself to handle risk in its projects-learning what management must do to build the capacity of the whole organization to control risks and (2) a full understanding of how individual project managers handle the initial step of identifying risks since this first step is so critical. If you miss major risks up- front, handling them downstream i n the project becomes more costly and some- times just doesn't work.

Our objective, then, is to learn how to categorize risks and we will use a risk matrix template to do so. A risk matrix template is a table showing categories of risk down the left column and providing information on each risk across the top. One approach to this information is to list definition, potential impact, probability of impact, response plan, and monitoring plan. Another approach cat- egorizes risks in terms of external unpredictable (like our earlier definition of uncertainty), external predictable, internal nontechnical (I would call this man- a~erialloraanizational). technical. and legal. - , .

-we will go deeper into risk identification, identifying and categorizing risks i n various kinds of ~roiects. This is where vou will see "windows and flags" for iden- - 7 - tifylng risks and getting them "on the screen" early in the project. For instance, in a highway construction project, a f i l e might be that you can always predict t h a t subcontractor concrete finishers represent a major risk (reliability, quality of work) and need to be listed in the risk matrix. If you know you have a major challenge up front-not because it's a particularly difficult task but because its history suggests uncertainty-then use risk management tools to define it and monitor it. This is a risk “flat in that it flags a potential risk simply by its defi- nition. It's also a "window" of opportunity to get on top of t h a t task early.

The success of a risk identification process lies in the initial project work breakdown structure. If you have identified all the necessary work to compete the deliverable in the WBS then risks can be identified by looking a t each risk

Demyaifying Risk: Using the @MI PMBOK 91

and going through the mental exercise of asking, "what could go &-ong and what would happen i f it did?"

The real problem results from not identifying a task in the k BS t h a t later creates real risk exposure-missing a major risk in the initial stages because you missed a n important function or component. If it isn't visiblb early, a major risk can "show up" later. For instance, you may have i d e n t s e d a major software engineering task i n your WBS t h a t isn't t h a t challenging, so ydu assign a low risk to it. But the real risk lies in the availability of a key software engineer to do the work-which you did not identify in the WBS and which later gives you real headaches! 1

Communicate risks I Communicating and reporting on risks is part of communicatin$ and reporting on the project itself. You are not only trying to reduce uncertainty and report accomplishments, but also to alert stakeholders t h a t the project is in a sensi- tive stage of uncertainty.

Given a list of risks, you will need to know how to develop a dlan to commu- nicate those risks to the appropriate project team members and stakeholders, as well a s to management. li This reminds us that it doesn't make much difference what sks you have identified if you haven't communicated with people who have a stitke in the proj- ect and who can help address risks. This requires us to identify those people who have a direct interest in the project outcome and who must commit to the risk management process. These interested parties would include the customer or client, all project team members, support personnel, corporate management, investors, and even the competition. I

The challenge here is to figure out how to present a risk so t h a i people under- stand it and come up with good ideas on how to handle it. Yod don't want to create fear; you want to create commitment and resolve. You also want to focus key people on the right risks, the ones t h a t can create the most problem and opportunity. The 80 to 20 rule says that 80 percent of your risks will not be impor- tant; it's the 20 percent that will be critical that you need to identify and manage.

Monitor and review risks I Keeping up with risk involves equipping your team members a n d suppliers with the tools necessary to monitor risk and the sensitivity to catch risk prob- lems before they occur. It is mostly a n interpersonal process, not: a formal proj- ect review process.

Given a project in which tasks have been mheduled and risks dave been iden- tified and ranked, develop a plan t o monitor and control changes in risks and risk potential a s a n integral part of the project review process. 1 It takes some planning and effort to monitor how risks chang as the project progresses and how those changes affect t h e original risk assessdents and proj- ect outcomes. This is typically done through a project review process where

92 Chapter Four

individual project risks are reviewed as part of the broader review of the whole project. For instance, in our software debug issue, a n upcoming software design review might be scheduled and during the project review prior to t h a t design review a checklist might be constructed to "flag" debug issues.

The other part of the monitoring process is making sure t h a t the team mem- bers closest to the iob are aware of risks and communicate risk information a s - - - - ~ ~~~ the design and development is occurring. They are the most likely to know the extent of change i n a risk assessment and how it will impact the project.

Develop rlsk-based schedules

The risk-based schedule referred to earlier is simply a schedule, which i s "informed" by risk considerations. Durations reflect things that could happen.

Given project risks, you will need to know how to develop a PERT chart for the project showing worst case, best-case, and most likely case schedules, based on risk.

This subject is a special one, focusing on building your skills to use the PERT chart tools in Microsoft Project or equivalent project management s o f t w a r e to identify and weigh worst, best, and most likely cases, and to write notes t h a t will assist i n project reviews and communicate risks through the software.

We are not expecting you to be experts i n the PERT charts, just to know how they are used. If you are going to be a project manager dealing with risks in a project, you will have to know the basics of project management scheduling and PERT analysis.

Risk scheduling. Project schedules serve several purposes:

1. Schedules provide a transition fiom project definition, such a s the WBS, to time and cost, and to interdependency. That is, schedules pin down actual tasks, durations, start and finish dates, and resource assignments, and most importantly, Linkages between tasks. You manage from a schedule, not a WBS.

2. Schedules enable a project manager to lay out the total project impact of a given risk scenario, t h a t is, given a number of complex tasks and interde- pendencies (links), creating different durations a n d resource mixes for selected tasks which involve risk gives the project manager a way to meas- ure schedule impacts.

This is why we have you identify three scenarios using t h e PERT tool i n Microsoft Project, pessimistic, optimistic, and expected, for the five greatest risks in your project. This process helps you see the usefulness of having three sched- ules with different milestone dates and seeing that when you assume an optimistic scenario you may have scheduled a given resource to do the work, but in the pes- simistic scenario that resource is no longer available! Now you find that the worst case impact of one risk has created other risks because it has pushed the sched- ule into a window where the original schedule assumptions will not work.

Demystifying Risk: Using the PMI PMBOK 93

A Note on Microsoft Project PERT and Risk MatrixTerrninology I Microsoft Project uses t h e termspessimistic, expected, and optidistic. Expected usually means the duration you originally estimated without cbncern for risk, although it may not. Optimistic means the risk and impact are low and you think you might be able to "beat" the expected. Pessimistic means t h a t t h e risk and impacts are high and you don't think you will be able to "makk" the expected duration.

In the risk matrix you use the terms high, medium, and l o r fo! risk rankings. I n general, high is over 50 percent probability and high severity;medium is less t h a n 50 percent probability and moderate severity; and low i s less t h a n 10 per- cent probability and low impact.

Table 4.4 compares the terms from your risk matrix and your PERT analysis.

Risk Response I I We will focus on risk response, monitoring, and communication. ~ L r e is where we get to the "meat" of the project risk management proces-the plarhed and sched- uled action that a project manager takes to deal with project risks, the review and monitoring of changes in risks and risk management effectiveness, and the com- munication and interchange between key project participants on risk issues.

By now, you should have a good grasp of what project risk assessdent is all about. "So what?" you say. Well, now we will answer the question, "Once I know what my risks are going to be and what impacts they may have, what do I 80 about it?"

There are four parts of the response process- response, monitor, review, and communicate. I 1. Response. Response involves developing a risk management p ~ a h to address the

risks identified and rank ordered in the project plan. Responsemeans control,

TABLE 4.4 Comparison of Risk Matrlx and PERT Analysis 1 Risk ranking in risk High (risk severity

matrix is high and the probability that it will happen is high)

Microsoft Project Pessimistic terminology (duration reflects

concern based on the probability that risk will occur and will have major adverse impacts and slip the schedule)

Medium (risk is moderate and impact not so severe)

Expected (original estimate of duration without considering risk, unless there is a reason to change it)

Low (risk is low and impact low even if it occurs)

Optilh~stic (duration reflects low rlsk and therefore "hope" that the risks can be controlled by contingency plans a n d t h e task can be completed qucker than expected)

94 Chapter Four

e.g., assuring that there is a contingency plan for each risk t h a t might be trig- gered by a change in a key indicator, such a s meeting a n intermediate mile- stone in the design of a piece of equipment. This is the key part of project risk management-the development of a risk management plan that provides you a prepared response to anticipated risks, tailored to that risk and its impacts. This is why we have you develop a risk management plan as part of the course.

2. Monitor. Monitoring involves identifying indicators t h a t "flag" t h a t a given risk may be occurring and t h a t the probability of a given risk has changed. For instance, if the risk involves a technology performance issue (a given piece of equipment must perform to a standard) then the earliest indicator that the equipment is not performing should be identified through a monitoring process. I n this case, a n engineer or contractor is requested to submit a report on a preliminary "test run" of the equipment, early enough to head off a major disaster when the equipment fails in use.

3. Review. The project review process involves establishing a n agenda and process for regular reviews. The agenda reflects risks and requires t h a t each review meeting specifically address the risks inherent in a project.

4. Communicate. Communicating risks to the right parties improves the capac- ity to respond to risks and also offsets the tendency to have a n isolated view of risk within the team. Communication involves reporting the results of risk assessment, the risk management plan, and monitoring and review results to key stakeholders including: a. Customer b. Investors c. Management d. Project team e. Contractors

Risk response, monitoring, and communication are integral to the process, not a separate activity. In the real world of project management, the response to risk is played out i n a series of day-to-day decisions a s developments unfold, guided by the risk management plan. Risk response is really a state of readiness, a focus that the project manager has on certain aspects of the project. The focus changes over the course of the project because key risks come in and out of focus. The purpose of risk management planning is to narrow down the critical "things" to keep your eye on and manage during the life cycle of the project.

Risk response factors

The capacity to respond to risk is heavily dependent on the quality of planning and control in the project cycle. Risks that have not been anticipated and contingen- cies that have notbeen-integrated into the schedule will be &lYicult to respond to, regardless of intent. This means that risk response must be timely and embedded into the planning process, beginning with the WBS and schedule. There are sev- eral factors that weigh heavily on the success of risk response (Fig. 4.1).

Demystifying Risk: Using the PMI PMBOK 95

People

Earned value:

Costbenefit

Figure 4.1 Risk response factors.

Earned value. Cost and schedule variance are key inputs to &isk response, particularly root causes. The root causes of schedule slippage and bost escalation a r e typically related to underlying risks t h a t could and shohld have been addressed in the up-front planning process starting with the WBS! Risk planning should uncover potential root causes before t h e final baselide schedule is completed. Earned value can be seen a s an indicator t h a t a risk has not been attended to; a late wake-up call t h a t is often difficult t o address1

Risk intensity. Despite quantitative tools for calculating proLabilities and intensities, there is considerable personal and professional judgment involved i n aligning a risk response with the intensity and impact of t h a t risk. I n the end, a project manager must make the decision on t h e expected value of a given decision a t a key project milestone or crossroad. Intensity is best dimensioned . - - by those closest to the point of impact (e.g., customers, project t&am members, functional and technical professionals), so the most accurate source! for evaluating intensity is t o t a p t h e j;dgrnent of t h e key stakeholders. I People. As we have pointed out earlier, risk management is essedtially a people issue, not a technical or analytic issue. Project managers must hepend on t h e awareness and judgment of those closest t o t h e work to assess dnd respond to risk. The key is placing responsibility for risk identification and rbsponse in the hands of those planning and designing the work early enough to incorporate all worst case scenarios. Key stakeholders will respond to a culture that encourages and enables early contingency planning by anticipating risks and integrating them into project schedules and budgets. I n the absence of such a culture, the organization can quickly deteriorate into finger pointing when nanticipated risks impact a project schedule or budget. P

96 Chapter Four

Technology. Technology creates risk simply because projects often involve designing a n d testing new technologies or integrating new systems. New systems and products are by definition risky and involve key decision points based on risk. But these risks should be addressed in the design and testing process itself. I n other words, technology risk is integrated into every step of t h e design process. For instance, i n t h e development of a new electronic instrument, the project team faces the risk t h a t the instrument will fail i n tough industrial applications. That risk is translated into a design function to test the instrument in those conditions, thus responding to t h e risk a t the point of design.

Customer. The customer is a major factor in responding to risk since it is the customer who will likely foot t h e bill for response and pay t h e price for unanticipated risk impacts. Thus the customer must be involved in every step, from concept through prototyping and production. The most practical approach here is to report to the customer on the risks in a project specifically i n terms of customer expectations. That involves understanding customer expectations and reporting on progress against those expectations regularly.

Processes. Often, a key process will determine how a risk is addressed and how risk response is managed. For instance, if prototyping is built into a system$ development process, the risk of customer rejection of the product can be offset early. I t is in defining the process t h a t key risks and responses are designed into the way work is done.

CostlBeneflt. Two kinds of costs occur in risk management-the costs of responding to unanticipated impacts of risk and the costs of planning a n d addressing risk proactively a s p a r t of t h e process. I t is not the cost of risk response t h a t determines next steps as much a s the relationship between costs and benefits, and the timing of the response. "Pay me now or pay me later," might well be the guiding principle. The cost of a given product test in the design process is likely to be much lower than the cost of responding to a product failure on a performance standard t h a t was not tested in design.

Corrective action. Despite the best-laid plans and schedules, project management is largely a process of midstream adjustments and corrections based on the actual dynamics of a project in progress. That means t h a t close monitoring of key project indicators is key to real-time response to actual progress. Corrective action, the process of continually bringing a project into line with its performance objectives, and aiming the process to completion, is facilitated by contingency plans already built into the schedule i n anticipation of risks and uncertainties. Without such plans, corrective actions are often ill conceived in the heat of the crisis and often generate counterintuitive results. What is expected a s a result of a given action not only does not happen, but other things happen i n t h e project as a result, which create new problems.

Demystifying Risk: Using the PMI PMBOK 97

Contract Management I Various kinds of contracts can have substantial impacts on thesuccess of risk management strategies. As shown in Fig. 4.2, the buver and seller risk is asso- ciated with a variety of contract types. Generally, fiked price contracts create risk for the seller, while cost reimbursement contracts create risks for the buver. Time and materials (T&M) contracts fall somewhere in between.

Given project risks and t h e need to contract project work t h a t is a t risk, develop a strategy for using appropriate contract types to reduce andlor share risks with project contractors.

Some of your biggest risks may be encountered i n managing c lo ntractors who are doing some of your project work. Thus it's important to choose the right kind of contract type and process to make sure the contractor shares in the risks of completing the work. The more you can get the contractor to share risks, the more likely t h a t the contractor will do a good job and flag risk$ early. We will explore fxed price, unit price, and cost reimbursable contract types and their impacts on risk management.

In sum, the book takes you through a process, beginning with difinitions, early identification a n d categorizing of risks in your project, moving to assessing those risks, and then building risk planning capacity in the orgahization. Then we cover the process of communicating and reporting on risks t o various stake- holders, and then we cover monitoring and reviewing risks. Next we address scheduling risks and working on pessimistic, optimistic, and expected scenar- ios and then we address how we respond to risk, prepare risk management plans and communicate them. Simply put, the course foUows the risk manage- ment process-risk identification, risk assessment, risk planning, risk report- ing, risk scheduling, and risk response.

When you think about it, the decision to contract out work cdanges t h e risk "equation" since work done in-house does not have the same "leverage" t h a t

High El- Buyers risk

Sellers risk

Types of contracts I

FFP FPIEPA FPI CS CR CPlF CPAF CPFF CPPC

Figure 4.2 Risk and types of contracts.

98 Chapter Four

contracting out provides. First, you can rarely "incentivize" (provide incentives, such a s added compensation) in-house personnel to manage risks successfully on a particular task, while a contract allows you to do so. Second, contracts allow you to document shared risks, t h a t is, to share with the contractor the costs of a particular risk occurring and impacting the project.

Various kinds of contracts have different impacts on contractor performance because the nature of the contract sets the conditions for the work. Contract type can impact financial objectives, contractor involvement, costs, schedule, and quality, as well as customer satisfaction. Here are the four basic contract types and their implications for risk.

Lump Sum Contracts. Lump sum contracts encourage the contractor to cut corners since there is no process for getting more funding. The risk is t h a t if the deliverable is not well defined, the contractor may not produce to the project design. Lump sum puts all the risk on t h e contractor, a n d therefore t h e contractor acts accordingly.

Unit Price Contracts. Unit price is based on paying for each unit. This kind of contract shares risk with the contractor, encouraging the contractor to reduce the cost of volume production.

Target Cost Contracts. Target cost is the ultimate shared-risk contract, since both parties estimate a cost and work together to achieve it, leaving the door open for more funding if the target is not achieved.

Cost Reimbursable Contracts. Cost reimbursement contracts do not share risks very well. The contractor can repeatedly claim more costs based on continued work to refine the deliverable and cover past mistakes. The project manager is left with the basic risk in a cost-tvpe contract. " -

The process of negotiating a contract brings out the risk issues because it is in the interest of both ~ a r t i e s to avoid surprises and anticipate and mitigate risk. Financial and costing considerations become t h e vehicb for sharing risk. I n the process, the contractor attempts to minimize risks by pressing for more clarity in requirements and definition of the deliverable and by negotiating a contract type and price t h a t protects t h e contractor from unforeseen risks. The contracting company or agency attempts to minimize risks by transferring them to the extent feasible to the contractor. The contract relationship helps to clar- ify the implications of risk and how risks can be avoided.

Chapter

Making Risk Policy: A Risk-Based Program Management Manual

The purpose of this chapter is t o provide a n example of a manual t h a t might be useful i n setting the stage for effective risk management.

The purpose of the manual is to describe a risk-based program management system. The term program management describes the planning, scheduling, tracking, a n d delivery of programs and projects through the product devel- opment process. A program is a product line or portfolio a n d a project is a phase of a program. For a product development process, the process typically produces:

1. A product documentation package 2. Aproduct prototype and documentation for a product demonstration

3. An engineering design

Principles embody policy and guidelines for the program management process and risk is to be handled. For instance, i t would be policy that all programs and projects will be planned and managed in a way consistent with these princi- ples. The process is managed by a program manager who is responsible for pro- ducing products t h a t satisfy customer requirements. Customer requirements a r e documented i n a system requirements specification (SRS). Products a r e produced through a product development process, which meets customer requirements. I n collaboration with department managers, program managers follow this manual in planning, scheduling, and tracking programs through the product development cycle and in identifying, assessing, and responding to risk.

The following principles underlie t h e risk-based, program management process.

100 Chapter Five

Meet customer requirements

Arisk-based planning process is customer-driven, striving to meet or exceed cus- tomer requirements and control customer risk. Typically, the customer's tech- nical requirements are embodied in an SRS prepared by the system engineer. The customer's schedule and resource requirements are embodied in a baselined, program schedule prepared by the program manager and approved by the direc- tor of product development. In addition, the program manager maintains close contact with the key product manager or contact point for a program to ensure that customer needs, expectations, risks, and scope changes are addressed and managed through a systematic process.

Follow product development process

Risk is in t h e details, i n the technical process of producing a product or service. The program management process will ensure t h a t products a r e managed through the product development process tailored to particular product require- ments and risks. Program managers use the work breakdown structure (WBS) in that policy a s the basis for scheduling a program with exceptions for special programs, which do not involve the entire certification WBS.

Standard work breakdown structure

The standard WBS for schedules is specified a s follows:

Program. This is the product line incorporating a basic set of features and func- tionality.

Project phase. This is the particular set of features and functionality for a pro- gram, based on particular customer needs and risk tolerance (level of capac- ity to absorb risk).

Stages. These are the generic steps in the product development process, e.g., requirements, detailed design, prototype development, design validation, ver- ification, a n d manufacturing transition, all containing risks and decision options.

Functions. This is the task level within a stage, e.g., mechanical, electrical, and software design within detailed design.

Tasks. This is the operating component level where work is achieved through individual or small team activity a n d where risk is built into the work of people who do the real work.

Teamwork

Program managers and functional managers establish teams to carry out the work with the objective of building a n environment of high-performance team- work and collaboration. Teams address risk a s part of their everyday work.

Making Risk Policy: A Risk-Based Program Management Manual 101

To the extent possible and to avoid risk inherent in bad performance, staff will be assigned tasks that are consistent with their backgrounds and expressed pro- fessional interests. Program teams will be composed of professionals who are suited to the work they are expected to perform. Team staff members will be ori- ented and trained a s necessary to enable them to perform assigned tasks, again to avoid risk.

Define and communicate the scope of work, risks, and assignments clearly

Product requirements and job assignments will be defined and communicated to the program team clearly through t h e program schedule and individual assignments. This is to empower staff to understand how their work contributes to the overall customer requirement and to prepare for work assignments with appropriate training and development.

Collaboration across the organization

Collaboration between the program managers, department managers, and the program team is the essential ingredient to the success of program management. The organization encourages continuous, professional communication a n d information exchange among program team members and department a n d system managers i n a concurrent engineering framework. The objective is to create both individual team member accountability for particular tasks a n d inherent risks and a broad support system to ensure individual success despite risk.

Work will be risk, quality, cost, and schedule driven

Maximum emphasis will be placed on preparing tight program schedules t h a t incorporate all the work necessary to meet requirements on time. Program schedules will be planned and "scrubbed" in a collaborative process that ensures t h a t all necessary work is included a n d all task durations, interdependencies, and resources are tightly planned and estimated. Schedule baselines will be established and work initiated only after schedules have been tightened through this process.

Ensure timely procurement of product components

Program managers pay special attention in early program scheduling to ensure the availability of required product components and test equipment. Hardware - - specifications, p a r t s , t e s t equipment, and supply items will be included in ini- tial program schedules and appropriate lead times established. Risk ~ l a n n i n n - and control a r e integrated $0 the schedule a s well a s contingency plans. Procurement actions will be generated i n a timely way to avoid schedule delavs attributable to lack of components.

102 Chapter Five

Change will be managed

The organization will administer the engineering change notice and configura- tion management processes to ensure that requirements and product component - changes are managed and controlled. A systematic change management process ensures that specifications can be met within schedule and resource constraints.

Progress in reducing risk will be tracked periodically reviewed

Program managers will track program progress, prepare weekly reports, and prepare for weekly program reviews conducted by the director of product devel- opment. Department managers and selected team members will participate in risk tracking and program reviews as appropriate.

Program Management: Roles and Responsibilities

The organizational framework for program management is a collaborative, - - - team-based organization requiring cooperation between program managers and functional deoartment managers. I n t h a t framework, the program manager - - - has responsibility for delivery of the product within quality, schedule, a n d resource requirements. Department management is responsible for supervising staff and maintaining the technical capacity of their departments to support pro- gram management. There is a general awareness of risk issues and daily dis- cussion of potential for overcoming risk.

Program management office

The program management department includes all program managers and the program administratorlplanner. The department is responsible for assuring consistency in the application of this program management guide throughout the product development process. The department tracks performance of the overall program management process.

Within the department, program managers will consult regularly with each other on scheduling and resource plans a n d potential conflicts, and ensure con- - sistent approaches to scheduling details, work breakdown structure, budgeting, and sharing schedule information. On the initiation of new programs, program - managers will consult with each other on potential resource impacts and issues.

Program manager role

The program manager is ultimately responsible for meeting customer require- ments, managing risk, and delivering the program within schedule. The program manager provides leadership to the program team, ensures t h a t the program meets product specifications, delivers the product on time and within resource constraints, and i n general controls the "what and when" of the project. The pro- gram manager produces time-phased schedules for each program, tracks

Making Risk Pollcy: A Risk-Based Program Management Manual 103

progress and anticipates future impact, and ensures linkages with related pro- grams and projects.

The program manager manages programs through all stages of product devel- opment and, along with the systems engineer, ensures t h a t required design reviews are conducted a n d documented, and all actions resolved.

The program manager has the primary responsibility for creating a program plan for each program and a program schedule composed of tasks and mile- stones. The program plan is created with support from the customer, program team members, and department managers. Once the program is underway, the program manager is required to keep t h e program schedule current, track progress, and incorporate changes as required. The program manager uses proj- ect management software to produce and update schedules and resource reports, and is expected to be proficient in t h e use of such software for control and pres- entation purposes.

The program manager has t h e primary responsibility of creating and main- taining a detailed program schedule t h a t meets all program objectives. The schedule must be consistent with the generic WBS, and includes:

Summary tasks and task structure and key milestones t h a t correspond to all major program objectives contained i n t h e program plan.

All product development activities and tasks required to execute a given pro- gram including systems design, detailed design, certification, test equipment, reliability, safety, design reviews, manufacturing, procurement, and test assets.

Tasks detailed to the lowest practical level. Activities and tasks should gen- erally be built four levels down.

Resources assigned to activities and tasks and leveled to reflect a realistic workload.

Departmental manager roles

Department managers for systems engineering, mechanicaYoptica1 design, elec- trical design, software design, and certification are resl~onsible for building and - . - maintaining the resource and technical capacity of their departments to sup- port the product development process. Here are some key functions of depart- ment managers in the program management process:

Assign staff to programs and support assignments

Ensure technical processes and systems are in place to identify and address risk and accomplish programs

Prepare and maintain department schedules for each program, identifying department level assignments

Attend program review meetings and provide advice and support to program managers

104 Chapter Five

Program team member roles

Risk management starts with people and how they approach their jobs. Each program team member is responsible for understanding his or her individual tasks and inherent risks, and for general support to overall team performance. Team members are accountable for keeping technically proficient and per- forming their assigned tasks i n a timely way, consistent with the schedule. Team members are responsible for communicating with their program managers and functional managers on issues or problems encountered i n their team tasks. They collaborate with each other and the program manager, promptly attend program team meetings, and report to their program managers and department managers on schedule and technical issues, respectively.

Role of the program adrninistratorlplanner in the PMO

The role of the program planner i n t h e program management office (PMO) is to promote consistent best practice i n program and risk management. The administratorlplanner provides administrative support to program managers and departments with scheduling, resource planning, and reporting service, and pre- pares analyses of resource impacts to identify and resolve conflicts. In addition, the program adrninistratorlplanner prepares program management guidelines, provides training, and develops program evaluation metrics, and maintains indi- vidual program schedules for the director of product development andlor program managers.

Program Planning, Scheduling, and Resource Management

The product development process is primarily schedule-driven. Effective and dis- ciplined scheduling and tracking of work and resources is directly related to cus- tomer satisfaction since customer expectations always include timely delivery as a key priority.

The scheduling process begins with a program plan t h a t describes the over- all program in general terms. I t is a reference source for all documents which impact on the program. The program plan includes:

Program overview

Program strategy

Customer identification

Program objectives

Risk management

Measures of program success

= Program scope and requirements (Summary) Program management, including team roles, schedule, resource plan, and milestones, program review, and risk management

Program development and review process

Reference documents

Making Risk Policy: A Rlsk-Based Pmgram ~anagement Manual 105

Once a program plan is approved, good scheduling is a t the hleart of the pro- gram management process. Program schedules created i n Microsoft Project, linked to a central resource pool tile, and posted on the network conktitute the basis for program development, tracking, and review. A good scheduling process pro- vides adequate time to ensure that the work breakdown is comprehensive and responds to the customer requirement and product functionality, that scheduled task durations and predecessors are as accurate as possible, that dey linkages are made, and that people and resources, once assigned, understand interdependen- cies and are available and committed to the program when they are needed.

Before a schedule is drawn up, the work itself must be clearly defined in a WBS. Thus scheduling provides for a n SRS (in t h e requirements stage), which defines the what a n d why of t h e program or product (e.g., a dekcription of the product and its functionality and its inherent risks). The scheduling process helps to flesh out requirements a s individual features are prdgrammed into various iterations of the schedule, leading to the baseline.

Once the work scope is understood and signed off by the cus t! omer, schedul- ing defines when a n d how the work is going to be done, key interdependencies, when the deliverable will be produced, and who will do the work. The schedul- ing process assigns staff to scheduled work and commits staff 'to do the work within the time constraints in the schedule. Scheduling is a resburce planning tool providing a high degree of discipline to the assignment of dtaff since each task is specifically described and time-constrained. Thus scheduling requires t h a t those who actually going to do the work-those who are beihg scheduled- also be part of the process. Since scheduling "signs up" and mobilizes staff to fit new work into their schedules, which typically include other program work, it requires t h a t there be a clear picture of staff availability (e.g., the current resource picture). New program schedules are phased-in based on the time- lines and resource impacts of current work.

The integrity of a schedule is only as good as the description o 1 the work, the processes in place to do the work, a good picture of interdependencies and resource availability, and the commitment of the people who are slated to do the work. This process becomes more complicated when there are several programs or projects operating a t the same time-a multiproject environment-wheie staff time is always limited by previous cornmitme&.s driven by earlier or concurrent projects, and by anticipated and unplanned work. In the end it is the quality of the plan- ning and communication process and the capacity, commitment, and motivation of the individuals actually doing the work t h a t drives a successful schedule.

Project management software makes i t easier to accomplish the scheduling process by capturing important planning and scheduling data hnd making it available to a wide cross section of people, and facilitating presentations and progress tracking. The following process assumes access and proficiency in Microsoft Project a s the support software a s a network-based communication tool.

planning a n d

Scheduling tailors the product development process to real time and available resources, and flags conflicts and new resource needs. Schedulingprovides time- phased and linked tasks and milestones, assigns resources to complete the work,

106 Chapter Five

and supports the monitoring of performance, resource allocations, budget, and earned value.

Figure 5.1 is a n example of a baselined program schedule (Gantt chart). Note the inserted column for percent complete, added through the insert toolbar, then column. Note t h a t predecessor for ID 88 is 87FF+1, entered through the task information dialogue box. 87FF+1 indicates t h a t the task has a finish-to-finish relationship with ID 87, plus one day.

Figure 5.2 is the resource usage view of that same schedule. The program man- ager and the project team can see from this view what resources are assigned to the project and the level of assignment in terms of hours, against a calendar.

Here are indications of risk bottlenecks in how resources are shared between projects. Applying the theory of constraints and critical chain management, pro- gram managers see project bottlenecks early and focus on managing scarce resources, and use project buffers, to control key people or equipment t h a t could later delay project delivery.

Figure 5.3 is the tracking Gantt view of the schedule after it has been updated. Note that the tracking view includes a percent complete column with actual com- pletion percentages.

Figure 5.1 Baselined program schedule.

Making Risk Policy: A Risk-Based Program Management Manual 107

Figure 5.2 The resource usage view. I I

Figure 5.4 is the tracking Gantt with bar chart, which shows Actual progress (black bar) within the planned duration (blue bar).

Five-step scheduling process I

The program manager generates the scheduling process, the dekartment man- ager serves a s a resource on product functionality and department resources and ensures t h a t the technical procedures are in place to complete t h e work. This process works effectively only with a constant dialogue betwee program man- agers, department managers, system engineers, and the team.

The scheduling process for product development involves f i e 1 steps culmi- nating in the product deliverable. The general sequence of work is first to define the work from customer requirements; structure the work into anoutline or work breakdown structure; define a n overall, top-level task structure and work flow; then identify tasks, durations, risks, and interdependencies, and then develop

108 Chapter Five

Figure 5.3 Tracking Gantt chart.

department staffing plans to accomplish the work, estimate the costs, and kick- off, monitor, and close-out the program.

Table 5.1 outlines the five functions-a description of the function, and the roles of the program manager, department manager, director of product devel- opment, and project team.

Schedule control

44

45

Mon 9/11/00

mu 9114100 Tue lMB100

45

46

47

Product specification changes t h a t impact schedules are approved by the pro- gram manager and departments involved. The program manager initiates two kinds of changes-schedule updates based on tracking information, such a s per- cent complete, and more fundamental changes from customer inputs, design change notices, and other more substantial changes in the scope of work. Affected department managers a n d the appropriate program manager must agree to all

0%

0%

27%

EdQ

8

1 day

3 days

235 days

Verification and test

integrate four CCAs In chassis

Sotiware requlrernents docurnentatlon

Mon M l m D

Tue 9/12/00

Tue 2/11W

Making Risk Policy: A Risk-Based Program Management Manual 109

I Desrnond Michael

I Desmond Michar I

Figure 5.4 Tracking Gantt chart with bars.

schedule changes. After the baseline schedule is saved, the director of product development must approve any slips or changes in scheduled milestones on the critical path and review all risks in monthly program reviews.

Baselining the schedule

After a preliminary schedule is prepared and analyzed, cross program resource conflicts resolved, and successful delivery of the product within the schedule determined to be feasible by the program manager, the schedule is baselined. Establishing the baseline schedule is a significant action in the program man- agement process, signifying the official kickoff of the work and indicating a

110 Chapter Five

TABLE 5.1 The Scheduling Process

Director of product

Scheduling Description of Program Department development Project function function manager role manager role role team role

1. Develop top- level work breakdown in Microsaft Project or Excel

2. Flesh out schedule, establishing task and subtasks, durations, risks, interdependency, and constraints

3. Assign resources to schedule, estimating hourly requirements for each task

4. Establish risk- based schedule baseline, c o n f m i n g program 'Wickoff'

Develop top- level program structure consistent with product development process

Identify tasks and risks; prepare risk matrix, prepare preliminary schedule

Establishes resource needs to support schedule; assigns work from scheduled tasks to staff; confirms resource availability

Save schedule a s '%aseline3' in Microsoft Project software, placing file i n central directory on network

Lead role, working with systems engineer and department management

Identify risks

Lead role with inputs from department staff; works to fmd ways to accelerate work in concurrent tasks when feasible and address risks

Works with departments to identify program team and meet other resource requirements

Takes lead to kickoff program, handing out hardcopy of baseline schedule a t meeting, along with resource usage table that defines resource commitments

Participates in developing top- level structure

Confirm risks

Helps define how scheduled work and inherent risks can take advantage of prior work, supports concurrency in work schedules

Lead role, department managers are responsible for staffing program with competent, adequately trained personnel and providing adequate resources

Participates in kickoff meeting, supports resource usage plan

Review, comment, approval

Review, comment, approval

Review, comment

Approval of baseline before i t is saved a s such

Helps program manager develop structure, a s requested

Helps department manager find efficient ways to work in parallel

Participates with department manager and program manager in fitting assignments into current and projected workload

Review, comment

Making Risk Policy: A Risk-Based Program Management Manual 111

TABLE 5.1 The Scheduling Process (Continued)

Director of product

Scheduling Description of Program Department development Project function function manager role manager role role team role

5. Monitor Enter actual Gets percent Reviews actual Reviews Recommends performance data on percent complete and and planned actual and corrective against complete other BCWP, and planned action to offset baseline, andlor cost performance makes schedule report on data from time- information recommenda- slippage performance, sheet project from project tions variances, and codes; revises team members; cost to start and finish report weekly complete, dates as to director of manage appropriate product change development

strong commitment to the schedule and resource plan. The baseline is the point of departure for monitoring and tracking process. When a project is baselined, the project schedule is complete. Here are some rules of thumb for baselining:

1. The purpose is to get to a baseline schedule t h a t captures all the work to be done. This includes key documentation and procurement tasks. The baseline schedule does not change unless the basic scope changes. Once agreement is reached, the program manager confirms the baseline by saving it and making it available on the network as the baseline. There is no uncertainty where the baseline is and how to access it.

2. The baseline schedule is the agreed-upon, scrubbed schedule for the pro- gram, linked to the resource pool. The baseline shows all interdependencies, linkages, and resource requirements, includes all tasks necessary to get the work done, and shows impacts on parallel programs and resources. All pro- curements and test equipment are covered in the schedule.

3. The baseline schedule is resource-leveled-the schedule can be implemented with current, available resources. Assigned staff are aware of the commit- ments and have "signed-on" to complete their tasks to meet the schedule milestones.

4. Getting to the schedule baseline involves collaboration between the program manager and all departments a n d staff involved i n planning and imple- menting the schedule. A baseline meeting is held to arrive a t a final agree- ment on schedule and resources committed before the baseline is saved to the network. The program manager facilitates the meeting, and all department managers attend and come prepared to commit their resources to the final, agreed upon baseline schedule.

5. The final review of the schedule a t the baseline meeting involves reviewing all stages and tasks, linkages, and resources assigned line-by-line.

112 Chapter Five

6. The baseline schedule is monitored weekly, with actual percent complete data and changes in s t a r t and finish dates entered weekly and reported a t program review.

7. Risk contingencies from the risk matrix data are plugged into the schedule and durations estimated along with other tasks. A risk-based schedule is prepared.

Basellne procedures

The program manager uses Microsoft's Planning Wizard (or Tools, Tracking, Save Baseline) to set a baseline schedule. At the same time t h a t a baseline is created, a backup copy of the project file is created as a permanent archive of the original schedule for later reference and comparison to actuals.

Sometimes it is necessary to create a baseline schedule before t h e complete schedule and task structure is determined, simply to serve a s a basis for cap- turing actual progress. This is because some work t h a t is clearly on t h e critical path, such as mechanical design or long lead-time procurement, must begin immediately to meet key milestones, sometimes before all the details of a sched- ule are worked out. To accommodate to this, when the final schedule is completed the baseline can be updated by saving a n "interim plan." The interim plan saves particular start and finish date changes t h a t are made after a baseline h a s been saved. Interim changes can be made for the entire project or for selected tasks.

Managing schedules on the network

The basic objectives of network management of program schedules are to: (1) enable the program management department to control schedule updates and schedule versions and (2) provide department managers and staff with a n easy way to review and provide input to schedules and schedule assumptions. Here are the steps involved:

1. All schedules will be housed on the server in individual program manager folders.

2. The central resource pool file will be housed in the schedule folder. Archive versions of schedules will be housed i n a separate folder.

3. The program management department will control access to schedule files. The director of product development and the program management depart- ment (program managers and program administratorlplanner) will have "write" access to the schedules. Department managers, systems engineers, and team staff and other users will have "read" access to program schedules.

4. The program management department is responsible for maintaining and updating program schedules on the network. Once the director of product development, the program manager, and department managers agree on a proposed schedule andlor update, t h e schedule will be linked to the resource

Making Risk Policy: A Risk-Eased Program Management Manual 113

file and resource conflicts will be identified and resolved. The program man- ager will then save the schedule a s a baseline schedule. Once baselined, the schedule will be placed i n a designated directory. The baseline schedule will be t h e only version of t h a t schedule housed on the network (except for archives) and will serve as the source of "planned versus actual" tracking information.

Resource planning and control

Scheduling is essentially the process of planning for use of personnel and equip- ment resources. Good program management requires t h a t there be a process to plan for the acquisition of future resources, to allocate current and projected resources to schedules, and to make shifts in resource management as required. The process provides for a central resource pool to identify impacts of project schedules and ensure the efficient utilization of the workforce. The resource pool information on the network is shared with management staff and all team members to allow each team member to evaluate the scheduled work assigned and to provide guidance on task definition, durations, start and finish dates, and interdependencies.

While work actually done on a project is tracked automatically by Project when percent complete d a t a a r e entered, t h e program management a n d finance departments collect actual work done from time sheets to gain a more accurate assessment of actual work. Actual work is tracked from time sheets, which collect hours of work against the project account-numbering scheme. The program manager is responsible for establishing t h e account numbers for charges to the project and for assuring t h a t time sheets a r e kept for all work on the project. The project administratorlplanner is responsible for working with t h e finance department to collect data each week and enter these into appropriate schedules.

Tracklng and program review

The director of product development will hold weekly program-review meetings to discuss broad program issues; detailed technical, resource, and schedule problems; project team ~erformance; and risk mitigation. Program managers are responsible for preparing presentations for these reviews and identifying key agenda items. Department managers and team members attend program review meetings a s appropriate.

The program manager tracks the progress of the program on an ongoing basis and updates the schedule on a weekly basis. The program plan is to be updated as changes i n plans warrant. Program managers hold periodic reviews with the - - - program team in preparation for reporting and to support task assignments and feedback, either a s a single meeting with all functions represented, or a s a - series of meetings with major functional areas represented a t each meeting. Program managers report progress for their portions of the weekly report, due to the director of product development.

114 Chapter Five

Schedule update procedures

Using Microsoft Project, program managers can track and update actual per- formance information including percent complete for each task, change in task start date, change i n task finish date, task duration, task cost, and total work once a project is underway.

1. Percent complete on a task. At the very minimum, the program manager updates percent complete for each task on which work h a s been done during t h e past week. These data are gathered from t h e appropriate project team members based on their assessment of the percentage of work actually done compared to the baseline work definition. Program managers are responsi- ble for briefing team members on the importance of accurate assessments of percent complete and how their estimates are used to update project per- formance. When percent complete is entered, Project changes the actual start date to match the scheduled start date and calculates the actual duration and remaining duration.

2. Add a new task to a baseline or interim plan.

3. Enter actual duration of a task.

4. Enter actual start and finish dates for a task.

5. Enter actual work (e.g., hours) completed on each task (from time sheets).

6. Reschedule incomplete work.

Analyzing variance

The program manager uses tracking data to determine how the actual progress of the scheduled work compares to t h e original baseline schedule, but more importantly to determine impacts of actual work done on t h e overall schedule and on critical milestones.

Variances t h a t are tracked include:

1. Tasks that are starting or finishing late. Along with updating the task start and finish dates through the ToolsPl'racking command, the program manager identifies impacts of t h e change on linked tasks.

2. Tasks that require more or less work than scheduled. Changed durations andlor additional resources can be assigned to tasks t h a t are running late. Project will shift durations and start and finish dates automatically when resource units are changed.

3. Tasks that areprogressing more slowly thanplanned. Tasks on the critical path that are progressing more slowly than planned must be addressed either through redefining t h e task to stay within the schedule or adding resources. Tasks off the critical path provide the program manager with some slack time or "safety buffer" before they go onto the critical path because of delays.

4. Resources that aren't working for scheduled hours. If there are major vari- ances i n actual work versus planned work, this can have implications for

Making Risk Policy: A Risk-Based Program Management Manual 115

several projects. Based on actual hours worked, program managers reassign resources and link to the resource pool to broaden impacts and conflicts. Project's resource leveling capability can be used to address resource conflicts a s well.

5. Earned value. Earned value is an indicator of cost and schedule variance. I t is important to track both, whether the actual work is on schedule a n d whether the actual resources expended on the work are consistent with what it should have cost to get the work done based on the baseline budget. I n other words, earned value tracks whether the work accomplished actually cost what i t should have cost, given the original budget. Reports on earned value show schedule variance and cost variance.

6. Corrective action. The real issue in variance analysis and earned value is what corrective action the program manager takes to put a program, which is showing substantial schedule variance, back on schedule. Program man- agers are responsible for alerting the team to these variances, reporting them in program review, and coming up with corrective actions. Some corrective actions include:

Making sure there is no scope creep, t h a t is, the work the team is doing is not on the system requirements specification Implement risk contingency plans Change task dependencies and linkages Assign overtime work Hire or assign additional resources Decrease amount of work necessary to do a task Reassign resources Delay selected tasks Change working hours

I n support of tracking and program review, the program administrator1 planner:

Serves as a resource for Microsoft Project procedures and training

At the request of a program manager, tracks progress against the schedule and anticipates future schedule problems

Flags current and new issues for the week from current schedules

Distributes assignments i n the central resource pool to project team staff and gathers feedback

Identifies conflicts and facilitates resolution

Program closeout and lessons learned

Each program manager meets with the program team a t the end of a program to go over the project, identify uncompleted documentation or other tasks, and to identify lessons learned. Lessons learned are captured and reported back to

11 6 Chapter Five

the director of product development and the program administratortplanner for follow-up action.

Defining the Program Management Process and Risk

It is important to describe program manager responsibilities, especially in risk planning and control.

Responslblllties

I t is the responsibility of the director of product development to provide lead- ership and direction to the program management department and department managers i n carrying out this policy. I t is the responsibility of the program management department to carry out this policy i n collaboration with depart- ment managers.

The program manager (PM) is responsible for all aspects of a programlproject including cost, schedule, and technical performance. He or she has the respon- sibility for planning, scheduling, tracking, and coordination of a product or series of products and is responsible for maintaining the program management data (schedules, plans, action items, and the like) and ensuring t h a t all tech- nical data are updated a s the design and plans change.

The PM manages programs through all stages of product development and along with t h e systems engineer ensures t h a t development design a n d risk reviews are conducted and documented and all actions are resolved.

The program manager:

Defines clear objectives for each respective program and ensures t h a t all pro- gram personnel are informed a s to these objectives

Establishes a program plan that meets all the objectives identified for a given project

Creates a detailed schedule, in conjunction with team members and depart- ment managers, t h a t meets all program objectives

Provides direction to all team members and anylall departments for the pur- pose of meeting program objectives

Tracks progress of a project or series of projects

Reports progress against the plan and schedule to management

Identifies and resolves problems associated with the programjproject

Identifies and mitigates developmental risks

Identifies all hardware needs for each program and ensures t h a t these are included in forecast management plans

Serves a s the customer a s the primary point of contact (POC) for any hard- ware returns.

Making Risk Policy: A Rlsk-Based Program Management Manual 117

Process

The following sections describe the requirements for program management.

Program coordination

The PM is responsible for t h e overall management a n d coordination of t h e programlproject during each stage of development. I n order to accomplish this the PM is required to conduct periodic project review meetings with the program team (including design, certification manufacturing, and procurement person- nel) to ensure a unified and informed effort. The PM is responsible for ensur- ing t h a t corporate management approves any change i n requirements. As program requirements change, t h e PM ensures t h a t the program plan and schedule and other applicable program data are kept current and distributed.

From initiation of program activities through completion of the product the PM ensures t h a t all program requirements are identified, implemented and ver- ified, all changes are tracked and incorporated, and all data artifacts are pro- duced a n d maintained through all stages of the product development and production. Along with the engineering organization the PM is responsible for determining the proper effectivity for any design change to products t h a t are in either the product development or production stage.

In the event of issues and resource conflicts t h a t cannot be resolved by the program manager and department managers, the program manager is respon- sible for raising them t o the level of the director of product development for prob- lem resolution and decision.

Program plan

The program manager has the primary responsibility for creating a program plan and schedule of major milestones t h a t identify all program objectives for a given project or series of projects. The program plan will be created based on inputs h o m the program team members and functional managers. The PM is required to keep the program plan current and incorporate changes a s required. The program plan must include, a s a minimum:

Overview of customer requirements, program scope, and objectives

Identification of major tasks, risks, and schedule milestones

Basis of program (new development, modlfy existing product, and the like) and strategy to meet objectives (e.g., qualification by similarity or perform qual- ification testing)

Identification of quantity of units needed for development activities and their uses (how many test assets are needed and why)

Identification of test equipment and components needed for the program (spe- cial test software, special test sets, fixtures, jigs, cables, and the like)

Identification of any special tests required for the program

118 Chapter Five

Procurement requirements for development efforts

Manufacturing requirements for development efforts

Outside test facilities needed

Outside integration (AIC, customer lab, and t h e like)

Estimate of ODC required for the project including materials for test assets, test equipment, outside facilities, travel and any other pertinent costs

Risk assessment and risk mitigation plans

Program schedule

The PM has the primary responsibility for creating and maintaining a detailed program schedule that meets all program objectives. The schedule must contain, a s a minimum:

Tasks and milestones t h a t correspond to all major program objectives and milestones contained in the program plan

All tasks required to execute a given program including systems design, detailed design, certification, test equipment, reliability, safety, design reviews, manufacturing, procurement, and test assets

Tasks detailed to the lowest practical level. Tasks should generally be identi- fiable to a single resource

Resources assigned to tasks and leveled reflect a realistic workload

Identification of manpower requirements for the program

The PM department is responsible for reviewing the resource allocations of all promam schedules and anticipating resource conflicts and problems. This is - - accomplished by assessing each proposed program schedule in terms of its impact on current schedule resource commitments and recommending solutions.

I t is the PM's responsibility to identify and present to the respective depart- ment manager(s) any schedule andlor resource conflicts t h a t prevent the pro- gram from meeting its objectiveslgoals. If the conflict cannot be resolved with the department manager without impacting these objectiveslgoals, the PM shall present the c o d i c t ( s ) to the director of product development for direction. If it is deemed t h a t t h e conflict still cannot be resolved without impacting t h e pro- gram objectiveslgoals, it is the PM's responsibility to communicate the problem and impact back to the customer.

Program baseline and kickoff

When effort on a new projectlprogram or phase is initiated, the PM is required to convene a kickoff meeting for the work being initiated. The kickoff meeting should include department staff and product development, manufacturing, quality, and purchasing personnel, a s a minimum. The purpose of the kickoff

Making Risk Policy: A Risk-Based Program Management Manual 119

meeting is to present the program plan and schedule and formally initiate pro- gram activity.

Program tracking and reporting

The director of product development holds weekly program review meetings to discuss broad program issues. detailed technical. resource. and schedule rob- . - lems, project team performance, and risks. Program managers are responsible for preparing for these reviews and anticipating key agenda items.

The PM is required to track the progress of the program on a n ongoing basis and update the program schedule on a weekly basis. The program plan is to be updated a s changes in plans warrant. Program managers are required to hold periodic reviews with the program team, either a s a single meeting with all func- tions represented or a s a series of meetings with major functional areas repre- sented a t each meeting.

Problems t h a t significantly impact cost, schedule, or product performance must be identified, investigated, and reported to management so t h a t decisions can be made on a fully informed and timely basis. As part of the program track- ing and reporting, i t is the program manager's responsibility to identify those problem areas and to assume responsibility for resolving them.

Chapter

Risk Matrix Samples

This chapter deals with forms and templates for risk matrix analysis.

Steps in Preparing a Risk Matrix

Figure 6.1 diagrams the steps for preparing a risk matrix.

Step 1: Identify tasks with risk. The overall project risk i s the sum of t h e individual risks associated with product development plus the risk associated with the market for t h e product. I n other words, the risks associated with producing the product to specification is different from the risk associated with its market performance. Thus both risks must be incorporated into the risk identification process. The first risk-the project market risk-is identified i n business planning and project selection for the company's portfolio. The second risk-the product performance risk-is identified as the total impact of all the task risks associated with its design and production. It is the second performance risk that is identified i n this step, task by task. The way this is done involves the work breakdown structure (WBS). Each level and tasWcomponent of the WBS is reviewed and ranked in terms of potential risks and then all risks are racked up for t h e risk matrix exercise. Some risks will disappear when intensities are dimensioned; others will be ranked high and addressed with contingency planning.

Step 2: Describe risk. The description of the risk is a statement t h a t covers what could go wrong with the task. For instance, if the task is product design, the risk could well be the potential for the design to be unworkable when i t comes to prototyping and production. I n other words, the product cannot be reproduced.

Step 3: Determine impact. The impact of the risk is the change that would occur in key project indicators when such a risk occurs. For instance, the impact of a

122 Chapter Slx

From WBS and interviews,

identify project riskltasks

with inherent

Step 6: Identify

root causes for each

risk

Describe the risk in

detail-what is apt to happen

Step 7: Prepare

wntigency plan for

high risks 1

Step 3: Determine impact on schedule,

cost, quality, customer

satisfaction

Step 8: Estimate schedule

impacts using MS Project

PERT analysis

Figure 6.1 Steps in preparing a risk matrix.

Step 4: Estimate the chance that the risk will

happen; what is the

probability?

Step 9: Incorporate all contingencies into schedule;

establish buffers

Step 5: Rank risks in

terms of severity-

overall how severe is this

risk?

Step 10: Identify

triggers for applying

contingency buffers

design problem would be delayed schedule, increased cost, loss of customer support, and the business risk associated with a failed project.

Step 4: Estimate chancelprobability of risk event. The estimation of risk involves ranking a risk i n terms of 25, 50, or 75 percent chance of occurrence. Going further with quantification of risk is usually ineffective for most projects because t h e margin of error in such calculations far outweighs t h e benefits of going through the mathematics of probability. Project managers are urged to rely on key stakeholder views of risk rankings and past history of similar projects.

Step 5: Rank risk by severity. Here t h e risk is ranked i n terms of severity. Although a risk may have a high level of probability, its severity may be minimal. Thus the cost of contingency is low. On the other hand, a low-probability risk may have a very high severity, e.g., the chance t h a t a key, sole source supplier would go out of business may be low, but the impact would be severe, were it to happen.

Step 6: Identify mot causes. Here is the analytic exercise t h a t can actually help manage risks. This involves identifying root causes of anticipated risks and incorporating response to root causes in schedules and task definitions. For instance, if a design flaw is apt to be created by new software then the root c a u s e t h e lack of good software suited to the design task-must be addressed with a contingency.

Risk Matrix Samples 123

Step 7: Prepare contingency plan. A contingency plan is a schedulable task t h a t addresses the likelihood that a linked task will not work. Such a plan is designed to correct a n event or action t h a t delays the schedule or impacts the quality of the work. For instance, a contingency for a failed software integration task might be the outsourcing of a parallel activity to complete integration with outside resources.

Step 8: Estimate schedule impacts uslng MS Project software. Here the project manager applies the theory of constraints. When a predictable resource or other bottleneck is identified in the planning process, which is created by risk, t h e project manager identifies t h e worst case (pessimistic) schedule impact using MS Project PERT analysis and establishes a buffer schedule for t h a t contingency.

Step 9: Incorporate risk In schedules and establish buffers. The new pessimistic, risk-based schedule is not baselined into the project, but a buffer of time equal to the difference between the "expected" and "pessimistic" durations is withheld by the project manager for later use. The project manager will "dole out" these time buffers a s needed and triggered by a risk event.

Step 10: Identify triggers for applying buffers. I t is important to identify what events or indicators will trigger a buffer action based on risk. Sometimes the project team will see symptoms first and trigger action; sometimes the risk itself occurs and triggers a buffer. Anticipating how decisions will be made helps to avoid last minute "crisis management" t h a t inevitably leads to further problems.

Here are some examples of risk matrices. Note that the Risk Matrix in Table 6.1 addresses a systems development proj-

ect. Note also t h a t the contingency plan for the "systems not compatible" risk is "testing the system by simulation and i n integration." This is a good exam- ple of a contingency action t h a t would be placed directly into t h e project base- line schedule. This way the contingency is embedded into t h e project schedule to offset the potential risk.

Summing Up: Risk Matrix Examples

These examples are illustrative of t h e application of t h e risk matrix tool to risk management. The key point here is t h a t each contingency action is not simply "noted." I t is embedded into the schedule as a normal task in the baseline sched- ule. Arisk matrix is not designed to establish another list of things to do; its pur- pose is t o help plan a n d schedule t h e project so t h a t all contingencies a r e embedded into the project core.

124 Chapter Six

TABLE 6.1 Sample Risk Matrix 1: Systems Development Project

Impact (technical,

Description of schedule, Severity (high, Contingency Risk items risks cost, quality) medium, low) plan Ranking

Testing Critical function Technical High Formal testing 5 - needed by new system may be overlooked if not tested properly.

plan Test specification

Test cases Testing schedule

Method to log test results

Systems not Not ensuring Technical High Test compatibility 5 compatible the new in simulation

program will and during be compatible integration. with the old. If not, a n entire new system will be needed.

Network Network goes Technical Medium downtime down while

implementing new system.

Lack of Not enough Quality Medium information research was

done during the planning and analysis phases.

Termination, if ' Project termina- Costlquality Low applicable tion needs to

be done early a s not to lose money and time.

Document Research Costlquality Low review documents

should be reviewed early on to adjust items to terminate in early stage.

Be prepared for 3 downtime with slack time available.

Have the project 3 well researched before i t is approved by upper management.

Enough research 1 should have been done to terminate the project before it got to far.

Management to 1 review all documents for continuation permission.

Risk Matrix Samples 125

TABLE 6.1 Sample Risk Matrix 1: Systems Development ProJect (Continued)

Impact (technical,

Description of schedule, Severity (high, Contingency Risk items risks cost, quality) medium, low) plan Ranking

Review data Review data Quality Low To be done by 1 after approval management has been given to make sure the data a r e correct.

The approach Quality Low Management to 2 toward the review appro- project has to ach plan be acceptable. during research.

Table 6.2 shows a risk matrix on a hiring project.

TABLE 6.2 Sample Risk Matrix 2: Hiring Project

Impact (technical,

Description of schedule, Severity wigh. Contingency Risk items risks cost, quality) medium, low) plan Ranking

Survey Applicants may This risk impacts Medium A very thorough 1 not score a s cost because of first interview recommended the cost of the will weed out on the perso- survey, and most people nality profile also impacts who may not and then are schedule receive a s not eligible to because it recommended be hired. finds more on the Reid

applicants survey. that can "pass" the survey.

Unqualified Applicants that This risk impacts High The best way to 2 applicants apply for jobs the quality of ensure a

may not have the staff you qualified the desirable end up with a t applicant pool qualifications. store opening. is to engage

i n active recruiting. I will actively recruit from other Lowe's locations and from competing retailers in the area.

(Continued)

126 Chapter Six

TABLE 6.2 Sample Risk Matrix 2: Hiring Project (Continued)

Impact (technical,

Description of schedule, Severity Wigh, Contingency Risk items risks cost, quality) medium, low) plan Ranking

Trailer permits We may not have all the required permits to operate the hiring trailer.

This risk impacts the schedule of the project.

Medium Prior to opening 3 the hiring trailer schedule a n appointment with the city inspector to ensure all permits required have been received.

Supplies There is a possibility that we may run out of supplies.

Drug testing There may be applicants who do not pass the drug screening.

Schedule impact

This risk impacts both cost and schedule. The drug testing is expensive and is reserved for the applicants who are to be hired. When an applicant doesn't pass the drug screen we will have to look for the next qualified applicant for the job.

Medium We will inventory 4 supplies daily and place our supply orders weekly

This risk rarely The biggest 5 occurs so i t deterrent to has a low this risk is the severity rate. explanation of

the hiring process to every applicant. By the third interview the applicant will be told three times that they will be required to take a drug test. We also have signs that say we conduct drug testing, t h a t usually deter anyone who may not pass from auulvine.

Note that this risk matrix covers a hiring process, including a drug test. The task "supplies" includes a contingency to check supplies every day to offset the risk of running out of supplies for drug testing. Again, this contingency would be added to the schedule--each day if necessary-to ensure that drug supplies were available.

Chapter

A Case in Risk and Microsoft Project

Good risk management requires substantial organizational capacity to handle risk-related information and data and to calculate schedule and cost impacts of various risk events. As projects become more and more complex, risk manage- ment requires a n effective project management software program and sup- porting network systems t o allow exchange of d a t a a n d analysis. Microsoft Project provides a good base for project planning and control and for schedul- ing and costing out risk mitigation actions. But the organization needs a net- work system with a workable directory so t h a t project teams and stakeholders can access and communicate timely risk data.

I n addition to its usefulness in documenting contingency tasks as a part of the baselined schedule, MS Project's PERT (Program Evaluation and Review Technique) analysis allows for estimating alternative scenarios and impacts on schedule and cost. PERT analysis provides a template for placing weights on three scenarios-xpected, optimistic, and pessimistic--and estimating dura- tions as well.

This chapter addresses a case study in how to use MS Project in selecting and scheduling a project, and how to manage project risk. The "Huntsville case" tracks a project from selection and early planning through project initiation, and then into project review after 2 months into the work. The project is presented i n four parts. P a r t 1 is a project selection exercise using net present value and a weighted scoring model reflecting risk to rank two competing projects. Once a project is selected, Parts 2, 3, and 4 involve implementing the selected proj- ect-learning the MS Project management software, preparing schedules, pro- ducing and interpreting reports, and taking corrective action based on risk events and project progress. The project also involves preparing management reports on project progress and corrective action. "Assignments" are made to the reader to get hands-on experience, and a n answer is provided to all "assign- ments" and question.

128 Chapter Seven

Part 1: Portfolio Project Selection and Risk

The Seitz Corporation was founded i n 1932 by Johann Seitz. The main prod- ucts of the firm were small to medium plastic bottles and containers, used mainly i n the food and dairy industries.

By 1975 the annual sales of the corporation had reached $31 million and the firm enjoyed a dominant market position i n the upper Midwest. I n 1982, Walter and Teri Sietz--Johann's grand children-assumed t h e day-to-day operations of the business. Teri Seitz was a somewhat unstructured, but dili- gent, student of the latest business school theories and decided t h a t i n order to meet increased competition, especially from Japanese companies, Seitz Corporate needed to develop a long-range strategic plan. A consultant was hired to do this. The plan reflected much of the philosophy t h a t had enabled the company to succeed i n t h e past, but this was the first time these philoso- phies had been written down and synthesized into formal goals. The key ele- ments of the strategic plan, ranked according to priority with number 1 being the top priority, are a s follows:

1. Double total sales within the next decade.

2. Develop and market new products based on the company's plastics experience.

3. Reduce dependence on equipment suppliers.

4. Be first or second, based on market share i n any region.

5. Attain a national presence in the container industry.

6. Increase productivity.

By 1987 sales had increased to $80.5 million. Much of this increase was the result of new markets established i n the northeast, southeast, and western parts of t h e country. New plants were built in Salinas, California, and Harrisburg, Pennsylvania, and as a result of the product efficiencies, reason- able transportation costs, and aggressive marketing Seitz was now t h e leader in the western market and held a solid second place in the northeast. The firm had maintained its leadership in the original midwest territory.

The corporation is now in the process of selecting major investment programs for the 1997 to1998 period. Atotal of $3,000,000 remains available for projects during this period. One selection remains and will be made from two candidate projects, which have been culled over from over a dozen project proposals. The details of the two projects are a s follows.

Candidate Project 1

Steve Pokorski, the Vice President of Operations, and Joe Downs, the Director of Plant Engineering, have submitted a proposal to replace the extrusion equip- ment in the West Milwaukee plant. The proposed new equipment is to be man- ufactured based on a prototype designed and built in Down's developmental facility. All existing equipment had been acquired from three major suppliers. Pokorski authorized the prototype because he felt t h a t the suppliers had become

A Case in Risk and Microsoft Project 129

unresponsive to Seitz's bid requests. The technical superiority of the new type of equipment will allow for significant improvements in productivity. The fol- lowing are the supporting financial data:

Initial investment $2,475,000 Year 1 Return $700,000 Year 2 Return $800,000 Year 3 Return $800,000 Year 4 Return $800,000 Year 5 Return $800,000

Risks. Project 1 initially presents many risks that should be incorporated i n the project selection process:

1. Technical risk-new equipment failure

2. Contract risk-supplier delivery failure

3. Performance risk-poor estimates of productivity payoff

I n each case t h e risks are major because they would substantially delay com- pletion of the project and its viability.

Candidate Project 2

Janis Clark, Vice President of Marketing, has proposed another project, which would establish a new plant in Huntsville, Alabama. During the last 3 years sales have been steadily increasing in the area to the point where Seitz has achieved third place i n t h e market share. Clark claims t h a t t h e market is extremely price sensitive and Seitz's more efficient production capacity would ensure quick attainment of the second position if transportation costs to mar- kets i n the southeast were lowered. The financial data to support this proposal are shown below:

Initial Investment $2,550,000 Year 1 Return $550,000 Year 2 Return $600,000 Year 3 Return $400,000 Year 4 Return $1,150,000 Year 5 Return $1,300,000

Risks. Project 2 presents many risks because it is a new construction effort:

1. Construction design failure

2. Design risk-space layout and production process problems

3. Performance risk-unforeseen labor issues

4. Cost isk-inaccurate estimates of cost

130 Chapter Seven

Exercise

A. Compare the projects using a weighted scoring model based on the com- pany's strategic goals, risks, and project descriptions.

B. Using a discount rate of 12 percent, calculate the net present value for each of the projects.

C. Make a selection of the most desirable project based on t h e results of A and B. Support the selection with comparison charts and net present value calculations.

D. Prepare a report to management supporting your decision.

Note: The purpose of this assignment is to illustrate to a project manager and the project team the importance of being involved in the actual selection of the project and knowing its background and assumptions. Analysis of projected cash flows, risks, and net present value provide valuable information on what is expected of a project a s well as information t h a t will be useful to the project manager once a project is selected. For instance, net present value requires a n estimate of cash flow over the life cycle of the project, which requires some analysis of initial investment costs and expected revenues on a regular basis. Such a cash flow analysis usually requires some planning and outlining of the project to identify key milestones and deliverables which can be invoiced to the customer for progress payment. The weighted model requires assessment and ranking of projects against strategic goals, as well a s the determination of actual weights for each. This exercise should provide valuable background and insight as the project manager enters the initial phase of t h e project, once selected.

Introduction to Parts 2,3, and 4

Parts 2, 3, and 4 of the course project will give you t h e opportunity to use the project management software to construct a preliminary schedule (Part 2), "scrub" a n d adjust t h e schedule to respond t o changes and risks, a n d add resources (Part 3), and track, interpret, and take corrective action based on actual progress (Part 4). You are provided relevant schedule, cost, a n d per- formance data to enter into the software, and you are asked to interpret progress and prepare reports to management on issues such a s conflict management and organizational structure. Remember t h a t the software automatically cal- culates and constructs the Gantt chart and critical path &om your data entries, thus bypassing the manual development of system diagrams and calculation of earned value and other indicators.

Entering data into MS Project to reporting on a project is sometimes chal- lenging. Sometimes the data are difficult to enter; sometimes the results are not what you expected. There a r e no instructions in the course project on t h e soft- ware, so you are expected to use the required software manual to guide your data entry and interpretation. The software may not work exactly as the manual sug- gests, and you may encounter results and reports t h a t differ from those of your

A Case in Risk and Microsoft Project 131

colleagues. All this demonstrates the experiences of real project managers in real project situations.

There is no right answer to this case, even if results such a s final budget and earned value indicators should fall in a predicted range. Work on clear, analytic answers to the questions posed, especially on corrective action. (What would you do as a project manager given your interpretation of progress and problems?)

Part 2: Project Planning and Risk

I n January 1997 the board of directors of Seitz met in Milwaukee with several important questions on the agenda. Among the decisions to be made was the selection of investment projects to be executed during the next fiscal year. After a detailed presentation, one of the proposed investments, the construction of a new plant in Huntsville, Alabama, was approved. Janis Clark, who had sub- mitted the proposal, was given the responsibility for executing the project. I n the memo which informed h e r of the board's decision she was given authority to spend $2,750,000 and was given a target date of J u n e 1998 for completion of the plant and the first shipment of the product.

Besides being provided with funds i n excess of t h e original budget request, Clark had been given access to other functional elements of the corporation's Midwest plant and headquarters for assistance in the project. Steve Pokorski, the Vice President of Operations, and Joe Downs, Director of Plant Engineering, (who had submitted a n alternative proposal which the board had rejected as being "reactionary and backward i n thinking") were instructed by the board to provide Clark with whatever she needed, even if it meant that their own per- formance would suffer. Down's prototype was, of course, turned over to Clark so t h a t she could use the technology in the new plant.

Clark immediately called in her regional sales manager and her marketing director to assist her in initiating the project. They decided t h a t the first objec- tive was to put in place a n appropriate organizational structure and to staff it with the required personnel recruited from both internal departments and from outside the company. Being a marketing and sales organization they were a little thin on people with technical skills, but they expected to utilize the best and brightest from Down's and Pokorski's organizations because a s Clark said, 'They don't really need much talent to r u n their operations anyway. We can offer their best people higher level management positions on the project team and then a t the new Huntsville plant." When one of her staff questioned if these people would all be willing to move to Alabama, even for a promotion, she replied "who in his or her right mind would want to stay in Milwaukee when they could move to Alabama; and with a promotion, too!"

Although they expected the project manager to finalize the plan, Clark and her assistants drafted a preliminary list of the tasks, which they felt were needed to accomplish the project, together with precedence relationships and task durations.

Clark had decided t h a t one of the products to be produced i n the new plant would be a new plastic container for wine products. She felt t h a t glass bottles

132 Chapter Seven

were on their way out a s wine containers and t h a t this was a ground floor opportunity to capture a major new market segment. In order to introduce the product properly, however, she felt t h a t the plant would have to be ready no later t h a n the end of 1997.

Assignment. You are a consultant who h a s been hired by the directors of Seitz Corporation to monitor the initial phases of the project. Answer the following questions in the form of a confidential report to t h e board on your evaluation of the project to date and recommendations.

1. Based on the information given above, define a n appropriate organizational structure for the project. Choose among the matrix, functional, and pure project organizational structures covered in the text. Include i n your orga- nizational chart details of how the project should tie-in to the parent company, and how the project itself should be organized. Provide a n organizational chart and give the reasons for your selection.

2. Identify any potential conflicts between Clark, Downs, and Pokorski. Identify the type of conflict, the effects they might have on the project, and how they might be resolved.

3. For Parts 2 , 3 , and 4 of the Course Project, you will be using Microsoft Project to document the project. So study the program manual and get familiar with the software. For this part p a r t 2), follow directions to start the project and save the project file first. Set the current date (pull down the project infor- mation box from the Project menu to enter dates) a s March 17,1997, and the project start date as April 17,1997. Then enter task data onto the Gantt chart from Table 7.1 (preliminary plan). Print out the preliminary schedule, a printed Gantt chart.

4. Prepare a risk matrix on the Huntsville project, complete with contingency plans.

5 . Do any issues about the project tasks and their relationships "jump out" a t you-are the tasks in a logical sequence and does the overall structure and "contour" of the project look right?

6. Will the plant be ready by the end of 1997 a s Janis requires? If not, will it meet the J u n e 1998 deadline set by the board of directors? What options might be open to ensure that these deadlines are met, if the current sched- ule indicates t h a t the plant will not open in time?

7. Prepare the report to the board covering your answers to the above questions.

Notes on the software. Don't forget to change the current and status date of the project for Parts 3 and 4. This is key to the effectiveness of t h e software in "knowing" what dates you are working with a t any time. Be sure to save the file when you are finished, but don't save it a s a baseline yet. Remember also, in printing out the Gantt chart, to adjust the timescale of the bar chart to a scale t h a t allows you to print the whole project on one page. Go to the Format menu

A Case in Risk and Micmsoft Project 133

TABLE 7.1 Huntsville Preliminary Plan

Task number Task name Duration (in weeks) Predecessor

1 Select an architect 2 None 2 Recruit and train managers 6 None 3 Select real estate consultant 2 None 4 Create production plan 4 None 5 Building design 6 1 4 6 Site selection 3 3 7 Select general contractor 2 5 8 Permits and approvals 3 3,6,7 9 Building construction 24 8

10 Plant personnel recruiting 8 2,4 11 Equipment procurement 24 4 12 Raw material procurement 8 4 13 Equipment installation 4 11 14 Product distribution plan 2 4 15 Landscaping 3 9 16 Truck fleet procurement 8 14 17 Preproduction run 4 10,12,13 18 Production start-up 1 17 19 Distribution 1 16,18

and click Timescale, then adjust the major scale and minor scales until you can place the whole project on one page.

Part 3: Establishing the Risk-Based Project Plan Baseline

During the various meetings held by Janis Clark, one of the major priorities was the selection and appointment of a project manager for the new Huntsville plant project. The decision had been made to use a mixed organization, which would provide the project manager with a n independent staff and would also allow the use of some resources from the existing functional organization of t h e corporation. Clark wanted to have the project staff transition into the operational management roles of the new plant upon completion of the project. Clark con- tacted Steve Pokorski. Vice President of Ouerations. to seek his assistance in filling the project manager position. Pokorski was interested in assisting because he realized t h a t once the Huntsville olant was comuleted the resuonsibilitv for ongoing operation would be his. At first there was conflict between Clark and Pokorski because of the rejection of Pokorski's alternate proposal, but his had been dealt with by Teri Seitz who, upon recognizing the seriousness of the con- flict, and having no desire to let it fester, had hired a management consultant, The SIGMA group, specializing in team building and conflict resolution.

Pokorski had been through similar projects in the establishment of the Salinas plant and the Harrisburg plant and had learned some difficult lessons along the way. The first project (Harrisburg) had been implemented by a project team organized and r u n out of t h e corporate office. The staff returned to their origi- nal jobs after the project was complete, with the plant operation managed by a team locally recruited during construction. Pokorski had decided after a long and

134 Chapter Seven

difficult start-up period t h a t in the future the availability of potential man- agers recruited internally would be a priority.

Pokorski had proposed four candidates who he discussed with Clark and between them they selected two possibilities. On two occasions the candidates were brought to Milwaukee and interviewed. Andy Piltz, the Material Manager in the Salinas plant, was chosen and accepted on March 15, 1997.

Andy took about 2 weeks to transfer his responsibilities in the Salinas plant during which time he made a preliminary organization plan and identified with Pokorski's help some possible project team candidates. By t h e end of March he had contacted his candidate list and received commitments for the three posi- tions he had decided to fill internally. The staff list included:

Project duty Plant position Current job

Production specialist Manufacturing manager Senior manufacturing manager Marketing specialist Marketing manager Regional sales manager Facility specialist Maintenance manager Asst. maintenance manager

I t was decided t h a t accounting and personnel managers should be recruited locally by the project manager and undergo training in Milwaukee. All other plant project and plant staffing decisions would then be the responsibility of the personnel manager. After several meetings with his staff, Piltz completed the t a s k list (see Table 7.2, revised plan) by adding a summary task for t h e

TABLE 7.2 Revised Huntsville Plan

Task number Task name Duration (in weeks) Predecessor

1 Huntsville Project 2 Select a n architect 2 3 Recruit and train managers 6 4 Select real estate consultant 2 5 Preproduction plan (new) 2 4 6 Create production plan 4 7 Building concept (new) 2 2 8 Building design 6 9 Site selection 3

10 Select general contractor 2 11 Permits and approvals 3 12 Building construction 24 13 Plant personnel recruiting 8 14 Equipment procurement 24 15 Raw material procurement 8 16 Equipment installation 4 17 Product distribution plan 2 18 Landscaping 3 19 Truck fleet procurement 8 20 Preproduction run 4 21 Production start-up 1 22 Distribution 1 .

A Case in Risk and Microsoft Pmject 135

TABLE 7.3 Huntsville Resource and Fixed Cost List

Resourcel cost initials

- - - -

Hourly Full name Cost type rate ($Am) Fixed cost ($)

Facility specialist Project manager Carp. personnel Production specialist Building design Real estate consultant Site cost Manufacturing engineer General contractor Permit costs Building costs Personnel director Equipment costs Architect Equipment installation Marketing specialist Accounting director Truck cost Traffic manager Landscaping Purchasing agent

Personnel Personnel Personnel Personnel Fixed Personnel Fixed Personnel Personnel Fixed Fixed Personnel Fixed Personnel Fixed Personnel Personnel Fixed Personnel Fixed Personnel

Huntsville Pmject, adding task 5,preproductionplan, and task 7, building con- cept. At this time the Project team also prepared Table 7.3, resource cost List, and Table 7.4, resource loading list.

Assignment for data entry to Microsoft Project

1. Enter Andy Piltz as Project Manager (go to File and Properties) and set the current date to April 17, 1997 (go to Project and Project Information box).

2. From Table 7.2, insert the two new tasks and task durations into the project task list. You will have to change the predecessors to establish the correct link- ages after the two new tasks have been added.

3. Create a summary task for the Huntsville P r o j e c e a new task added a t the top of the list and "out dented" from the rest of the tasks. (When you have added the summary task a t the top of the list of tasks, block the entire list of tasks below and click the out dent button (the one that points to the right) a t the upper left of the screen.)

4. Enter resource (both personnel resources and fixed equipment resource) costs:

First enter personnel resources. Using the information supplied on Table 7.3, resource cost list, enter personnel resources and their hourly rates by entering them on the Resource Sheet. (Go to View, Resource Sheet, then entry table.)

136 Chapter Seven

TABLE 7.4 Huntsville Resource Loadlng Llst

Task resource assirmments Resource name-percent assigned

2 P M - 10% FS - 60% 3 P M - 15% CP- 80%

- - -~~

FS - 25% RC - 30% FS - 20% PS - 10% PA- 25% M E - 10% M E - 30% TM - 40% LC - 100% AD-10% M E - 70% M E - 70% M S - 20%

TC - 100% PA- 10%

Then enter fixed costs, using the information supplied on Table 7.3. (Note that fixed costs are entered i n a different view and t a b l e t h e Gantt view and the cost table--consult your manual)

5. Then assign those resources to tasks. Assign hourly resources from the attached Table 7.4, resource loading list. (You assign resources by high- lighting each task, then clicking to get the task information box, then click- ing resources and entering the resource and the percent assignment to t h a t task). Note t h a t some of the resources you are assigning are fured costs (like SC, site costs)-they are assigned 100 percent to one task.

6. Then print the Resource Sheet showing resource name, initials, and costs.

7. Print a project summary report and a Gantt chart.

8. Answer t h e following questions relying on this view and other appropriate reports:

I s the Project within budget? What are t h e budgets, both total and by month, for each task? Are there any resource conflicts (overallocated resources)? If so, what resources are overallocated and for what time periods? What is the current total cost and schedule for the project? How does this compare to the original plan?

A Case in Risk and Microsoft Project 137

What is the critical path of the project? (Go to Project, Filtered, then click Critical and the Critical Path tasks will be shown on the screen. Print t h e screen.) Your answers to these questions should be i n the form of a project start-up report addressed to Janis Clark. It should include a summary analysis of the reports generated by MS Project, which should be attached as backup and referenced in the your analysis.

Since the project plan is now completed, save the project a s a baseline sched- ule. Saving a project as a baseline is a significant action, in effect signaling a n authorization to initiate the project work. Aproject kickoff meeting is typically held to emphasize transition into project implementation.

Part 4: Project Review for Progress, Risks, and Earned Value

Assume now t h a t the project has been kicked off and has been running for 2 months. Andy Piltz i s conducting his biweekly project review meeting on J u n e 15,1997, for the Huntsville Project. He is particularly interested in review- ing earned value of the project so far and determining what corrective action he might take to keep the project on course. The project started on time and infor- mation regarding time, progress in terms of percent complete, and expenditures have been collected. The attached table on actual resources expended is a summary of costs through June 15,1997,2 months into the project. Using data reported from task leaders, the table also presents "percent completed" for each task, and the amount of effort put in by the various resources on their assigned tasks.

Assignment

1. In the Project Information Box (Project, click information box) set your cur- rent and status date to J u n e 15,1997. Do not shut down the computer a t this point; proceed to enter actual days worked i n the next step.

2. Update your project baseline plan with the actual days the assigned personnel worked on each task (Table 7.5). To enter the actual days go to View, Task Usage, Table, then Work and then enter days into actual column.

3. Print an earned value report.

4. Interpret t h e report, using t h e d a t a on budgeted cost of work schedule (BCWS), budgeted cost of work performance (BCWP), actual cost of work performance (ACWP), and schedule and cost variance.

5. What is the new critical path of t h e project? (Go to Project, filter, critical.)

6. What corrective actions a r e suggested, given the results of this project on J u n e 15, 1997? Prepare a status report to management, which clearly con- veys the status of the project and your recommendations for corrective action. Support your recommendations with appropriate reports from MS Project.

138 Chapter Seven

TABLE 7.5 Actual Huntsville Resources Expended (as of June 15,1997)

Task Resource name-days

2 FS 6 days PM 1 days 3 CP 32 days PM 4.5 days 4 PM 3 days FS 4 days 5 ME 8.5 days P M 4 days PS 8 days 6 ME 16 days MS 4 days PS 12 days 7 AC 10 days F S 4 days 8 FS 4 days 9 MS 3 days RC 12 days FS 6 days

10 AC 2 days FS 2.5 days PM ldy PS 2.5 days 11 AC 1.5 days GC 2 days PM 1.5 days RC 4.5 days 12 1 3 FS 4 d a y s MS 2.5 days PM 4 days PS 4 days 14 P A 1 dy ME 8.5 days 15 AD 4 days ME 4 days PA4 days PS 4 days 16 MS 6 d a y s TM 4 days

Remember t h a t you are being asked to both interpret the indicators and come u p with corrective actions. Corrective actions might include schedule adjustment, team performance feedback, finance and budget, reviewing per- cent complete data, looking a t quality impacts, and looking ahead to antici- pate ways to adjust the project given progress to date.

Suggestions. The earned value reports should show some figures (BCWS, BCWP, andACWP) in some task boxes for the tasks t h a t started before J u n e 15, 1997-your status date. Sometimes, however, the earned value reports do not show any numbers in any boxes indicating t h a t t h e software did not record your actual-days-worked entries. This can happen if you don't change t h e current and status dates i n the project information box before you enter the actual-days-worked information in Part 4. So you will have to correct the data entry so t h a t you have earned value figures to assess. So if you find you have no earned value figures i n your report, resave the schedule as a n interim plan, reenter the actual days, make sure the current and status dates are entered a s J u n e 15,1997, and print the earned value report, which should now show figures for those tasks t h a t started by J u n e 15.

Risk and This Case

This case is exemplary of a complex business problem of project selection and implementation t h a t addresses risk a t every turn. Risk was apparent in how the two projects were evaluated and selected; the company tries to balance risk with payoff. Cash flows are subject to risk because they may not be backed up with good research and analysis. Risks inherent in the projects themselves might not be clear since to do a thorough risk matrix each project WBS would

A Case in Risk and Microsoft Project 139

have to be completed and risks identified and ranked in a risk matrix. Cost esti- mates did not reflect those factors.

Once the Huntsville project was chosen, its risks were addressed i n initial scheduling and estimating project resource and costs. Risks were inherent in the earned value estimates in P a r t 4 in the sense t h a t the estimates of actual resources and associated percent complete were not accurate.

The Solution

I n the selection process we would propose t h a t Project 2 be approved. This proj- ect will allow the company to meet most of its goals that have been listed as pri- ority-double total sales within t h e next decade, develop and market new products, reach first or second position in regional market shares, attain a national presence in the container industry, and increase productivity. All objec- tives will be accomplished, below the remaining project budget of $3,000,000 coming in a t $2,550,000 from start to finish. Based on the calculated analysis from the net present value and undiscounted payback, the payback period will be less than 4 years, leaving 6 years within the 10-year range to double sales. A team will need to be dedicated to the project to address all the variables but problems are not expected because we have gone through this several times already. This makes the planning and implementation processes of the project smoother because our technical support is familiar with the procedures. This is the ideal time to start this project because the market is yearning for our prod- ucts. Reports show t h a t t h e market is particularly price-sensitive i n t h e Huntsville area giving our economical products a n advantage. Compared to Project 1, Project 2 is the preferred project to put into operations looking a t the calculations from all three sources. Below you will notice two models used in scor- ing the projects-weighted scoring model analysis (Table 7.6) and the net pres- ent value analysis (Table 7.7):

TABLE 7.6 Huntsville Weighted Scoring Model Analysls - -

Weighted Scoring Model

Projects

No. Category Weight One Two

1 Double total sales within the next decade 25 5 5 2 Develop and market new products based 20 2 4

on the company's plastic experience 3 Reduce dependence on equipment suppliers 20 5 2 4 Be 1st or 2nd, based on market share 15 2 5

in any region 5 Attain a national presence in the 10 2 4

container industry 6 Increase productivity 10 4 4

Total weighted score 100 280 375

140 Chapter Seven

TABLE 7.7 Huntsville NPV Analysis

Year Cash flow Rate N W

Proiect 1

Project 2

I n evaluating the two projects we used a comparative study t h a t was based on how well the two projects met their strategic goals. To set u p the weighted scoring model we first assigned a weight or percentage t h a t represented the importance of t h e goal. Next, a score was assigned to every category for each project, where the score would represent how well each project met its objective. For clarification purposes, a score of 1 represents the lowest score and a score of 5 represents the highest score. The percentages are particularly important because Seitz Corporation h a s prioritized their strong philosophies. These philosophies a r e part of t h e strategic plan to achieve their long-term goals. Rationality for each score relates to the contribution t h a t each category gives to the organization meeting its goals. In the category of doubled total sales, proj- ect 2 would presumably achieve those goals quicker because the perspective loca- tion is already showing evidence of increased sales. Sales t h a t are steadily increasing yield evidence of prominent possibilities. To add to the ideal mar- ketplace, Clark claims t h a t the "market is extremely price-sensitive," which gives Seitz's economical products a n advantage over competitors thus allowing them to attain second position in the southeast market. This is particularly important because aggressive marketing would not be needed in Project 2-Seitz would be providing the region with products consumers are asking for through their purchasing tactics. Thus Seitz Corporation would get a quicker return on their investment not having to divert money to boost sales. The slow or slack initial period often seen when manufacturers move to a new area would not be seen-that period when natives to the area are observing quality and prices of the new product comparing it to their usual purchase, which they are accustomed to.

A Case in Risk and Microsoft Project 141

NPV Project 1

51,000,000 I

-$3,000,000 ' I Years

NPV Prolect 2

$1,000,000

5500,000

50

-5500,000 5 =, 41,000,000 n -$I ,500,000 -52,000,000

-$2,500,000

-53,000,000 Years

Flgure 7.1 Huntsville NPV chart.

This would also reduce project longevity, enabling participants to return to functional projects, and reduce integration of functional groups because once the - - - machines are installed and are operating properly manufacturing will begin and the plant manager will oversee operations.

As a result, we propose Project 2 be selected. The following information will also show why Project 2 seems to be more in line with the company's strategic goals and objectives (Fig. 7.1).

Organizational Structure

Based on the information gathered, our recommendation a s to the type of orga- nizational structure should be the pure project organization. The project is sep- arated from the rest of the parent system. It becomes a self-contained unit with

142 Chapter Seven

I President I

Project Manager 1 + V.P. Manufacturing Marketing n

V.P. R&D

Project Manager 2

-i Marketing w

Manufacturing Manufacturing

Personnel Personnel

Figure 7.2 Huntsville organization chart.

its own technical, marketing, finance, research, personnel, and development staff tied to the parent firm by the tenuous strands of periodic progress reports and oversight. We would suggest the following personnel be placed i n each depart- ment (Fig. 7.2):

MarketingISales: Janis Clark

Manufacturing: Steve Pokorski

R&D: Joe Downs

Finance Outsource: hire from outside

Personnel Outsource: hire from outside

We chose Janis Clark for the marketingtsales position because t h a t is where her talent will be best. We chose Joe Downs to lead research and development because of his role a s the director of plant engineering we felt t h a t position would suit him best. Steve Pokorski was given the position of manufacturing because of his extensive knowledge in operations. By utilizing this particular

A Case In Risk and Microsofl Prolect 143

structure, the lines of communication are greatly lessened, which often leads to better communication between departments. Because authority is centralized, the ability to make quick and accurate decisions is greatly increased. The posi- tions marked outsource (hire from outside) will allow the company to hire local talent to round out the team without having to draw personnel from other parts of the company.

Possible Conflict and Resolution

As for areas of conflict, Pokorski and Downs may have negative feelings toward Clark due to their rejected proposal in favor of Clark's. Another area of conflict could be t h a t Clark's request of resources from Pokorski and Downs may cause their departments to perform poorly even though they are instructed by the board to provide Clark with whatever she needs, even if i t meant t h a t their own performance would suffer. Next, we would definitely feel some contention due to the fact they may disagree with Clark every step of the way because of their opposite version of the proposals. Last but not least is the fact t h a t Clark's proj- ect will overlap with Pokorski and Downs' responsibilities creating more rocky roads. Recognizing the seriousness of the potential conflict the company will need to have a team building and conflict resolution retreat headed by the manage- ment consultant, the SIGMA group, including Pokorski and Downs a s part of the project team. Including Pokorski and Downs will give them a sense of own- ership as part of the team.

Conflicting Schedule

Do any issues about the project tasks and their relationships "jump out" a t you-are the tasks in a logical sequence and does the overall structure and "contour" of the project look right? At first glance project tasks and their rela- tionships seem to r u n smooth until you really start looking a t some areas of con- flict. For instance, the plant personnel being recruited well in advance of production-what will they be doing and doesn't this drive up cost. The next thing would be having the raw materials delivered before the building has actu- ally been constructed. Equipment installation is to be completed before the building is actually constructed. That means, t h e schedule will have to be changed. As for production start-up, we would think you would need a building constructed in order to begin distribution.

Plant Readiness

As for the plant, being ready by the end of 1997 is highly unlikely. As of today it is scheduled to be completed on January 14, 1998, which meets the deadline set by the board of directors. I t is possible for the plant to be ready by Janis dead- line if the building can be constructed earlier by a t least 1 month.

144 Chapter Seven

Project Cost

According to my figures, we show this project to be within budget. The total proj- ect cost is $2,612,970.00. Please see the following chart:

1. Huntsville Project

2. Select a n architect

3. Recruit and train managers

4. Select real estate consultant

5. Preproduction plan

6. Create production plan

7. Building concept

8. Building design

9. Site selection

10. Select general contractor

11. Permits and approvals

12. Building construction

13. Plant personnel recruiting

14. Equipment procurement

15. Raw material procurement

16. Equipment installation

17. Product distribution plan

18. Landscaping

19. Truck fleet procurement

20. Preproduction r u n

21. Production start-up

22. Distribution

Resource conflicts (overallocated resources)

Yes, there are resource conflicts. There are three resources t h a t are overallo- cated:

Facility specialist is overallocated t h e weeks of 4/13/97 t o 4/27/97 by 30 percent.

Production specialist is overallocated t h e weeks of 4/13/97 to 4/27/97 by 120 percent.

Manufacturing engineering is overallocated the weeks of 4/13/97 to 4/27/97 by 195 percent.

A Case in Risk and Micmsoft Project 145

Current cost and schedule

The total cost is $2,612,970.00 and the project end date is 2/18/98. If we followed the original plan according to the board of directors, where the allocated budget was $2,700,000, and completed by J u n e 1998 then we would be within budget and ahead of schedule. If we followed the original plan according to Janis Clark, where the allocated budget was $2,550,000, and completed by end of year 1997 we would be over budget and behind schedule.

Critical path

The critical path is 1 , 6 (create production design), 7 (building concept), 8 (build- ing design), 10 (select general contractor), 11 (permits and approvals), 12 (build- ing construction), 18 (landscaping).

Earned value analysis

The information represented below will support the earned value interpretation t h a t follows:

BCWP $170,848.74

BCWS $448,108.00

ACWP $1,061,668.80

SV (schedule variance) ($277,259.26) behind schedule CV (cost variance) ($890,820.06) over budget

My interpretation of the numbers is that we are over budget and behind sched- ule by a substantial margin. But after taking a closer look a t the numbers and the charts you'll notice that we have procured equipment and our truck pro- curement t h a t was not needed or could have waited, which pushed my variance in the wrong direction.

Critical path

The new critical path for the project is: 4 (select real estate consultant), 11 (permits and approvals), 12 (building construction), and 18 (landscaping).

Corrective action

Corrective actions t h a t will get us back on track will be to make procurements when they a r e necessary in the time of the project. As for the schedule, if we see after further investigation t h a t we are really behind then we would have to add more resources or extend the schedule out or both. Also, investigate any slip- page and determine whether or not the schedule will need some type of adjust- ment. After checking and verifying reports for accuracy, a s discrepancies could

146 Chapter Sewn

go toward explaining the schedule variance, the next thing we would do is go to the accounting department to verify whether the reports match. From there, we would have a meeting with my team members to find out where they are and get any feedback on what we can do to get back on track. Finally, we feel there is a good possibility t h a t the tasks can be rearranged so t h a t the schedule com- pletion may be faster and actually go smoother. We would reanalyze the sched- uling of the three positions t h a t were overallocated (facility specialist, manufacturing engineer, and project manager), which played a major role in the project.

Risk Analysis in Project Selection

Risk can be factored into project selection by assigning a risk ranking to each project (Tables 7.8 and 7.9). For instance, recognizing t h a t Project 1 faced technical, contract, a n d manufacturing performance risk, each risk can be ranked in terms of risk cost, or the cost of implementing key contingencies, as follows:

Project 1 Productivity improvement

Technical risk New equipment failure Contract risk Supplier delivery failure Performance risk Poor estimates of productivity payoff

Project 2 Build Huntsville project

Technical risk Construction design failure Performance risk Unforeseen labor issues Cost risk Inaccurate estimates of cost

TABLE 7.8 Huntsville Project 1 Risk Matrix

Risk Impact Probability (K) Contingency Cost of contingency

New equipment Technical failure; 50 (unproven Modify equipment; $40,000 schedule and cost technology) new tooling

Contract Contractor failure; 75 Rebid contract; $33,000 schedule and cost start over

Productivity Payoff not achieved; 75 Reduced sales $540,000 schedule

Total risk score $613,000

A Case in Risk and Microsoft Project 147

TABLE 7.9 Huntsville Project 2 Risk Matrix

Risk Impact Probability (%) Contingency Cost of contingency

Construction Bad construction design, 50 (unproven Modify equipment; $40,000 design failure schedule and cost technology) new tooling

Bad space layout Cost 75 Rebid contract; $3,000 start over

Low labor Productivity payoff 75 Reduced sales $40,000 productivity not achieved

Inaccurate Budget overrun 75 Reduce net income $ZOO,OOO estimates of cost

Total risk score $Z83,000

Comparing the two risk scores, the Huntaville Project is the lower cost exposure due to risk. Therefore the risk analysis supports the choice of Project 2.

Huntsville: Risk-Based Scheduling

Arisk-based schedule can be put together using the MS Project toolbar, the out- come is a s shown in Table 7.10.

Risk and the Huntsville Project: Journey in Risk

I n sum, the Huntsville Project is instructive because there are so many risks associated with the whole process, from business strategy through project review, based on earned value. Risk and benefit were integral to the project life cycle.

For instance, there were substantial risks associated with:

The development of business strategies

The selection of a project from the two candidates

Project-level risk--overall risk associated with the two candidates

The development of the task list

The estimation of task duration

The determination of resource requirements and assignments

TABLE 7.10 Huntsville Risk-Based Schedule Data

Expected Optimistic Pessimistic Caclulated, risk-based High-risk task duration duration duration duration

Select architect 55 days 20 days 80 days 65.83 days Site selection 40 days 23 days 70 days 57.17 days Truck fleet 66 days 50 days 89 days 78.67 days

148 Chapter Seven

The linkages in the project schedule

The performance of the key project team members

The conflicts inherent in the project team

The decision to use actual hours as a n indicator of work accomplished

The entry of data into MS Project

Risks associated with each task

At each such step in the process, the risks and benefits of the situation a t hand had to be measured and evaluated against the strategic objectives of the com- pany. Some risks were documented (e.g., the risk matrices in the solution), but i n other cases the risks were considered, ranked, and decisions made without analysis. This is the real world of risk since a thorough analysis of every risk would not be feasible.

Chapter

Customer-Driven Project Management, TQM, and Risk

The purpose of this chapter is to illustrate the importance of seeing risk from the customer's perspective and recognizing that risk is inherently a customer and quality issue as described i n total quality management (TQM) concepts. As the major stakeholder and project sponsor, the customerlclientpays theprice a t the end of a project if risk is not well managed. I n the context of the three legs of the total quality management stool, risk is associated with: (1) customer expectations and satisfaction, (2) empowering t h e project team, and (3) the effectiveness of continuous process improvement.

Customer-Driven Risk Management

A customer-driven project team is a team that responds to customers and man- ages customer satisfaction as a regular team function. Risk management is a n overall obligation of the customer-driven project team. The teams continually assess risk a t the project level and in each task of the project-not only in terms of time and cost, but also in terms of the technical feasibility. Again, the customer- driven lead team establishes the system for risk management. This risk man- agement system influences the use of the other project management tools and techniques.

No project is without risk. That is, the probability t h a t a given process, task, subtask, work package, or level of effort cannot be accomplished as planned. Risk is not a question of time; it is often a question of feasibility. I t pays in the devel- opment of the WBS to assign risk factors to each element of the WBS, separate from the assignments of schedules and milestones for the work. Risk factors can be assigned based on uncertainty, technological feasibility, availability of resources, or competition. Later, the elements with high-risk factors are given

150 Chapter Eight

close attention by the project manager, whether or not they are on the critical path itself. Special attention is given to customers, users, and clients.

One of the most effective ways to deal with risk is to develop customer-driven contingency plans, or parallel courses of action-and changes in the WBS- t h a t come into play if the task cannot be accomplished a s the customer sees it. Contingency planning is based on "satisficing," a s Herbert Simon called it, rather t h a n optimizing, and recognizes t h a t in developmental projects, some things t u r n out to be impossible dreams.

Customer-driven contingency plans are carried out by the project manager, based on the level of risk assigned to a particular element of the WBS. When testing a new technique or approach, for example, a manager might estimate a 15 percent chance of successfully completing Task 1 and satisfying t h e user, because few new techniques work well the first time they a r e attempted. Similarly, there may be only a 10 percent chance of successfully completing Task 2 because of the organization's previous experience with a similar prob- lem. Hence, there is only a 1.5 percent probability of even reaching Task 3 if its performance depends upon successful completion of the preceding tasks. Once Task 3 is completed, however, it may be implemented again and again, depend- ing on how many problems have to be solved.

Illustration of Risk Management-the Defense Risk Program

The U.S. Department of Defense (DoD) has for many years provided standard templates to contractors for reducing risk i n system development. The DoD uses templates directed a t the identification and establishment of critical engi- neering processes and their control methods. For each of the critical engineer- ing processes a critical path template is provided. The template addresses the following areas for each critical engineering process:

Area of risk

Outline for reducing risk

Timeline

TQM Template. TQM is defined as an organized process of continuous improve- ment by private defense contractors and DoD activities aimed a t developing, producing, a n d deploying superior material and products. The primary risk i n reaching a n d sustaining this superiority is failure to manage with a pur- pose of constantly increasing intrinsic quality, economic value, a n d military worth of defense systems and equipments. Note t h e focus on management first, not technical risk. The armed forces a n d defense industrial entities may not a t t a i n a lasting competitive military posture a n d long-term competitive business stature without a TQM a t the highest levels. TQM is applicable to all functions concerned with the acquisition of defense material, supplies, facilities, and services. Being satisfied with suboptimum, short-term goals and objectives has adverse impacts on cost, schedule, and force effectiveness.

Custorner-Driven Project Managernent,TQM, and Risk 151

Ashort-term approach leads to deteriora-tion i n the efficacy of specific products, the firms that produce them, and the industrial base overall. A major risk is also entailed with the inability to grasp and respond to the overriding importance attached to quality by the "customer" or user activities.

DoD outline for reducing risk

The organization has a "corporate level" policy statement attaching highest priority to the principles of TQM. This policy statement defines TQM in terms relevant to the individual enterprise or activity and its products or outputs.

The corporate policy statement is supported by a TQM implementation plan t h a t sets enduring and long-range objectives, list, criteria for applying TQM to new and ongoing programs, provides direction and guidance, and assigns responsibilities. Every employee a t each level plays a functional role in imple- menting the plan.

All personnel are given training in TQM principles, practices, tools, and tech- niques. Importance is placed on self- initiated TQM effort.

The TQM effort begun in the conceptual phase of the acquisition cycle is vitally concerned with establishing a rapport between the producer and the user or customer and a recognition of the latter's stated performance require- ments, mission profiles, system characteristics, and environmental factors. Those statements are translated into measurable design, manufacturing, and support parameters t h a t are verified during demonstration and validation. Early TQM activity is outlined i n the Design Reference Mission Profde tem- plate and Design Requirements template. The Trade Studies template is used to identify potential characteristics, which would accelerate design maturity while making the design more compatible with and less sensitive to variations in manufacturing and operational conditions.

Design phase TQM activity is described i n the Design Process template. Key features enumerated include: design integration of life cycle factors concerned with production, operation, and support; availability of needed manufactur- ing technology; proof of manufacturing process; formation of design and design review teams with various functional area representation; and use of pro- ducibility engineering and planning to arrive a t and transition a producible design to the shop floor without degradation in quality and performance. The Design Analysis template and Design Reviews template provide guidance in identifying and reducing the risk entailed in controlling critical design char- acteristics. Both hardware and software are emphasized (refer to the Software Design template and Software Test template). Ahigh-quality design includes features to enhance conducting necessarv test and inspection functions (refer - to the Design for Testing template).

An integrated test plan of contractor development, qualification, and pro- duction acceptance testing and a test and evaluation master plan (TEMP)

152 Chapter Eight

covering government-related testing are essential to TQM. The plans detail sufficient testing to prove conclusively the design, its operational suitability, and its potential for required growth and future utility. Test planning also makes efficient use of test articles, test facilities, and other resources. Failure reporting, field feedback, and problem disposition are vital mechanisms to obtaining a quality product.

Manufacturing planning bears the same relationship to production success as test planning bears to a successful test program (refer to the Manufacturing Plan tem- plate). The overall acquisition strategy includes a manufacturing strategy and a transition plan covering all production-related activities. Equal care and empha- sis is placed on proof of manufacture as well as on proving the design itself. The Quality Manufacturing template highlights production planning, tooling, man- ufacturing methods, facilities, equipment, and personnel. Extreme importance is attached to subcontractor and vendor selection and qualification including flow down in the use of TQM principles. Special test equipment, computer-aided manufacturinrr. and other advanced equipments and statistics-based methods are -, - - used to quality and control the manufacturing process.

Timeline. TQM is used throughout the product life cycle. TQM-oriented defense contractors and government activities concentrate on designing and building quality into their products a t the outset. Successful activities are not content with the status quo or acceptable level of quality approach. These activities respond to problems affecting product quality by changing the design andlor the process, not by increasing inspection levels. Reduction i n variability of the detail design and the manufacturing process is a central concept of TQM a n d is beneficial to lower cost a s well a s higher quality. Defect prevention is viewed a s key to defect control. Astute TQM activities are constantly on the alert to identify and exploit new and proven managerial, engineering, and manufacturing disciplines and associated techniques.

DoD manuals stress the following TQM principles:

Total commitment to quality

Continuous improvement

Involvement of many functions

Long-term improvement effort

Customer focus

TQM principles include company action that:

Produces a policy statement (vision/mission)

Pursues a TQM environment

Stresses a TQM implementation plan

Customer-Driven Project Management,TQM, and Risk 153

Fosters ownership

Advocates training

Includes quality as a n element of design

Encourages measurements

Includes everything and everyone

Nurtures supplier and customer relationships

Encourages cooperation and teamwork

Portfolio and Program Management

DoD policy first articulated the importance of project selection and portfolio management i n t h e 1980s and h a s refined the c o n c e ~ t . The initial and most dis- - ruptive risk involved i n program management lies in the inability to choose the right portfolio of projects in the first place. Fit and consistency with strategic plans, cash flow analysis, r a t e of return, company competency (Can we make this product?), lack of business analysis on markets, technical feasibility, and legal risk are key factors contributing to successful risk management.

Fit with company strategy. Alignment with strategy is a key risk challenge because projects that might otherwise be attractive might not be part of the company's plans for growth and competence. The weighted scoring model is one tool for assuring "fit with strategy," but the risk here is i n t h e inability to measure whether, i n fact, a candidate project is going to help implement a company strategic goal.

Cash flow. Since profitability and rate of return is key to company growth, a project must be planned out over the long term to ensure net income growth. This means that candidate projects must be "fleshed out." The risk here is t h a t cash flows are misestimated and t h a t key decisions and assumptions behind the decision are not made explicit.

Consistency with company competency. If the company does not have expe- rience in a given area, it does not matter whether the project is consistent with strategy and cash flows are promising. Company capacity to perform is directly related to past experience and capacity-"sticking to the knitting" is still a major principle of success and therefore a useful risk management concept.

Market analysis. If the market and future demand for a given project out- come or productlservice are not well researched, the risk is t h a t a n efficient project may meet schedule, cost, and quality objectives, but produce a prod- uct which is not marketable. Therefore the focus i n risk planning must be in the adequacy of early business market analysis and research.

Technical feasibility. Since technical feasibility is key to new systems, if a proj- ect involves new, unproven technology there is inherent risk in the project.

154 Chapter Eight

Technical feasibility can be offset by embedded risk measures as described ear- lier in the product development process.

Legal risk. Legal and regulatory risk is attributable to changing government regulations and legal issues involved in liabilities for a given product. The risk here is that the company fails to understand and anticipate legal and regu- latory constraints on a product or service.

Value of Customer-Driven Risk Management

Customer-driven risk management captures the critical importance of seeing risk i n the eyes of the customer and client. Afocus on customer risk can uncover uncertainties a n d risks i n a project t h a t are not apparent i n a n internally focused risk management process. For instance, i n developing a software prod- uct, the customer focus may be grounded in compatibility or interface of systems, while the internal, project-oriented focus for software development might well be in conformance with performance requirements without much attention to interface issues.

Risks in customer expectation, needs, and requirements

Program and projects face customer risk is three areas and each challenges t h e risk management process:

Customer expectations

Customer needs

Customer requirements

Customer expectations. Sometimes customers expect more t h a n they specify i n written specification documents. Expectations change from new information uncovered in the project itself. The risk associated with customer expectations reflects t h e inherent value of projects themselves; a s products a n d service outcomes are produced and information is made available to the customer t h a t uncovers new opportunity, customers sometimes change their minds.

Customer needs. What the customer needs is not necessarily what the customer expects or requires. Needs suggests analytic data on customer needs, a n objective view of needs underlies the project process, but needs are seldom differentiated from expectations and requirements.

Customer requirements. Requirements a r e t h e actual specifications for t h e product or service outcome. Sometimes requirements a r e drawn u p by project teams based on what i s feasible rather t h a t what is required. The risk here is t h a t t h e requirements document does not adequately capture customer need.

Customer-Driven Pmject Management,TQM, and Risk 155

Risks in customer and sponsor relationships

There are two basic risks inherent i n the relationship with project customers and sponsors. They are:

1. Losing the commitment and support of sponsors. Project sponsors can with- draw support from a project for a variety of reasons unrelated to the project itself, e.g., financial issues, market turns, changes i n organizational leader- ship, mergers and acquisitions. The risk is t h a t the project manager will be surprised by such a withdrawal of support and have no contingency or "workaround" action to offset it. Again, it is the ability of the project manager to foresee factors t h a t might lead to loss of sponsor support that will lead to successful management of this risk.

2. Managing sponsor resistance to change. Sometimes a new product or serv- ice will produce changes in a customer or sponsor organization that can be dysfunctional. Thus the risk is t h a t the project manager again is surprised by resistance in a sponsor or customer organization to the very product or service the customer specified.

In both of these cases the lesson is this. Build and maintain a close relation- ship with your customer and sponsor to help anticipate risks and issues for the customer before the customer sees them.

Chapter

Strategic Planning and Risk- The Eastern Case

As indicated earlier, risk is inherent in the nature of the business itself. Business planning aimed a t developing a business strategy considers various risks and t h r e a t s t o its success i n t h e planning process. This chapter uses t h e case approach by addressing how a real company, termed the Eastern Company for purposes of this case, handles risk in its business planning process. Eastern is a global manufacturer and distributor of aluminum products.

Typically, the Eastern Company faces major competition and challenge from a global aluminum market and from foreign manufacturers who regularly "dump" aluminum into western markets a t very low prices. Thus there is con- tinuous risk i n the business from forces out of the control of internal company and project management. To address the risks inherent in its business, Eastern prepared a risk-based strategic plan.

Eastern faces eight risks and has developed eight strategic goals to address them.

Risk I . Required electric power will not be available a t a n affordable price. Strategy I . Secure economically priced power to reduce the risk of power

shortage.

Risk 2. Cost increase in aluminum manufacturing will increase faster t h a n margin. Strategy 2. Secure other resources a t reasonable costs to offset the risk of

cost escalation.

Risk 3. Customers will not be satisfied with Eastern's products. Strategy 3. Cultivate customer awareness and promote customer satisfac-

tion to avoid customer satisfaction risk.

Risk 4. Eastern's working environment will prove to be unsafe a n d t h e company will experience substantial loss of workforce and finance a s a result.

158 Chapter Nlne

Strategy 4. Create a safe working environment to control the risk of worker injury and associated costs.

Risk 5. The Eastern workforce will not grow with the technology available for continuous improvement.

Strategy 5. Build a responsible and knowledgeable workforce to avoid the risk of workforce instability.

Risk6. Eastern will not act to improve the technology of manufacturing in time to keep ahead of competitors.

Strategy 6. Improve technology and plant equipment to produce products more efficiently to control productivity risk.

Risk 7. Pollution from Eastern facilities will lead to noncompliance with government environmental requirements.

Strategy 7. Improve Eastern's impact on the environment to avoid the cost - ~ of pollution and noncompliance.

Risk 8. Increasing waste in the manufacturing process and workforce will lead to uncontrolled costs.

Strategy 8. Reduce waste and non-value-added costs to control the risk of wasted effort.

Eastern recognized the need to directly take action to sustain its ability to suc- cessfully compete on a continual basis in the world aluminum marketplace. The assumption was t h a t despite the fact that Eastern employees, in general, were dedicated to providing the highest-quality products and services to the cus- tomer a t a competitive price, and to providing a positive return for their owners' investment, they were heavily unionized. The company committed to the princi- ple that: We will not be able to step up to those challenges unless our employees- a n d the union-can see where we are going a n d wh.y, a n d have the opportunity - - to '%buy-in." It is through this strategic plan and its communication plan that they saw t h a t they could accomplish alignment and reduction of their considerable risk exposure.

The strategic plan was communicated continuously throughout the plant through special meetings and focus groups to ensure t h a t all employees under- stood it and could relate it to their work. Employees were encouraged to docu- ment actions they or their teams were taking to accomplish or support particular initiatives. This process would continue as we updated the plan annually and realigned our policies, procedures, and organizational structure to accomplish the plan.

This strategic plan was developed by the directors of Eastern with support from area managers.

Commitment and Partnership

Eastern management and the union stated directly that they were committed to this mission for the organization. I t was clearly recognized t h a t by working together to accomplish this mission, the interests of all participants would be

Strategic Planning and Rlsk-The Eastern Case 159

served. All management and employees would benefit from long-term job secu- rity, job enrichment, and the monetary rewards t h a t result from a successful business, which was able to manage its risks. Eastern's stakeholders and owners would benefit from the product recognition and profitability gained by produc- ing superior goods and services. Eastern's customers would benefit from the high quality and service levels delivered to them. Finally, the community was to enjoy a stable revenue base from the success of Eastern and from the skills and services individual employees offered.

Stakeholder relations

The company stated t h a t Eastern's stakeholders were people, organizations, or groups of people who have a vested interest in the success of the company. Their major stakeholders were:

Employees, who seek continued employment and income, quality of work life, and opportunities to learn and develop-their perceived risk was related to job security and lack of growth and development and marketability

Customers, who seek quality products a t low cost and reliable delivery-their perceived risk was related to product price and quality and timing, but mostly price. Cost was a major issue a s competitors dumped quality aluminum a t lower prices

Owners, who seek return on investment and continued viability-their risk was grounded in stock value

Regulators, who seek compliance with laws and regulations-their risk was in noncompliance with regulations and the cost of enforcement and litigation

Community, who seek contributions through taxes and service, and minimal environmental impact-their risk exposure was in losing the industry tax base but having to pay pollution and environmental control costs

Suppliers, who seek to meet Eastern requirements and continue business with Eastern-theheir perceived risk lies in their inability to meet Eastern con- tract requirements and having to share more of the risk in contracted work than they can handle

To illustrate the documentation of a risk-based strategy, the following docu- ment contains a n executive summary, situation analysis, and a detailed descrip- tion of eight key strategies. The situation analysis provides a framework for the strategies including mission and goals, management direction, SWOT analysis, and linkage to the parent company strategic plan. The eight strategies are sup- ported by specific initiatives and a system to measure achievements of those initiatives.

This strategic plan for Eastern Aluminum Company covered a 5-year period, from 1996 to 2000, and thus will help to guide the company and its employees into the twenty-first century. As the general long-term pathway to growth and

160 Chapter Nine

profitability, the plan presents the company's approach to achieving Eastern's cen- tral strategic goal-to compete successfully on a continuing basis in the world aluminum marketplace. The plan served a wide variety of purposes, including support to ownership decisions; support to budgeting and resource allocation; guidance for management and employee planning, training, and education; and support to long-term capital investment planning. A major element of the strate- gic planning process t h a t produced this document is the communication of the plan and its underlying vision, assumptions, and values to our employees.

The plan explored Eastern's current strengths, weaknesses, opportunities, and threats, and presented and discussed eight basic key strategies, initiatives, and measures to accomplish the central strategic goal.

Eight Strategies

Within the overall framework of the basic strategic goal to compete successfully in the world aluminum marketplace, and consistent with the parent company's strategic objectives, eight key strategies were a t the heart of this strategic plan:

1. Secure economically priced power.

Eastern would find ways to lower its power costs through a variety of strate- gies, including building stronger partnerships with power companies and state and local governments, and through exploration of independent options for generating less expensive power.

2. Secure other resources a t reasonable costs.

As the cost of materials rises, Eastern planned to find low-cost sources for raw materials as well as explore approaches for using lower-grade materi- als. Eastern would take the initiative to ensure t h a t effective partnerships are built with quality suppliers.

3. Cultivate customer awareness andpromote customer satisfaction.

Eastern would work to educate employees about customers and their require- ments and promote closer ties with customers. Greater appreciation of cus- tomers would give employees more incentive for addressing future customer requirements and connecting their daily work more clearly with the "value chain" to the customer.

4. Create a safe working environment.

Eastern was working to improve its safety record through enforcement of safety and health rules and regulations. Employees would be better edu- cated and trained to understand safety implications of their work. Safety com- pliance would be considered a major performance standard for all employees.

5. Build a responsible a n d knowledgeable workforce.

Facing a major workforce turnover i n the next 5 years, Eastern placed spe- cial emphasis on strategies to build a more responsible a n d skilled work- force, to improve the partnership with the union, to improve performance

Strategic Planning and Risk-The Eastern Case 161

and productivity, to lower labor costs, and to find better ways to work together through teamwork. They recognized t h a t if this strategy-grounded in the commitment to building a team-based organization-is not accomplished, Eastern could not thrive and grow even if the other strategies were accom- plished.

6. Improve technology a n d p l a n t equipment toproduceproducts more efficiently.

Eastern prided itself on its leadership i n technology and technical innovation and plans to continue this industry leadership. Eastern was managing sev- eral capital improvement projects to make major breakthroughs in produc- tivity and quality. Eastern felt it was demonstrating to its customers and its employees through these improvements t h a t major investments are being made in the plant to meet the challenges of the future global marketplace.

7. Improve Eastern's impact on the environment.

Through strict compliance with federal, state, and local environmental stan- dards, Eastern would continue to respond to and anticipate environmental impacts and address them. Special emphasis was made to meet new clean- air requirements.

8. Reduce waste a n d non-value-added costs.

Eastern continued to pursue quality and process improvement initiatives to eliminate unnecessary costs due to accidents, rework and scrap, outdated positions and job requirements, and equipment damage. Employees would continue to be trained and educated in process improvement and reengi- neering to streamline the way work is accomplished.

Overview

Eastern had already been turned around from a high-cost swing plant, with a confrontational labor atmosphere, to a much more competitive operation prac- ticing effective and efficient management and supervision, worker empower- ment, and self-directed team concepts. However, there was new urgency to ensure that all employees understood t h a t the plant would grow only "by per- mission" from future customers, and only if i t continuously improved its pro- ductivity, quality, and internal cohesion and teamwork across departments. The following text discusses how they were positioned to compete in the future.

Strengths, Weaknesses, Opportunities, and Threats

The following discussion covers Eastern's strengths, weaknesses, opportuni- ties, and threats.

Strengths

Eastern had made a concentrated effort to retain its competitive position in the marketplace through technology. Its major strength is its ability to produce quality products continuously, focus on technology and capital improvement, and

162 Chapter Nine

keep wages and salaries relatively high for its employees while controlling costs. Capital improvements and improved management and team practices have made it possible to achieve record premium production i n the recent past. Eastern continued to demonstrate its leadership i n technological improvements and plant capital investment.

Eastern had experienced the longest run a t full capacity in its history, remain- ing one of the few North American smelters not curtailed due to the recent metal surplus caused by t h e flow of aluminum into the world market from the Commonwealth of Independent States. Eastern continued to show resilience and responsiveness i n the face of changing market conditions.

Eastern was working hard to empower our w o r k f o r c ~ i m p r o v e their knowl- edge, skills, and responsiveness. They sought to align their incentive and reward programs, partnership practices with hourly employees, performance appraisal systems, and quality and process improvement initiatives with our key long-term strategies. They faced the future turnover of the workforce with a strong com- mitment to use the opportunities that changes bring to build a leaner, more inte- grated, and productive plant team.

At t h e heart of its strength was Eastern's traditional core competency to choose, operate, and improve process technology effectively; to produce a vari- ety of difficult-to-produce premium products; and to understand and meet cus- tomer needs. Whatever initiatives Eastern undertook, i t knew it h a d to continuously improve these drivers of success.

Weaknesses

Eastern's products (primary, slab, billet, tee, and foundry pig) were priced by the worldwide commodities market. High quality and excellent service of these products would ensure a positive customer relationship, but Eastern could not control the selling price of the finished product.

Eastern knew t h a t it was a high-cost plant compared to other producers, pri- marily because of the age of the facility and technology, and because of high wages, salaries, and fringe benefit levels. Because Eastern had little or no con- trol over the market price, the cost of producing aluminum became a key deter- mining factor i n remaining globally competitive. I n fact, 75 percent of all aluminum in the world was being produced a t a cost lower t h a n Eastern.

Eastern faced major challenges in turning over its workforce and creating a more energetic a n d knowledgeable workforce team. Past practices had not always inspired employees to align themselves with the plant's best interests and commit themselves to continuous improvement through teams.

Eastern needed to improve its ability to learn and document its successes, in short, to become a "learning" organization. Past practice h a d not always taken advantage of what the organization had already learned through the years.

Opportunities

Demand for aluminum was continuing to rise; supplies of aluminum had increased each year with primary aluminum products now sold on a worldwide basis.

Strategic Planning and Risk-The Eastern Case 163

Eastern had the opportunity to position itself a t the midpoint on the world cost scale, the point a t which 50 percent of world production costs would be higher than Eastern's. I n achieving this position, Eastern could take more advantage of its high-quality products and services and its improving productivity.

A reduction of 4 cents per pound by 1999 would have placed Eastern in t h a t competitive position, keeping mind that other aluminum plants are also attempt- ing to reduce their costs.

Eastern's major opportunity was to improve its process efficiency and pro- ductivity through a combination of technology and capital improvement, build- ing a more efficient workforce and reducing labor costs. The 4 cents per pound cost reduction could be achieved by:

1. Conversion of potlines (production lines) to a new "point feed" technology already underway.

2. Reduction of man-hours per ton by 15 percent from 1996 to 2000.

3. Reduction of non-value-added costs wherever possible through process improvements, total quality management, I S 0 9000 certification, and other quality initiatives.

Eastern had a major opportunity to improve its human resource practices and programs a s the plant transitions its workforce in the coming five years, both through better training and development of supervisory and hourly employees, and better, more effective assessment and hiring practices.

Threats and R i s k s

If Eastern did not continually reduce costs, their position would worsen because:

1. New plants with lower costs would open.

2. Existing competitive plants would reduce cost and improve their cost position.

3. Other plants with higher costs would close, worsening Eastern's position.

The most critical of these risks was the possibility that power costs would con- tinue to rise beyond Eastern's capacity to absorb them. This scenario represented the most significant threat to Eastern's continued growth and had to be avoided. I n addition to power costs, the long-term cost of coal could be another impor- t a n t threat to Eastern growth, as well a s unanticipated environmental regula- tions, particularly from the federal clean air act.

In addition, although Eastern had made major progress in building a more team-based culture, the process could not be slowed by resistance to change and failure to be clear about new roles and functions. Therefore, one source of threat and risk was clearly from within, the threat of slow deterioration of the momen- t u m of teamwork and process improvement already underway. Such a step backward could always happen a s a result of neglect and a lack of trust and respect i n the organization.

164 Chapter Nine

Eastern's Strategic Plan

Eastern's strategic plan was a n integrated set of strategies, initiatives, and measures supporting a n overall goal of competitiveness. Figure 9.1 presents a graphic depiction of the company's eight key strategies. Each strategy was seen a s serving the central goal of world competitiveness, but each strategy was also inextricably tied to the others, indicating a strong interdependency of all plan elements. If any one strategy and risk-reduction plan was not accomplished, overall achievement of the goal suffered.

The plan describes plant strategies, initiatives, and measures of success. Initiatives are programs and projects now underway or planned to help accom- plish a particular strategy. Measures are indicators of progress and will be used to monitor the achievements of the eight key strategies.

Underlying elements of the risk-based strategic plan

Five major elements formed the basis for this risk-based strategic plan- mission, commitment and partnership, driving forces, core competencies, and stakeholder relations. They are discussed below.

Mission. Eastern's mission was to be the most cost-effective producer of the highest-quality primary aluminum products shipped on time to its customers,

Reduce waste and non value added

con- to avold cost

priced powcr to avoid risk oI inefficient rices. ?-

pmrnote customer satlsfaction to avoid risk of "undrlighted"

equipment to produce products more efficiently to avold

Figure 9.1 Eight key strategies.

Strategic Planning and Risk-The Eastern Case 165

with optimum utilization of resources. They placed special emphasis on their employees a n d their role in defining the company's mission and on good community relations. They recognized t h a t accomplishing the mission involved a never-ending journey of continuous improvement.

Commitment and partnership. Eastern management a n d the union indicated t h a t they were committed to this mission for the organization. It was clearly recognized t h a t by working together to accomplish this mission, the interests of all participants were best served. All management and employees would benefit from long-term job security, job enrichment, and the monetary rewards t h a t resulted from a successful business. Eastern's stakeholders and owners would benefit from the product recognition and profitability gained by producing superior goods and services. Eastern's customers would benefit from t h e high quality and service levels delivered to them. Finally, t h e community would enjoy a stable revenue base from the success of Eastern and from the skills and services individual employees can offer.

Driving force: production capability. An underlying element i n this strategic plan was the single most important driver of company success-its capability to convert resources effectively into products through highly organized and managed production processes. Their value-added for the future will continue to be their capacity to produce products continuously.

Core cornpetencles and risk contingencies. Three core competencies separated Eastern from its competitors:

1. Its capacity to effectively choose, operate, a n d improve process technology. Its ability to keep up with technology change was rooted i n its ability to anticipate technology risk stemming from out-of-date technology.

2. Its capacity to produce a variety of difficult premium products. I t s ability to change its production systems quickly was rooted in its ability to antici- pate the risks of change in product requirements and plan for them.

3. Its capacity to understand a n d service customer needs. Its capacity to under- stand its customers and especially to anticipate and manage customer serv- ices to reduce the risk of failed customer service expectations.

Eastern would strive t o maintain and build on these core competencies.

More on eight key strategies

Eastern identified eight key strategies to carry out its central strategic goal of global competitiveness. Each strategy was carried out through several initia- tives and was monitored by the measures presented and discussed below.

Strategy 1-Secure economically priced power. The cost of power was a major factor in Eastern strategic plan. I n its partnership with the community, power

166 Chapter Nine

TABLE 9.1 Measures and Risks: Cost of Power

Initiatives Measures Risks

Address power pricing issues by: Maintaining relationships with Potomac Edison, Public Service Commission, People's Council, local and state government

Investigating power-wheeling sources and benefits

Developing alternative power sources, including self- generation

Increasing community support for reducing Eastern's power costs

Eliminating power modulation

Reduced power costs by 2 to 4 mills per Kilowatt hour (approximately $6 to 12 millionlyear)

Favorable public response and concern for Eastern's power pricing issues

That relationships with stakeholder agencies would deteriorate

That power-wheeling sources (independent sources of power created by deregulation) would not provide lower prices

That self-generation of power would fail either from technology problems or cost

That the community would not support Eastern

That power modulation-the practice of energy providers to reduce power could not be a n t i c i ~ a t e d

companies, and state and local government, Eastern would develop support for its efforts to continue to compete i n the world aluminum marketplace. Eastern planned to negotiate lower power costs and to explore independent options for generating less expensive power (Table 9.1).

Power costs became the key factor in maintaining competitiveness because of impending major increases in costs from new sources. Eastern management was working closely with utilities, government officials, the community, and other power sources to ensure t h a t i t can achieve independence in power gen- eration should t h a t be necessary. Power-wheeling sources and benefits were being pursued as well as self-generation options.

While this issue is beyond the scope of any one employee, special attention was given to communicating the power cost issue to all employees so t h a t they could understand the urgency of the situation and help Eastern to achieve power independence.

Strategy 2-Secure other resources at reasonable costs. The cost of materials continued to rise and had the potential to erase savings created by increased productivity and reduced power costs. Eastern planned to find low-cost sources for raw materials a s well as explore approaches for using lower-grade materials. Eastern would continue to manage human resources costs through employee attrition and retirements (Table 9.2).

Key raw materials (alumina, aluminum fluoride, petroleum coke, and liquid pitch) were purchased for all parent company smelters by the same parent office. These costs were rising to a point such that the Eastern's overall cost effec- tiveness was threatened.

This issue challenged the company's capacity to find and use lower-grade materials such a s calciner fines and lower grades of petroleum coke. The com- pany would continue to acquire both raw materials and supplies from the most efficient sources while assuring quality. This involved forming partnerships

Strategic Planning and Risk-The Eastern Case 167

TABLE 9.2 Resources: Measures and Costs

Initiatives Measures Risks

Obtain raw materials such a s Maintain or decrease current That raw materials would not be petroleum coke, pitches, alumina, raw material costs available on a just-in-time basis and hardeners

Secure high-quality supplies from the most economical sources

Manage human resource (labor) costs Reduce man-hours per ton by That human resource costs would through attrition and retirements 15 percent by the year 2000 inflate and attrition goals would

Contribute to overall not be achieved efficiency and productivity

Explore innovative approaches to Maintain or decrease current That lower-grade materials would using lower-grade materials such a s raw material costs be acquired calciner fines and lower grades of petroleum coke

with suppliers to limit the number of such sources. This would accomplish two objectives-holding down costs and minimizing purchasing and warehousing requirements.

As a major cost element, labor costs had to be controlled while productivity was enhanced through capital improvements and better management, team, and individual performance. Reduction of man-hours per ton by 15 percent by the year 2000 was a major measure of success in reducing risk exposure.

Strategy 3-Cultivate customer awareness and promote customer satisfaction. Eastern continued to provide consistent and high-quality products and services to end-users a n d customers. The company would work to ensure t h a t all employees were aware of customers and their needs. Emphasis on the customer would encourage the development of new products and services and help Eastern establish a larger market niche. Eastern would look to external stakeholders to verify gains made in employee customer awareness and customer satisfaction (Table 9.3).

Eastern had to establish a market niche i n high-quality, premium products to remain a viable company and successfully compete. To meet this demand, Eastern h a d to work closely with i t s ownership to identify future customer needs. Eastern would continue to work with parent company marketing teams in the areas of initial order processing, customer team visits, and customer surveys.

Eastern would also make i t easier for customers t o deal with the plant. Increased use of bar code systems and electronic data interchange would be planned, establishing a "seamless" electronic relationship with prospective cus- tomers. More attention would be paid to promoting our laboratory and metal- lography capabilities.

The continuing move to quality worldwide was having its impact on the com- pany. More customer inquiries, such a s from the automotive industry, were

168 Chapter Nine

TABLE 9.3 Employee Awareness: Measures and Risks

Initiatives Measures Risks

Enhance employees awareness Third-party assessment of employees' That employees were not able about customer and customer awareness to connect their success with end-product satisfaction Recognition through accreditation and company success in

quality audits (American Association end-product quality for Laboratory Accreditation, and the like)

Selectively diversify products Capacity to change products That its product mix could not and services to support Number of customer assists through the be diversified market expansion Metal Quality Group

Support parent company Inventory Management System ( m S ) That the parent company marketing strategy data strategy was not consistent

Market services to make Customer team visit comments with Eastern's strategic plan customers aware of Eastern's Customer satisfaction data and core competence capabilities

Focus on individual customer International Standards Organization That Eastern's process demands in metallurgy, @SO) 9000 registration improvement efforts were not product chemistry, packaging QS 9002 accreditation successful because of and delivery requirements Monitor customer claims and contacts personnel and union through process improvement about technology services and products disincentives

Develop a long-term cast house Review customer satisfaction survey plan and monitoring systems results

Improved product turnaround indicators

Set up cross-functional teams Internal custamer satisfaction surveys That cross-functional teams to increase awareness of Extent to which internal customer would not work because of internal customers requirements are met internal conflicts and role

definitions

expected regarding our quality standards. This development prompted efforts to maintain registration a n d refine documentation to both I S 0 9000 and American Association of Laboratory Accreditation, and for attaining QS 9000 and 14000 certification a s well. Increased cycle time was becoming a major cus- tomer exvectation. generating internal plans to develop systems to measure . - - order entry, production scheduling, and shipping performance.

Finallv. because manv emvlovees did not have a direct relationship with cus- ", " - 7 tomers and customer needs, the company was undertaking a program to enhance employee appreciation of customer needs. This program included use of a third- party organization to monitor employees' understanding of these issues.

Strategy 4--Create a safe working environment. Eastern had si@icantly reduced accidents in recent years and needed the support of employees and management to continue these safety efforts. I n addition to developing and implementing state-of-the-art safety procedures and guidelines, the company needed to enforce safety and health rules and regulations consistently (Table 9.4).

Eastern recognized its responsibility and accountability for the safety and health of each employee and for t h e preservation of property and equipment.

Strategic Planning and Risk-The Eastern Case 169

TABLE 9.4 Safe Working Environment: Measures and Risks

Initiatives Measures Risks

Eliminate safety and health Decrease accident incident rate That safety initiatives would not hazards by: Stay within accident and safety be accepted and implemented by

Upgrading engineering scorecard budget employees and managers standards, safety features and Improve safety severity ratio index That safety guidelines and ergonomics consistently Rate of completion of items on regulations would shift

Promoting employee awareness safety list and audits substantially Updating Joint Safety and Improvements in efficiency and job Health Committee guidelines performance

Enforcing rules and regulations Improved plant safety performance Increasing team and employee record accountability for safety and Increased safety gain sharing health payout

The company would continue to incorporate into the design and operation of all facilities safeguards and procedures that will minimize risks of personal injury and loss of property and equipment. Management was responsible and account- able for the safety and safe work conduct of all employees who report to them. Employees were equally responsible and accountable for safe practices a s well a s assisting in the ongoing safety program by reporting unsafe practices, pro- cedures, or conditions when they were observed.

As indicated i n the initiatives underway as part of this strategy, Eastern was giving special priority to upgrading engineering standards to reflect safety requirements and criteria. I n some cases, this could have meant added cost and time constraints on planned capital projects, a n expense well worth the investment in a safer working environment.

Strategy !+Build a responsible and knowledgeable workforce. By increasing the skills and abilities of individuals, teams, and supervisors and empowering them, Eastern would be able to increase productivity, reduce operating costs, solve personnel problems, and increase teamwork across the entire plant. Initiatives in support of this priority included training and developmental opportunities in support of self-directed work teams (Table 9.5).

S t r a t e w 5 held the kev t o successful achievement of the balance of t h e other -" strategies-the building of a workforce and organization that: (1) was aligned with the strategic direction of Eastern: (2) was structured, capable, and moti- - . . . vated to improve performance; and (3) worked together across departments to provide a "seamless" process of production and quality.

I n building a flatter, more streamlined workforce, t h e company's strategy in the past had been to press for reduced manning and more teams and teamwork. As a result, many teams had been generated and trained to take responsibility to solve problems and make decisions necessary to keep their process operat- ing a t peak efficiency. Supervisory and hourly positions were reduced and roles and functions were changed.

170 Chapter Nine

TABLE 9.5 WorkforceTeams: Measures and Risks

Initiatives Measures Risks

Develop or continue: Continuation of empowered, self- directed work team development (decision-making and responsibility)

New performance appraisal system for salaried employees

Development planning Knowledge and skills training for bargaining unit employees

Supervisory development program Strategic plan communication process Conversion to parent salary structure New bargaining unit job classification (stemming from the labor contract)

HR strategic plan

Offer developmental opportunities to sustain employee education and growth through:

Mentoring Inside training Outside technical managerial training

Opportunities to manage

Better communication and coordination within team members and between supervisors and teams

Innovative, timely, and sound employee and team decision- making

Better use of tools, equipment, and raw materials

Employees will be prepared to assume new responsibilities as a result of developmental exposure

Enhanced partnership agreement Increase i n ideas and solutions from employees

Reduce man-hours per ton

Successful development planning Track progress through training records

Enhanced employee performance

That self-directed teams would not work in the unionized work setting

That employees would not act on incentives to train and develop new s k i s

That the strategic plan communication plan is not effective in improving employee support of company goals

That the plant could not implement mentoring and training initiatives because of the company culture

Now in the spirit of building t h e total Eastern organization, t h e company's strategic emphasis would go beyond reduced manning a n d generation of teams. The strategy would be focused on organizational effectiveness-building the whole organization through a stronger linkage and alignment between - - - - - management, supervisors, a n d bargaining unit employees. The opportunity before company management was to build new supervisory roles and functions - - - into our new team-based organization, requiring development of leadership skills, better business and productivity management and monitoring skills, a n d more support for technical supervision and cross-department process improvement. Support services such a s h u m a n resources management were present to help to lead t h e effort. Organizational barriers to effective super- vision would be identified a n d eliminated. Organizational a n d training ini- tiatives were underway to help supervisors function a s t h e guiding force for day-to-day operations.

Development tools would include business and productivity management, process improvement, facilitating and mentoring opportunities, inside training, outside development (technical and managerial), and management opportuni- ties within the organization. To focus on incentives, Eastern would review its performance appraisal and gainsharing structure to ensure t h a t they were aligned with this strategic plan, and making improvements when called for.

Strategic Planning and Risk-The Eastern Case 171

To ensure effective communication, quarterly plant communication meetings would continue and more information would be provided to employees "online," especially in the area of human resources.

Strategy &Improve technology and plant equipment to produce products more efficiently. The company was managing several capital improvement projects to upgrade the condition of equipment and work processes a t the plant. The company needed to continue these improvements while also employing sound capital project management skills. Eastern would work to speed up completion of these capital projects a n d t o keep them within budget and quality requirements (Table 9.6).

As evidenced in the partial list of capital improvements above, Eastern was heavily engaged in upgrading its technological and equipment base in order to maintain its leadership and core competency. The company was a front-runner in keeping pace with required capital improvements to aging plant infrastruc- ture. Improvements are underway in the product production lines, carbon plant, cast house, substation, and laboratory, and in general plant functions such as emission and noise control, and information system management.

TABLE 9.6 Capital Improvement: Measures and Risks

Initiatives Measures Risks

Complete capital program and Completion of capital improvements, That capital budgets would not budgets each year including be completed

Conduct major maintenance Conversion of potlines to point feed That maintenance projects are projects and overhauls technology not completed for a variety of

Substation life extension reasons Cast house continuous homogenizing furnace

Rod shop anode cleaner Ladle shop ladle cleaner Bake oven rebuild Potline capacity expansion Rebuilt remelt furnace Developed stack filter systems for metal treatment Facilities expansion Completed stamper upgrades for billet and slab

Conduct research to ensure that Completion of research and That necessary research on Eastern adapts or incorporates development @&D) projects within emerging technologies is not improved or emerging budget conducted technologies

Develop a stronger capital Improved capacity to complete That the project control system project management system projects on time within budget and is not made operational through training and other schedule developmental assignments

172 Chapter Nine

The focus for this strategic plan was the completion of capital projects within budget, schedule, and technical requirements. This meant developing a stronger capital project management system and employing more effective project man- agement practices.

Strategy 7-Improve Eastern's impact on the environment. The company would continue to monitor its impact on the local environment. These efforts would be directed toward reducing environmental degradation and pollution F a b l e 9.7).

This strategy addressed the company's environmental a n d community rela- tions practices. Eastern would continue to stay ahead of environmental require- ments through two basic approaches-41) being proactive in assisting regulators a t all levels i n developing sound and cost-effective regulations t h a t both imple- ment environmental legislation and meet t h e needs of community a n d t h e business and (2) planning and implementing capital improvements a n d oper- ating measures to comply with environmental requirements, attempting a t the same time to ensure t h a t such improvements also contribute to overall plant productivity.

Costs of compliance would increase a s well in the administrative areas of record keeping, reporting, training, planning, and monitoring, and in acquisi- tion of necessary monitoring equipment, creating the need to streamline these systems. Eastern would continue to develop the capacity to prevent pollution through technology improvements and through a multimedia approach t h a t

TABLE 9.7 Regulatory Compliance: Measures and Risks

Initiatives Measures Risks

Comply with federal, state, and local Eliminate incidents of That new regulations that environmental regulations by: noncompliance Eastern could not respond to

Providing proactive assistance to Monitor response time for would be enacted regulators identifying and fixing violations

Educating employees about regulatory requirements

Promptly reporting noncompliance and correcting any violations

Filing Title V air permit application Participate in voluntary activities on Eliminate environmental, safety, That voluntary efforts do not environment, safety and health or health complaints about the improve community relations issues, such as EPA Greenlights, plant or its operations reducing greenhouse gases and PFCs, and noise nuisance reduction

Encourage environmentally sound Partnerships with state and That local growth objectives and industrial and agricultural growth local agencies dynamics would change

substantially

Continue farm production Farm production and That the company's efforts a t maintenance of safe farm production around the environmental practices fringe of the plant were

unsuccessful

Strategic Planning and Risk-The Eastern Case 173

addresses losses of material to air, storm water runoff and solid or liquid waste streams.

Strategy 8-Reduce waste and non-value-added costs. Eastern continued to experience waste and non-value-added costs, such a s safety and property costs related to accidents, rework and scrap, and equipment damage. Process improvement and problem-solving teams would continue to focus on reducing these costs (Table 9.8).

This strategy was in concert with strategy 5 to build a knowledgeable and pro- ductive workforce. Both were required to improve overall productivity. This strat- egy was key to improving the overall productivity of Eastern by eliminating waste and unnecessary work, for example, by reducing the cost of poor quality through process improvement and IS0 and QS 9000 and 14000 documentation.

The company's quality and process improvement efforts started on t h e pro- duction floor where its quality was built-in through consistent practices and extensive use of statistical process-control methods. Eastern was committed to being quality-driven, not cost-driven, thus the quickest route to elimination of waste and non-value-added costs was "doing it right the first time." They looked to this strategy to be a major factor in lowering our operating expenses by 4 cents per pound.

TABLE 9.8 Costs of Waste: Measures and Risks

Initiatives Measures Risks

Involve quality and risk reduction Amount of rework and scrap by That the company teams were teams in identifying and resolving department on a monthly basis not successful in resolving quality problems i n key Stay within approved budget quality issues production processes guidelines for rework and scrap

costs

Minimize equipment damage by Review monthly maintenance to That equipment damage rates educating employees, monitoring ensure departmental continued equipment use, and enforcing accountability for responsible rules for properly using equipment equipment use

Stay within approved budget guidelines for equipment expenses

Eliminate duplication of effort in Benchmark other processes That administrative administrative processes Monitor process costs redundancy and increase costs

Process improvemenffreengineering of operation continued Encourage employee use of best practice techniques

Improve inventory management of Reduce inventory by a t least That inventory management supplies and equipment (includes 5 percent initiatives were not successful maintenance, production, and raw because of internal plant or material in-process) supplier performance

limitations Minimize waste generation and Waste product reductions That increasing rates of waste increase recycling production would continue

174 Chapter Nine

The teams would continue to identify and resolve quality problems in key pro- duction processes-a new focus would be placed on administrative and support processes to ensure t h a t they were under review i n t h e context of process improvement a s well.

Communicating Strategy and Risk

The company prepared a communication program t o promote t h e company strategy and to explain the risks inherent in the business and the local plant setting. The structure of t h a t plan has been provided below.

Key strategic goal. Improve Eastern's capability to compete on a continuing basis in the world aluminum market place.

Explanation of strategies

Strategy l-Secure economically prlced power. The cost of power is a major factor in Eastern's strategic plan. I n i t s partnership with t h e community, power companies, and state and local government, Eastern will develop support for its efforts to continue to compete in the world aluminum marketplace. The company plans to negotiate lower power costs and to explore independent options for generating less expensive power F a b l e 9.9).

Strategy 2--Secure other resources at reasonable costs. The cost of materials continues to rise and has the potential to erase savings created by increased productivity and by reduced power costs. The company plans to find low-cost sources for raw materials a s well a s explore approaches for using lower-grade materials. Eastern will also continue to manage human resource costs through attrition and retirements (Table 9.10).

Strategy 3-Cultivate customer awareness and promote customer satisfaction. Eastern continues to provide consistent and high-quality products and services to end-users and customers. Eastern will work to ensure t h a t all employees are

TABLE 9.9 Strategy 1: Secure Economically Priced Power

What we will do How we will measure achievement

Maintain relationships with Public Service Commission, Pwple's Council, local and state government

Investigate power-wheeling sources and benefits Develop alternative power sources

Increase community support for reducing Eastern's power costs

Reduced projected power costs by 2 to 4 mills per kilowatt hour (approximately $6 to 12 millionlyear)

Report to support decision Alternative power contracts Obtain favorable public response and concern for Eastern's power pricing issues as indicated by favorable legislative and regulatory decisions

Eliminate power modulation Effective date, 111197

Strategic Planning and Risk-The Eastern Case 175

TABLE 9.10 Strategy 2: Secure Other Resoumes at Reasonable Costs - -

What we will do How we will measure achievement

Obtain lower cost raw materials such a s petroleum Continuous reduction in raw material costs coke, pitch, alumina, and hardeners

Secure high-quality supplies from the most Reduction in rework due to supply quality economical sources

Explore innovative approaches ta using alternative Cost reduction graded materials, such a s calciner fines and lower grades of petroleum coke

Reduce human resource (labor) costs through attrition Reduce man-hours per ton (MPT) by 15 percent by and retirements theyear2000

aware of customers and their needs. Emphasis on t h e customer may encourage the development of new products and services and help the company establish a market niche. The company will look to external stakeholders to verify gains made in employee customer awareness and customer satisfaction (Table 9.11).

Strategy 4--Create a safe working environment. Eastern has significantly reduced accidents in recent years, and needs the support of employees and management to continue these safety efforts. I n addition to developing and implementing

TABLE 9.1 1 Strategy 3: Cultivate Customer Awareness and Promote Customer Satisfaction

What we will do How we will measure achievement

Enhance employees' awareness about customer and end-product satisfaction through a customer education and visit program

Selectively diversify products and services to support Alumax market expansion

Support parent marketing strategy Market services to make customers aware of Eastern's capabilities

Focus on individual customer demands in metallurgy, product chemistry, packaging, and delivery requirements through process improvement

Develop a long-term cast house plan and monitoring systems

Set up cmss-fundional teams to increase awareness of the needs of internal customers within plant operations

Third-party ratings and assessments of employees' customer awareness

Recognition through accreditation and quality audits (American Association for Laboratory Accreditation, and the like) I S 0 9002, QS 9000

Capacity to change products as measured by new product cycle times

Numher of customer assists through the Metal Quality Group

Alumax inventory management system (AIMS) data on the results of inventory management initiatives

Customer team visit comments Customer satisfaction data International Standards Organization @SO) 9002 registration

QS 9000 accreditation Monitor customer claims and contacts about technology services and products

Review customer satisfaction survey results Improved product turnaround indicators Internal custamer satisfaction surveys Extent to which internal customer requirements are met

176 Chapter Nine

TABLE 9.12 Strategy 4: Create a Safeworking Environment

What we will do How we will measure achievement

Upgrade engineering standards, safety features, and Achieve 1 miUion accident free hours ergonomics Stay within accident and safety scorecard budget

Promote employee awareness Rate of completion of items on safety list and audits Update Joint Safety and Health Committee guidelines Improve efficiency and job performance Enforce rules and regulations Improved overall plant safety performance record Increase team and employee accountability for safety Increased safety gain-sharing payouts and health

state-of-the-art safety procedures a n d guidelines, Eastern needs to enforce safety and health rules and regulations consistently (Table 9.12).

Strategy &Build a responsible and knowledgeable workforce. By increasing t h e skills and abilities of individuals, teams, and supervisors and empowering them, Eastern will be able to increase productivity, reduce operating costs, solve problems, and increase teamwork across the entire plant. Initiatives in support of this priority include training and developmental opportunities i n support of self-directed work teams (Table 9.13).

Strategy 6-Improve technology and plant equipment to produce products more efficiently and more economically. Eastern is managing several capital improvement projects to upgrade the condition of equipment and work processes a t the plant. Eastern needs t o continue these improvements while also employing sound capital project management skills. The company will work to

TABLE 9.13 Strategy 5: Build a Responsible and Knowledgeable Workforce

What we will do How we will measure achievement

Develop or continue: Empowered, self-directed work team development (decision-making and responsibility)

New performance appraisal system for salaried employees

Development planning Knowledge and skills training for bargaining unit employees

Supervisory development program Strategic plan communication process Conversion to parent salary structure New bargaining unit job classification (stemming from the labor contract)

Better communication and coordination within team members a s measured by regular employee surveys

Innovative, timely, and sound employee and team decision-making a s measured by efficiency of meetings and performance results

Better use of tools, equipment, and raw materials, a s measured by tool replacement costs

Employees are prepared to assume new responsibilities measured by increase in voluntary assignments

Enhanced partnership agreement measured by reduced grievances

Increase in number of ideas and suggestions from employees

Reduce man-hours per ton

Offer developmental opportunities to sustain Successful development planning employee education and growth through: Track progress through training records

Mentoring Enhanced employee performance Inside training Outside technical managerial training Opportunities to manage

Strategic Planning and Risk-The Eastern Case 177

TABLE 9.14 Strategy 6: ImprweTechnology and Plant Equipment to Produce Products More Efficiently and More Economically

What we will do -

How we will measure achievement

Complete capital program and budgets each year Conduct major maintenance projects and overhauls

Conduct research to ensure that Eastern adapts or incorporates improved or emerging technologies

Develop a stronger capital project management system through training and other developmental assignments

Completion of capital improvements, including: Conversion of production line to point feed technology Substation life extension Cast house continuous homogenizing furnace Rod shop anode cleaner Ladle shop ladle cleaner Bake oven rebuild Production line capacity expansion Rebuilt remelt furnace Developed stack filter systems for metal treatment Facilities expansion Completed stamper upgrades for billet and slab

Completion of R&D projects within budget

Improved capacity to complete projects on time within budget and schedule

speed up completion of these capital projects and to keep them within budget and quality requirements (Table 9.14).

Strategy 7--Improve Eastern's impact on the environment. Through voluntary efforts and i n compliance with s t a t e environmental standards, t h e company will . - continue to monitor its impact on the local environment. These efforts will be directed toward reducing environmental degradation and pollution (Table 9.15).

TABLE 9.15 Strategy 7: Improve Eastern's Impact on the Environment

What we will do How we will measure achievement

Comply with federal, state, and local environmental Eliminate incidents of noncompliance regulations by: Reduce response time for identifying and fixing

Providing proactive assistance to regulators violations Educating employees about regulatory requirements Trainning feedback Promptly reporting noncompliance and correcting any violations

Filing a Title V air permit application for Compliance environmental capital improvements

Participate i n voluntary activities on environment, Eliminate environmental, safety, or health complaints safety and health issues, such a s EPA Greenlights, about the plant or its operations reducing greenhouse gases and PFCs, and noise nuisance reduction

Encourage environmentally sound industrial and Community satisfaction, a s measured by community agricultural growth recognition of Eastern's practices

Continue farm production Farm production and maintenance of safe environmental practices

178 Chapter Nine

TABLE 9.16 Strategy 6: Reduce Waste and Non-Value-Added Costs

What we will do How we will measure achievement

Involve QUEST teams in identifying and resolving Reduction of rework and scrap tracked by the quality problems i n key production processes department on a monthly basis

Zero increase in budget for rework and scrap costs

Minimize equipment damage by educating Review monthly maintenance to ensure departmental employees, monitoring equipment use, and accountability for responsible equipment use enforcing rules for properly using equipment Stay within approved budget guidelines for

equipment expenses

Eliminate duplication of effort i n administrative Benchmark other processes processes Monitor process costs

Process improvementlreengineering Encourage employee use of best practice techniques

Improve inventory management of supplies and Reduce inventory by a t least 5 percent equipment (includes maintenance, production, and raw material in-process)

Minimize waste generation and increase recycling Waste product reductions

Strategy &Reduce waste and non-value-added costs. Eastern continues t o experience waste and non-value-added costs, such a s safety and health costs related to accidents, rework and scrap, a n d equipment damage. Process improvement and problem-solving teams will continue to focus on reducing these costs (Table 9.16).

Postscript to the Strategic Plan

The Eastern strategic plan had been designed as a guidepost for the future, a way of realizing the vision of becoming more responsive to changes going on glob- ally, more supportive to customers and employees, and more cost-effective in manufacturing processes. However, it was not a "cookbook" for success. They rec- - - ognized t h a t management a n d employees would continue to have to make informed judgments together each day to make the plan work. And they would

~ -

have to learn better from their successes and mistakes.

Acquisition and Merger

Although the strategic planning and risk-reduction process was a focused and comprehensive process, and had measurable impacts on plant productivity a n d success in dealing with its costs and product problems, a major development was not anticipated i n the process-acquisition.

During t h e process of developing and implementing the plan, the company was acquired by a competing parent company, creating a high degree of uncer- tainty and disruption in the process. Work in implementing the plan was halted until the acquisition and merger process was completed, t h u s tempering what payoffs could have been produced.

Chapter

Risk Lessons Learned and the Project Risk Audit

There are two kinds of "postmortem" on a project and both open up opportuni- ties to look back a t the risk management process to see what worked and what did not. This chapter addresses how to do a risk "lessons learned" review and a project risk audit, gives examples, and provides insights on corrective actions based on actual risk feedback from postmortem sessions.

I n Fig. 10.1, "lessons learned" is the first step. This is the process of bringing the team together for a n informal discussion of what went wrong and what went right in the project and what the impacts were. Then t h e team identifies where such lessons can be applied in the risk management process, and iden- tifies possible institutional or organizational problems associated with the les- sons learned. Potential audit issues are identified and then a n audit is conducted on the issues top management would like to earmark for policy, system, or orga- nizational change.

The value of a timely postmortem "lessons learned" review lies in the cap- turing of insights of the project team members and stakeholders and docu- mented information on the project cycle, fresh from "combat." The process is like a military debriefing in the sense t h a t it is well-focused and tries to capture the intensity of feeling and information all a t once. The implications for successful risk management in future projects are major since it is in the insights about what did and did not work t h a t the organization and management team gains valuable information on future project risks and opportunities.

Project Audits

Project audits are not the same a s lessons learned. Project audits are performed by external teams who have not been part of the project process--objective out- siders. The audit has been described a s "the process of coming down off the

Lessons learned

Looks at how risks were managed Dimensions impacts Focus on team experiences Lists pmblems Lists root causes w

Documentlapply lessons learned

Identifies where lesson can be

Documents lesson learned and audit

Project risk a u d l

Review lessons learned Evaluates audit issues Selects audit issue Conducts audit

System and procedure change I Makes institutional change, policies, procedures,

Figure 10.1 Transition from lessons learned ta audit.

mountain after the battle to kill the wounded." Such audits can be very useful if they address issues already identified by the project team. The purpose of an audit is to connect factors t h a t contributed to project successes and failures based on documents and recorded information, and to match the project out- comes with project goals and objectives.

How to Do Risk Lessons Learned Review

Alessons learned project review should be conducted soon after project close out and should include all project team members, a member of top management, and stakeholder representatives. The focus should be on identifying what went right and what went wrong and dimensioning what went wrong i n terms of unan- ticipated or unmitigated risks and uncertainty. This can be accomplished by scheduling and facilitating the meeting around key risk issues or topics that help to capture the risks inherent i n the project. The following is an example of a n outcome report from a risk lessons learned session in a modern avionics instru- ment product development process.

Example o f a lessons learned report

What went right? (Things that we w a n t t o recreate f o r future projects)

This was a focused team with largely full-time assignments

Our team was autonomous-we drew the line with the customer appropriate "windows" for changes, disruptions, and the like

Little or no scope creep

Resources (e.g., test equip) allocated to resolve problems quickly

m Contingency plans in place when necessary

Risk Lessons Learned and the Project Risk Audit 181

Team defined its approach to documentation, and the like together, "as we went" (also noted as a weakness below)

Communication within team was good

Consistent high priority on this project from corporate-this was a high- visibility, high-priority project from the beginning and we knew it

Responsiveness of team members to each other very effective

Project itself was not technically insurmountable; success was feasible

Team able to separate what was controllable from what was not-such a s flight test-and managed accordingly

Team was highly proficient; good professional and technical skills

Scheduling process handled resource issues somehow

Program manager was open to change; flexible in responding to team issues

Program manager used schedules a s guides but was very task and action oriented in meetings

What went wrong? (Things that we want to correct for future projects)

Company process and procedure requirements and differing interpretations of document requirements sometimes acted a s barriers to necessary work and did not always facilitate successful completion of the project, e.g.? software documents, reference documents, and tables

We sometimes described procedures after we completed them instead of before; documentation often followed verification rather t h a n guiding it, e.g., STD checklist

Confusion and uncertainty i n the actual application of ISO, procedures on the one hand, versus "actual" procedures t h a t the team decided were necessary to get the product out on time

Company changes (split) created resource issues; we had to "ad hoc" it i n handling engineering change notices, assembly drawings, and the like because of resource problems created by t h e split and loss of staff

Document numbering system created a lot of tension and uncertainty

Training needs-staff involved in the project were not always trained to carry out procedures, e.g., staff loading the boxes did not have good guidance a n d training

Ineffective version control on some documents and configurations

Stress created by long hours was a problem--can't stretch people and expect them to stay on

Schedules were not accurate, in many cases, compared to the real work, e.g., the sequence of tests and dry runs

Sometimes the team did not have the "big picture" on the project; sometimes the big picture helps to facilitate doing your job

Wasted time in some meetings-meetings had agendas, but there were times when the team "blew off steam" and wasted a lot of time

Some residual issues rooted in "military" versus "commercial" approach had an impact on the project, which came right in the middle of the transition from military to commercial ways of doing things

Contingency actions

lssue 1. Document numbering system Recommendation. Set aside time and develop a new document numbering

scheme t h a t reflects the way we want to do business

lssue 2. Big gap in documenting actual procedures and processes; problems in sequence and review of documents

Recommendation. Develop and document how we followed or created proce- dures for I S 0 audit (they will want to see how we followed our own procedures); review current processes for sequence and review of documents

lssue 3. No accountability for master charting function Recommendation. Decide clear accountability for master chart function

lssue 4. Don't have the right tools to accomplish process definition, control, and documentation

Recommendation. Decide what the right tools to facilitate documentation are and acquire them, e.g., Framework replaces Word, Agile is used to control ver- sions, and Requisite Pro documents requirements

lssue 5. Ineffective management of document and procedure revisions Recommendation. Develov a referenced master list of documents a n d

acronyms to ensure effective revision management

lssue 6. Some staff did not follow established procedures and processes Recommendation. Develop staff accountability for following established

procedures and documentation requirements; follow-up with consequences if necessary

lssue 7. Inefficient acquisition of needed equipment Recommendation. Plug required test equipment early into the scheduling

process; anticipate asset issues before they happen

lssue 8. We don't capture observations, problems, and corrective actions along the way, lessons learned are lost

Recommendation. Establish a way to identify and capture project issues, processes, and corrective actions along the way

lssue 9. Conflicts in doing product development in a manufacturing environment; can't build the same thing twice

Recommendation. (this issue was tabled)

Risk Lessons Learned and the Project Risk Audlt 163

Issue 10. There is a widely held view-that we need to turn around-that the company is good a t identifying weaknesses but does not follow-up to fix them- there is a concern that issues such as those coming out of this session will not be addressed because of the pressure of time and work.

Recommendation. Make presentation to top management to get personal com- mitments from key executives on corrective action to mitigate risks on future projects.

A postscript to lessons learned

Risk management is in the end a people-centered process, and it is in the key decisions t h a t people make daily t h a t the conditions for effective risk reduction and response are created. Because the lessons-learned process focuses on the people who actually did the project work and gleans from them a realistic a n d practical perspective of risks a s they played out i n the project, the lessons- learned process can be very valuable.

Project Audit

The project audit starts with the appointment of a n auditor and a n audit team. The auditor is typically another project manager who assumes the role of an auditor with some experience in project planning and control.

The audit, unlike the lessons-learned session, is focused on a n independent gathering of information and documents from the project, and reviewing them against the goals and objectives of the project and best practice criteria. This involves the question, "did the project produce what it intended to produce, and how effectively and efficiently?"

Project audit focuses on key aspects of t h e project, a s follows:

1. Business planning. Were the risks which actually occurred and which impacted t h e project identified adequately in the early business planning process?

2. Follow-up response. Were those same risks monitored and controlled?

3. Organization-wide culture. Did top management support effective risk management as part of the project cycle?

4. Project team. Did the project team members perform their roles as "risk managers" during the process and integrate risk into their daily work?

5. Risk identification, assessment, a n d response. Was there a systematic process to identify, assess, and respond to risks?

6. Key processes, decisions, a n d milestones. Were key risk-related processes, such as testing and reliability, quality assurance and control, decision trees, - - - and product development integration milestones, actually followed?

7. Resources. Did the project experience resource constraints and were the constraints managed with buffers?

184 Chapter Ten

8. Safety a n d reliability. Were the correct tests and reliability processes in place?

9. Risk-based scheduling. Were project schedules adjusted using risk inputs and using the MS Project PERT analysis tool?

10. Monitoring. Were risks followed in the project process and decisions made on risk mitigation and contingency t h a t reduced risk?

The question of efficiency is reviewed through earned value and cost variance calculations. The issues would be:

Did the project stay consistent with the schedule and budget?

Did the project manager make adequate adjustments based on variations from risk events?

Did the project make its quality, schedule, and budget goals?

Cost and Risk Exercises-How Do Risk and Cost Work in a Real

Project Setting?

The purpose of this appendix is to provide some risk and cost scenarios and ques- tions and answer them so t h a t we can add some reality and practice cases and solutions into this discussion of risk management.

Let's say t h a t you are a project manager i n your company and have been assigned to a high-profile, mission-critical project t h a t has high-revenue poten- tial in a new market segment. After a n initial assessment. vou have determined - that it is a risky project since it relies heavily on new technology. However, your upper management does not fully understand and appreciate the basic concepts and approach to project risk management. As a result, you decide to prepare a brief tutorial for your upper management based on the questions t h a t follow.

(a) What is the difference between risk and uncertainty?

SOLUTION: For risk, the probability is known. For uncertainty, the probability is unknown.

(b) According to the PMI Project Management Body of Knowledge, what are the six subprocesses associated with the risk management process?

SOLUTION:

1. Risk management planning

2. Risk identification

3. Qualitative risk analysis

4. Quantitative risk analysis

186 Appendix A

5. Risk response planning

6. Risk monitoring and control

(c) How do you determine t h e risk event status?

SOLUTION: Risk event status = risk probability x amount a t stake

(d) Once risk h a s been identified a n d analyzed, what a r e t h e four risk response strategies t h a t may be used to address risk?

SOLUTION: Avoidance, transference, mitigation, and acceptance

Sample Questions

This section contains questions (and answers) t h a t might be used in setting exams for training the class. They are organized by key emphasis areas.

Emphasis area A

Given a project work breakdown structure W S ) , identify the appropriate level for estimating the project, identify the possible types of cost estimates, and rec- ommend the most appropriate alternative.

A l : Types of cost estimates. Since cost i s a major a r e a of risk, cost estimates a r e risks. Analyze t h e following a n d recommend t h e type of cost estimate (order of magnitude, budget, or definitiue) t h a t should be used to satisfy each of t h e following circumstances.

(a) Used for project funding and alternative scheme evaluation, when historical information is available.

SOLUTION: Budget

(b) Data include fairly complete plot plans and elevations, equipment d a t a sheets, quotations, and a complete s e t of specifications.

SOLUTION: Definitive

(c) Needed to support cost control during project execution.

S o ~ u n o ~ : Definitive

(d) An estimate prepared with t h e use of flow sheets, layouts, and equipment (but not design) details.

SOI~UTION: Budget

(e) An estimate using scale-up or scale-down factors, or a n approximate ratio estimate.

SOLUTION: Order of magnitude

Cost and Risk Exercises 187

A2: Delphi method. As a project manager, you have pulled together a team of subject- m a t t e r experts to estimate t h e t a s k durations for several key t a s k s on a software development project. You have asked each of them to provide a n optimistic, pessimistic, and most likely estimate, assuming t h a t one person would be working on each task (i.e., 40 hours per week, 52 weeks per year). The following a r e t h e d a t a t h a t resulted for one of t h e key tasks:

Individual estimates (in months)

Person Optimistic Most likely Pessimistic

Expert 1 1 3 12 Expert 2 2 6 18 Expert 3 3 6 16 Expert 4 3 10 13 Expert 5 1 4 24 Expert 6 2 5 20 Expert 7 5 6 23

(a) Summarize the basic steps i n t h e estimating process using t h e Delphi method with input from multiple sources (i.e., estimators).

SOLUTION:

1. Assemble estimators i n one room

2. Identify t h e task to be estimated

3. Each person provides a n optimistic, pessimistic, and most likely estimate

4. Individual estimates a r e displayed to everyone i n t h e mom

5. Each person discusses his or her assumptions and t h e issues that he or she considered

6. Individuals adjust their individual estimates based on t h e discussion

7. Outliers i n t h e final estimates are identified and discarded

8. Averages a r e calculated for t h e optimistic, pessimistic, and most likely estimates

(b) Based on t h e table above, which estimates would you consider outliers t h a t should be discarded?

SOLUTION: Expert 7's optimistic estimate of 5, and Expert 4's most likely estimate of 10 are clear outliers and should be discarded. Although the pessimistic estimates have a wide range, there i s no clear outlier and none of these estimates should be discarded.

188 Appendix A

(c) Calculate t h e expected duration of t h e prior task.

SOLUTION:

Average (optimistic) = (1 + 2 + 3 + 3 + 1 + 2)/6 = 2 months Average (most likely) = (3 + 6 + 6 + 4 + 5 + 6)16 = 5 months Average (pessimistic) = (12 + 18 + 16 + 1 3 + 24 + 20 + 23)17 = 1 8 months

Expected duration = 2 + 4 (5) + 1816 = 6.7 months

(d) What other time factors need to be taken into account to adjust the expected duration so t h a t the final estimate i s realistic.

SOLUTION:

Holiday, weekends, and vacation time

Time spent mentoring and coaching other team members

Time spent reviewing andlor inspecting other people's work

Interruptions for phone calls and email

Organizational meetings, project meetings, and administration

'Wait time" for information or assistance from others

"Switch time" between multiple tasks andlor projects

A3:Three-polnt estimate. A construction project requires t h e use of a special material i n several tasks over the next 9 months. Based on recent billings i n the geographic area where t h e construction is being done, t h e most likely price for t h e material is $27 nb. However, there have been price fluctuations over time based on market conditions and material availability. The estimated lowest price is $20 nb, and the estimated highest price is $35 fib.

There is also some uncertainty about how much of t h e material will be required for t h e project. Site conditions will affect the amount of material actually needed. The most likely estimate is 1,000 lb. However, a s little a s 800 1b or a s much a s 1,300 lb might be required.

(a) What is t h e expected price of the material?

SOLUTION: 20 + 4(27) + 35 = $27.17 fib

(b) What is the expected amount of material needed for t h e project?

SOLUTION: 800 + 4(1,000) + 1,300 = 1,016.67 lb

(c) From what sources (i.e., from who) might you receive optimistic, most likely, and pessimistic estimating information?

Cost and Risk Exercises 189

SOLUTION: Engineers, cost estimators, vendors, and others who are knowledgeable in the areas that you are estimating.

Emphasis area B

Given two o r more project alternatives, compare t h e m using equivalent worth a n d r a t e of r e t u r n methods to determine which alternative i s superior from a financial perspective.

61 : External rate of return-Riskexposure in financial analysis. Determine the external rate of return (ERR) in percent for the following cash flow stream, assuming a reinvestment rate or MARR of 10 percent. Please draw a cash flow diagram to assist in your calculations.

Net cash flow

Time - 0

EOY 1 EOY 2 EOY 3 EOY 4 EOY 4

in dollars Comments

(45,000) Initial investment 20,000 (5,000) 30,000 20,000 (2,000) Net salvage value

Note: EOY = end of year.

Future accumulation of recovered monies =Future worth of investment

12% 1.5735

x 1.5904 ,01691.1755 = .0963

15% 1.7490

(.0963)(.03) + .12 = .0029 + .12 = ,1229 ERR = 12.29%

190 Appendix A

82: Internal rate of return. A small computer manufacturing company i s thinking about taking on a new, short-term project to develop a specialized performance monitoring system for an Internet service provider. The following a r e t h e expected cash flows over t h e life of t h e project.

Cash flow

Time in dollars Comments

0 (250,000) Initial investment EOY 1 86,900 Annual net cash flow EOY 2 111,300 Annual net cash flow EOY 3 120,000 Annual net cash flow EOY 3 (25,000) Net salvage value when project

is closed out and sold

Note: EOY = end of year.

(a) Determine the project's internal rate of return (IRR).

PW(10%) = -7,647 (negative)

PW(8%) = -250,000 + 86,900 (PF, 8%, 1) + 111,300 (PF, 8%, 2) + (120,000 - 25,00O)(PF, 8%, 3)

PW(8%) = -250,000 + (86,900)(.9259) + (111,300)(.8573) + (120,000 - 25,000)(.7938)

PW(8%) = -250,000 + 80,461 + 95,417 + 75411 PW(8%) = 1,289 (positive)

i P W

8% 1,289

10% -7,647

(.1442)(.02) + .08 = ,0029 + .08 =.0829 IRR = 8.29%

Cost and Rlsk Exercises 191

(b) If t h e MARR is 10 percent, would you recommend t h a t t h e project be undertaken?

SOLUTION: Recommend t h a t t h e project not be undertaken, since t h e IRR of 8.29 percent is below t h e MARR.

83: Replacement analysis. A telecommunications company is currently considering replacing a n analog switching system in i t s service network. The old system has operating and maintenance costs of $80,000 per year and it has a n expected l i e of 20 years, a t which time it will have no salvage value. I n order to meet increasing customer data service needs, the old system will require a n immediate upgradation of its digital access a n d transmission equipment costing $100,000 if it is kept i n service.

A new, digital system will cost $400,000 a n d it will have a n n u a l operating a n d maintenance costs of $50,000 per year. The company h a s been offered a $50,000 resale price for t h e old system, a n d t h e new system h a s a salvage value of $100,000 a t t h e end of the 20-year period. Using a n MARR of 15 percent and a before-tax analysis, determine whether or not t h e company should replace t h e old switching system. Explain your answer.

Years Old system New system New system--old system

Since t h e present worth is less t h a n zero, do not replace t h e switching system.

84: After-tax cash flow. A major petroleum company i s considering a new project t h a t is intended to increase the efficiency i n a particular p a r t of its oil-dri1Ling operations. The company's after-tax MARR is 20 percent and the company i s subject to a n effective t a x r a t e of 40 percent. The information listed below represents t h e estimated cash flows associated with t h e project.

192 Appendlx A

Cash flow

Time in dollars

0 EOY 1 EOY 2 EOY 3 EOY 4 EOY 5 EOY 6 EOY 6

Comments

Initial investment Annual net BTCF Annual net BTCF Annual net BTCF Annual net BTCF Annual net BTCF Annual net BTCF Net salvage value when project is closed out and sold

Note: EOY = end of year, BTCF = before.tax cash flow, ATCF =after-tax cash flow.

(a) Calculate the annual depreciation deductions in the following table:

Depreciation deduction

Year Factor (in dollars)

1 .lo00 2 ,1800 3 ,1440 4 .I152 5 ,0922 6 ,0737

Depreciation deduction

Year Factor deduction (in dollars)

7 ,0655 8 .0655 9 ,0656 10 ,0655 11 ,0328 12 - -

Total 150,000

Depreciation deduction

Year Factor (in dollars)

1 .1 15,000 2 .18 27,000 3 .I440 21,600 4 ,1152 17,280 5 ,0922 13,830 6 ,0737 11,055

Depreciation deduction

Year Factor deduction (in dollars)

7 ,0655 9,825 8 ,0655 9,825 9 ,0656 9,840 10 .0655 9,825 11 ,0328 4,920 12 - -

Total 150,000

Cost and Risk Exercises 193

(b) Determine t h e present worth of t h e after-tax cash flows associated with t h e project. Would you recommend t h a t this project be undertaken?

SOLUTION:

Time

0 EOY 1 EOY 2 EOY 3 EOY 4 EOY 5 EOY 6

Depreciation BTCF deduction

(150,000) 45,000 15,000 48,000 27,000 50,000 21,600 55,000 17,280 60,000 13,830 95,000 55,290

Taxable income

Income taxes ATCF PW(ZO0h)

Note: EOY = end of year PW(20X) = -10,205.

Since the present worth i s negative, do not undertake t h e project.

Emphasis area C

Given a project cost estimate, recommend a project budget, justify any contin- gency funds, and recommend a plan for the control of budgeted and contin- gency spending throughout t h e project duration.

Cl: Project budgeting process. Describe five of t h e seven identified steps associated with t h e project budgeting process.

SOLUTION:

1. Get understanding of what client wants

2. Identify work to produce what is wanted

3. See if personnel a r e available

4. Identify risk involved with doing work

5. Get feedback on amount of time and resources

6. Identify problem t h a t could interrupt work

7. Calculate and publish time and cost target

194 Appendix A

C2: Project budgeting approaches. Single-project budgeting must fit into the overall budgeting process of t h e organization and t h e company a s a whole. As a project manager for one of your company's projects, you have been asked to provide a brief description of t h e top-down a n d t h e bottom-up approaches to the budgeting process.

(a) Explain the three basic steps in t h e top-down budgeting approach by identifying t h e organizational level a n d type of budget prepared a t each step.

Step Organizational level Type of budget prepared

1 Upper management Strategic budget based on organizational goals, constraints, and policies

2 Functional managers Mid-range budget for each functional unit 3 Project managers Detailed budgets for each project, including the cost of labor,

material, capital equipment, subcontracting, overhead, contingencies, and the like

(b) Explain t h e four basic steps i n t h e bottom-up budgeting approach by identifying t h e organizational level a n d type of budget prepared a t each step.

SOLUTION:

S t e ~ Oraanizational level Type of budget prepared - 1 Upper management Setting goals and selection of projects (i.e., a framework . .

for budget) 2 Project managers Detailed budget proposals for projects, including the

cost of labor, material, capital equipment, subcontracting, overhead, contingencies, and the like

3 Functional managers Mid-range budget for each functional unit 4 Upper management Adjustments and approval of the aggregate budget

resulting from the process

Emphasis area D

Given a project description, identify the risks inherent in the project, prioritize these risks, develop strategy for their mitigation or elimination, and commu- nicate this information to management.

Dl: Risk management concepts. You a r e a project manager in your company a n d have been assigned to a high-profile, mission-critical project t h a t has high revenue potential in a new market segment. After a n initial assessment, you have determined t h a t i t i s a

Cost and Risk Exercises 195

risky project since it relies heavily on new technology. However, your upper management does not fully understand and appreciate t h e basic concepts and approach to project risk management. As a result, you decide to prepare a brief tutorial for your upper management based on t h e questions t h a t follow.

(a) What is t h e difference between risk and uncertainty?

SOLUTION: For risk, t h e probability i s known. For uncertainty, the probability is unknown.

(b) What a r e t h e six subprocesses associated with t h e risk management pmcess?

SOLUTION:

1. Risk management planning

2. Risk identification

3. Qualitative risk analysis

4. Quantitative risk analysis

5. Risk response planning

6. Risk monitoring and control

(c) How do you determine t h e risk event status?

SOLUTION: Risk event s t a t u s = risk probability x amount a t stake

(d) Once risk h a s been identified a n d analyzed, w h a t a r e t h e four risk response strategies t h a t may be used to address risk?

SOLUTION: Avoidance, transference, mitigation, acceptance

02: Risk response strategies. Explain w h a t is meant by each of t h e following risk response strategies, and give a t least two examples for each strategy:

1. Avoidance

2. Transference

3. Mitigation

4. Acceptance

196 Appendix A

SOLUTION: Avoidance is defined a s changing the project plan to eliminate t h e risk or t h e condition to protect t h e project goals and objectives from i t s impact. Examples include:

1. Do not use unfamiliar subcontractors

2. Reduce scope to eliminate high-risk activities

3. Add resources or time to critical tasks during planning

4. Use familiar approaches rather t h a n innovative ones

fiansference involves shifting t h e consequence of a risk to a third party, together with ownership of t h e risk response. Transferring a risk gives someone else t h e responsibility for i t s management. I t does not eliminate t h e risk. Examples include:

1. Use of insurance and performance bonds

2. Use of warranties and guarantees

3. Use of contracts to transfer liability

4. Use of a fixed-price contract with subcontractors

Mitigation reduces t h e probability andlor consequences of a n adverse risk to a n acceptable level. Taking early action to reduce a risk's probability andlor impact is more effective t h a n reacting later. Examples include:

1. Adopt less complex processes

2. Plan for additional testing of complex elements

3. Use a more reliable or more stable vendor

4. Use a prototype i n t h e development process

Acceptance means t h a t t h e project h a s decided not to change the project plan to deal with a risk or is unable to identify any other suitable response strategy. Examples include:

1. Develop contingency plans

2. Identify risk-trigger points

3. Periodic review of risks and trigger points

4. Use contingency allowance (e.g., time, budget, staff)

Cost and Risk Exercises 197

D3: Risk identification and response. Your project team h a s just been assembled to begin preparing a plan for t h e following project: 1.0 Conducting Seminar

1.1 Project Management

1.1.1 Planning

1.1.1.1 Scheduling

1.1.1.2 Risk Management

1.1.2 Administration

1.1.3 Budget

1.2 Marketing Preparation

1.2.1 Brochures

1.2.1.1 Planning

1.2.1.2 Printing

1.2.1.3 Labeling

1.2.1.4 Mailing

1.3 Material Preparation

1.3.1 Design

1.3.2 Printing

1.3.2.1 Reproduction

1.4 Conduct Seminar

1.4.1 Reservation

1.4.2 Registration

1.4.3 Presentations

1.4.4 Critique Sheets

1.5 Logistics and Support

1.5.1 Transportation

1.5.2 Accommodations

1.5.3 Meals

Your project sponsor wishes to get a n initial reading (based on t h e 3 to 4 level WBS t h a t h a s been provided) on what risks a r e involved and how they should be managed. Explain a t least five risk areas associated with t h e project a n d provide a brief response plan for each.

198 Appendix A

SOLUTION:

Project risk area Risk response plan

1. Presenter availability 1. Use alternate presenters 2. Presenter availability 2. Plan back-up presenters 3. Printer errors 3. Product checkpoints in plan 4. Printer errors 4. Contractor performance requirements 5. Insufficient acwmmodations for clients 5. Contract for back-up moms 6. Late registrations 6. Space contingencies 7. Cost overruns in materials 7. Contingency fund 8. Presentation material errors or lost 8. Contract with local quick minute changes copy

service

D4: Evaluation of riskevents or opportunities (16 points). You are the project manager for a firm constructing a new electronic manufacturing facility. The facility i s designed to l a s t 1 5 years. The initial capital cost to construct t h e plant is estimated to be $150,000,000. I n conducting a n environmental scan of factors affecting your project, you have identified a 10 percent chance t h a t litigation by environmental groups over land use could delay t h e s t a r t of construction by 2 years and add $25,000,000 t o the cost of construction.

Over t h e useful life of t h e facility, t h e plant is expected to manufacture components t h a t a r e expected t o yield $40,000,000 each year i n n e t profits. Further, your marketing department has forecast t h a t there is a 25 percent chance t h a t heightened demand for t h e components may allow you to raise prices and realize profits a s much a s $50,000,000 per year of operation. However, there is also a possibility of a new competitor emerging i n t h e near future. While you view this a s unlikely, with only a 10 percent probability, if it does occur it will decrease your firm's profits by $10,000,000 per year due to t h e heavy price competition t h a t would ensue.

However, you a r e aware from your environmental scan t h a t t h e local government may raise real estate taxes to pay for mad improvements and t h e like because of the explo- sive growth t h e area h a s experienced recently. Based on t h e analysis by your firm's t a x lawyers, you estimate t h a t if t h e tax increase goes through, it will decrease your net prof- i t s by $2,000,000 per year. You estimate there is a 40 percent chance of this occurring.

The manufacturing of electronic componenta uses some very volatile chemicals. Although your firm h a s extensive experience i n manufacturing with these facilities, you know k o m historical data t h a t there is a 20 percent chance of a chemical spill in any year of operation. The occurrence of such a spill would decrease your firm's operating profits by $2,000,000 per year. Insurance is available to protect you from such losses a t a cost of $250,000 per year.

As p a r t of t h e proposal, a n d i n order to achieve all t h e necessary permits, your firm h a s agreed to clean t h e facility a t t h e end of i t s useful life a n d convert t h e facility for a n unspecified, nontoxic, government use. You e s t i m a t e t h a t t h i s will cost $40,000,000. However, you also estimate t h e r e is a 30 percent chance t h a t these costs could increase by 25 percent by t h e end of t h e plant's life d u e t o increased envi- ronmental regulation.

Cost and Rlsk Exercises 199

Assume that all costs are in normalized dollars, i.e., do not discount future cash flows.

(a) What are the opportunities and risk events presented in the scenario?

SOLUTION: Litigation, price increase, competition, tax increase, chemical spill, and regulatory impacts

(b) What is the value of the project if none of the risk events or opportunities occur?

SOLUTION:

Value = -$150,000,000 + (15 years)($40,000,000 per year) - $40,000,000 Value = $410,000,000

(c) What is the value of the project, including all risk events and opportunities?

SOLUTION:

Value = $410,000,000 - (0.1)($25,000,000) + (0.25)($150,000,000) - (0.1)($150,000,000) - (0.4)($30,000,000) - (0.2)($30,000,000) - (0.3)($10,000,000)

Value = $410,000,000 - $2,500,000 + $37,500,000 - $15,000,000 - $12,000,000 - $6,000,000 - $3,000,000

Value = $409,000,000

(d) What is the value of the project if all risk events or opportunities occur in their worst case?

Value = $410,000,000 - $25,000,000 - $150,000,000 - $30,000,000 - $30,000,000 - $10,000,000

Value = $165,000,000

(e) What is the value of the project if all risk events or opportunities occur in their best case?

SOLUTION:

Value = $410,000,000 + $150,000,000 Value = $560,000,000

Emphasis area E

G i v e n a project d e s c r i p t i o n and i d e n t i f i e d risks, p e r f o r m a s e n s i t i v i t y a n a l y s i s t o d e t e r m i n e t h e effects of i d e n t i f i e d risks o n the project.

El: Sensitivity analysis. I t is necessary to determine t h e number of lanes on a short tollway extension project. I t is expected t h a t t h e tollway will be i n service for 30 years and then be demolished with a n e t zero salvage value. Following are pertinent d a t a for t h e initial cost, a n n u a l operating a n d maintenance ( O & M) expenses, a n d a n n u a l revenues from tolls based on two scenarios:

Description Four lanes Five lanes

Initial cost $56,000,000 $72,000,000 Annual O&M expenses $2,300,000 $2,960,000 Annual revenues (optimistic) $10,000,000 $12,500,000 Annual revenues (pessimistic) $8,900,000 $11,525,000

Analyze t h e sensitivity of t h e decision due to the optimistic and pessimistic estimates of annual revenues by using t h e present worth (PW) method. Assume a n MARR of 10 percent. Recommend the number of lanes t h a t should be constructed. Explain your answer.

SOLUTION:

PW(4 opt) = -56,000,000 + (10,000,000 - 2,3OO,OOO)(P/A, lo%, 30) PW(4 opt) = -56,000,000 + (7,700,000)(9.4269) = $16,587,130

PW(4 pess) = $6,217,540

PW(4 range) = $10,369,590

PW(5 opt) = -72,000,000 + (12,500,000 - 2,96O,OOO)(P/A, lo%, 30) PW(5 opt) = -72,000,000 + (9,540,000)(9.4269) = $17,932,626

PW(5 pess) = $8,741,398

PW(5 range) = $9,191,228

Since PW(5) i s higher i n both t h e optimistic and pessimistic cases and t h e range (optimistic-pessimistic) of PW(5) is lower, select the 5-lane alternative.

E2: Break-even point and payback period. A project is currently under consideration by a company, b u t uncertainty exists regarding the life of t h e project. The following a r e t h e most likely (or expected) estimates for t h e project:

Initial investment $125,000 Project life 5 years Salvage value $5,000 Annual receipts $90,000 Annual disbursements $47,000 MARR 8%

Cost and Risk Exercises 201

(a) Using the annual worth (AW) method, determine the break-even point of the project in years.

SOLUTION:

Annual net cash flow = (P - S)(A/P, i%, n) + (S)(i%) (90,000 - 47,000) = (125,000 - 5,OOO)(A/P, 8%, n) + (5,000)(.08)

43,000 = (120,00O)(A/P, 8%, n) + 400 (AP, 8%. n) = .3550

n A/P

Break-even point = 3.38 years

(b) Based on the result in part (a), would you recommend the project for acceptance?

SOLUTION: Since break-even is 3.38 years and project life is 5 years, recommend a "go ahead."

(c) Calculate the payback period (in years) for this project and explain why it is different from the break-even?

SOLUTION: Simple payback = 125,000/43,000 = 2.907 years

The break-even recognizes the time value of money, the payback does not.

E3: Break-wen and sensitivity. Amajor communications carrier is faced with increasing demand on its long-haul transmission facilities between Chicago and St. Louis.As a result, the company is considering a new project to expand its transmission facilities on that route. There are two project alternatives: (1) install equipment with full transmission capacity now, or (2) install equipment in two phases. The following table shows the estimated installation costs:

Alternative Cost

Full-capacity Installation $140,000 Two-phase installation

Install fit phase now $100,000 Install second phase n years from now $120,000

202 Appendix A

All facilities will last until 40 years From now regardless of when they are installed. At that time, they will have no salvage value. The annual cost of operating and main- taining the facilities is the same for both alternatives. The company's MARR is 8 per- cent a t this time.

(a) Using the present worth (PW) method, plot a simple graph showing "year second phase installed" (i.e., the x-axis) versus "PW of cost" (i.e., the y-axis) for both alternatives. From the graph, determine the break-even point in years.

SOLUTION: The x-axis should range from 0 to 30 years. The y-axis should range from 0 to $250,000.

Full-capacity installation alternative:

PW of cost = $140,000, so this alternative is represented by a horizontal line.

Two-phase installation alternative:

PW of cost = $100,000 + ($120,00O)(P/F, 8%, n) Calculate PW of cost for n = 0, 5 , 10, 20, and 30 years

n=O P W of cost = 100,000 + 120,000 = $220,000 n = 5 PW of cost = 100,000 + (120,000)(0.6806) = $181,700 n = 10 P W of cost = 100,000 + (120,000)(0.4632) = $155,600 n = 20 P W of cost = 100,000 + (120,000)(0.2146) = $125,700 n = 30 PW of cost = 100,000 + (120,000)(0.0994) = $111,900

This alternative is represented by a plot of five points that decrease from left to right.

Break-even point = 15 years (approximately, from the graph)

(b) If it is estimated that the second-phase capacity will be needed in year 18, how sensitive is the decision to this estimate?

SOLUTION: If the second-phase capacity would be needed over the next 5 to 10 years, the decision is not sensitive to this estimate.

If the second-phase capacity would be needed between years 12 and 18, the decision is sensitive and would depend on the estimate of when full capacity would actually be needed.

If the second-phase capacity would be needed in year 18 and beyond, the decision on which alternative to use is not sensitive to this estimate.

Emphasis area F

Given identified project risks, apply expected value a n d decision tree techniques t o evaluate likely project outcomes.

F1: Payoff matrixlexpected value. A company is planning a project to develop a new product and has identified three strategies it can use to bring the product to market- A, B, and C. Three possible states of nature are also identified-a low market demand,

Cost and Risk Exercises 203

a n even market demand, and a high market demand. A payoff matrix, including t h e probability of each market condition, h a s been developed:

States of nature (profits in $million)

Strategy High = 20% Even = 50% Low = 30%

Determine t h e expected value of each strategy a n d recommend what strategy t h e project should take.

Expected value = (payoffhigh)(probability high) + (payoff even)@robability even) + (payoff low)@robability low)

Expected value of A = ($50)(0.2) + ($20)(0.5) + (-$30)(0.3) Expected value o f A = $10 + $10 - $9 = $11

Expected value of B = ($70)(0.2) + ($40)(0.5) + (-$60)(0.3) Expected value of B = $14 + $20 - $18 = $16

Expected value of C = ($25)(0.2) + ($15)(0.5) + ($10)(0.3) Expected value of C = $5 + $7.5 + $3 = $11

For this project, t h e strategy of choice would be B since it h a s t h e highest expected value.

F2: Expected monetary value. One of your projects i s estimated to have a variable life between 3 and 7 years. The following project estimates were arrived a t using historical data a s well a s expert judgment:

Initial investment $10,000 Project life 3 years with probability = 0.3

5 years with probability = 0.4 7 years with probability = 0.3

Salvage value $2,000 Annual receipts $5,000 Annual disbursements $2,200

204 Appendix A

Determine t h e expected annual worth (AW) of t h e project if t h e MARR is 8 percent.

SOLUTION:

For life = 3 years, t h e net AW is:

$5,000 - $2,200 - [($10,000 - $2,00O)(AIP, 8%, 3) + ($2,000)(.08)] = - $460 For life = 5 years, t h e net AW is:

$5,000 - $2,200 - [($10,000 - $2,00O)(A/P, 8%, 5) + ($2,000)(.08)] = $630 For life = 7 years, the net AW is:

$5,000 - $2,200 - [($lO,OOO - $2,0OO)(iw, 8%, 7) + ($2,000)(.08)] = $1,110 Expected AW = (-$460)(0.3) + ($360)(0.4) + ($1,100)(0.3) Expected AW = $446

F3: Decision tree analysis. Silver will be used in a manufacturing process o n a new product development project. You m u s t decide "to stock" o r "not t o stock" a large supply of silver. The uncertain variable is t h e f u t u r e price of t h e metal. You have t h r e e options:

1. Stock silver i n a large supply

Future price, probability, and present value of silver stock a r e a s follows:

Price Probability Present value

High . 3 $25,000 Medium .4 $5,000 Low . 3 $15,000

2. Stock no silver with present value = $0

3. Hire a consultant (at a cost of $3,000) to predict if silver prices will go higher or lower. Then, based on t h a t prediction (estimated to be 60 percent higher a n d 40 percent lower), determine "to stock" or "not to stock" a large supply of silver:

Stock silver i n large supply

Future price, probability, and present value of silver stock a r e a s follows if t h e pre- diction is for higher prices:

Price Probability Present value

High .4 $25,000 Medium .45 $5,000 Low .15 $-15,000

Cost and Rlsk Exercises 205

Future price, probability, and present value of silver stock are as follows if the pre- diction is for lower prices:

Price Probability Present value

High .2 $25,000 Medium .3 $5,000 Low .5 $-15,000

Stock no silver with present value = $0

(a) Diagram the problem in the form of a decision tree.

(b) Determine what would be the better option using the expected monetary value (EMV) criterion.

Decision 3 (25,000)(.2) + (5,000)(.3) - (15,000)(.5) = -1,000 versus 0 Decision 2 (25,000)(.4) + (5,000)(.45) - (15,000)(.15) = 10,000 versus 0 Decision 1

Stock in large supply = (25,000)(.3) + (5,000)(.4) - (15,000)(.3) = 5,000 No stock = 0

Hire consultant = (10,000)(.6) + (0)(.4) - 3,000 = 3,000 Because 5,000 is greater than 3,000, don't hire a consultant but stock silver in large

supply.

Emphasis area G

Given a project in progress, collect d a t a o n cost and schedule parameters t o determine w h e t h e r t h e project is o n plan. Use e a r n e d value calculations t o determine whether control actions a r e to be taken. Develop recommendations to achieve a satisfactory outcome a n d describe a reporting plan.

GI: Project status and reporting. As the project manager for a key project your firm is delivering to a top client and you are preparing a progress report t o your client indicating your project's performance. The project has been in actual progress for 9 months. The information below provides the original schedule of task durations, budgeted costs, performance to date, and a network diagram.

206 Appendix A

Task Duration (months)

Budgeted costs

A 2 months B 1 month C 4 months D 2 months E 2 months F 1 month

Network diagram: A + B + C -, D + E + F

Percent Actual dollars complete expended

100% $150,000 100% $125,000 75% $500,000

0% $0 0% $0 0% $0

(a) Based on this information, prepare a costlschedule status report to show what you would share with your client.

SOLUTION:

Budget a t completion (BAC) = sum of budgeted costs = $1,200,000

BCWS for the 9-month point = Budget forA+ B + C + D = $1,000,000 B C W = $100,000 + $100,000 + (0.75)($600,000) = $650,000 ACWP = $150,000 + $125,000 + $500,000 = $775,000

Cost variance = BCWP - ACWP = $650,000 - $775,000 =-$125,000

Cost performance index = BCWPIACWP = $650,0001$775,000 = 0.84

The project is overbudget.

Schedule variance = BCWP - BCWS = $650,000 - $1,000,000 = -$350,000

Schedule performance index = BCWPtBCWS = $650,000/$1,000,000 = 0.65

The project is behind schedule.

Variance ACWPBCWP = $775,000/$650,000 = 1.19

Completed tasks = (1.0)($150,000) + (1.0)($125,000) = $275,000 In-progress tasks = $500,0001.75 = $667,000

Tasks not started = ($775,0001$650,000)($400,000) = $477,000

Total estimate a t completion (EAC) = $275,000 + $667,000 + $477,000 = $1,419,000

(b) What would be t h e best way to deliver this report to your client? What other information would you convey a t the same time?

SOLUTION: The project is clearly in jeopardy. I t is critical that you prepare a formal presentation to your client t h a t includes a t least the following.

Cost and Risk Exercises 207

You should objectively present t h e current project status. This would be best presented with a graphical depiction of t h e project status that will be easily understood by the client. You should also present t h e factors, events, or conditions t h a t brought about t

hi

s status and how you had anticipated them i n your project risk management plan.

You should present t h e measures and actions t h a t you are implementing to correct or eliminate any further slippage in project performance. The actions that you have already taken, or intend to take i n t h e near future, a r e t h e key items to present to your client, considering the current overall project status. This should lead to a current view of t h e project's estimated completion dates a n d costs.

G2: Analysis of project data. You have been provided t h e following information about the status of Task A on your project:

Status of Task A

Item Budget BCWS BCWP ACWP CV SV

Direct labor (hours) 5,000 3,500 3,250 3,000 Labor cost (dollars) 62,500 43,750 42,500 45,000 (2,500) (1,250) Material cost (dollars) 75,000 55,000 54,000 57,000 (3,000) (1,000) Labor overhead (dollars) 25,000 17,500 15,500 16,200 (700) (2,000) Material handling (dollars) 15,000 11,000 10,000 13,110 (3,110) (1,000) Total (dollars) 177,500 127,250 122,000 131,310 (9,310) (5,250)

(a) I s Task A on schedule? What is t h e scheduled and t h e actual completion percent?

SOLUTION:

Based on labor hours: Scheduled = BCWSlBudget = 3,50015,000 = 70% (Behind)

Based on labor hours: Actual =ACWP/Budget = 3,00015,000 = 60% (Behiid)

(b) What assumptions about costs were made during budget development?

SOLUTION:

Labor rate = ? = $62,50015,000 h = $12.50 /h for budget

Labor overhead = ? = $25,0001$62,500 = 40% for budget

Material handling = ? = $15,0001$75,000 = 20% for budget

(c) Is the project meeting t h e targets i n part (b) above?

SOLUTION:

Actual labor r a t e = ? = $45,00013,000 h = $15.00 /h (greater t h a n budget)

Actual labor overhead = ? = $16,2001$45,000 = 36% (less t h a n budget)

Actual material handling = ? = $13,1101$57,000 = 23% (greater t h a n budget)

208 Appendlx A

63: Project control devices. Explain three project control devices that could be used in the schedule area, three in the cost area, and three in the quality area.

Area Control devices

1. Schedule milestones Schedule critical path method (CPM) Schedule summary reports Schedule Gantt charts Schedule earned value measurement

2. Cost earned value measurement Cost productivity Cost bid estimateshudgets Cost Contract provisions Cost Change pricing

3. Quality design documents Quality code and local requirements Quality testing and inspection Quality industry standards Quality punch lists

Emphasis area H

Given multiple projects that compete for resources within t h e firm, u s e capital rationing techniques t o determine which projects should be funded.

HI : Capital rationing. The following information has been developed for five independent project investment opportunities that have been identified by your marketing, manufacturing, regulatory compliance, and engineering departments:

Cash flow (in $thousands) at end of year

No. Project area Year 0 Year 1 Year 2 Year 3 Year 4

1 Marketing -10 4 6 5 5 2 Manufacturing -15 8 7 6 2 3 Reg. compliance -5 1 3 4 5 4 Engineering (A) -7 4 4 4 4 5 Engineering (B) -8 3 4 5 6

Calculate the profitability index (PI), the payback period, and the net present value (NPV) a t 20 percent (the W R ) for each of the above projects. Then, based on your selection criteria (such a s profitability index, payback period, net present value), recommend how $25,000 of internally generated funds should be spent. Note: Funds may be assigned to future projects.

Cost and Risk Exercises 209

SOLUTION: Since all projects have a positive n e t present value, all could be chosen. Decision criteria on each project are:

Investment Payback period Project number (in $thousands) Profitability index (Y~s.) NPVIinvestment

Based on t h e financial criteria described above, t h e following recommendations would be made:

Based on PI: approve 3,4, a n d 5 with $5,000 left for new projects.

Based on payback: approve 4 and 1 or 2 with funds available or approve 1 and 2.

Based on NPV: approve 3, 4, and 5 with $5,000 left for new projects.

HZ: Let's ration some capital-what a capltal Ideal Your budget for projects is $400K. Data for simple Projects A, B and a more complex C a r e shown below. All have 8-year economic lives, and there a r e no salvage values.

Project Initial cost Annual net revenue

Project A can be undertaken i n any combination with t h e others. However, Projects B and C a r e mutually exclusive. Further, Project C can actually be considered a s two proj- ects where Project C1 would be a small version and Project C2 would be a large version. You could choose C 1 or C2, and neither could be paired with B.

(a) Using a n NPV framework, ration t h e $400K budget i n t h e most efficient way. Assume t h a t t h e MARR i s 12 percent.

SOLUTION: We can eliminate C2 right away because if we consider "expansion" of C1 into C2, we would spend $llOK u p front and generate only $80K in net revenues over the life of t h e project. Thus, we a r e left with five options to evaluat-A alone, B alone, C1 alone, A + B, a n d A + C1.

210 Appendix A

Calculating relevant NPVs (leaving out t h e dollar signs), we get:

From t h e above results, it is obvious t h a t the combinationA+ B is superior to the others. Why? Because the N W s for both projects a r e positive and sum of the NPVs (i.e., $177.3K) is t h e highest possible.

(b) Speculate in a reasoned way on your choices if you could spend a n unlimited amount of money on projects.

SOLUTION: If we had a n unlimited amount of funding, I would still choose t h e combination A + B. The mutually exclusive n a t u r e of Projects B and C precludes u s from undertaking both and we have shown already t h a t A + B is preferred to A + C.

More Questions on the Risk Management Process and Cost

Work breakdown structure

Questions a n d examples t h a t focus on the description and purpose of the work breakdown structure and its use in decomposing a project into a set of integrated tasks and activities

Problems that demonstrate WBS levels, work packages, and deliverables Problems and scenarios that develop the coding of WBS elements and the link- age to cost accounting systems

Estimating

Problems that demonstrate the difference between order of magnitude, budget, and definitive project estimates and their application

Questions t h a t describe t h e methods of estimating activity durations and estimating various types of costs (e.g., direct, indirect, capital, and t h e like) and the bases used for project estimating

Scenarios and cases t h a t identify and address major issues associated with estimating

Project financial perspectives

Questions t h a t require the student to perform calculations using interest rate, discount rate, and minimum acceptable rate of return

Problems, scenarios, and cases t h a t require the understanding and use of equivalent worth methods, rate of return methods, break-even analysis, and payback period i n the evaluation and selection of project alternatives.

Questions and problems t h a t demonstrate the effects of depreciation and taxes on project alternatives

Cost and Risk Exercises 211

Project budgeting

Problems and questions t h a t describe the inputs to the project budgeting process, general approaches to budget preparation, and risk considerations

Questions t h a t demonstrate the purpose and application of contingency funds and management reserves to account for risk

Scenarios or cases t h a t describe project financing alternatives and capital rationing techniques to deal with the issue of limited resources

Risk analysls and decision criteria

Problems t h a t require the student to understand risk and risk events, types of project risks, the steps associated with the risk management process, and risk probability and impact

Scenarios and cases t h a t require the student to apply risk impact assess- ment techniques including expected value, decision trees, sensitivity analy- sis, expert judgment, and simulation

Questions t h a t apply risk response strategies, a s well as monitoring and con- trol mechanisms

Project control systems

Questions t h a t describe the development of the requirements for project mon- itoring and control-what to monitor, how often, and from what source the data will come; and timeliness of progress/performance reporting.

Problems, scenarios, and cases t h a t address the project issues of scope man- agement, cost/schedule/performance tradeoff, and change management

CosVschedule management

Problems t h a t require the understanding and computation of earned value measures-earned value a t project review points, cost variance, cost per- formance index, schedule variance, schedule performance index, and project estimate a t completion

Scenarios or cases t h a t apply earned value measures to project decision making, recovery alternatives, and replanning efforts

CosVschedule control systems criteria (CISCSC)

Questions t h a t focus on the description and background of the cosUschedule control systems criteria (CISCSC) established for project control, a s well a s t h e major areas of t h e criteria-organization, planning a n d budgeting, accounting, analysis, and revisions and access to data

Appendix

Risk-Based Project Schedule

This appendix is a Microsoft Project schedule showing the results of the PERT analysis. Note the calculated durations based on expected, pessimistic, and optimistic estimates taken from a risk matrix.

PERT Analysis Schedule

ID Acquire terminals in strategic areas Duration Optimistic dur. Expected dur. Pessimistic dur.

1 Study population and expansion areas 122.5 days 110 days 155 days 115 days 2 Determine population growth 17 wks 12 wks 16 wks 21 wks 3 Lineup finances 15.33 wks 10 wks 14 wks 20 wks 4 Determine market for terminals 9.17 wks 10 wks 1 5 wks 0 days 5 Assess terminal worth 14.67 wks 12 wks 14 wks 17 wks 6 Personnel availability 15.33 wks 10 wks 16 wks 17 wks 7 Assess terminals 104.17 days 75 days 100 days 125 days 8 Proper personnel utilized 7.33 wks 8 wks 12 wks 0 days 9 Engineering studies performed 20.83 wks 1 5 wks 20 wks 25 wks

10 Evaluate equipment 9 wks 6 wks 8 wks 12 wks 11 Environmental hazards limited 8.33 wks 6 wks 8 wks 10 wks 12 Drawings of terminals available 2.17 wks 1 wk 2 wks 3 wks 13 Employees 159.17 days 95 days 110 days 240 days 14 Use new or existing employees 4 wks 2 wks 4 wks 5 wks 15 Accountant for terminal purchase 15.67 wks 10 wks 16 wks 18 wks 16 Legal documents in order 13 wks 10 wks 12 wks 16 wks 17 Financing complete 11.33 wks 8 wks 10 wks 15 wks 18 Documentation finalized 11.33 wks 8 wks 10 wks 15 wks

Appendix

C Demystifying Business and Project

Risk Management: A Checklist

!? DemystHying Business and Project Risk Management: A Checklist -.

Action What? Why? When? Output? Who?

Business culture

Create Risk Management policy

Assess organization awareness

Deliver training program

Reward effective risk management

Create business intent to manage risk

Find out how aware workforce is of risk and risk response impacts

Design training around practice planning tools; use to introduce business risk

Provide rewards for good risk management effort and effectiveness

Confirm that it is Part of business important and back plan; underlies i t up project process

Survey workforce Every 6 months

Workforce will Every year with implement if they refresher understand tools

Incentives motivate During projed

Policy statement on how the business will handle risk

Workforce awareness of risk management report

Certification

Compensation reward

Executive and program management level

HRProject team

All pm, teams, and technical personnel

Project managers and team members

Business strategy

Risk component of Provide for a risk SWOT analysis; Annual update of Risk-based business Executive and business plan section in the threats = risks business strategic plan; integrate with program

business plan and Translate to and business plan financial and managements communicate it product line risk profitability

exposure analysis Strategic objectives State objectives in Measurable strategy Part of plan; Set of 10 long term Executives and

terms of risk goals communicate to objectives program managers workforce

Project selection

Do risk assessment In developing Use PMBOK Each time project Rank order projects Program managers of candidate business portfolio of process; broad- portfolio pipeline is using composite and functional projects projects, use risk as brush risk updated risk, alignment, managers

one criterion for assessment cost and revenue project selection assessment

Weigh risk against Demonstrate that Trade off risk with Each time pipeline is Analysis, data, Project management revenues and risk has been opportunity for updated documentation office, project team, alignment embedded in profitability and business planning

business and taking advantage of staff financial analysis business core

competence

Project ~ l a n

Requirements State customer requirements in terms of customer risks

WBS

Task list

Include risk contingencies From risk matrix in WBS work activity

Include risk tasks and contingencies in baseline schedule

Network diagram Show risk in network diagram with 3 scenarios, expected, pessimistic, and optimistic

-

Risk that customer requirements do not reflect risk, or misunderstanding customer perspective and expectations on project risks

Because there is inherent risk in missing major parts of the deliverable in initial planning; WBS assures coverage of major "chunks" of work

Task list should include all anticipated contingency actions should risk events occur

Arrow diagram shows critical and non-critical paths; riska inherent in focusing on critical path when resource constraints in non- critical tasks may serve as bottleneck theory of constraints

During initial Requirements concept phase part document stating of project plan customer

requirements and risks

During development WBS in organization of the deliverable, chart form and the "work" should outline in MS include initial Project contingencies identified in risk assessment

After WBS is Task list in MS prepared, do task Project Gantt chart list and link; there or spreadsheet is inherent risk that linkages will be too "hard;" allow for "soft" linkage

During translation Arrow diagram in of WBS to Gantt MS Project or other chart, prepared to software show dependencies and paths

Project manager functional manger, and customer

Project manager

Project management office andlor project manager

Project management office template, or project manager

(Continued)

% Demystifying Buslness and Project Risk Management: A Checklist (Continued) QD

Action What? Why? When? Output? Who?

Calendar based Relate network to diagram time to begin to see

schedule impacts and milestones

Risk-based schedule Do risk-based schedule using MS Project PERT analysis tool

Project plan (Continued)

Histogram using During translation arrows and of WBS to Gantt calendar chart

MS project Gantt During initial chart showing scheduling, then calculated risk- any time risk is based duration identified and after weights and contingency 3 scenarios are prepared entered

Graphics software or Project manager Word document

MS Project schedule Project management file showing office or project calculated manager durations for high risk tasks

Risk management process (see PMBOK)

Risk identification Using input from business plan, identify and rank project tasks in terms of risk

Risk assessment Assess risks using risk matrix format

Risk response Prepare contingency actions and include in baseline schedule

Using data and information and past experience, rank summary tasks in WBS using risk matrix

Complete risk definition, impact (schedule, cost, qualiQ, business growth); make probability estimate (25%,50%, 75% probability), severity on pmject outcome, and contingency

Response is planning through definitive contingency plans and tasks which are embedded in project schedule as regular tasks-triggered if risk event occurs

During business Risk matrix Project management planning, project office or project and portfalio manager selection, and project WBS scheduling

During business Risk matrix, Project manager planning, project updated monthly seledion, and project planning and control

During pmject Risk contingency Project manager planning, responses actions and contingencies are designed to address specific risks and recorded; this is where the team anticipates what might happen

Risk matrix

Decision tree

Prepare risk matrix The risk matrix is a s basis for the basic checklist scheduling item for risk

throughout the process; it is the guide for action

Do decision tree This is the way analysis to project managers expected value of anticipate decisions optional decisions they will have to

make based on risk, and what alternative paths and expected values will follow each decision path

to slow or delay the project, what can be done to prevent it or address it, and schedules contingency tasks into the project

During project Risk matrix Project manager and planning a basic following team or task risk matrix file is prescribed format managers established and appears with all project planning and project review documents

During project Decision tree Project manager planning, decision diagram with tree analysis is expected values applied to high risk calculated tasks

Integrate risk into project manual

Basic project manual Assure that risk is not treated separately, but seen as part of the way projects are planned and controlled

Provide software Train and provide tools software analysis

tools in manual

Because risk should not be treated separately 6vm project management process; manual captures how risk is integrated into process

Much of the risk analysis can be done through spreadsheets and decision tree analysis software; workforce needs to know how to use them

Business establishes Onfine and hardcopy Project management a system of basic manual including office (PMO) project manuals a s basic project part of planning and risk "projectizing" the management tools organization and templates

Business establishes Software library IT and project a support system of managers risk management application software and trains appropriate staff

N N Demystifying Business and Project Risk Management: A Checklist (Continued) 0

Action What? Why? When? Output? Who?

Productltechnical process development

Define producfftechnical development process in generic WBS

Project codes

Assure that buainess h a s defined the core product development and technical processes which it uses to produce products and services, e.g., engineering, construction, system development, standardizing where possible

Provide for coding actions in WBS so t h a t costs can be captured

Because project risk management cannot be successful unless both technical and pmduct development result a requirements are conducted to control risk, and management impacts, e.g., schedule and cost are applied to the real industry processes that create customer value

Because once you have identified all tasks and risk contingencies, you will want to capture costs against those codes to build a history of risk management and mitigation costs

Business establishes WBS file a generic WBS of technical processes; these a r e recorded and updates so that all project WBS and schedule information, and risk data, is taken from the generic model and tailored

Functional managers

When generic WBS Coding system Accounting, project is set up, codes are integrated with management added a t the time sheets and appropriate level to accounting system capture costs

Identify customer risk tolerance

Assess customer Solicit customer Because customer When requirements Customer risk perspective on input on customer may have different are being written analysis Customer business and risks and and valuable representative and project risk and uncertainties insight on business functional and how much risk and project risks project managers, customer is willing that have been part jointly to assume of the customer

expectations but not reflected i n real planning

Lessons learned

Risk audit Do a project risk audit following selected projects to evaluate success in anticipating and managing risk

Lessons learned Prepare and meeting and report communicate short

report on what project team members and customers learned in the project that would reduce risks in a similar future ~ r o i e d

Because insights and documents that can lead to better risk management in the future will be lost unless a risk audit team builds a history of the project, how risk decisions were made and how effective risk management was

Because the best lessons and insights a r e going to be lost unless someone facilitates a lessons learned session and report

At project close-out Risk audit report to Project management project manager office, audit sta$

project and functional managers

At close-out Lessons learned Project manager report, referencing systems, decisions, risk, outcomes but no names

Bibliography

Barkley, B. T., and James Saylor, Customer.Driuen Project Management: Building Quality into Project Processes, 2d ed., McGraw-Hill, New York, 2001.

Bennatan, E . M . , On E m e and W ~ t h i n Budget: Software Project Management Practices and nchniques, Wiley, 2000.

Burgelman, R., Modesto Maidique, and Steven Wheelwright, Strategic Management o f Technology and Innovation, 3d ed., McGraw-Hill, New York, 2001.

Buttrick, R., The Interactive Project Workout, Prentice Hall, 2000. Harrington, H . J., Daryl R. Conner, and IVicholas Horney, Project Change Management: Applying

Change to Improvement Projects, McGraw-Hill, New York, 2000. Keane, Inc. Productivity Management: Keanek Project Management Approach for Systems

Development, 2d ed., Keane, Inc, 1995. Kendall. G.. end Steven Rollins. Advanced Project Portfolio Maneement and The PMO, J . Ross

~ u b l i ' s h i i g , 2003. Meredith, J., and SarnuelMantel, Jr., Project Management:A ManagerialApproach, 5thed., Wiley,

2003. Project Manapement Institute. A Guide to the Project Management Body o f Knowledge. Project - ~ ~

Management Institute, 2000. Project Management Institute, Practice Standard for Work Breakdown Structures, Project

Management Institute, 2001. Royer, P. S., Project Risk Management: A h a c t i v e Approach, Management Concepts, 2002. Shtub, A., Jonathan Bard, and Shlomo Glorbersan, Project Management: Engineering, Technology,

and Implementation, Prentice Hall, 1994. Wideman, R. M., Project and Program Risk Management: A Guide to Managing Project Risks and

Opportunities, Project Management Institute, 1992.

Index

Page numbers followed by f or t indicate figures and tables, respectively.

A Acceptance of risk, 65, 83

examples, 196 Activity-based costing, 54 Activity duration estimates, 55 Activity sequencing, 57 Airlines

aircraft utilization, 35, 35t reasons for bankruptcy, 34 risks for new entrants, 34, 35-36

Analogous cost data, 55 Annual worth (PW) method, 201 Assumptions analysis, 80, 81 Avoidance of risk, 65, 83

examples, 196

B Baseline schedule

interim plan for, 112 process, 109, 1lOt-lllt, 111-112 sample, 106, 106t

Benefits, vs. risk, 5-7 Brainstorming, 79 Break-even point

calculation. 20&201 and sensitivity, 201-202

Budgeting expert estimates in, 55 project, 19%194 risk-based, 60

Burr, Donald, 35 Business culture

checklist, 216t risk-based, 12

Business framework pyramid, 22,23f

Business plan, a s risk management planning tool, 76

Business strategy. See also Strategic objectives; Strategic planning

checklist, 216t Business value, sample analysis, 28-21

C Capital rationing, sample calculation,

208-210 Cash flow exercises, 191-193 Client risks, 47 Concept risk, 5 Contingency planning, 5 5 , 6 M 1 Contract management, 97-98 Contract types, and risk implications, 97f, 98 Cost accounting, 54 Cost estimates, 186 Cost reimbursable contracts, risk

implications, 98 Costs

direct vs. indirect, 57 fixed vs. variable, 57

Culture. See Business culture organizational, 13, 15, 75 risk-management. 15-16

Customer requirements. 4, 37-38 Customer risk, 1 5 6 1 6 5

tolerance checklist, 221t

D Data precision ranking, 81 Decision tree analysis, 62, 82, 88

defined, 62 example. 6%66,64f, 2 0 4 4 0 5 theory, 63

Definitive costing, 55 Deliverables, phasing of, 67 Delphi technique, 79

basic steps, 187

226 Index

Department managers, role i n program management, 10S104

Design risk, 5

E Earned value analysis, 85,95 Earned value monitors, 66 Estimates

defined, 54 vs. negotiating, 16 optimistic vs. pessimistic, 59 risk considerations in, 60 sources for, 57-59 three-point, 188 time, 55 types of, 54--55

Expected value, 62 sample calculation, 203-204

Expert judgment defined, 65 used in budget estimates, 55

External rate of return (ERR), 189 External risks, 61, 79

F Financial analysis tools, accuracy of, 59 Financial risk, 48 Functional management, competency,

14

G Gantt chart. 43

examples, 43f, 106f, 108f, 109f

I Impact, assessment techniques, 62 Influence diagrams, 80 Information systems, a s risk management

planning tool, 76 Ingham, Harry, 17,18f Insurable risk, 61 Internal rate of return (IRR), 190 Internal risk, 61

J Johari Window, 17-19,18f

L Learning organization, 14 Legal risk, 61 "Lessons learned" review, 179-183

checklist, 253t focus on people, 183 sample report, 18C183

Luft, Joseph, 18 Lump sum contracts, risk implications, 98

M Microsoft Project software

data entry sample, 135-137 PERT analysis schedule sample, 245 for preliminary scheduling, 130 for project documentation, 132 for risk-based scheduling, 5 5 5 6 ,

147,147t Mitigation of risk, 66, 83

examples, 196 Motivation, a s project manager function,

52

N Negotiating, vs. estimating, 16 Net present value (NPV)

for project selection, 139-140, 140t, 141f sample calculation, 26t, 29t, 31t

Network diagram, 4 0 4 2 custom-tailored model, 42f earlyoate-start analysis, 42,43t generic model, 41,41f time-based, 42

Nontechnical risk, 61

0 Order of magniture estimating, 54-55 Organizational culture

defined, 15 risk-based, 75

Organizational risks, 79

P Parametric estimating, 55

risk in, 58 Payoff matrix, 202 PERT analysis, 23,55

and risk-based scheduling, 55-56, 92, 123, 245

vs. risk matrix, 93,93t Peters, Tom, 14 PMBOK. See also Risk management process PMBOK (PMI). 50

current standards vs. future needs, 69-70, 70t, 72

and project management, 69-73 and risk management planning, 73-75 and risk management processes, 71t-72t,

72-73 Portfolio management, 23 Predictable risk, 61

Index 227

Present worth (PW) method, 200 Probability of murrence, 62, 87 Product development

checklist, 252t process, 99 scheduling See Schedule; Scheduling

Production risk, 5 Productivity rates, 55 Program management

coordination, 117 defined, 99 kickoff meeting, 118 office, 102 plan, 117-118 process, 99-102 reviews, 216 roles, 102-104 schedule, 118 tracking of progress, 119

Program manager (PM) responsibilities, 116119 role, 102-103

Program planner, 104 Program team, 104 Project audits, 179-180,18Of, 183-184 Project budgeting

approaches, 194 process, 193-194

Project charter, 78 Project control devices, 208 Project data, sample analysis, 207 Project management

and communications, 51 and corrective action, 96 and human resources, 51 and integration function, 52 and PMBOK framework, 69-73 and quality, 51 and risk planning, 5C-51 risks, 79

Project manager a s facilitator, 53 leadership function of, 52 risk-taking tendencies of, 17-18 role in risk management, 52-53

Pmject manual integration of risk into, 219

Project planning case study, 131-133 checklist, 217t-218t incentives for integrating risk,

17-19 linked to strategic planning, 13-14 outputs, 78

risk-based baseline, 133-135 steps for integrating risk, 37-43

Project risk. See also Risk vs. business risk, 2 2 , 4 4 , 4 5 4 6 and client setting, 4 5 4 6 identification of, 15,16,61 market vs. product performance, 121 as part of planning process, 2, 4 project deliverable impact, 47 reporting responsibility for, 66 response audits, 85

Projects change requests, 85 crashing of, 67 initial risk assessment, 4 M 9 life cycle of, 48 market analysis program, 27,3%34 operational program example, 27, 32 planning process, 49-50 risk-based budgeting, 60 start-up program example, 26, 31 status report example, 206-207 types of risks in, 129

Project scope, a s key factor in project planning, 59

Project selection analysis of risk in, 48 case study, 127-130 checklist, 216t-2171 net present value analysis, 139-140, 140t.

141f risk analysis, 1 4 6 1 4 8 weighted scoring model analysis, 139-140,

139t Project team knowledge, 58 Prototype risk, 5

Q Qualitative risk analysis, 23, 72, 80-82

outputs, 81-82 tools for, 81

Quality risk, 48 Quality, tradeoffs vs. cost and schedule, 66 Quantitative risk analysis, 72, 82-83

outputs, 82-83 tools for, 82

R Replacement analysis, 191 Response planning, 65 Risk. See also Project risk; Risk identification;

Risk management vs. benefits, 5-7 business framework for, 22,23f

228 Index

Risk (Cont.): categories, 7E-79 communication of, 66, 91, 174-178 consequences, 62 vs. cost, 70 defined, 1,3-4 demystifying, 36 external vs. internal, 2 monitoring of, 4, 91-92 multidimensional nature of, 22 opportunity created by, 3 organizational, 19 personal, 19 practical, 9 vs. quality, 70 residual, 84 response strategies, 65 root causes, 80 secondary, 84 theoretical, 9 tradeoffs, 44-45 triggers, 80 vs. uncertainty, 22, 185, 195 a s vertical process, 22 a s way of thinking, 7

Risk assessment bottom-up approach, 60 goals, 87 iterative approach, 60 qualitative, 23 as step in risk management process,

89 tools, 86 top-down approach, 60

Risk-based budgeting, 60 Risk-based scheduling, 55-56, 92 Riskhenefit template, 6f Risk database, 85 Risk events, 61

sample evaluation, 198-199 status determination, 195

Risk identification, 72, 86. See also Risk assessment

checklists, 85 outputs, 79-80 process, 90-91 and risk management plan, 77 sample plan, 197-198 a s step in risk management process,

89 and SWOT analysis, 46-47 tools for, 79-80 training in, 14

Risk intensity, 95

Risk management building culture of, 15 costs, 96 customer-driven, 149-153 defined, 3 demystification of, 1, 2f 'lessons learned" review, 179-183, 180f and organizational culture, 13 partnering in, 47 as people issue, 95 subprocesses, 185-186,195 and SWOT analysis, 45 U.S. Department of Defense example,

150-154 Risk-management culture

defined, 15 Keane Company example, 15-16

Risk management organization competencies of, 13 preparation of, 9, 10f

Risk management planning, 72, 73-74 and business strategy, 73 methodology, 7 7 6 7 i n multiproject environment, 75 policies, 74 project manager role, 74 stakeholder risk tolerances, 74 tools for, 76

Risk management process, 8&92. See also PMBOK

checklist, 218t-219t creation of, 88-89 steps, 89

Risk matrix, 81,88, 88t Good FlightAirlines example, 28t, 30t. 33t K i n g project example, 125t-126t Huntsville example, 146, 146t-147t office building example, 41t vs. PERT analysis, 93, 93t steps in preparing, 121-123,122f systems development project example,

124t-125t Risk monitoring, 72, 84-85

as step i n risk management process, 89 tools for, 85

Risk planning, 50-51 institutionalization, 50 phase, 15 as step in risk management process,

89 training programs, 51 "walk the talk" programs, 51

Risk qualification, 87 Risk quant

ifi

cation, 87-88

Index 229

Risk response audits, 65 factors, 94196, 95f process components, 93-94 sample plan, 197-198 a s step in risk management process, 89

Risk response planning, 72, 83-84 and common risk causes, 83 outputs, 84 and risk thresholds, 83 tools for, 83-84 updates, 85

Risk response strategies, 186, 195 Risk reviews, 66

periodic, 85 Risk scenarios, 17 Risk scheduling, a s step in risk management

process, 89

S Schedule. See also Scheduling

baseline procedures, 109, 111-112 control, 10%109 integrity, 105 PERT analysis sample, 213 as resource planning tool, 105, 113 resource usage view sample, 106, 107f tracking of variances, 114-115 update procedures. 114

Schedule risk, 48 Scheduling. See also Schedule

five-step process, 107-108, 1lOt-lllt functions, 1lOt-lllt on the network, 112-113 program plan, 1041105 project management software for, 105 tracking Gantt chart sample, 106, 106i

l08L l09f Scope

changes in, 85 modification of, 67

Scope creep, 59 Senge, Peter, 14 Sensitivity analysis, 62, 82, 87

sample, 200 Simon, Herbert, 150 Simulations, 65, 82 Software development

risks in, 58 Software Engineering Institute (SEI), 3

as source of risk data, 58

Southwest Airlines, 34-35 Stakeholder risk tolerances, 74

Eastern Company example, 159 Strategic objectives

examples, 24-25 risks associated with, 25 a s statements of risk contingency, 46

Strategic planning Eastern Company example, 16CL161,

1 6 6 1 7 3 linked to project planning, 13-14

SWOT analysis Eastern Company example, 161-163 in risk identification, 46-47, 80 in risk management, 45

T Target cost contracts, risk implications,

98 Task list, 40, 40t Technical risk, 61,78 Transference of risk, 6 5 , 8 3

examples, 196 Triple constraints, 52

U Uncertainty, vs. risk, 185, 195 Unit price contracts, risk implications,

98 Unpredictable risk, 6 1

W WBS. See Work breakdown structure (WES) Weighted scoring model, 301, 32t, 47

for project selection, 139-140, 139t Workaround plans, 85 Work breakdown structure (WBS), 14

coding of, 54 vs. cost accounting, 54 cost estimating, 53 defining of activities, 53 deliverable level, 38 outline, 39 and product performance risk, 121 resource planning, 53 and risk identification, 90-91 a s risk management planning tool, 76 standard, 100 subtasks level, 38-39 summary tasks level, 38 workpackage level. 39