Equipping the Project Executioner

Matt Eventoff, a US-based messaging and communications strategist, spends much of his time working with lamenting CIOs, CTOs and other IT executives labouring to hammer that final nail into the coffin of failed IT projects.

Grieving clients call Eventoff in once they have finally accepted that the project is terminal or towards the end of the decision-making process, to ensure the reasons for the death are made explicit and information is delivered to stakeholders as intelligibly and articulately as humanly possible. Eventoff says those corporations who use his services do so for very good reasons. In his broad experience the number one issue confronting IT executives forced to kill a project is a lack of clear communication as to why it has been taken off life support.

“I have watched CIOs lose star employees and future talent due to a miscommunication or mixed message that certainly cost the company more in the long run than the program ever would,” Eventoff says. “One instance was a decision based on financial information where the owner of the project was never informed of the reason, took the termination of his project very personally, and looked for employment elsewhere. That was not the result the company was looking for.”

Palliative care is essential when a project is dying a slow and painful death, not for the project itself, but for all those watching its death throes and starting to mourn. CIOs must ensure reasons for either termination or continuation are clearly conveyed to the right audience. That means taking an inventory of every player and every person affected by the decision, and ensuring each is communicated with personally, Eventoff says. It’s a move that can accrue some real ancillary benefits. For instance the very process of communicating and developing the core message about the decision often allows a lot of information never normally discussed during the decision-making process to come to light, leading to fresh insights or even revelations that can eventually alter that decision.

Biting the Bullet

Like amputating a gangrenous limb before the infection can hit the entire body, there are times when an organization has no choice but to kill a runaway project before it kills the company. In those instances, it is usually far better to bite the bullet early than to allow a failing project to linger on in pain.

“The risks around deciding on appropriate projects are myriad and much like those of any other large investment a corporation might make,” Prevoyance Group points out in a recent paper Building the Project Firing Squad. “Indecision leads to missed opportunities, or a competitor outmanoeuvring you while you sit on the sidelines analyzing, pondering and pontificating. Poor decisions lead to bad investments, or an abundance of activity in one area at the expense of missed opportunities in another potentially more important area. In addition, nothing saps the morale of your people more than continuously making a decision, then revisiting and revising that decision every week, bouncing your teams between objectives like [a] costly game of ping pong.”

Based on his personal experience, says Sandip Lahiri, an IT architect at IBM Florida, employee morale is best maintained by killing dying projects — even in the face of likely penalties — the instant it becomes clear they can’t meet their major goals.

“One project I was involved with attempted to replace a COBOL-based system using a client/server system,” Lahiri says. “However, the client/server system originally ran 10,000 percent slower than the COBOL system. All fine-tuning and optimization efforts did not make it run any faster that the COBOL system. Management finally axed the project in spite of legal consequences. One partner did indeed sue.”

Making the decision to axe a project is easier when all projects are selected in the light of clear and unambiguous goals and objectives, whether financial (ROI, IRR, EVA) or more subjective in nature, as in the Body Shop’s dictum that no products requiring animal testing will be sold or developed.

Clearly articulating objectives at the very beginning ensures they will be taken into account during project planning and makes it easy to recognize when those objectives are not being achieved, says Bob Mittelsdorf, who runs Singapore-based project management consulting firm Mittelsdorf Consultants. In such cases the project should be canned, or at least shelved until external conditions causing the deviation from the objectives have been resolved. Sensitive feelings should be ignored.

Page Break

“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.

Page Break

Protecting Bruised Egos

Perhaps the toughest part of killing a project is ensuring the egos involved aren’t killed along with it. Human beings seem to be born with an innate dislike of being associated with failure, says D Kate Forbes, director, Internet and database marketing at Philadelphia-based financial services software company Sungard. Threats to projects that people hold near and dear typically trigger an innate survival mode in which they will make every attempt to keep the project alive against all logic. “We simply do not want to fail, and until we lose that aspect of our human selves, this will always be a problem to overcome,” Forbes says.

Better then to label failed projects as “learning opportunities”, she says. Unfortunately, it can be extremely difficult to get the organization to think of projects as learning opportunities rather than failures until the culture of the organization is behind such a shift. Our human nature also threatens to get in the way because calling attention to the failed project calls out the fact that the team failed. “We would rather the unsuccessful projects go quietly away than label them and learn what they have to teach us. It’s a vicious circle,” Forbes says.

“In some cases, the project is not a failure, but the business needs or the market has changed since it was initiated. In IT, the environment changes so fast that you can almost bet on the assumptions, needs and technology changing during a project. If we go in with this mind-set, it may alleviate the stigma associated with ending a project prior to completion. Now we just have to deal with the issue of time wasted.

“So what can we do? Find a leader who can evangelize a project while not being so connected to it that they cannot separate themselves from it. Have that person interview the stakeholders within the organization and determine the direction after hearing each group’s input and analyzing that against the project documentation. This should provide some well rounded insights.”

1 2 Page 1
Page 1 of 2
6 digital transformation success stories