Large IT Project Success and Failure in Government

[part 3 of a 5 part series | part 1 | part 2 ]
My previous post described the organizational change management challenges with large IT projects. Public sector organizations have more challenges, particularly with Enterprise Resource Planning (ERP) implementations. There seems to be so many IT disasters in government. These disasters befall government organizations with high IT capacity. Consider the Government of Canada with on-going projects of:

• “Phoenix” pay system, using Oracle Peoplesoft, with hundreds of thousands of incorrect pay transaction and many public servants underpaid or unpaid
• Shared Services that includes reduction in service quality, higher costs and inability to create a standard e-mail system
• Content managemement environment for “canada.ca”, using Adobe software, that is millions of dollars overbudget

There are numerous IT project failures in the US, UK and Australia. The American Government Accountability Office (GAO) “has previously reported and testified that federal IT projects too frequently incur cost overruns and schedule slippages while contributing little to mission-related outcomes.”

Special characteristics of Government IT

Governments inherit large IT project challenges. There are additional challenges:

• Yearly budgets: Although governments plan across many years, the fiscal focus is always on the yearly budget. This creates more short-term thinking of saving money within single fiscal years at the expense of long-term returns. This creates increasing technical debt in governments.
• Legacy systems: Short-term thinking often leads to lowering investments in new technology leading to more investment in “keeping the lights on” and the need for “big bang” projects to yank systems into the modern world.
• Multiple stakeholders: “Due to the complex and inter-connected nature of the government, even small projects have multiple stakeholders across different agencies.” This generates competing incentives and muddles project governance.
• Waterfall design: Nature of government procurement generates the expectation of well-planned milestones and deliverables. This ” creates all kinds of problems, beginning with the fact that often users and analysts really don’t know what a system should do until they get the chance to play with it, coders operate on specifications which may not lead to a desired result and the project can be way down the road to development before people realize it should have been done differently.”
• Focus on old processes: Change resistance in government creates situations where new systems are expected to work like legacy systems, even though these old systems have proven ineffective. “So essentially, you end up automating a dumb way of doing things without making any real operational improvements.”
• Lack of business incentives: The nature of public sector employment means that project performance often has little to do with career performance, where “political consideration may play a more salient role when making a decision to start a project or prevent early termination of unsuccessful projects.“
• Devil’s triangle on steroids: Systems integration firms win large turnkey IT projects. Manufacturers or hardware and software products used in the project are rarely part of the governance structure. This creates an environment where systems integrators have incentives to improve revenue through scope increases and manufacturers begin the view integrators as main customers. Time and material “projects will almost always be over budget and off schedule as contractors have clear incentives to bill the government as much they can.”

Organizational Change Management in Government

My previous post provided a list of large IT change management actions. According to Panorama Consulting: “We know from our own research that companies with effective change management and communications plans are 3.5 times more likely to outperform industry peers. In the public sector, this number is even higher. A change management plan includes taking the time to establish organizational readiness, conduct business process mapping, prepare workforce transition and training strategy documents, conduct change agent training, and prepare a change impact analysis.”
Additional organizational change management actions in government include:

1. Stakeholder communication: There needs to be massive and persistent outreach communications using e-mail, newsletters, events, meetings, webinars that provides insight to why the project is good for the government and for public servants. IT must include feedback loops that identifies problems and opportunities early.
2. Define success: Provide a clear definition of what success will look like and build it into the governance structure. “Make sure that there is a clear set of rules for who is in charge, what results are desired, and how decision-making is going to take place.”
3. Acknowledge change: “There will be resistance not only from the expected areas but also from unexpected and maybe even unknown areas. Be honest about this fact and address the naysayers by having a plan in place.”
4. Dedicated team members: Implementation and management team members need to be dedicated to the project. Otherwise, team members are distracted by other operational concerns, with project priorities become implicitly lower. There must also be planned transitions for staff once the project is completed to reduce concerns.
5. Eliminate perverse incentives: There should not be incentives for civil servants to accept delivery of incomplete projects, nor should civil servants feel that any sign-offs or acceptance is personally risky.
6. Quick wins: Projects should be broken into many small deliverables beginning with prototypes. The demonstration of progress and the acceptance of user feedback goes a long way to overcoming change resistance.
7. Eliminate scope creep: Provide an iterative delivery structure that provides planned functionality at milestones. Rather than add scope prior to the iteration, based on older systems, plan feature enhancements in context of the latest version.”Plan projects as a series of additional functionalities, so that people don’t feel they have to get their feature in the first release – think of it like trains leaving a station rather than one big bang.”