First responders know a feeling well: being late to the scene is profoundly frustrating.

I stumbled into this feeling in my own work. I started my career helping local governments to improve their operations using math. But I kept being called about “software trouble” instead. Software trouble involves overly complex technology deployments that cost too much and deliver benefits too late, if ever. I’d be called to make sense of the mess. But I was always late to the scene. The initial budget was long gone, staff were burning out and leaving, and the elected team was asking questions.

I’ve noticed three major sociological stages of software trouble that I hope to illuminate in this series. The earliest of these stages, typically finished before anyone is paying enough attention, is the poorly controlled brainstorming of problems and potential solutions. This mistake snowballs in later stages, when procurement transactions happen and finally when leaders double down on initiatives showing distress. By adding structure to this earliest, brainstorming phase, the most trouble can be avoided for the least effort. There’s a tremendous opportunity here to deliver better results for staff and residents alike.

Unforgivable Costs

Software initiatives rival large physical infrastructure projects in their budget and timeline risk. Overruns associated with software trouble routinely run into multiples of initial cost and schedule estimates. The psychological burden of software trouble can be even deeper. Measured in resignations, early retirements, burnout, and disengagement among key staff, technology projects that go wrong can truly corrode the soul of a city or county.

A recent example comes from Birmingham City Council, the largest local authority in the United Kingdom. Birmingham officially defaulted on its bills in September 2023. While pay equity liabilities were the nominal driver of this bankruptcy, software trouble was significant enough to note as a contributing factor. Birmingham undertook an Enterprise Resource Planning migration initially budgeted to cost £19 million. By June 2023, £47 million had been spent, with total cost estimates running to £100 million.

A blunder of this scale cannot plausibly be forgiven through good deeds elsewhere in a municipal career. Framed more positively, quietly sidestepping software trouble is one of the most valuable, if unsung, things a city or county leader might ever do.

Poorly Controlled Brainstorming

In postmortem analyses I’ve done for local governments, I started to notice that the headwaters of software trouble are further upstream than typically acknowledged. I keep landing on a poorly controlled brainstorming process as a root cause.

Brainstorming happens in an early project phase that goes by several names, such as “requirements analysis” or “needs assessment.” Regardless of name, an organization must articulate what it is collectively attempting to achieve with an initiative. Brainstorming itself—a time-boxed exercise of idea generation, with a goal of maximizing the volume of ideas—is vitally important for good outcomes. It’s important to get all ideas on the table so that the most salient ones can be winnowed from the rest.

But without extra structure, idea generation and idea winnowing become enmeshed. This is simply humans being humans. In an unstructured group discussion, to throw something extra into the pot or shut someone else’s idea down is to be helpful, be seen, and express social status. 

Conversely, to keep things simple by staying quiet is to forfeit social status. Without structure, even brilliant and conscientious people create bloated, incoherent “designs by committee” whose complexity shows up later as bad, expensive, overdue technology. The sociological forces that enmesh brainstorming with winnowing appear regardless of how a workplace looks. They appear in-person and remotely; they are felt in meetings, memos, emails, and Teams chats.

If these forces are wrangled early enough in a technology initiative, the war is practically won.

Disciplined Winnowing

Poorly controlled brainstorming ultimately answers, “What solution would address all of our needs?” Well-disciplined brainstorming and winnowing instead asks, “What’s the smallest change that could be really helpful?”

I’m agnostic about branded methodologies to make organizations more productive. I believe success comes from finding great people and giving them breathing room to do their best work, while branded methodologies in the real world usually encourage micromanagement. Yet as far as I can tell, popular methodologies are unanimous on well-articulated brainstorming and winnowing:

• The Lean Startup methodology cherishes a “minimum viable product,” comprising the smallest possible unit of functionality that can be brought to market to test an idea.

• The Design Thinking methodology suggests phases of divergent thinking and convergent thinking, culminating in the rapid delivery of a prototype.

• The Lean/Six Sigma methodology offers processes not only for brainstorming, but tools such as affinity diagrams and multivoting to help focus an initiative.

Each of these methodologies offers a step of time-boxed idea generation, then a separate step of winnowing to converge on a solution that can be rapidly and inexpensively tried. They give people ample room to be seen and express status in the brainstorming phase. They then artfully minimize the social stigma of having ideas thrown out in the winnowing phase.

Finding the smallest change that could be really helpful leads to overwhelmingly cheaper, faster, and less risky solutions, building momentum and resources to tackle further improvements one by one.

Internal Champions

Especially where software initiatives have historically been bloated, expensive, and late, separating brainstorming from winnowing is difficult. Stakeholders fight the process because the “not now, but later” of good winnowing sounds like “never.” The potential costs of software trouble are so high that facilitating this process deserves your best leadership resources. That might mean crossing departmental lines to borrow a colleague with the best facilitation skills, hiring a consultant who is independent of any software solution, or even stepping into an unfamiliar room yourself.

You are likely to land on several competing good ideas and a need to choose among them. As a practical measure, I suggest favoring initiatives with a passionate internal champion at the front lines who is likely to stay with your jurisdiction for a long time.

Paradoxically, the internal champions with the knowledge and power to ensure success of an initiative are often at the very bottom of an organizational chart. In his role as a senior manager of continuous improvement and change management at King County, Washington, Steven Sawada facilitates organizational improvement, both with and without software deployments in the picture.

He emphasizes the need “to understand what’s happening with the people closest to the work.” These people, Sawada notes, “not only have a better picture of what’s broken, but they also hold the key to the human system behind whatever technology you’re going to throw at it. And if you can’t get them to see […] how the vision gets to the heart of the problem that they experience on a day to day basis, you’re not going to succeed.”

I vividly remember the internal champion in my first tangle with municipal software trouble, a code enforcement officer involved with city licensing and permitting. My interview with her had to be at an odd hour; she was an hourly worker assigned to night shifts. This code enforcement officer was awesome. She was desperate for the broken software solution to work better, as it had destroyed her own day-to-day productivity. When I met her, she’d already extensively documented the software trouble in writing to help the software implementation consultant.

However, like me, she was late to the scene. She was only consulted deep into the project, after the money was gone, the vendor locked in, and the deployment failing, hoping to dig out after all the big forces of software trouble had already asserted themselves.

I still wonder how much better this community would have fared had she been part of well-disciplined brainstorming and winnowing from the very beginning.

Potent leverage

By winnowing a project with great care in its earliest stages, before sales representatives appear, immense cost and trauma can be avoided. Software trouble compounds over the life of a project. I’ll subsequently explore the challenges when the public-service motives of government find themselves in tension with the profit motives of the software industry, both around the time of procurement and then later, once distress appears in a software deployment. A tightly winnowed statement of need with a passionate internal champion is potent leverage to navigate this tension well.

If you can, arm yourself with this leverage before vendors are even mentioned. Don’t be late to the scene.