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. Avoiding costly disasters requ...
Larry TiemanOctober 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.

Drive Business Strategy and Growth

Drive Business Strategy and Growth

Learn how NetSuite Financial Management allows you to quickly and easily model what-if scenarios and generate reports.

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.

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

CFOs need to insist on having a finance lead assigned to the leadership team of critical projects, and they need to spend time with that analyst. If the CFO doesn’t have access to reliable data on work hours, contract spend, and software and hardware license and maintenance costs, and if he isn’t able to compare these costs to forecasts (thereby seeing the burn rate), then he doesn’t have the control he needs.

Be Prepared to Roll Both Ways
A surprising number of project failures occur during implementation. Not all risks can be identified before the build phase, even in the design-test-build model. Nearly 15 years ago, during a business consolidation, the business for which I was working wanted to replace three accounts payable (AP) systems with a new one. The business did its research and chose Oracle AP.

But the business did not recognize that there were process differences between how Oracle applied cash and the standard transportation-industry expectation. Oracle expected cash to be applied at the invoice level (think of your credit-card bill), while the industry expected cash to be applied to an item (think of the socks, shoes, and DVD player you charged at Target as items and the total Target charge as a line). Transportation customers demand the ability to withhold or make partial payment at the item level (e.g., socks), so cash had to be applied to an item. Consequently, from the Oracle AP perspective, transaction volumes were thousands of times larger than expected and it couldn’t handle them. Fortunately, the problem was identified before the old systems were retired, thereby avoiding a significant cost overrun. Nevertheless, the project could not be implemented.

The implementation of a new system almost always means changing the way people work. Regardless of the suitability of the business process embedded in the software, many projects fail during implementation because the process can’t be adopted.

The CFO’s Risk Responsibilities
Costs and complications can grow very quickly when a project gets in trouble during the implementation stage. The CFO needs to ask the IT and the business leaders to explain their risk-mitigation strategies. What happens if the new system doesn’t work correctly? Can the business fall back on the old system? Can features be turned off that might be problematic for the business or customers? Can the new system be implemented by location or function? Insisting on a plan to keep the business running should things go wrong can avoid a larger disaster.

Like everyone else who has made a career of building and installing systems, I’ve had my share of projects that did not go well, and some that failed outright. But those projects in which I had a partnership with an IT-savvy CFO never failed spectacularly. The key is structuring projects to eliminate all the known risks, and the secret to that is engaging business leadership to get as many independent views on the project as possible.

And then you have to listen to what they’re telling you.

Larry Tieman has been a senior vice president at FedEx, a CIO, and a CTO for the past 20 years. He can be reached at [email protected].