How to Respond Productively to Risk in an Operations Management Project
Responding to risks when they occur is one of the great tests of an operations project manager. This is particularly complicated by three “laws” that work against efficiently completing the project. One law, Parkinson’s law, applies to times when things are going well. The other two, Brook’s law and Homer’s law, kick you when you’re already down.
Stay productive: Parkinson’s law
Cyril Northcote Parkinson observed in 1955 that “Work expands to fill the time available for its completion.” He based this observation on years of working with the civil service, yet engineers and programmers are often accused of “gold plating” or “over-engineering” (these are both terms meaning that the engineers have developed the project far beyond what the customer requires or cares about) when left with excess time.
Yet tightening deadlines too much to prevent “gold-plating” can also be counterproductive. Research consistently shows that employees, when faced with clearly unrealistic deadlines, simply give up trying to meet them and make progress very slowly.
The best approach to avoid Parkinson’s law without driving employees to despair is to establish moderately aggressive timelines.
Recover from delays: Brook’s law and Homer’s law
When a project falls behind schedule, getting the project back on track is surprisingly difficult. Typically, managers resort to one of four methods:
Adding resources (typically, extra employees)
Working employees overtime
Delaying the project
Reducing project scope
The first two methods are both problematic, because of the rework cycle. Research also shows that rework — work that you thought was complete but turns out to be defective and needs to be redone — is a large part of all projects. Rework is prevalent in every project from building airports, to remodeling houses, to developing new services, to writing software.
In any project, there are a number of tasks to complete. The remaining tasks in the project are completed by personnel at an apparent task completion rate. Some of these are indeed actually completed. However, many of them only appear completed. In reality, they become undiscovered rework, which will need to be done over again. As this rework is discovered, it increases the remaining tasks that need to be completed.
The rework cycle interferes with project completion because adding personnel only increases effective personnel after a delay as the new employees learn enough about the project to be useful. However, in the short term, until the new employees come up to speed, the average experience of personnel is reduced (at least with this project). This increases the mistake rate, which drives up undiscovered rework, thus delaying the project.
Adding workers to a project late in its life cycle usually results in mistakes and delays. This is the reason behind Brook’s law, which is “adding workers to a late project makes it still later.” The implication is that if you need to add resources, then you really need to do it before you actually need them in order to properly train and prepare them to help.
This also means that you’ll have to vigorously monitor your project so that you can add resources at the first sniff of trouble.
One alternative to adding new workers is to work existing workers overtime. This usually works as long as you don’t work them overtime for too long. Otherwise, Homer’s law comes into play.
If you make overtime a fact of life for employees for too long, you’ll end up stretching out the timetable for your project, according to Homer’s law. Working overtime increases productivity in the short run. In the long run, however, it increases fatigue, which in turn increases the mistake rate, setting the rework cycle off again, this time with a vengeance.
Delay the project
Adding employees to a late project often doesn’t work, and working employees overtime has limited usefulness, so sometimes the best approach for managing risks related to productivity is to revise the schedule to reflect a delay. While this may seem defeatist, it may actually get the project done faster than adding new people or working your current personnel overtime for too long because it won’t kick off the rework cycle.
Another approach that works well is to sacrifice functionality, also known as reducing scope.
Sacrificing functionality is often a successful strategy for managing a delayed project. One way to implement this approach is to design “sacrificial” functionality into the project in the planning phase. If the project runs over budget or is delayed, then this functionality can be sacrificed.
The advantages of this approach are twofold. Early in the project, while it is still on time, all the employees are fully occupied so that they don’t waste time on over-engineering the project. Later on, if the project timing does go awry, you have already identified what functionality can be dropped with the least impact on the customer’s satisfaction.
For example, one software provider delivered 85 percent of its software project to a client on time, and the client was reasonably happy. However, the provider made sure that the 85 percent delivered contained the functionality that was most important to the client. At a more prosaic level, we’ve all turned in papers in school in which we’ve sacrificed some content in order not to be late!