cfo.com

Print this article | Return to Article | Return to CFO.com

How CFOs Should Manage IT Project Risk

There's more to risk mitigation on large, transformative IT implementations than simply keeping an eye on the spend.
Larry Tieman, CFO.com | US
October 18, 2011

When it comes to enterprise software projects, it pays to be a pessimist. Even the best CIOs can have a critical project run away from them, damaging the business. In my experience, most major IT projects miss their time lines and cost estimates (and lack promised functionalities) - but not seriously. Some projects, however, go very wrong with cost overruns of 400% or more with little or nothing to show for it. Structuring the management of projects to detect, correct, or kill runaway projects early is essential to project risk management. CFOs should insist on certain risk-mitigation strategies to manage these potential cost and business risks.

A common refrain in runaway software projects is that the senior-most IT officer did not know things were going very wrong until it was too late. A less-common tune is that, apparently, neither did the CFO.

A CIO I worked for is an example. Tall, good-looking, great hair - if he'd been young, he would have had all the things I lacked. He also had presence and vision. He was impressive.

Unfortunately, he didn't think much about project management. He hired me to fix some products that were buggy and late. The fixes were quite easy and took only five months to complete. Any CIO with a competency in project management could have directed the same changes just as fast.

He left for a CIO position at another organization, where he launched a $65 million system to manage operations. "We're betting the company on this," he told one trade journal. They lost.

There was a key technical failure. The requirement was for SAP to perform at a speed unprecedented at the time. He failed to put in place the proper controls for such a technically risky project, and once the extent of the problem was understood, it was too late to do anything about it. His company was soon purchased by a competitor.

Design-Test-Build
Engineers do not design, build, and then test a bridge by driving trucks across to see if it falls down. Software should not be built or installed until all the technical risks are identified and solved. This is a design-test-build approach that I insist upon for large or risky projects.

When building FUSION (a complex database integration) for FedEx, there were numerous technical issues to resolve before development could confidently begin. Chief among these was whether the system could meet performance requirements. The test was conducted using real data at the proposed vendor's lab. The vendor's pre-release products failed the performance test and it took several weeks for the redesigned products to be ready for retesting. If the issues had not been discovered until development was completed, the project would have been in serious trouble. Once the performance issues were resolved, the project proceeded on plan and was both a technical and business success.

Even one of my idols, the late Max Hopper, former CIO of AMR, let a high-risk project get ahead of the headlights. The 1988 project, called CONFIRM, was to be a leading-edge travel-reservations system combining airline, hotel, and rental-car information. The consortium partners were American Airlines, Marriott, Hilton, and Budget Rent-A-Car, with Max's organization, AMR Information Systems, doing the development.

I was the director of data systems way down in Max's organization. (I think he had 15,000 people in his organization, which went far beyond IT.) Early on, I heard the plan was to use IBM's DB2 as the main database, operating at a transaction rate far in excess of anything done with DB2 before. My team was adamant that DB2 couldn't do what was being asked of it, and I communicated our concerns up through the organization.

Whether or not Max ever took note isn't important. He didn't know (or didn't listen to) concerns from many other areas about the technical feasibility of CONFIRM. And he didn't know that the project was failing and that the status reports were fraudulent. Firings, resignations, lawsuits, and countersuits ensued. American Airlines would eventually write down more than $100 million in CONFIRM assets and settle out of court with the partners for a reported $160 million. Max failed to execute basic people- , project- , and financial-management competencies, and he placed too much trust in his vendors.

Communicate, Communicate, Communicate - Independently
During my time at FedEx, every critical project was assigned to an IT vice president where failure, no matter how remote a possibility, would have serious business consequences. This vice president was responsible for the success of the IT aspects of the project and reported directly to me as the senior vice president. Each of these projects also had a program manager, a technical lead, and a financial lead. The program manager and technical lead also reported to me. The financial lead reported into the finance organization, but on a routine basis reported status independently to me. There was also an independent testing organization again reporting directly to me. The traditional project structure would have had everyone working for the vice president, including a financial analyst from the IT organization. The objective of our structure was to get as many independent perspectives as possible on how the project was proceeding.


 




CFO Publishing Corporation 2009. All rights reserved.