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.