Lucas Cherkewski

Assurance

Hit and Miss #275

Hello!

Say a government has a policy objective. Implementing it requires sophisticated underlying infrastructure. This infrastructure is large, complex. Likely there’s a legacy system in play, one that, though at times stretched at the seams, continues to work—more or less, often with much thanks to staff heroics.

Senior actors in this government—politicians and public servants alike—know they need to get this right. They’re terrified of the alternative, of the impacts of failure, any failure, on people’s lives. At the same time, they’re not fully confident in their own ability—that is, the ability of the government and its public servants—to get it done.

Likely this is for a few reasons: the public service has (been?) shrunk, and lacks the capacity (if not the ability) to get this done; similar initiatives, in their own experience or elsewhere, have gone off the rails; there are a lot of stakeholders, internal and external alike, and they’re worried their own organizational structures and procedures will get in the way of satisfying those stakeholders. And, also, because they’re decision-makers with a lot riding on their decisions—and, let’s face it, they’re human—they want some kind of assurance that things will be okay.

So they hire some help. A consulting firm, maybe. This firm considers a range of approaches to deliver the required infrastructure, and, given the constraints noted above, recommends a procurement-centred approach, with a few characteristics:

  • Because it’s so high-stakes, the procurement will check potential suppliers against a long list of qualifications (because we need to be assured, and credentials are assuring), ensuring only the largest, most established players can bid.
  • Because it’s complex terrain, this approach pushes risk onto the vendors doing the work, often through financial caps or incentives.
  • Because the vendors are taking this risk on, interested suppliers work collaboratively—through question and answer sessions, industry days, or, these days, through “agile procurement”—with the government to define the requirements, so the vendors know what they’re on the hook for.

The end result is still a long spec of requirements, as many procurements feature, but it’s ones the government and potential vendors have now co-developed. An RFP follows (issued only to those who meet the stringent qualifications, who’ve been involved in defining the requirements), an uneasy calm settles over the government and winner(s) alike, and it’s time to start delivering.

Sometime later, things go wrong, as they’re wont to do, and the blame game begins. Public officials are called to account for the performance (or not) of the purchased system, which falls short of the policy objective they sought. They point to the vendors—if the vendors had just done their jobs properly, you see, all this would’ve been avoided. Some attention goes to the vendors, but the hard, difficult, uncomfortable job of accountability remains with the public officials—since it was their decision, in the first place, to go with this procurement approach.

The end result of this cavalcade of anger and fear? Another example of a major procurement gone wrong. Another weight on the shoulders of those tasked with these difficult decisions—perhaps prompting them to double down on the approach (more requirements, more external help, and so on). And the system still doesn’t work, at least not as it should.

Some examples of this cycle, in whole or in part (since, to be clear, it’s not always like this, though it’s common enough in its entirety):

Depending on your background, you may have read my opening parable and thought, “Ah, he’s talking IT procurement!” Makes sense—I’ve done that here before. Maybe you nodded vigorously, thinking of an example (or two, or three, or …). But, as these articles show, I’m just recounting a tale told time and again—though more recently in the news of late—of public sector procurement.

It’s interesting to be confronted with the same patterns that afflict IT procurement playing out in other fields, like transit and architecture. In some corners, at least, there’s growing acknowledgement that the project management and procurement methods designed originally to deliver static infrastructure don’t work for delivering dynamic systems like software (the infrastructure of a digital world). But what to do when those methods—or, more precisely, their current, often externally-advised, incarnations—are also failing to deliver static infrastructure?

I have a feeling some of the prescriptions from the world of IT procurement—break large contracts into smaller ones, manage more in-house (investing in the capacity to do so), restructure qualifications to enable broader market participation, and so on—are sensible approaches for all procurement—whether delivering software, transit, or architecture.

But it also seems to me a story of human fallibility and our relationship to control. Any project like this will be rife with uncertainty. There’s a response to uncertainty that pushes elsewhere: longer, clearer requirements; stricter qualifications; stronger penalties. Knowing a strong wind will come, but not knowing when or where, this response fortifies, embracing rigidity and gripping tighter to what little remains bolted down.

There’s another response to uncertainty that flows. Instead of going big and defining the plan in advance (whether independently or or in consultation), it slowly builds, moving with the uncertainty along the way, resulting in a structure that can, in the end, sit comfortably with the uncertain winds. It’s about next best steps, not detailed upfront plans.

Now, I doubt the folks working on any of these initiatives think they’re embracing rigidity. The description of a flowing response, of next best steps, likely resonates with them. But when the structure of an initiative is predicated on pushing—big, external, and so on—your path is already largely set.

We want certainty and assurance, yes. But sometimes the best we can hope for is simply confidence that those involved will take the best steps along the way. And that likely requires unclenching our shoulders—burdened though they are—and building in more flexibility, rather than rigidity. Easier said than done.

Un?relatedly, I enjoyed reading Mandy Brown’s “The parable of the bees” this morning, a brief post on metrics, economics, and people.

All the best for the week ahead!

Lucas