“The review process should encourage transparent and impartial decision making; egos and office politics must be left out of it,” Mittelsdorf says. “This obviously means that strong leadership from the very top is necessary, and that there is no shame on the project manager whose project is killed. In fact, the organization should reward the PM who suggests that their project not meeting its goals and objectives be cancelled.”
Mittelsdorf warns the decision to not cancel a project should never be based on the fallacious argument that “we’ve spent so much already, we should just finish the job”. Corporations waste millions of dollars every year on projects that are allowed to continue when they should be terminated, he says.
On the other hand, cancellation decisions can and should be influenced by the project’s significance to the business. Many large-scale projects started as disasters but lead eventually to great success, both financially and for the customer, points out Mark Atkinson, VP innovation at Deutsche Telekom in Melbourne. In general Atkinson says, smaller projects may be better assessed against a corporate “hurt statement”. If the gain doesn’t exceed the pain then someone must sell the concept of killing the project to the customer.
When it’s become clear the deliverable once thought desirable would be either unhelpful or not worth the further development cost, killing a project is the best possible outcome, says US-based “retail operations problem solver” Mark W Schumann, whose focus is on boosting the work of underperforming software development tools. In such cases, Schumann insists, the team hasn’t failed, but has instead successfully freed up resources to expend on more productive uses.
“The mistake a lot of organizations make is in sticking with a static go/no-go analysis that was made before beginning the project,” Schumann says. “Often we discover things along the way about the scope or application of the proposed deliverables that should, but often don’t, change the go/no-go calculation. In the design phase, for example, team members may find that some or all deliverables are available from existing system resources. Would it be a failure to stop working at that point and simply start applying what already works?
“In shops where design decisions are continually reshaped by customer feedback, this could happen at virtually any time. Sometimes even writing the unit tests — before developing any new application code — reveals the weak points in a plan that must then be revisited. It’s a truism, but true, that the earlier you spot such a turning point the better.”
Schumann says the key is to watch continually and not to fear making small adjustments along the way.
However as Remi Onopa, IT security and compliance specialist consultant at Connecticut-based professional services firm Carlin, Charron & Rosen, points out, CIOs and PMs should always be aware that since many people are likely to be evaluated on the merits of any project, a great deal of individual effort is likely to have already gone into any project, making it particularly hard for those involved to let go.
“Of course there are always politics that keep meaningless, resource-wasting projects afloat,” Onopa says. “Some are just kept alive to increase department’s budget or to make it seem that something is getting done.” He says under these circumstances, objectivity and assertive decision making — scarce commodities in many organizations — are desperately required.
“Is the project hurting your bottom line and is there no end in sight?” Onopa asks. “Cut it. Sunk costs are just that — you can’t recover them — but there is no need to dig a deeper hole. Sure, a few feelings will be hurt in the process, but that’s crudely better than hurting everyone’s feelings when it comes to raise time, because of few botched projects.”
“I would kill projects that have clear acceptance criteria for which the critical ones have failed, with no acceptable recovery,” says Theresa Edgington, Assistant Professor at Texas-based Baylor University. However Edgington says organizations need to be cautious with truly innovative projects, where sometimes just slowing down the investment and better milestones are needed.
“Some innovations precede the market window,” she says. “When I was in the industry, one of my engineers came to me to note one of our advanced technology products could not meet a key product requirement. Instead of killing the project, I indicated we’d shelve it, to see if the technology could work at a later date for something else. It’s just semantics, but it means a lot to your staff when you don’t kill their children unnecessarily. We still accomplished what was necessary: no continued investment until we had an attainable objective. Your team needs to respect business goals, but they have invested themselves in these projects, sometimes quite emotionally.”
If a project is to be killed off easily it needs to be done either during planning and analysis or design, says Michael Ackerman, president and CEO of Commsworld. Once a project makes it to the build stage a significant portion of the budget has been spent (both capital and expense), which means the write-off could be worse for the company than actually completing a project with a reduced scope that will not meet the company’s needs. This applies mainly for the capital expenditures, he says.
“I believe if equipment and services are capitalized and in the case of equipment, if it cannot be reused elsewhere in the organization and the project is cancelled, then capital depreciation must all be taken in the first year. If the amount is large enough, it could materially impact the company’s bottom line,” Ackerman says.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.