Slow and steady sometimes wins the race. There is something to be said about controlled “best practices” in institutions. The difficulty with so-called government”best practices” is that most were developed to solve problems you don’t have, in ways you can’t use. You need to find emerging good practices that solve problems you have, in ways you can use.
This notion was on display during the governance workshops at the FreeBalance International Steering Committee conference in Miami last month. There’s a growing sense that traditional project management methods have proven ineffective for large government IT implementations and PFM reform. This is particularly true when implementing Enterprise Resource Planning (ERP) systems in government. Although using Enterprise Software designed for government, like Government Resource Planning (GRP), improves success rates, more is needed.
Legacy is what Legacy Does
There’s a lot of talk about legacy technology in government. Governments incur higher IT operations and maintenance costs that businesses, on average. The problem is not so much legacy technology as legacy thinking. Many governments are migrated from obsolete technology to legacy at a time when businesses are moving to the cloud with easily adaptable and low-cost SaaS applications. Our view is that there is something fundamentally wrong with so-called IT “best practices” in government.
Starting with looking at GRP as IT, rather than as reform and modernization. It’s not IT, it’s transformation.
We explored these IT legacy practices at FISC.
Most GRP implementations focus on risk reduction through documentation, and the separation of concern.
Overly Documented Practice
The primary risk mitigation strategy in legacy thinking is documentation: document the project, document the as-is, document the to-be, document the test plan, document the project plan, document minutes of every meeting, document each step in user acceptance….
You get the point.
Providers turn into authors and editors. Documentation complexity results in focus on obsolete practices from previous systems. More code is customized. The compliance focus means that providers anchor on contracts. Projects diverge from needs.
And, the time required to document, to understand documents, to approve documents creates delays. Delays result in increasing change resistance. That’s because documents are a poor representation for progress. Governments project managers become reluctant to sign-off at milestones because complex documentation is abstract.
These practices mean that implementations are certain to fail to meet original need, or deliver on time, or cost the original budget. Many fail to meet all three.
And, project post-mortems often suggest that more documentation should have been written.
Separation of Concern
The idea has been to use so-called “best practices”. For example: separate manufacturers from integrators, separate budget, financial, procurement, human resources, taxation concerns into silos.
Separation of concerns means implementation outside the big picture, with different incentives for providers, lack of integration, without full budget coverage – many expenditure applications operate completely outside commitment accounting.
The separation approach has prevented many governments from a holistic view of matching software with expected reform, it’s created perverse incentives for consultant providers, software manufacturers, proposal consultants, and IT staff.
The lack of a holistic view and integration means that systems rarely meet long-term goals. The destiny is a cycle of replacing systems with new systems that also don’t meet the longterm need. As described in a previous post:
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.
Waterfall Legacy Government IT Projects
Waterfall techniques assume that all planning can be performed before software can be adapted. It is assumed that the final result of the software will meet expectations because of stringent design work.
Legacy thinking envisions IT and PFM reform projects as predictable. Legacy practices are imposed on contractors in order to reduce perceived risks. Our analysis of FreeBalance projects, projects by other firms, and the project management and PFM reform literature has led us to the conclusion that waterfall practices increase project risk significantly.
The design work, consisting of “As-Is” and “To-Be” analysis in Software Requirements Documents often takes up to a year to complete.
- Documentation-focus anchors implementations on how legacy systems operate, rather than government objectives
- Documentation-focus drives unnecessary code customization
- Solution-focus includes inappropriate “best practices” from different contexts, disconnecting projects from problems to be overcome
- Contract-focus makes for emphasis on functional checklists, at the expense of non-functional needs like usability, and manageable
Governments often find that traditional needs analysis fails to uncover comprehensive requirements. That’s because analysis operates in a vacuum, without a broader context of how government jobs are actually accomplished, what problems need to be solved, and what emergent practices could be leveraged for change.
Let’s face it: governments have been implementing commercial software for GRP and PFM needs for decades. Legacy practices have constrained success. This comes at a time when governments are challenged to digitally transform. To implement citizen-centric mobile systems. To augment service delivery through digital. To integrate with social networks. To implement blockchain and artificial intelligence.
Governments are facing a strategic inflection point. Dominant government IT practices restrict digital transformation success
![Government IT Project Management Tipping Point]()
The Government Agile Evolution
Governments, like large enterprises, operate many IT systems. Legitimate concerns about security, performance, quality and reliability mean that governments need strong IT governance. The shift from waterfall to agile implementation should not compromise IT governance. The Gartner Group, for example, recommends a bi-modal approach to IT: “Bimodal is the practice of managing two separate but coherent styles of work: one focused on predictability; the other on exploration. Mode 1 is optimized for areas that are more predictable and well-understood. It focuses on exploiting what is known, while renovating the legacy environment into a state that is fit for a digital world. Mode 2 is exploratory, experimenting to solve new problems and optimized for areas of uncertainty.”
Many observers believe that bi-modal doesn’t go far enough. Analyst Dion Hinchcliffe, for example, states that “the real world of technology and the activities that make it bear fruit cannot be neatly compartmentalized into a dual structure.” Success may be better found in a multi-modal approach. Or, by considering more agile processes for implementation and more rigid processes post-implementation.
Agile In the Real World
How do Internet giants develop innovative solutions? What patterns are relevant to governments? Are there emerging government-specific success patterns? These were the questions we asked after diagnosing GRP and ERP public sector implementation problems. The success patterns led to the our agile methodology update, A-i3+qMTM.
We saw that our positive implementation experiences aligned with agile techniques practiced at innovative Internet firms. It also aligned with emerging practices from country development. Success patterns coalesced around four dimensions:
- Product Integration: GRP and ERP implementation methodologies are traditionally separated from product development methodologies. And, the code for COTS software is rarely adapted by the manufacturer to meet customer needs. Orphan custom code is developed instead. FreeBalance has integrated implementation and product development for decades. Custom code augments our COTS software. This approach operates similar to DevOps, an agile software development process.
- Workshops: Context is critical to reform success. We discovered that documents and reports rarely tell the public sector reform story. You find this out by engaging people. We also discovered that public servants were not exposed to reform contexts: good and appropriate practices rather than unrealistic “best practices” or very poor legacy poor practices. User and project team engagement was needed. FreeBalance developed engagement workshops as a lean mechanism to communicate context. And, we learned from the emerging “canvas” approach like the Business Model Canvas, to create government-specific workshop structures.
- Storyboards: The FreeBalance specifications structure was revised in 2008 to reflect the approach of reusable components, that we call “government entities”. This includes articulating the entity and entity parameters. These parameters enable massive configurability. The interaction among entities is defined. That’s because entities are reused among applications. It all makes perfect sense to our product developers, yet it’s abstract for PFM experts. We developed a storyboard approach to facilitate specification development using an approach from design thinking. This has been extended in our updated agile methodology. (Demonstrated during FISC 2018 workshops.)
- Change Management: Organizational change management is particularly challenging in government. We’ve learned from the Problem-Driven Iterative Adaptation (PDIA) approach from the Harvard Kennedy School. PDIA covers far more than change management. The technique has an ideal government-focused approach to stakeholder (agent) identification, and communications approaches. We’ve also discovered that the value of change is rarely communicated effectiveness to potential change agents or future users. We came to realize that the Value Proposition Canvas is an ideal tool to use. (Demonstrated during FISC 2018 workshops.)
A-i3+qMTM leverages success patterns for a comprehensive agile methodology that also includes:
- GESCED: An adapted version of the business strategy PESTLE (Political, Economic, Social, Technology, Legal, Environmental) for the government context. (Demonstrated during FISC 2018 workshops.)
- Agile: An adapted version of Kanban and Scrum for iterative development
- Doing Development Differently: An agile approach, with a manifesto, for step-by-step government development, that includes PDIA
Agile Implementation Outcomes
A-i3+qMTM covers the entire project lifecycle beginning with our proposal to governments. We evaluate risk factors up front such as program constraints, requirement contradictions, and poor practices. This determines our risk approach and informs contract negotiation.
The key A-i3+qMTM characteristic is iterating core processes that are delivered in waterfall serially. These parallel processes begin with mandatory product training. Government project teams need to see system capabilities in action. This is used for configuration and customization workshops. Capacity is built in parallel. Configurations are signed-off when seen in action. As is custom code. Progress is visual.
A-i3+qMTM accelerates implementation by anchoring projects on gain aspirations, and on the capabilities of the new system. Configuration doesn’t need a lot of documentation, just blueprint outputs from the FreeBalance Accountability Suite. The custom development process reduces complexity for PFM experts to articulate and validate needs.
A-i3+qMTM custom development process includes:
- FreeBalance on-site services staff build storyboards and use cases interactively with customers
- FreeBalance product management staff validates this input using technology knowledge, and identifies additional how government entities can be extended for other PFM Component Map requirements
- The validated storyboards and use cases are approved by customers
- FreeBalance product management staff develop specifications
- FreeBalance product development validates the specifications before developing code
- FreeBalance on-site services staff adds to the quality assurance to ensure that the result meets country needs
- Client User Acceptance Testing validates using the code in production (or demonstrates a need to adapt specifications)
Repeatability is a core challenge for any methodology. A-i3+qMTM includes process tools for repeatability.
- Canvas: Large visible workspace, typically wall or large whiteboard in size, that can be deployed online, following a series of workshop steps for brainstorming and decision-making
Alternatively can be deployed online - Boards: Large visible workspace, typically wall or large whiteboard in size, that can be deployed online, dynamically representing on-going activities
Alternatively can be deployed online - Blueprints: Description of a FreeBalance configurations that includes business rule and workflow articulation, country-specific custom development, reports, and interfaces
Describes any country-specific custom development - Templates: Document template for creating project artifacts
Appendix: A-i3+qMTM Description
The characteristics of the A-i3+qM methodology are:
- 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.