Conventional wisdom might say that the government’s labyrinthine procurement processes are fundamentally antithetical to the collaborative, iterative Agile way of thinking. But for executives like Stephen W. Warren, Executive in Charge and CIO of the VA’s Office of Information and Technology (OI&T), federal procurement regulations and processes present surmountable challenges. The secret is to fundamentally rethink what it means to deliver working solutions.

Focusing on the Wrong Things

Warren joined the VA in 2007 and has headed up the OI&T since 2013. The scheduling application in place at the time he joined dated from 2001, and according to Warren, “didn’t deliver.” It was killed in 2009. The problem “wasn’t just scheduling, but the way they did development.”

At the time, such large software implementations followed the traditional waterfall methodology: hammer out an extensive list of requirements and put it out for bid. Select a winning contractor and then expect them to deliver on the requirements within the specified timeframe and budget. However, this traditional approach almost always led to failures – each a spectacular waste of taxpayer dollars.

In fact, the success rate was so low that people threw desired features onto the initial requirements list on the unlikely chance that some of them might make their way to a working system. However, according to Warren, “60 – 80% of required features weren’t used” – even when they found their way into a functional application, which they often did not.

However, when Warren asked the project manager at what point he realized the current scheduling project was in hot water, Warren got a surprising answer. “According to the project manager,” Warren reports, “the project was never in crisis” since they were spending the entire budget every year, and thus were able to renew their funding for the next year. Their measure of success at the time was whether the project would continue to get funding, rather than whether it was able to deliver the necessary functionality.

Firm Deadlines are Key

By 2009, “there was a dramatic break in how we do work,” according to Warren. The fundamental change: introducing firm deadlines for all projects as part of an overall rollout of an Agile approach. In fact, all projects now have a firm time limit. “Six months or less or we won’t do it,” Warren says. Furthermore, the VA also had to accelerate the acquisition process itself. “If the time it takes to buy something is greater than the time it takes to deliver it, it won’t work.”

Shifting from a focus on particular deliverables to maintaining a firm deadline changes how the VA measures success. Now, success no longer depends on whether a project can renew its funding, but rather on whether it delivers on time. In fact, Warren is so adamant about this rule, “It doesn’t matter if the project manager dies,” they won’t push the dates back. Warren insists “the date is sacred to us.”

Remaining firm about delivery dates doesn’t guarantee all projects will be completed on schedule, however. In fact, about 80% of projects now come in on time – a remarkably high percentage compared to other agencies, in spite of the fact that about one out of five miss the deadline. But even with a handful of late projects, “96% of all projects deliver” on their requirements overall, a result that is remarkable generally, but simply unheard of in the context of federal government IT.

Even external forces outside the VA’s control aren’t sufficient reason to push a deadline. In fact, this past year their on-time rate was only 73% due to the government shutdown in October 2013. But they didn’t roll the dates. If they had, they would have achieved an 82% on-time completion rate instead of 73%. But “it doesn’t matter why you miss the date,” explains Warren. “Once you allow the date to float, there is no discipline” within the team from that point on.

The “Iron Triangle” Paradox

Any software project has what Warren refers to as the “iron triangle”: scope, budget, and time. The old project management adage states that if you fix any two of these constraints, the third must be allowed to vary. In the VA’s case, they are fixing the deadline, and there is also a limit on the budget. As a result, the scope of any project must be allowed to vary.

Warren endorses this tradeoff. “With Agile, we hold time and money,” he says. Instead, “we flex the scope” for each project, even though this approach goes contrary to conventional thinking. From the traditional waterfall perspective, allowing the scope of a project to vary makes no sense, as the whole point to putting a software project out to bid is to find someone who can build what you’re asking for – in other words, to deliver on the scope.

Resolving this seeming paradox is at the heart of the Agile approach that Warren has helped to institute at the VA, what he calls aiming for the “minimum viable product” – given the deadline and budget, target the minimum set of features that veterans will actually use. Once that minimum product is in production, repeat the process as many times as is necessary.

This iterative methodology which is central to what the VA calls the Project Management Accountability System (PMAS) is a “very aggressive approach,” Warren admits. In fact, their Agile way of thinking goes beyond software development to the underlying operational infrastructure that Warren’s team is also responsible for. “For Agile projects, we build infrastructure to match the capability of what we’re delivering,” Warren says. “We bring infrastructure online as needed.”

The coordination between development and operations goes even deeper. “We’re building discipline into the team with DevOps,” Warren continues, “breaking down the boundary between development and operations. We’re getting the team to understand and to gel across the boundary.” This organizational transformation at the VA OI&T also extends to its management. PMAS drives a culture of accountability among project managers, who are now accountable for meeting project goals, as well as among senior leaders, who are accountable for eliminating any obstacles to on-time delivery.

Getting Scheduling Right

Combining Agile development methodologies with firm deadlines, an iterative approach to provisioning technology infrastructure, and a results-focused, DevOps-centered organizational and cultural shift is a complicated and high risk endeavor, but the proof is in the results.

Today, the VA is currently in the process of replacing their existing scheduling system. The request for proposals (RFP) is full and open, and they expect to make the award early next year. In the meantime, they are working to fix the most serious issues with the current scheduling system following the aggressive, Agile approach Warren champions.

The VA has identified eleven critical patches to the existing system. Their team has deployed six, and five more are in testing and due to go live before the end of the year. One of the critical patches due in 2014 is a calendar view – an essential part of any modern scheduling system but a feature that has been woefully missing from the VA’s scheduling applications up to this point.

It’s important to note that VA personnel must schedule more than veterans’ appointments: they must also coordinate hospital resources and equipment. “If the patient shows up for surgery and gets anesthetized, is on the table and the proper equipment doesn’t show up – that would be a non-starter for us,” Warren explains. After all, providing the best possible care for veterans and their families is the VA’s core mission, and Warren won’t let his team forget it.

Intellyx advises companies on their digital transformation initiatives and helps vendors communicate their agility stories. As of the time of writing, none of the organizations mentioned in this article are Intellyx customers. Image credit: Adam Fagen.