Projects that are terminal need to be shelved

Unnamed contributor says cutting losses on failing projects is vital

When you have less, you have to do less. High on your priority list should be to invest as little time and capital as possible on losing propositions. Of course. Some losing propositions are hard to spot, but many are easy to identify. High on the list are projects that have no chance of success. And by "success", I don't mean completion. It is easy to complete a project – well, no, it isn't. Relatively speaking, though, it is easy when you compare what is required to complete a project with what is required for the project to succeed. Here's the difference: Completed projects produce all of the deliverables described in the statement of work, in accordance with their specifications. It is nothing to sneer at; accomplishing even this isn't easy. But completion doesn't matter, unless the deliverables are put to productive use in ways that change and improve how the business operates. That is what is required for success. So how you can identify projects that will never succeed? Here are some indicators. Large size, long duration: Any project with more than seven core team members and a completion date more than six months after its launch date is questionable. Any project with more than 20 core team members and more than two years to get its work done has a chance of success that is technically greater than zero – but not by very much. To be fair, you probably should not kill these. What you should do is break them apart into a collection of separate small projects, each with no more than seven core team members and six months from start to finish. You won't officially be doing less with less, but you'll be doing the same with less, because two-year projects engender a relaxed attitude. They also let slackers hide behind the herd. So by breaking sizeable projects apart, you'll get more out of each staff member. While you won't be doing less with less, you'll be doing the same with less – not a bad result. No sponsor: Sometimes it is easy – no business executive was willing to step up to the plate and sponsor a project, and because it was important for the company the CIO (you?) had to do it. Forget it. You'll be able to bring the project to completion. But you won't be able to bring it to a successful conclusion, for a simple and obvious reason: A project's deliverables are just means to an end. The end – the goal – is business change. Business change is hard enough when high-level executives are willing to stick their necks out and take risks to make it happen. If no business executive wants change enough to sponsor the project, it won't lead to any useful result. Ever. Bring these projects in front of the executive committee (or whatever group is responsible for project governance) and suggest, politely but forcefully, that since nobody seems to want the project's results enough to serve as sponsor, the company should invest its resources in something else that business leadership does want. Bad sponsor: Sometimes it isn't so easy. Sometimes a project has a sponsor in name only (SINO). These are easy for a project manager to spot. The sponsor is never available for update meetings, ducks important decisions that are beyond the authority of the project team, fails to commit members of his or her staff to the project (or does commit them, but doesn't make sure they show up when they are needed) and informs the project manager, when issues arise, "That's your problem and I expect you to solve it". SINOs are the people who figured out while advocating bold change is a career builder, implementing bold change is the sort of risk only losers take on. When the project wraps up, SINOs will explain that the deliverables don't do what they need them to do, blaming the project manager and project team for the mismatch. Dealing with SINOs won't be easy. As a class, they're better at company politics than you are, so you have to find a way around them that doesn't force you to outplay them at their own game. Your best bet is to promote a new philosophy to the executive committee. Because all projects are about business change, all projects must include the tasks, deliverables and participation required to make business change happen. It should be an easy sell. Once you get their approval, instruct your project managers to make the necessary changes, which means the project plan will now include specific tasks that have business participants' names on them. If they don't show up, you can recommend to the executive committee that because the SINO clearly can't spare enough staff time to make the project successful, the company is better off cutting its losses than continuing. No point: In the end, businesses experience only three forms of benefit: increased revenue, decreased costs or better-managed risks. Any other supposed benefit is either a means to one or more of these ends, or it isn't a benefit at all. It is up to the sponsor to identify the benefit, commit to it, figure out how long it will take to show up, and explain how everyone will be able to recognise the benefit when it does. Cost-cutting is the easiest to measure, of course, but that doesn't make it the most important – revenue generally wins that award. Regardless, if the executive committee doesn't already enforce the discipline of "no revenue, no cost-reduction, no risk management, no project," then it should. Encourage this. You already have less – primarily, less staff, so doing less is not an option. It is an inevitability. And if you're going to do less anyway, the first items to toss are the ones that are worthless.

Join the newsletter!

Error: Please check your email address.

Tags managementprojects

Show Comments
[]