Equipping the Project Executioner
- 05 September, 2008 11:25
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.”
The tricky part, Forbes says, is finding that leader to begin with. What’s needed is a personality trait, not technology expertise, but organizations almost always assign the technology expert or hire an outside consultant with that same expertise to examine the remains of the project. These same individuals have a proclivity to suggest additional life support over calling time of death, in deference to their own basic survival instinct.
Project leaders should also be alert to the dangers of deception by project team members desperate to postpone or avoid any cancellation decisions, says Mike McClure, consulting principal at Canberra-based IT consultancy Ajilon.
“One of the human factors that I often see undermine various attempts at instituting good project governance is the wish of the project team to avoid the stigma of failure that comes from project cancellation,” McClure says. “In many cases this has led to people writing misleading status reports to the governing body, making it hard for the SRO or project board to make good, evidence supported decisions.
“It is a major cultural change to sell people on the idea that a cancelled project is more of a success whereas a project that drags on and continually fails to deliver is a failure. If that sort of culture is well established, then the project team will be more likely to self-moderate on the issue of a bad project they should kill so they can move on to a better project versus the project that just needs ‘a little more loving attention’.
“It’s easy to say that only the funder or project sponsor should say when to pull the plug, but that discounts the effect of a Death March project on the technical team,” Schumann says. “It’s demoralizing and exhausting, it runs the risk of losing your best people, and requires recovery time afterwards. When you consider the business impact of stopping a project, the health of your technical or development team has to be part of the analysis.”
It is also vital to have the decision made by people with skin in the game, says Jim Bullock principal consultant for US-based software developer Rare Bird Enterprises. Let the people who depend on the project’s success and the people who are on the hook to deliver decide.
“It’s easy to prolong a zombie project when someone else has to live with it,” Bullock says, “and amazing how sensible people get when they have a personal stake in their decisions. So, on a project, allocate five per cent of the project budget as a bonus awarded to the folks on it and using it . . . as it generates its ROI. Or, you could just bet them lunch. As they think up their answer, their face will tell you whether they believe the project can work.”
Page Break
Sidebar | Beating a Dead Horse
How companies treat the dead horse
Dakota tribal wisdom says that when you discover you are riding a dead horse, the best strategy is to dismount. However, in business we often try other strategies with dead horses, including the following:
1. Buying a stronger whip. 2. Changing riders. 3. Say things like: “This is the way we have always ridden this horse.” 4. Appointing a committee to study the horse. 5. Arranging to visit other sites to see how they ride dead horses. 6. Increasing the standards to ride dead horses. 7. Appointing a tiger team to revive the dead horse. 8. Creating a training session to increase our riding ability. 9. Comparing the state of dead horses in today’s environment. 10. Changing the requirements and declaring: “This horse is not dead.” 11. Hire contractors to ride the dead horse. 12. Harnessing several dead horses together for increased speed. 13. Declaring: “No horse is too dead to beat.” 14. Providing additional funding to increase the horse’s performance. 15. Do a cost analysis study to see if contractors can ride it cheaper. 16. Purchase a product to make dead horses run faster. 17. Declare the horse is “better, faster and cheaper” dead. 18. Form a quality circle to find uses for dead horses. 19. Revisit the performance requirements for horses. 20. Say this horse was procured with cost as an independent variable. 21. Promote the dead horse to a supervisory position.
From: http://www.thehumorarchives.com/joke/Beating_a_Dead_Horse
Page Break
Sidebar | Who Makes the Call?
Depending on its size, the decision to kill a project might rest with one or many
Commsworld CEO Michael Ackerman believes who makes the call to cancel a project depends upon the size of the project. If the project is large enough to have a steering committee then that group needs to be the one that makes the final recommendation to the project sponsor(s) who will make the ultimate call. If it is a smaller project, then the decision should be made by the project manager (PM) or the portfolio director.
“Of course input would need to be provided by the business, technical teams, and finance. In a perfect world, feelings would not be a part of the equation, but we have all been on projects that were near and dear to someone’s heart. If a pet project is be cancelled then a presentation must be made as soon as possible to the sponsor showing them in black in white,” Ackerman says.
“The harder question is how to tell if a project is doomed to failure or just in jeopardy of failing. In all my years of working in IT I have never been able to create a check list that allows someone to just answer a few questions and come up with the right answer. I’ve taken two approaches in the past to try and make this decision but both have a subjective component to them.”
The first method is a team-based approach. Get the leads from the all teams in the room and whiteboard the issues: technical, budgetary, operational, and so on. When you’ve done the list go back and next to each one record the group’s confidence level that the issue can be mitigated. Once this exercise is complete and the ensuing discussions ends, Ackerman normally calls for a vote on cancelling the projects. However, before the vote is called for, he prefaces the vote by asking each member to imagine for a moment this is money coming from their personal cheque account instead of the corporation’s and to not think about the impact cancelling the project has on their teams.
“After a consensus is reached, I tend to review the information collected and add my own input because I have found that no one is truly able to take themselves out of the equation. I always reserve the right to add a personal note, if I am not the decision maker, and then forward the recommendation to the steering team or portfolio director,” Ackerman says.
For smaller projects Ackerman tends to conduct the research himself, taking into account all of the items above and weighing it against the talent level of the team members and his belief in their abilities to redress the issues and then make the call.
Be warned, though. Ackerman says wherever it seems likely the current team cannot overcome the obstacles in front of them, the difference between cancelling a project and trying to save one comes down to the project manager’s ability to bring in a the “A” team or a SWAT team to help resolve the issues. If the team continues with the same staff in place and the analysis suggests there is less than an 80 percent chance of recovery, chances are that the project will still fail.
“After all, the current team got themselves into the mess and as a result most likely will not be able to get themselves out,” he says.
— S BUSHELL
Page Break
Sidebar | Figuring the Benefits
Deciding whether to repair or terminate is the issue
The UK’s Office of Government Commerce (OGC), which developed ITIL and Prince2 for project management, has also developed and released “MSP” Managing Successful Programs.
Within it is what Shayne Phillips, director, ICT strategic programs, Investment & Assurance for the South Australian government, describes as a well documented publicly available approach to the art of portfolio management.
OGC suggests matching program investments that help define work efforts designed to change, grow, transform or adjust the business against business benefits which prove the value of doing the overall work of the program [project].
Generally, this should be done by a leadership team (the sponsoring group) from within the business. The team prioritizes the work efforts based upon analyses of the business cases, requesting use of limited business funds for a program against a stated set of succinct business benefits that will be realized by the business if the investment is made.
“The key is to not shelve the business case straight after the program initiation decision has been made, but to measure and track the business benefits via a business benefits realization management practice,” Phillips says.
“The practitioners — business change managers, rather than project or program managers — should declare and monitor any risk to the original set of business benefits that warranted the original investment from the business.”
When programs cease producing benefits, or when the risk profile is such that benefits are highly unlikely to materialize, the original sponsoring group should make the call to either repair or terminate.
“A benefits profile will define how each benefit will be measured and what the starting point for this measurement activity is. These should be done as part of the business case development and used as the basis for monitoring during the lifecycle of the program.
“Program benefit reviews should be conducted regularly and cover both expected benefits and those benefits that should have been realized to date — if there are any. Some benefits do not materialize until after the change program has taken place. Knowing when to hit the off switch in these cases demands a lot more maturity of the sponsoring group.”
Phillips says while the feelings and concerns of the key suite of stakeholders and senior management within the sponsoring group count most, that shouldn’t stop the sponsoring group from being totally pragmatic about flicking the kill switch. Gut feel won’t cut it, he says.
“Facts from the original business case will materialize from the original assumptions and this is where the detail is that defines success or failure of a work effort, it is also what will determine killing or repairing,” Phillips says.
— S BUSHELL