How agile and product management can work in government - Part II

Part II: How can government truly take advantage of new technologies?

Get the basics right.

This segment is a follow-on to my last post which discussed the legacy left by FITARA and system development life cycles. As a reminder, I identified two key problems stemming from that history and some ways to fix them.

• First, system requirements often change before a 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.
• 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 support framing problems, breaking problems down into manageable solutions, driving iterative development around those solutions and assessing how customers can be better served with each successive release.

Ann Lewis, the amazing former Technology Transformation Service Director, and the fabulous Jennifer Pahlka recently published articles on the importance of product management in government IT projects and principles for product development models. They urged government to create Product Manager roles and use them appropriately, along with several other notable recommendations, which taken together, have immense potential to decrease the historic failure of government system builds. But HOW does government break free from their historical development practices?

How to Implement in Agencies? Shift the Nuts and Bolts of IT Project Delivery

Given that many agency governance boards, budget structures and acquisition processes are not set up to support agile development and a product mindset, how do agencies begin to adopt these best practices?

In my last post, I mentioned some basic success factors I have seen in every successful government IT project.

• 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.

Here are four key areas that can support these success factors and advance the product mindset and agile development that are key to great system development outcomes.

First, IT staff must see business involvement as a value add. Getting Product Managers involved from the beginning will bring tremendous clarity to the problem the system is trying to solve and bring the voice of the customer into design and development. Ideally, business Product Managers and IT partners would co-lead release planning to ensure that all developers and agile sprints are moving toward key delivery outcomes and strategic business priorities.

Second, the business has to be willing to give up resources for this work. Who makes great Product Managers? The people closest to the work. These are the folks who can envision the full capability needed, break down that capability into chunks, called epics in agile development, prioritize which of those chunks to deliver first, and translate this work for developers. IT, on the other hand, can consider technology capabilities and ground all decisions in both technology opportunities and infrastructure realities. Together, the IT lead and business Product Manager should be a cohesive team.

For Product Managers, this should be their full time job, and they should continue to report to their business units throughout the project. When the project is complete, they should return to their business organization and become an ambassador for the new system and a key resource for their colleagues. Multiple Product Managers could be needed during the development period and could come and go depending on what segment is in development and the business expertise needed (see note on complex projects below).

I’ll offer an example of how a product manager may need to guide the work. The key is to focus on delivering pieces of functionality over time. Perhaps the registration segment of a system will be released first, along with identity authentication. First, get that segment operational and in use. This may require a new database, with the ability to communicate between the new registration system and, say, the existing payment processing system for a period of time. This does not mean running parallel data in two systems. It means populating a new database with new registration data, keeping the payment data in the old systems, and communicating between the two. If historical registration data can be kept in the old system for queries, that’s much easier than conducting a data migration. Move data only if you have to. Successive segments, for instance status of a case or claims processing, will populate the new database as they are released. The team can learn as they go and, if needed, shift the next release to better meet the needs of customers, stakeholders and development teams - this ability to shift along the way is the key to iterative, agile development. Shifting requirements don’t change the core functionality that needs to be built.

Third, acquisition shops in government need to understand this new way of working and craft contracts accordingly. This may mean identifying tasks and deliverables differently. In the best scenario, the business partners, led by the Product Manager, will have broken the work down into major epics before the contract is put out for bid. This allows the tasks and deliverables in the contract to be set up for iterative development - e.g. deliverable 1 = delivery of the database, deliverable 2 = delivery of the registration capability, etc. - and allows for more firm, fixed-price contracts. It also focuses deliverables on actual functionality, rather than delivery of plans, such as the Project Management Plan, the Functional Architecture Plan or another loosely-defined Phase of the project.

If the vendor needs those plans to deliver that segment, they will develop them. If IT needs the documentation, include it in the contract as required documentation. But the government should not be contracting for Plans or Phases, they should be contracting for a registration capability and a payment capability. Ann Lewis emphasized this when she said “Product managers shift agencies from a compliance culture to a delivery culture and enable adaptive implementation across pubic-private teams.” It’s important that the contract be designed to support the delivery culture driven by the product manager

Finally, executives and senior managers must lean in to leading with a product mindset and understand their roles in supporting this new way of working. This is very different from how most agencies work today. If executives or senior managers are asking about the interoperability with existing infrastructure or whether the staging environment is up and running, they are asking the wrong questions. And if they are seeing slides that communicate milestones around plans or phases, the Project Leads are sharing the wrong information.

Executive sponsors and decision makers should be asking how long it will take to develop the next fully operational piece of functionality, how they can help remove roadblocks for that delivery, or what the team learned from customer feedback. And presenters should be presenting their status on delivering, e.g. the registration functionality or payment functionality. Executives must seek to understand the difference between a project that is focused on the wrong issues vs. the right ones. Customer ease/satisfaction and user’s task success, along with efficient agency processes, are good starting metrics to be captured before development and as segments are released, not at the end of the project. This level and type of inquiry from top leaders will help drive the right priorities and speed of delivery from the team.

One Last Note - Very Complex Projects

Many government projects are quite complex and have multiple segments in development at once. This scenario may require an overall Project Manager as well as one or more Product Managers from the mission or business areas.

Again, an example. Let’s assume you have two development teams working on both the registration and payment segments at the same time. Once those are complete, you ask those development teams to start work on, e.g. case status and claims processing. In this scenario, the best chance for success is when the business provides Product Managers that have specialty knowledge in those segments being built, as well as an overall business Project Manager and an IT lead that can tie all the capabilities together and ensure they are prioritized with the correct dependencies in mind. This may require more staff than business organizations usually provide for IT projects, but it is critical to the success of the project.

Each Product Manager should be fully responsible for delivering the functionality in their area of expertise, from planning through development and deployment, and ensuring it works for customers and users. The overall Project Manager would conduct regular release planning to ensure each product team working concurrently knows when they need to reach deadlines and can quickly remove barriers to delivery. This structure works well even in very complicated system development with five or more development teams. It takes careful sequencing, but it speeds delivery and produces usable functionality along the way.

Key Take-Aways

To summarize, there are some key practices agencies can adopt to implement these new ways of working.

1. Product Managers, working in mission areas and fully dedicated to the system build and implementation, are the key to successful system development. Even in this very lean environment, business organizations should devote enough resources to generate successful outcomes.
2. IT development projects should be organized by key segments of functionality. The business Product Manager and IT lead together should ensure usable capabilities are iteratively released as development progresses. And ongoing user feedback should be integrated into the system design.
3. IT should invite business Product Managers to co-lead development efforts to ensure strong business outcomes. IT should ensure new systems create efficiencies, reduce technical debt, and advance existing or planned infrastructure.
4. Procurement professionals should alter the way they write RFPs, PWSs, SOWs and Task Orders. Contract deliverables should be organized around the functionality to be delivered. Periods of performance and additional levels of effort can add flexibility to projects.
5. Government leaders must lead with a product mindset. This means funding incrementally based on planned releases of functionality, asking the right questions to drive delivery, and seeing the project through to completion.

I have seen many IT system development failures in my decades in government, but the most successful projects all had some version of the above practices present. In fact, the most successful had all factors present. There are many barriers that can stand in the way of good development methods - including regulations and the federal budget structure. But government has always worked within constraints. So let’s ensure we continue to study what creates successful projects and support those findings in today’s IT development efforts.

Next article: What criteria should we use to determine if we should buy commercial or build an IT system from scratch?