s09e22: But Where (Or How) Do You Start?
0.0 Context Setting
Wednesday April 28, 2021.
Frankly, I had a terrible morning. Don’t ask.
I wrote to Hamish McKenzie, the co-founder of Substack today (replying to an email chain he started in 2017 wondering if I’d be interested in trying out a new newsletter platform) to finally get this newsletter off Substack and properly onto Buttondown. And I got a reply! Progress? We’ll see, I guess.
On with the show.
1.0 Some things that caught my attention
On the back of the previous episode’s post about the UK Post Office’s Horizon IT project, another long government/technology piece today (which, to be honest, applies to pretty much most technology projects), as well as a few short things that caught my attention.
Short things first, then:
Computers that talk and gender
The Computer’s Voice - From Star Trek to Siri is a book by Liz W. Faber.
Caught my attention because: deconstructing the voices of computers that talk through the lens of gender is totally my jam and honestly seems like good reading for anyone involved in anything that even remotely touches voice user interfaces.
The hidden mythology of Okami
The Hidden Mythology of Ōkami: Part by Katherine Byrne from 200 is a brilliant first post about the frankly stunningly art-directed 2006 game Okami. Caught my attention because: the debate about art and videogames was over years if not decades ago and here’s as good a reminder as any. Also, people who do interactive, non-games work should pay more attention to games because there’s so much to learn from and be inspired by.
The Palm Foleo
This 2007 article from Nielsen Norman Group (so, honestly, two blasts from the past) about the Palm Foleo (“Palm Foleo: A Failed mobile Device”). Caught my attention because: of all my writing about what the iPad might be good at, might not be good at, and what it might deliberately not be good at, through the lens of a mobile computing device launched 3 years earlier.
Maslow Got It Wrong
Maslow Got It Wrong by Teju Ravilochan is (was) at first a piece on where some of the ideas behind Maslow’s Hierarchy of Needs came from. The piece has a good author’s note that acknowledges the need for revisions and follow-ups. Caught my attention because: Maslow’s hierarchy is trotted out often enough that anything wrong about it is worth knowing, anything about its origins or related material is worth knowing, and honestly I’m as guilty of this as well – making sure you understand what it actually means, instead of just the general gist.
Data streamed across mirrored shades
Andrew Ferguson found the novelization of Hackers, the 1995 film and it is glorious. Caught my attention because: mainstream depiction of technology and what technology might become, and the anticipation of the wider public’s perception of that technology is kind of a thing I’m interested in anyway.
Bail on the condition he… …doesn’t carry any fake QR codes.
Via Ross Floate, a man in Adelaide, Australia was arrested and bailed for “[allegedly placing] fake QR codes over business COVID check-ins”. Caught my attention because: Okay for one, can you get more cyberpunk-ish, and second: the whole risk of using QR codes and what feels like security through obscurity which relies on people not… printing out and putting other QR codes on top… as well as the quite frankly amazing bail condition of “not carrying fake QR codes”(!)
2.0 Where Do You Start?
I had a conversation last week with someone at a pretty big government department about this problem I’d call Where Do You Start.
The problem looks a bit like this:
-
You have a government department and it’s busy humming along.
-
You’d like to do something new. It’s not big — not like replacing your entire system. It’s not completely small, either, because you would like what you’re doing to become big.
-
What you want to do also doesn’t have anything to do with a crisis, or meeting a past-due requirement. You are in the most enviable position of a green field. Obviously you need to show results and be quick about it, but nothing is exploding (too much).
-
What you’re describing, or what you’re suggesting you want is actually a combination of policy/program/delivery/organizational change. Let’s just bite the bullet and call it Digital Transformation.
-
You know you want to do things differently. You might want to do things differently because you:
-
know that you’re organized around silos that don’t make sense anymore, or you recognize that you are organized around silos that would make the outcome you would like to see difficult to achieve;
-
only have experience with a certain model of technology procurement, design and delivery (i.e. traditional government technology procurement: up-front requirements analysis, control agency approval, solicitation, waterfall design and development, emphasis on project management);
-
are intrigued or have heard about new approaches like digital services, user-centered design or human-centered design. You might have heard about “agile” (and you might also be nervous about it, because you might have heard/seen/experienced some agile failures); and
-
suspect that a conventional solicitation/procurement might go to the incumbents (“the usual suspects”), or would only be accessible to incumbents and, basically, want such a different approach that you are not confident incumbent vendors are able to provide it.
-
-
You have a team around you who are good at what they do. But what they do isn’t what you want. This doesn’t mean that the team can’t be good at what you want, just that they’ve never done it before. Nobody is good at things they have ever done before. You would like more assurance than “trying our best at something new”. This is, after all, public money that you’re spending.
-
Given the above, you’re stuck. Do you need to procure something? You might feel like you need help writing the solicitation. You might feel like you’re not even sure what should be in the solicitation, or what shouldn’t be. Or how to communicate it. Or if there are different types of solicitation available. Or even later on, once there are responses, how they can be evaluated. Does this mean you need to procure help with the solicitation? Is that even allowed? How would you know if that help was any good?
You have a big question: given all of the above, where do you start? What do you do next? You’re at the very earliest stages — you have an idea of an outcome or a change you’d like to make, but it feels like the current environment is going to push you down a certain route, or that it’s the lowest-energy route, the one of least resistance. Which is fine — that’s the way things are — but how do you go about the actual next steps? What are they?
So: let’s pretend we’re having a conversation and I’m answering these questions for you.
1. What’s the Actual Problem
Let’s make sure you’re clear on the problem you want to solve or the outcome you want to achieve. For our example, let’s assume this is an internally-driven problem. It’s not an external requirement, like Federal or State rules now say we must implement x, or report y.
You might be thinking: “We do process X and there has to be a better way of doing this. I want to find a better way to do process X”.
Wanting to find a better way to do process X is a problem, but to borrow a phrase, it’s not the right problem.
But, I never find abstract examples like this helpful.
So let’s make it real.
Imagine you’re in charge of restaurant hygiene inspections, and the way you’re set up is that in addition to investigating urgent reports and regular inspections required by legislation, every 2 years you also generate a list of restaurants to proactively inspect. 2 years seems a long time to you. So the way you’re currently thinking about your problem is:
“As part of our food safety job, we come up with a list of restaurants to inspect for hygiene every 2 years and there has to be a better way of doing this”
I like asking “so that…?” when people have statements like this. It helps anchor your problem to an outcome.
Anchoring a problem to an outcome opens up how we might achieve that outcome. Approaching something like a process problem means you’re already thinking about a certain process-type solution, as if you’re pre-ordaining (“There must be better software, or better technology, for doing this thing”).
So ideally, the problem now becomes reframed as:
“There has to be a better way of inspecting restaurants for food hygiene than using a list we come up with every 2 years so that fewer people are struck ill when eating in restaurants”
This immediately brings up some new questions that it would be good to have answers to:
- How many people are currently struck ill when eating in restaurants?
- How would we know if fewer people were struck ill when eating in restaurants?
- When people are struck ill from eating in a restaurant, do we know when the restaurant was last inspected?
- When we inspect restaurants, do the incidences of food illness decrease?
Some of these questions are going to be annoying. Some of them may be, in practicality, out of scope of what you’re doing or want to do right now because they open a can of worms that you don’t want to deal with yet because they’re existential to your organization (e.g. “are our restaurant inspections actually effective at preventing food-borne illness?”)
So, for practicality’s sake (but tabling it as a pretty fundamental issue), let’s assume that inspections are effective.
Figuring out this actual problem (reducing the number of people who are struck ill when eating in restaurants) while feeling like it makes your initial question impossibly big, is actually helpful to defining the scope of what to do and where to do it.
But you might want to be prepared for different answers than what you assumed.
Because it may be that there are different ways to reduce the number of people who are struck ill when eating in restaurants, than improving the way you use a 2-yearly generated list of restaurants for inspection.
But let’s assume that for practical and political reasons (which are real reasons), the actual opportunity right now is to do something about this inspection process that is kicked off by the generation of this list every 2 years.
2. Nail the process to the outcome
You need to make a map that takes you from the start of something to your outcome. This map will help you understand or decide what you want to try changing in order to achieve our outcome of reducing the number of people who are struck ill when eating in restaurants.
This map is one that is practically centered around an inspection process and the generation of a list of restaurants for inspection.
But most importantly, it is a map that ends with reducing the number of people who are struck ill when eating in restaurants.
Keep this in mind, because when you get to the solicitation or procurement stage, what you want to center is the outcome of reducing the number of people who are struck ill when eating in restaurants.
Nailing the process to the outcome means doing the work so you know:
- who the different people and teams are involved in getting from one end of the map to the outcome
- the information that goes into this process
- the decisions involved, and who makes those decisions
- the actions involved, and who performs those actions
In other words, you need some sort of journey map, or some sort of conceptualization of one.
Understanding this map is important because in traditional language, it will help you define scope. A clearly defined scope helps reduce risk. This map is like (but not the same as) a business process diagram. It is different from a business process diagram because it involves people and their experiences more, which sounds trite, but isn’t in practice.
Doing this doesn’t need to take long. You just need enough of the map to know more than you did before.
Doing this will mean you have a better idea of what you should put in a solicitation.
3. Yes, but what do I do next?
To make this simple and minimal, you need at least:
- Someone internal to own this initiative because you aren’t outsourcing this: you’ve said you want a new internal capability because this is core to your business.
- Someone to manage a product or service — someone to own what it is that you might be making or changing to achieve your outcome. (This is not project management). Owning means making decisions.
- Someone to do just enough research to help you nail your process to your desired outcome, which helps to figure out scope. This means a whole bunch of research interviews not just to technology and program, but also in this case restaurant owners as well as figuring out what existing technology vendors are involved.
- Someone to run procurement to help you express what you want to buy, design how you’re going to communicate those needs, run the process through to selecting and buying what it is you need.
You may be thinking “Well, we’ve never really done that before. We’re going to have to buy figuring that out. So what do we need to buy?”
It depends. That isn’t a helpful answer, but it’s the true one. The reason why “it depends” is based on:
-
your immediate expertise environment — what sort of expertise is available to you? If your assumption is that there is zero or negligible expertise available to you, your assumption is likely wrong. (It is more likely that any expertise that is available doesn’t have an outlet, or is not required / actively pushed away by existing technology management and procurement processes);
-
your wider expertise environment — there may be teams outside your organization that have the relevant expertise; and
-
honestly, a lot more factors.
4.0 Give me short version already
OK, there’s two answers here:
-
Find existing, experienced teams in your government structure who can directly help and train people in your organization in defining, drafting and running through to award a problem-based, iteratively delivered, time-limited solicitation for achieving an outcome; or
-
Procure services or workshops (which might include organizations like 18F, from the Federal government) that will do the work involved in helping your team define, draft, publish and communicate a problem-based, iteratively delivered, time-limited solicitation for achieving an outcome.
You might be thinking: Thanks Dan, that’s not actually an answer. I want to know what, exactly needs to go into that solicitation, or if it’s, say, an IAA, what needs to go into it. (Clue: for the IAA, I expect that the organization you’d be signing the IAA with would have pretty good language).
Well, I’m just over 1,900 words in, and that’s going to wait for the next post. But as a preview, some of the key words are going to be:
- outcome definition (“statement of objectives”)
- technical discovery
- user research
- journey mapping
- user stories
- evaluation criteria
In the meantime, I highly recommend reading the comprehensive and state-of-the-art reference work, the De-Risking Guide from 18F.
OK, that’s it for today!
How are you doing?
Best,
Dan