The six (or seven) stages of delivering the impossible

I'm probably going to mix metaphors like metaphorical thing writing this. I didn't realise that so much of this process had a fishing metaphor (I've been fishing maybe once or twice in my entire life). The almost never-used Agile methodology, Design Systems Development Methodology has four stages (which might be five) to it's product management framework. The UK's Government Digital Service has a (suspiciously similar) four-step process - Discovery, Alpha, Beta, Live. There are probably others.

These are the phases that I've experience.

1. Bidding

At some point, somehow, there's going to be a bid. As some point, there's going to be a proposal for some work to be done. And then at some point, you and your team are going to be engaged to do it.

I wish I knew what the right thing to do was here. If you're involved in the bid process and you're too honest about what can be done in the time, you won't get the job. If you're involved in the bid process and you're not honest enough you will hate yourself, you will make things difficult for you and your team and the client will have real ammunition on you when it comes to the dreaded section four (see below).

If you were not involved in the bidding process, I absolutely promise you, that some mad shit will have been promised. You might also become aware of people in your organisation that are making a career out of promising mad shit that can't possibly be delivered. It is difficult to like these people.

To be frank, if everyone is coming at this cold, if the clients don't know you and you don't know the clients, the chances of what's promised in the bid being sensible are pretty low. If there's some degree of trust between you (the delivery organisation) and the clients, that increases the chance of some sanity in the bid.

If you don't know the clients and then don't know you, it might be a sensible idea to first do some kind of mini-project with them. That would be sensible. Build trust, understand the client, they values, understand their users. But "sensible" and the "software development sales process" aren't words that are often located together.

2. Winning

Congratulations! You're on the hook. Oh my god, now what? Now you have to do a whole bunch of "Sprint Zero" stuff. Now you have to get a team in place, now you have to find a place for the team to work. Now you have to deal with a whole bunch of crap that is just embarrassing.

Now is when it turns out that you can't get your staff in their offices because they don't have security passes.

And now is when you establish an Agile way of working. Now is when you find out who really does have Agile experience and you has "yeah, yeah, yeah of course" Agile experience. This is where you have to agree with your team a way of working that is sustainable (almost no worked weekends, very few late nights) but is and the same time, sufficiently open to new, awkward, direction-changing information. What we're trying to do here is to agree ways of progressing, rather than just an agreed activity.

Gathering requirements without, checking those back with users and clients is an "agreed activity."

Designing an end-end solution, without checking back with users is an "agreed activity."

Developing against a list of requirements without testing the working software that's produced with users is an agreed activity.

As a team, you need to agree not to do these agreed activities.

3. Waiting

We're just spending money and realising that the client's idea is crazy, will cost too much and take forever. This is the phase where we start to answer lots of questions. How big is the problem? What is our speed of progress through the problem? Are there glaring, obvious flaws in the solution? When do we need to deliver, when do we really need to deliver? What's important to the clients? What's important to the client organisation? Who are the potential users? What's important to them? This is a paradoxical phase. At the same time as we're realising the enormity of the problem, and possibly identifying why it can't be solved in the way that it's being framed, we are trying to build relationships with the people who need the problem to be solved, and can actually help us solve it. We need these relationships to be strong because section four is on its way.

4. Despair / grief / renegotiation

The project as it's framed isn't deliverable for some reason. What is expected for delivery has to be de-scoped, re-directed, re-focused or modified in some way.

At the beginning of this piece, I said six or seven stages. And this is the one that I wasn't sure was a separate stage, but at the same time, this is the one that I'm pretty much certain no project can do without. It's in the nature of the things that win bids that they're big, shiny, superficially attractive and short on crucial detail.

In order for a project to be successful, you have to find something that is small, fundamentally valuable and detailed.

5. Pull

This is when a project can start to "sing". We've identified some value. Something that is valuable to your clients and valuable to your clients' users. Try to deliver that thing.

Deal with all the obstacles that you find to delivering that thing. Bitter experience shows that a lot of those obstacles are out, way out, beyond the team. Try to trigger all the trip wires by attempting to deliver something as early as you can and see who jumps out of the undergrowth and tells you that you can't.

6. Delivery - your customers are hooked

Boom! You've landed something, now you can deliver more.

7. Maintenance - the line goes slack

The client is bored now.