Carl Angotti
Angotti Engineering, Sunnyvale, CA
(carl@angotti.com)
David Greenstein
Design Shrink, Inc., Cupertino, CA
(green@designshrink.com)
© February 3, 1999
Introduction
Projects are always full of risks and uncertainties. Schedules often slip when a risk becomes reality, and these slips can have serious consequences on time-to-market. The key is to plan for a certain number of known risks, thereby reducing the possibility of schedule slippage.
In this paper we will describe common schedule risk factors, introduce a four step risk management process, and prescribe strategies to preempt risky project situations. We will give you some tools to identify risk and lower its impact, thereby saving your projects from schedule slips.
Types of Risk
Risk factors affect projects in different ways. Schedule slips are just one result of project risks. There are also budget overruns, scope changes, and quality degradation that could occur.
The companies that we service focus on time-to-market products in highly competitive marketplaces. In this environment the most costly mistake is to be late to market. Although budget, scope, and quality are mentioned to some degree, this article concentrates mainly on the risk factors associated with project schedules.
Impact of Schedule Slipping
The most obvious impacts caused by slipped schedules are increased project cost, changed scope, and compromised quality. The impact of a schedule slip can be especially severe for companies focused on time-to-market. Missing a market window by a month or week can destroy market share and hurt profitability. For medium to large sized companies it could have negative long-term strategic consequences, and for small startup companies one missed opportunity could mean closing their doors. Schedule slips could also impact the internal operations of a company by lowering moral and increasing turnover. All of these problems could and should be avoided by keeping projects on track. Lowering project risks is one way to minimize schedule slips and minimize its impact.
Real World Projects
The US Military is expert at planning large, long term projects. Over time they have developed many of today's Project Management accounting practices, like the Earned Value Method, to measure and control cost, performance, and schedule. Even with all of this experience, the military slips most of their project schedules. AUS Congress review of military projects for the years 1978 through 1982 found that the average project took 33% longer than planned. Some fared better and some worse than the average. The differences between project schedules were the risks and uncertainties that occurred during the projects.
We assert that those who plan for and manage project risks will reduce their chance of schedule slips. The risk factors outlined in this paper can be used during the project planning stage to create contingency strategies to save the schedule from slips.
A Simple Risk Model
Before we continue to discuss risk, we need a simple model of what it is. There are two general uses for the risk evaluations, in one case, an accurate value needs to be defined, in the other, a relative measure will suffice. The use of a relative measure requires less accuracy in the estimates, since the results are only going to be compared relative to one another. Only risks that are relatively close to one another in size need be estimated more accurately. The difficulty is trying to quantify its value on some scale. A very simple model would define risk as:
Risk (in $) = Probability (in %) x Impact (in $)
For a particular risk, an estimate of the probability of an event occurring is made. Then an estimate is made for the dollar impact of the event. Both of these are, in some sense, judgement calls, but often a relative measure of several risks can be made easily. If an exact value needs to be placed on a particular risk, more information will need to be obtained to improve the estimates. This, in itself, will cost an amount of dollars, which must be balanced against the judgement of the potential value of the risk. An example of a low risk calculation would be:
Estimate of Probability of Event1 = 1/1000Estimate of Impact of Event1 = $100,000
Risk = (1/1000) X $100000 = $100
An estimate of a clearly higher risk would be:
Estimate of Probability of Event2 = 0.75Estimate of Impact of Event2 = $100,000
Risk = (0.75) X $100000 = $75,000
In this case, clearly the latter risk is much greater than the former. The ability to rank them is easy, so the accuracy of the estimates need not be great. If the two risks came out approximately the same, it would be more important to have more accuracy in the estimates. Usually, for Risk Management, the risks are calculated and ranked with the highest one being worked on first. This is especially true if the economic value or the risk is high.
For example, lets say the potential loss of sales to a competitor for a schedule delay was estimated as $10000 per day. A one month delay would have an impact of approximately $300,000. If the probability of a one month schedule slip according to past history was 75%, then the risk of schedule slip of one month would be $225,000. Preventing such a slip would be very valuable. This would be one risk that would be worth going after.
To complete this example, and if the estimates of impact and probability are accurate enough, we must then compare the cost of any changes to be implemented in the organization against the estimated savings of $225,000.
The entire risk management process itself brings with it a cost of implementation. This must be balanced against the estimated value of the risks to be assessed. The process relies heavily on the judgement and experience of the person and/or team that will engage in the process. It also depends on what historical data has already been gathered. Both of these factors can significantly lower the cost to accurately evaluate a particular set of risks. The more historical information that is presently available, the more effective the process will be. Finally, the entire process itself is subject to continuous improvement. At the beginning, there is more judgement than information. Later there is far more information used and far less judgement required in the estimates. Taking the steps to get the process started is probably one of the most critical decisions an organization can make.
Four Step Risk Management Process
Risk Management is accomplished by following a straightforward four step process. By following these steps, an organization can manage the risks to a project from any source. These steps appear as follows:
The first step is to identify the risks and risk factors. This is accomplished by first becoming aware of potential risks, such as from a list similar to the one presented. Sometimes, this requires great honesty and courage on the part of the PM to actually identify risks and risk factors that are at work in their organization or project. Then they, preferably along with the help of the project champion, or best of all with the help of upper management, should begin the Risk Management process. This step in itself involves risk to the project, the organization and possibly even the PM.
The second step is to assess the probabilities and impacts of the risks and risk factors. This step relies heavily on historical data and information gathered from past and current projects. This data is often not readily available. Methods need to be created to validate the probability and impact of the events under consideration. This might include creating ways of using the current accounting system information and other information systems to gather the appropriate data. Methods also need to be devised to detect the risk factors that are commonplace on organizational projects. The process could involve using data that can be obtained from previous projects. For example, how easy is it to compute your current average schedule slip as a percentage of the original estimate?
This third step in the process involves analyzing the information gathered in the previous step. Risks are computed, and risk factors are looked at carefully and ranked by their value. It is often valuable to review lessons learned from previous projects and assess what factors contribute to specific risks. At this point, modern Decision Analysis methodologies can be employed to rank the risks and risk factors.
Step four involves the creation of the strategies that will implemented to reduce the risks that have been evaluated. We have noticed that there are a number of strategies that can be used to help in this part of the process. These are discussed later in this paper.
Ten Common Schedule Risk Factors
Schedule Risk Factors are those conditions that occur that appear to significantly correlate with slips in schedule. When we prepared this paper, we assessed the common Schedule Risk Factors we noticed in the projects with which we have been involved. These projects most often involve high tech, rapid turn around, product or software development projects. Other industries probably encounter similar problems.
Our assumption is that organizations are attempting to plan, schedule and control their projects. Those not engaging in this overall process are almost doomed to having it be the major risk factor. The risk factors that we encounter are in effect especially when project managers are dealing with technical and other highly skilled personnel that must deal across functional boundaries. Listed below are ten examples of these.
If the organization is dependent upon another internal project, or its own "Bleeding Edge" technology, it can suffer the same effects. Evidence of this can often be accompanied by management or project personnel to require team members to have hope, think positively, consider every problem is really an opportunity, proclaim "we'll think of something", etc. Meanwhile, the schedule slips.
This factor looks like NIH, "Not invented here". There are arguments as to why process, tools, etc. can't change. One hears statements like "At IBM, Intel, 3Com, etc. we did it differently and it always worked". If the manager wants to make a change, the team will look for why it won't work, rather than adapt. Or always point out its flaws. All of this resistance, of course, has a corresponding work slow down, or worse, no one speaks up to the PM or team to indicate that they can't or won't work with the change.
This is another "emperor's new clothes" affect. Team members or management refuse to take into account these "start up" costs, and continue with the original, optimistic, plan. They pretend that there is no learning curve.
This is phenomenon involves inter-group sparring. It is especially prevalent between divisions, and accentuated by professional and functional style and knowledge differences. It is exacerbated by physical distance. Things "fall between the cracks" or important information doesn't get exchanged.
The work expands to fill the time available. It often involves poor planning. It can also involve the "Student Project Syndrome" covered in the book "The Critical Chain" by Eliyahu Goldratt.
New tools, software, hardware, management approaches, etc. drain time away from real work. This is a problem with highly skilled resources that are focused on goals other than those of the project. It sometimes is a product of general, rather than closer, management or the higher technical skill of a project resource than that of the manager.
These are highly schedule adverse events that occur during the execution of the project. In this case, there can be no planned response, since the event is unknown. There is no contingency plan in place to detect and handle these events.
This is another example of another "setup time" cost that has big effects on a project. It involves a lack of real considerations of its effects on the project team and the immense changes that can occur at this time.
Risk Management Strategies
Now that you have identified the schedule risk factors for your project, it is time to create strategies to avert these risks. Schedule slips and their risk factors are usually symptoms of the real problem: poor initial strategies. We will discuss eight preemptive strategies and contingency plans to reduce or eliminate schedule risk.
Optimistic Scheduling is often a risk factor when upper management is not fully behind your plan. Management will try squeezing out any scheduled time in favor of reaching the marketplace quicker, and they may do this anytime during a project.
Management often needs more information to make decisions. You need to sell management on the project schedule before kick-off, and get them to agree not to meddle during the project. Write up a few line contract on a piece of paper and have them and the team agree to it, or even sign it. That agreement makes the schedule more tangible to everyone. Upper management will better understand the consequences if they change their minds and the team can focus on minimizing scope changes.
People inside companies get an "always behind schedule" attitude after three or four major schedule slips. Courses of action are taken to get the schedule back on track, like "Piling On People", using "Bleeding-edge Technology", and acting busy ("Parkinsons Law"), but each slips the schedule even more. Frustration settles in, and people come to assume that every schedule will eventually slip.
To turn this "always behind" perception around, you must take preemptive measures. One strategy is to acknowledge tasks that complete on time to reinforce the idea that it does happen. Also, clearly communicate the consequences of being late on a schedule. This lets people know that projects can be done on time and that late projects have a price.
Often people are promoted through the ranks to be Project Managers without any formal training. This lack of proper training allows for many risk factors to surface, from "Optimistic Scheduling" to runaway "Personal Agendas".
A solid solution is to provide them Project Management training. University MBA programs often have continuing education courses in Project Management, and they provide the tools necessary to deal with many of these risk factors.
The biggest problems we have seen with project teams are "Poor Communication Between Groups" and "Parkinsons Law". Communication is poor because people will tend to work on tasks and not on teamwork. A task is tangible and measurable, while teamwork is more esoteric and subjective. Parkinsons Law applies because busy-looking people are usually left alone, and this adds to poor communications too.
A strategy to improve communications between groups is to send them to teamwork training. Some are called "ropes courses" that allow the team to act out fun situations to improve their communication and build trust. A one day course can pay for itself if the team learns how work more efficiently together.
The definition of a fool is "someone who does the same thing over and over hoping the result will turn out different". "Optimistic Scheduling", "Piling on People", and "Bleeding-edge Technology" are often used project after project with the hope things will get better, but the schedule continues to slip.
A preemptive strategy would be to review the "lessons learned" of a prior project and apply that knowledge towards the next project. For example, people that used "Bleeding Edge Technology" for a prior failed schedule could use older, more stable technology in their next project. Instead of "Piling on People" towards the end of a project, at the beginning of the next project spend more time in the planning phase.
Often "New Tools, Technology, or Processes" introduce uncertainties into the schedule. Sometimes there are hidden problems and they can grow into projects themselves.
During project planning you can implement measuring systems to monitor the progress of the project. Specify a definite amount of time or number of tasks to trigger your corrective actions. For example, if it takes more than three tasks to fix a new technology, then change back to your older, known technology. Or if a new process delays milestones for a week, then put more management attention on the details of that process until it snaps back to schedule.
The old school of management taught cost accounting and Earned Value methods. They are thirty or forty year old methods that measure schedule by dollar amounts. The US Military created many of these techniques for large, long term projects.
There is never a better time than now to study new Project Management methods. New techniques, like Theory of Constraints, concentrate on the tasks of a project and the critical path. They are a better fit for todays time-to-market projects. A good book on the subject is "Project Management in the Fast Lane: Applying the Theory of Constraints" by Robert Newbold (St. Lucie Press, 1998).
Most rewards for a job well done are given at the end of a project when everything is completed. Without some recognition during a project, people tend to hide in their cubes, communicate less, fill up their time looking busy (Parkinsons Law), and some even perform extra curricular work outside of the project.
Summary
We have discussed how to lower your risk of slipping project schedules using a four step process for managing and controlling project schedule risk factors. The process requires identifying potential risk factors, assigning a value to the risk, prioritizing, and developing strategies to remediate the risk.
We identified ten common risk factors that could impact a project. Some factors are obvious, but some are not and it is important to identify them all. You are encouraged to review them all when planning for project risks.
We measured risk as a percentage probability of the event occurring times the potential financial impact if it occurs. The resultant numeric value can be compared against other project risk factors to help prioritize the potential risks.
Finally, we listed strategies to remediate risks to lower their chance of occurring. Its "an ounce of prevention is worth a pound of cure" method of risk reduction. Lowering the risk of schedule slips is cost effective and insures time-to-market. Those who take a few moments to plan for potential risks will lower their schedule slips and reap the benefits.
February 3, 1999