CXO

Evaluate these three factors to manage project risk

A former CFO explains how IT executives can perform a basic assessment of project risk by examining three key components: technology life-cycle, business requirements, and project management capabilities.


The goal of risk management in software development, according to the Carnegie Mellon Software Engineering Institute (SEI), is to change the culture of the IT department from “fire fighting” and “crisis management” to proactively avoiding problems. All IT groups could benefit from adopting that approach to save money and increase the chances for success of all IT projects. To make that shift, IT leaders need to incorporate risk assessment into their everyday work.

According to Peter Faletti, a CFO-turned-consultant, a good framework for anticipating risk looks at three factors:
  • Technology life-cycle
  • Business requirements
  • Project management capabilities

Faletti has come to rely on this approach based on his experience in the executive suite of three regional financial institutions, as well as his current work with Atlanta-based consultancy North Highland. In his consultant role, Faletti now advises companies embarking on major IT projects. Although Faletti has been a finance executive, he believes that the broad framework of looking at risk is equally important to IT executives—in part, because people on the business side of the project sometimes don’t participate as actively as they should in the planning process.

Risk assessment tools
TechRepublic has tools to help you identify project risks in more detail. Download our checklist to quickly assess key project risk factors, and use our Excel template to track those risks.

Technology life-cycle risk
Faletti said that the basic question IT leaders need to ask to assess a risk is, “How long will this [technology] be an effective approach to solving these problems?” His advice is to bring in technical experts who can assess the likelihood that the chosen technology will provide a solid foundation for future contingencies. Those contingencies could be as simple as needing an extra field in records, or as complicated as dealing with a merger or acquisition.

Faletti used to aim for a three- to five-year outlook on the technology life cycle, but that’s not always possible with the current pace of technology. His advice is to keep the bottom line in mind when assessing the risk.

“If it’s going to take you two or three years to put something in place, you certainly want to use it for some period of time and get your payback out of it,” he said.

When trying to quantify risk, Faletti uses two approaches. “I use the low-medium-high ranking to quickly sort the range of project risks, and then I try to be more precise about any risk that is rated high,” he said.

For application software, Gartner analysts look at several factors to evaluate the risk of using legacy systems. In a recent report ("Assessing the Age of Software Systems," February 2002), signs of high life-cycle risk include low frequency of new releases, low availability of training, and a reduction in vendors of related tools and hardware.

Business requirements risk
Faletti traces the failure of many IT projects to poorly defined requirements from the outset. But a project can veer from meeting business requirements even after the requirements have been documented.

“One of the errors I’ve seen from people on the business side is to say, ‘It’s an IT project,’ and they abdicate their role in the whole project,” Faletti said. IT leaders must fight that attitude and keep business representatives involved to reduce the risk of failure.

A recent Gartner report ("Avoiding Failure in Large IT Projects: New Risk and Project Management Imperatives," July 2002) also noted that when project teams take corrective actions without notifying stakeholders in the business units, the consequences often include higher resolution costs and even project failure.

Project management risk
In most cases, the responsibility for communicating project problems to the business unit falls on the project manager. Too often, IT leaders choose project managers who don’t have the skills and experience for the job.

“You need to be sure that the project manager is fully qualified for the size of the job,” Faletti said. He believes that IT leaders sometimes fail to consider that a person who can manage two small teams can’t easily make the leap to handling a project involving seven or eight different units. Inexperienced managers are much more likely to make critical mistakes, which can range from agreeing to unrealistic commitments to failing to address personality conflicts.

He looks for a mix of four skills. Faletti said he looks for about 30 percent project management skills, 30 percent communication and people skills, 20 percent technical knowledge, and 20 percent business knowledge.

One approach some executives may use to reduce risk for complex projects is to choose managers with different kinds of expertise to work in tandem. Bob Bianchi, an IT leader with experience dating back to his work on the Saturn rocket in the early 1960s, used that approach on a recent enterprise resource planning (ERP) project.

As the executive sponsor, he selected two experienced managers to set up and lead the project team.

“One came from the IT organization, but had a very strong customer service background. The other one was straight out of the manufacturing community,” he said.

Bianchi, who’s now with IT and engineering services provider Matcom, was pleased that the two project leaders communicated effectively with internal customers throughout the project—an important factor in reducing the business requirements risk as well.

Suggestions for IT leaders
Much of Faletti’s advice to IT leaders who want to reduce project risk centers on communication. When the project begins, the IT department must form a strong alliance with the business unit so the technical solutions align with the business requirements. Throughout the project, good communication between IT and the business units is important so that seemingly minor technical fixes don’t end up causing the project to fall short of business needs.

 

Editor's Picks

Free Newsletters, In your Inbox