The (Government) Project Paradox

Posted on March 7, 2018 in Economic Growth and Development

Governments have been on the forefront of project management innovation, as shown in this D-Day infographic from Stars and Stripes. And, yet there are many failures in the implementation of enterprise software in government.

Government project failures

Most governments demand that providers use project management best practices, consistent with the Project Management Body of Knowledge (PMBOK) from the Project Management Institute. Systems integration firms have strict project management practices. Governments often employ certified project managers.

I’d thought that we’d seen the zenith of government enterprise software and ERP failures from the US Department of Defense with 4 of 13 projects costing between 200% and 1050% of original budgets. That’s until the “Phoenix pay system” in the Government of Canada, a customized version of Oracle PeopleSoft, implemented by IBM. Macleans explains the current state in the video below:

The project management paradox

Why do project management “best practices” work in some contexts, and not others? Why are Internet giants using agile methodologies?
Traditional project management assumes that project are complicated, but predictable. The construction of a bridge, for example, can be complicated requiring technical engineering expertise. Engineers understand the strength of materials, how to build in different ground conditions, and deal with temperature changes. Project progress can be predicted based on similar projects. Of course, actual progress is very easy to see.
Enterprise software implementations are complex. Government Resource Planning (GRP) projects are transformational. Government financial, human resources, or procurement experts are needed. As are IT experts. Users need special training. (Bridge users need no new training). Most importantly, GRP projects transform and automate processes causing significant change resistance.
What we can predict from government enterprise software projects is that they are highly unpredictable. Suppliers are often 100% compliant with documented requirements from the government, as IBM has been with the Phoenix pay system. Yet, systems fail to meet the original requirements. That’s somewhat because traditional project management in government focuses on documentation as a proxy to real requirements. And, contracts, rather than user requirements, are paramount.

Paradox Patterns

Many government clients insist on following highly structured waterfall processes. FreeBalance, one of the few enterprise software manufacturers who actually implement software for clients, has uncovered many patterns that lead to risk:

• Anchoring: Software implementations are often anchored to the existing solution in place. Users want something familiar. However, existing systems are often fraught with inefficiencies and errors. Software is often customized to follow antiquated processes. Project decision-makers anchor to the “As-Is” processes. Unnecessary reports are created. Information quality often does not improve. The customizations lead to more errors. Of course, it’s all a bit odd when you consider that the purpose of getting a new system is because of deficiencies with the old.
• Documentation: Pages and pages of detailed documentation is created in traditional project management. Every stage requires documentation for sign-off by decision-makers. The more documentation, the more difficult it is for decision-makers to visualize what the eventual system will look like. For example, most methods for articulating specifications are very difficult for most people to understand. Easy for software engineers. This leads to delays. Many delays.
• Contracts: The desired outcome for systems integration firms is to deliver based on contractual obligations. Cost overruns and schedule changes are fine as long as the government will pay. Documentation, contracts, and contract amendments redefine success from original government objectives to contract compliance. That’s why systems integration firms get paid even when users are dissatisfied.
• Change Resistance: People see bridge construction in progress. Software is a different story. Many projects wait for full documentation sign-off before customization and configuration. This leads to increased change resistance. Users, government project team members, and decision-makers become disconnected from the implementation. The assumption is that the project is not going well because there is nothing to show for it.
• Team Bloat: The need for contract negotiators, documentation writers and explainers, leads to larger team sizes. This might seem like a good thing to those who haven’t read the Mythical Man Month, first published in the 1970s. Coordination and communications problems become exponential.

We’ve completed an evaluation of FreeBalance implementation projects, ERP in government projects, and good agile practices. Our methodology has been updated to A-i³+qM (accelerated, integrated, iterative, implementation-focused, quality management):

• Accelerated by eliminating as many legacy waterfall processes that lead to project problems. This includes unnecessary documentation and detailed project plans, in favour of workshops and short process steps. Team sizes are kept small to enable client communications and reduce coordination overhead.
• Integrated through a single methodology to support development and services implementation. This is integrated with customer requirements through the customer-centric processes. This provides transparency between the customer staff, the implementers, and the development team. Implementation and product development teams are integrated following DevOps practices.
• Iterative to be responsive to customer and implementation changes using phases. The methodology leverages the best of proven “lean” software development and services methodologies with workshops, short iterations, user stories, milestones and the ability to show progress. These techniques are extended beyond the development organization to implementation services leveraging productivity gains and ability to react to customer requirements.
• Implementation-focused with good practice templates and proven program management processes. This methodology is focused on the success of the customer implementation, rather than a software release that achieves internal or arbitrary goals. Implementation and product development are managed via a Program Management Office.
• Quality approach ensures that the software is released and supported meeting Commercial Off-the-Shelf (COTS) good practices with unit, system, stress and regression testing. Quality is integrated with implementation where FreeBalance tests based on customer environments.

A-i³+qM recognizes the deficiencies of traditional project management processes in GRP implementations. And, the patterns for failure.

• Anchoring: Aspirations become the anchor. Workshops are held after project inception. Government project teams are trained on the FreeBalance software to show what could be. Our people are experts in public financial management, civil service management, government budget planning, procurement etc. We know all about how public finances work, and should work. We focus on how our software can be configured to meet problems that need to be solved.
• Documentation: The FreeBalance Accountability Suite is massively configurable. This means that we can make business rule, workflow, language, and data changes rapidly without coding. It’s a massively no-code approach. Users can see whether requirements are satisfied. No need for massive amounts of documentation.
• Contracts: Contracts are important to FreeBalance. As a social enterprise, we focus on making implementations financially sustainable by governments. And, we have an incentive to deliver what is required, as fast as possible, so that we get paid as fast as possible.
• Change Resistance: Change resistance begins to melt through demonstrating progress with improving software configurations. That’s not to say that workshops and demonstrations eliminate all change resistance. The methodology has a deeper change management focus that in generic project management.
• Team Bloat: Our approach keeps team sizes optimal. We often encounter government or systems integration professional familiar with team sizes for ERP or custom developed projects. The customization footprint is so much smaller for FreeBalance projects.