E-MailClosing Out Risks
by Carl Pritchard, Senior Consultant, Cutter Consortium
What would it take to shut down your project intentionally? What state of nature would be required to actually drive you to formally terminate it? The unfortunate thing is that most project managers don't have an answer for that question, and the organizations that support them don't have the information either. All too often, we don't have a clear definition of an approach, terms, and process to shut down projects, which puts the organization at risk for continuing projects that are no longer profitable or that no longer serve their original intent. Instead, we forge ahead on projects that have strayed from their goals and that represent a drain on organizational resources. Whether it's because of politics, investments, personal interest, or contractual obligation, we plow on with projects that simply don't make sense.
But what if we close out the wrong project? What happens if we set ourselves up for legal action? Those types of questions are what hinder our abilities to shut down projects.
There are ways to prime ourselves for lower risk in shutting down projects. We can do so through consistent practice and through a clear understanding -- from the beginning of the project -- on what represents the appropriate time to shut down the project. Project chartering documentation generally does an exceptional job of defining the reasons to start a project. The same documentation can be equally effective at defining the reasons for shutting down a project, if the documentation is designed to accommodate that goal.
Chartering Project Closure
A charter is a document that declares the promises for a project. It provides authorization to use resources and authorization to forge ahead on a particular vision of the project. It should also include detail on when the project manager and team are authorized to walk away from the project and when management will acknowledge the need for a review to determine whether termination is warranted.
The rationale for closing out a project can be legion. The project is too far overbudget. It is too distant from the client's original goals. It will be delivered too late. It is proving too technically complex. While all of those reasons are sound, the challenge for most organizations is determining what constitutes "too much." One person's idea of too much is not the same as another's. As a result, there evolves a sense that there are no good reasons to actually close down a project before it reaches its conclusion. The definition of "too much" within the project charter can address the concerns that face the organization on a variety of fronts. A project that is on-budget and on-time can still be an abysmal failure that deserves to be shut down. But that can only be achieved it we have a clear definition of terms.
Terms that can be applied to such an evaluation should be specific, objective, and reasonably easy to discern. Examples would include:
The project will be sent to management review if/when the negative earned value cost variance exceeds 19% of the total project budget.
The project will be forwarded to management review if the project delivery date extends more than X weeks past the originally identified deadline.
The project will be forwarded to management review if the customer files more than 15 change requests.
The project will be forwarded to management review if there are more than six complaints on file.
What's noteworthy is that while reading through these few posted here, it's a fair assumption that many of you found one or more to disagree with. "We'd never shut down for that," you might argue. Fine! At least you know where you would not draw the line. If we have clear lines drawn, it not only helps at a managerial level, but also at a team level. Team members get a clear sense of when the project is inching toward the management limits for various behaviors and can work to avoid those limits.
In the past, some of my clients have challenged this notion, suggesting that creating a clear border for project termination creates an opportunity for team members to exceed performance measurement baselines with impunity, instead worrying only about the new thresholds. This is akin to arguing that the laws for speeding should not be established as they are. In most states, there is one set of actions associated with going only five miles an hour over the speed limit and a different set of actions associated with excessive speed of over 20 miles an hour over the speed limit. The laws for going only five miles an hour over the speed limit normally include a nominal fine and a point or two against a scale that could lead to revocation ... someday. The laws for going 20+ over the limit in some states are Draconian, including potential on-the-spot revocation of one's driver's license.
Do people drive slightly over the speed limit? Yes. Do many drive more than 20 mph over the speed limit? Very, very few. And generally, they are perceived as part of the lunatic fringe. Will projects exceed their performance measurement baseline? Yes. But the question as to whether or not they will head all the way to the tolerance limits is one of degrees. And because best practice organizations can establish those limits within a charter, project managers and team members can now serve management interests far, far better, as they know when, how, and why the project may ultimately "hit the wall."
Setting such limits has its advantages. The review for termination has much less of a stigma when the limits are in place. Team members know and understand review processes. Management gets a greater sense of control. Even clients and customers understand that their world will not be allowed to spiral out of control. Those capabilities make the early establishment of project tolerances well worth the investment.
-- Carl Pritchard, Senior Consultant, Cutter Consortium