How agile and product management can work in government - Part I
Part I: Why does government IT work this way?
Understanding the Legacy of SDLCs and FITARA.
At the end of healthy government projects, teams often hold after-action reviews or something similar where project team members get together and, inevitably, talk about what went wrong in a project and how to avoid doing it the next time. Many of us working in and around government have seen projects get renamed, rebooted, or just plain cancelled. But it is worth taking a hard look at how successful projects delivered what was really needed on time and on budget.
Many successful projects have a few things in common. And they are not what you think. They might have had strong project management, good governance, a good relationship with a contractor. But success in projects really comes down to these things.
- The project leaders really understood the problem they were trying to solve and knew how to communicate that problem effectively;
- The project team conferred with users or customers to ensure they were producing something that was intuitive and usable; and
- Agency leaders or project sponsors believed that a successful delivery would generate great improvement and provided support along the way.
Government should not be leaving these factors to chance. There are methods and structures government can put in place to ensure these factors are built into project delivery - every time.
First, let’s focus on how government systems development efforts inherited some of their current practices. In the 1990s and 2000s, agencies were busy adopting system development life cycles (SDLCs) that said the right way to develop systems was to, successively,
- gather all the requirements and document them,
- ensure plans were in place for integration, data migration, security, user training and more,
- share requirements with developers who would code them and develop working systems,
- test both the system components as they were developed and the final integrated system,
- develop the System Security Plan (SSP) and secure an Authority to Operate (ATO) and
- release the system, along with training, to users.
It was highly structured and useful for a time. Many of us experienced this waterfall system development method. IT shops all over government were structured according to this methodology (and many still are - Strategy and Planning, Development, Testing, Security, etc.). Acquisition documents organized CLINs around the steps (many still are) and checked off plans and step completions as deliverables. Executive governance committees were created to ensure all the steps were followed to reach success. Often, business project managers earned PMP certifications and ran the projects (I was one of them). But delivering working solutions before the steps were complete was forbidden. To begin development, you had to have a complete understanding of how the new system would affect everything it touched.
Sometimes, the business project manager stayed with the project through years of requirements gathering and development, and he or she got a working system in the end. But more often, the project manager would move to another job, leaving others to figure out what the requirements really were supposed to accomplish. Or the priorities would change and the project would lose its executive champion to the next shiny objective (not a typo). When these things happened, projects were not usually stopped. Instead, they slugged along to the end. If the end result delivered the requirements requested, the needs had often shifted with a growing understanding of the problem and shifting priorities, yielding a system that was outdated and sometimes unusable.
Then in 2014, Congress passed the Federal Information Technology Acquisition Reform Act or FITARA. This Act gave CIO shops across government more power to create, own and operate systems. There was, truly, a pressing need to stop the mission areas of agencies, or business organizations, from contracting for system builds. Systems developed by the business often included underlying infrastructure that was not interoperable with the existing IT infrastructure. With FITARA, agency IT organizations could justify owning all IT infrastructure buy and build decisions. They would also approve development of business systems based on interoperability with the overall environment, theoretically resulting in decreased overall IT costs. It was a brilliant idea and very much needed.
How Great Ideas Morphed Over Time
A decade later, FITARA is now often used as the excuse for IT not to involve the business organizations in IT decisions or development. When CIO shops inevitably receive more requests from agency business organizations for systems development than they can build, they often pull an IT group together to assess and prioritize the requests. They may present that assessment and recommendation to one or a few top business executives, or just make their own decisions on which projects should proceed. These decisions often pit key business functionality, such as foundational data analytics systems to advance AI capabilities, against more immediate needs such as critical case management systems or IT infrastructure projects.
- If the agency has a healthy strategic plan and IT governance ecosystem, the decisions will be more transparent with funds distributed across functions like customer support, compliance/enforcement or research.
- Without a healthy governance structure, deals get made at the highest levels, with little communication back to program managers who requested funding for the projects. If those program managers are motivated to develop some functionality despite being deprioritized, lack of governance can lead to redundant system functionality stemming from lack of awareness across the organization.
CIO shops, buoyed by FITARA, are also prone to leading system development without much business involvement. They need the business to define system requirements, but today, IT generally owns development and contractors, runs development sprints, determines key performance indicators and assesses project status and success.
Solve For The Problems
Two key problems stem from this history, and there ways to fix them.
- One issue, assuming business systems projects make it through budget and governance decisions, is that system requirements change before the system is fully deployed. This problem is one of the main reasons government is trying to shift from a waterfall development approach to an agile development approach that allows agencies to alter requirements as they are developing systems and deliver usable functionality along the way.
- The second is the dominance of IT in identifying, approving, developing, and assessing systems projects that deliver core business functionality. This is where Product Managers can be immensely helpful. Product managers can support framing problems, breaking that problem down into manageable solutions, driving development around those solutions and assessing how customers can be better served with each successive release.
In my next article, I’ll discuss HOW agencies can adopt a product mindset and an agile development approach. It provides practical ways for government executives and senior program managers (with help from contractors) to ensure that system development projects can use these practices to create successful outcomes.