Don’t Go Chasing Waterfalls: A Better Approach to GovTech Implementation
By Erin Jancic, Director of Operations
I oversee technology implementation for city and county governments. My work is often to shift the status quo.
Local governments often expect technology projects to follow a single path from detailing the requirements to releasing the solution, with the product being delivered only at the very end. At CityBase, we deliver software to local governments using a modern, iterative approach. We understand and embrace that a single process will not apply in all circumstances, and we amend our approach while staying true to Agile principles.
Agile processes have become the norm in technology over the last decade. We are starting to see local governments be more open to the approach, however it has arguably been a slower transition for this industry than others. Traditionally our clients are more risk averse than private companies—for good reason. When something goes wrong in government, everyone is affected.
Our job is to show our clients that while the Agile approach requires more flexibility and comfort with change, it is actually a path to more stable technology.
The Difference between Waterfall and Agile
Working on a new technology project in government can be a daunting task for city stakeholders. If you’re a government staff member, you will rightfully have a lot of questions going into a new large-scale technology project: How will my existing processes be affected? Will the new solution work as promised? When will the work be done? What does the vendor expect of my team and me?
Historically, government projects—like launching a new website or rolling out a new billing system—have primarily been done using a Waterfall methodology.
This method typically involves a long phase of documenting all requirements up front. This is followed by a development phase where the solution is built or configured, often with little to no engagement between clients and developers. Eventually there will be a phase for testing and client acceptance.
Since these later phases are the first opportunity for client stakeholders to see the software, it’s common for them to reconsider many requirements. The project can then get bogged down in change orders, with an opportunity for vendors to charge more money for the additional work. This results in inflated costs and delays to the delivery schedule.
We’ve heard too many horror stories of vendors and consultants charging into the millions of dollars for multi-year projects that ultimately fail—in part due to this process.
On the other end of the spectrum is to use an Agile approach to develop and implement technology. Agile is a strong reaction to the status quo, focusing more on outcomes over hours billed. This process also allows stakeholders to become more engaged throughout the process and help ensure things remain on track.
Using an Agile approach, there is less documentation, more phases of development and testing, small technology launches, and feedback throughout an entire engagement. We can provide more value delivering technology solutions vs. documenting what we’re going to deliver.
An Agile process is not without its hurdles. Some of the challenges to Agile development include setting the client’s expectations of how involved they will need to be during the project. It also takes a shift in culture and expectations for government staff, who are asked to readjust to an iterative process with less emphasis around when something will be totally completed. An Agile method is far from a silver bullet, but we’ve found many of its principles helpful in deploying technology.
Our Take on Agile
Over time, we have refined our process for del ivering software to one that’s based on Agile principles and is tailored for each city, and at times for projects within the city. Here are some of our approaches to technology development and project management.
Iterative Development
Iterative development means that smaller pieces of technology will be built, tested, and deployed throughout software implementation. This process encourages the software team to constantly focus on delivering value. The implementation team works with the client to focus on delivering the most important software functionality first, with additional functionality released in subsequent iterations.
This results in delivering business value throughout the project instead of waiting until the very end of an engagement to launch everything. An iterative approach is also an excellent way to manage risk during a long-term project, since issues are surfaced earlier. We can learn more quickly, and these insights from early iterations can be applied to future iterations.
Solving for Outcomes
An iterative approach can be a difficult cultural shift for government groups. In our experience, stakeholders are used to having everything delivered at once. They may get hung up on wanting full feature parity with their existing solutions or processes. In such situations, we work with stakeholders to understand why they are asking for a specific feature. We challenge them to ask themselves: What problem does this feature solve? How often does this problem happen? Is there a better way to solve this problem? This can help validate that the problem is worth solving rather than maintaining the status quo. In many instances, this has also resulted in a more effective business process, with implications beyond the tech itself.
While this can be a difficult transition for our clients, we find that after a few successful iterations, they start to embrace this approach as they realize its many benefits.
Showing vs. Telling
Government groups are used to having a lot of documentation to support technology projects. This stems from familiarity with the Waterfall approach, and it can also reflect a group’s skepticism with a new vendor. Typically, software can be built more efficiently by investing in visuals (designs, prototypes, early versions of a build, etc.) over documentation.
As we begin a project with a new client, there is often a steady request for documentation. We have found that after a few iterations, trust grows as the customer sees the value in visuals over documentation. The need for documentation decreases, and our velocity in building the technology increases.
Aligning Incentives
When we begin an implementation project, we structure our pricing and approach in a way that ensures our incentives are aligned with the city’s. This alignment can have an impact on pricing, project phases, delivery plans, and day-to-day process. If we are working on a large project with many unknowns, we will structure our process to allow for rapid prototyping and collaboration as we work with stakeholders to design the right solution. If the project has a clear scope and a hard deadline, we focus more on closely tracking execution and keeping scope stable and clear.
Our focus is on building and delivering technology that exceeds our clients’ expectations. We feel that the best way to do that is to stay true to our Agile principles, partner with clients to find the best solution, and build trust by delivering value iteration after iteration.
—
Image via Customer Think
