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.

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email CIO
• Follow CIO on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark