The IFMIS Project Failed – is it Time to Blame the Victim? class=

The IFMIS Project Failed – is it Time to Blame the Victim?

It’s no secret: large IT projects often fail to meet customer expectations. One study in 2003 demonstrated that only 34% of large IT projects were successful, while another on Enterprise Resource Planning (ERP) projects revealed an average variance of 182% of estimated cost and 230% of scheduled time.

In the best of cases, high capacity organizations use software designed specifically for their markets. This is partly to minimize the risks involved in implementing solutions that are not specialized or proven for their particular needs.

What does that say for IFMIS projects for government in Emerging Countries? For one thing, vendors are ready with a portfolio of reasons to blame the customer. Blame the victim.

In this portfolio of blame, the victim is accused of:

  • Having unreasonable expectations—it wanted too much too soon.
  • Lacking an adequate number of trained staff.
  • Not being sufficiently committed.
  • Demonstrating poor project management.
  • Frequently changing direction
  • Not effectively articulating the business process.
  • Being reluctant to manage organizational change.

There’s no doubting the gravity of these risks. But when governments provide detailed requests for proposals requiring vendors to demonstrate sufficient qualifications, and when vendors quote on fixed price contracts, how is it fair to affix responsibility on governments for all these risks?

Success is found not only in implementation, but in sustainable implementation. That is why it is incumbent upon software vendors and consulting companies to work together with governments to mitigate these risks lest they become permanent fractures.

  • Unrealistic expectations. The proposed software must be able to meet the customer’s timeframe for implementation. If the IFMIS software takes three years to implement when the requirements call for one year, it’s time to rethink the software.
  • Trained staff. In our experience, capacity building is a primary determinant of success. It’s tempting to cut back on training to reduce proposal costs, but it’s not just about the software—it’s about quality public financial management and broader IT training. Vendors should thus insist on training.
  • Not sufficiently committed. Any organizational change tests commitment. Quick, tangible successes are necessary to foster commitment.
  • Project management. The vendor must provide a specialized crew that helps and guides the government project management team—not the other way around.
  • Frequently changing minds. Governments issue proposal specifications based on conditions at the time. Governments cannot be expected to know how current problems can be overcome or solve new problems that are introduced through the use of the software. Vendors should expect changes.
  • Business process articulation. Governments acquire IFMIS to change business processes. Vendors should be experienced in government functions and should not need to ask generic business process questions. Instead, they should help facilitate the government’s adoption of good practices.
  • Reluctance to change. Very few people like change—this is a fact of life. Only committed and passionate consultants can effectively motivate change.

You might expect vendors to have learned by now how to maximize success. But unfortunately, vendors who deny their responsibility for failure rarely learn. By analyzing why we do markedly better than industry standards, we have been able to codify successful approaches, improve our processes, and devise methods to effectively mitigate such risks. We understand that the software developer needs to be intimately involved with and committed to the success of the IFMIS project. We work with our consulting partners to ensure success. We value the ability of our software to better meet the requirements of emerging economy governments.