, , , ,

Failing Technology Projects? Consider Going Agile

Our requirements don’t always represent what we want — at home and on the job.

Many of us – or our family members – have had experience working with home contractors. And sometimes, things don’t always go smoothly.

Maybe the paint color is a little off. Or the bathroom sink is placed just a little too high. Or maybe that open kitchen concept is going to cost a lot more than anticipated.

These problems usually arise because we’ve described what we wanted to someone else, and then we disappear, popping up again just in time to be disappointed with the final result.

But even as we struggle with this problem at home, our difficulties at work are much more pronounced. This is especially true when it comes to collaboration between business groups and IT departments. Business groups toss requirements ‘over the fence’ to IT, which then builds a solution based on those early specifications, and nearly everyone is unhappy with the final result.

This is where agile software development comes in. You may have heard of agile in the context of project management, IT, or both. But the missing explanatory piece is its relevance to the organization as a whole.

But first, the basics.

The Old Way: Waterfall and Unhappy Customers

The idea behind agile development is to avoid the traditional problems associated with technical solution development projects in large organizations. In the old model, business groups define a technological need – maybe a fishing licensing system or a new citizen-facing crime-reporting tool. They then identify all of their known requirements and ship them over to an IT department. The IT team then starts to build out a technology solution based on the pre-defined specifications. After some work, the technology solution is delivered. The industry term for this method is called ‘waterfall,’ since each step is done to completion before it moves on to the next phase.

This system works very well in theory. In practice, however, business groups do not always know all of their requirements beforehand. Or some of the requirements are ‘lost in translation.’ Most commonly, by the time IT has delivered the solution, the original requirements are outdated or have changed. Government work isn’t static, and in today’s technology-driven world, situations can radically change overnight.

Ultimately, this leaves business groups and IT in the unhappy position of having spent precious time and money developing a software solution that doesn’t meet the needs of the organization. Moreover, the organization has also built a system that is hard to change since it requires the two groups to go through the same waterfall process all over again.

The solution, then, is to figure out a software delivery method that is dynamic and nimble enough to keep up with the changing nature of government service. Agile has the potential to be that solution.

Agile: Talking Projects One Sprint at a Time

The essence of agile is that business and IT groups work more closely together, delivering solutions in smaller bites, to ensure they are working on the right path. The smaller bites, called sprints, are designed to show results and deliver value early through pilots or a proof of concept.

Agile also focuses less on a predetermined plan and is instead more responsive and open to change, since the focus is on collaboratively creating a working solution, rather than shipping something over from one department to the other and hoping that nothing changes.

Of course, a common fear is that, without a rigid set of requirements and a similarly rigid plan, an agile-driven project could go on forever.

In fact, the opposite is true. Since agile is iterative and collaborative, it actually works out the kinks earlier on the development cycle, leading to a solution that can actually be used once it is completed (often in just 2-4 weeks, which is the average time spent on the first ‘sprint’). It also allows project requirements to adjust and realign with the given timeframe and budget. Therefore, if one key element proves to be more time-consuming or costly during development than anticipated, you have the option of focusing primarily on that solution if it essential – cutting out less important pieces. Or you can just leave the problem piece out if it isn’t that vital. Without having flexibility baked into the process, you may find yourself going beyond your budget, timeframe, or worst of all, delivering a solution that doesn’t accomplish your goals.

All of this underscores the outcomes approach to agile development, which is the ideal complement to the concept of digital government discussed in earlier posts. When combined with software that unites customer engagement with simplified business processes and an ability to respond rapidly to on-going change, you are in a prime position to achieve a level of agility needed to achieve true organizational transformation.

It may be time to start managing our technology solutions the same way we’d manage our dream homes – by taking a hands-on, collaborative approach.

To learn more about agile software development, make sure to reserve a copy of our latest guide: The Future of Digital Public Service.

You’ll also learn about the following case studies:

  • The state of Maine’s innovative [digital] recycling plan
  • The U.S. Department of Education’s case-centric approach to customer service

Reserve yours today!

Pega is the best platform for modernizing government case-centric applications. We enable government agencies to uniquely address one of their most critical challenges, – the need to respond predictably and timely to continuous change. With Pega, agencies improve their ability to respond to change by 5X by automating the documentation, automating the programming, and automating the work. Government organizations around the globe are powering transformation at every level using Pega.

Leave a Comment


Leave a Reply

James Goodman

The issues with government IT projects are captured in the links below:
TIME Magazine Code Red: HealthCare.gob
You can take out Heathcare.gov and substitute “your project” and have a good idea what is happening.

Also see the Senate report on the Air Force ERP – ECSS:

You will see the problems aren’t waterfall versus agile, but more basic management and cultural issues.

Also, for a large project you need a hybrid approach to project management. This has worked in Aerospace for over 60 years. Try telling Congress to wait for a Scrum to set a budget for your project. Don’t trap yourself in a box. Try opening your project management tool box and selecting what will work in your culture and specific project.

Glen B. Alleman

The Waterfall acquisition process is DOD was replaced with Spiral in 1985, then Evolutionary in 2002. This may still be used outside of NASA, DOE, and DOD but not for lack of guidance and policy. Google “agile dod” for proper guidance on how to apply agile.

Agile alone is not sufficient for program success. Capabilities Based Planning, Programmatic and Technical Risk Management, assessment of increasing maturity of deliverable in units of measure meaningful to the decision makers.

Agile is necessary from for from sufficient for increasing the probability of program success.

The ACA site has many prob lems not addressable by Agile, not the least of which they don’t know what done looks like and have a non-functional program management structure. Agile is a powerful tool for writing software, getting that software in the hands of the decision makers early and often. But agile is of little value on a poorly manager program, with dramatic changes in requirements and capabilities late in the development cycle.

As well the ACA site and associated exchanges are wickedly complex on the regulatory and interface side. Agile interacts far down the development cycle for those intractable data structures.

Add to that funding, external politics, and other impacts and agile will not be able to deal with any of those.

Google “RAND root cause analysis” and “IDA root cause analysis” to see the sources of most program problems.

Gianpaolo Baglione

Glen’s comment: “But agile is of little value on a poorly manager program, with dramatic changes in requirements and capabilities late in the development cycle” is spot on. I’ve been in a situation where the client asked us to implement a complex set of business rules, bought off on all of the sprint demos, and then decided to scrap the whole thing at the end because it turned out their process was more exception that rules.

There were many lessons learned on that one.

Gianpaolo Baglione

Re: Tim: From this contractor’s opinion, T&M is the best vehicle type, followed by cost plus. What’s far, far more important though is that you trust your contractor, and vice versa. I’ve made fixed price task orders work, but only because our client trusted that we would have workable software at the end of our time box and we trusted them to not freak out, and to help us control end user freak-outs.