Thirty one days in a time of Corona

Something, anything of value

I never used to like deadlines. But I think they can be very useful.

There's this activity that I do as a warm-up on the first day of Agile training courses that I do. I split the group into teams. Then I ask people to draw a stick person (it can be a man or a woman). Then I ask them to give this person a smiley face. This is all on a big piece of flipchart paper.

Next: "Write down as many words and phrases as you can that you associate with a happy project - with a project that is going well."

Then I ask them to write down what they might notice if they interviewed to join a project that was going well. When they've done that, I ask them to write down what it feels like to work on a project that's happy, that's going well. As a way of getting into this, I ask them to imagine how they might feel if they worked on this project and they'd taken a long weekend away from it. When they wake up on a Tuesday morning, after a Bank Holiday, how do they feel?

Finally, I ask them to give the stick person that they've created a name.

And then, I ask them to do the same exercise all over again for an unhappy project, for a project that isn't going well.

It's very interesting what does and doesn't come out of this exercise.

"On time" and "to budget" get written down almost immediately for the happy project. And almost as often "Late and over-budget" for the unhappy project.

Relaxation and stress get talked about a lot. Often change is associated with an "unhappy" project - "Random shit that comes out of nowhere." Is the best that I've heard that expressed.

Sometimes. Very rarely. Other that mentioning budget, people will talk about money. They will say that a happy project will make money, or they will say that an unhappy project will lose money. Even more rarely, someone might mention satisfied customers. Never, ever in the history of this exercise have I seen anyway say anything about value.

It strikes me now that nobody has ever said that when they imagine that they wake up in a morning ready to work on a happy project they would feel valued. But that would be kind of cool wouldn't it?

So you have your project. And your project has been probably sold on one word, possibly a short phrase.

New.

Digital.

Different.

None of these things are inherently valuable in themselves. They are a kind of shorthand for valuable.

But somehow, if you're going to deliver this project successfully you're going to have to deliver something of value. Somehow, underneath that umbrella, you have to find something that is valuable.

Valuable to whom?

Good question.

Valuable to users, yes, definitely, ultimately, and if you can start there, that's fine.

But also valuable to customers, to the people who are paying for it.

OK, let me spoil the plot. How do you "Deliver the impossible?" You can't. It's impossible. The clue is in the meaning of the words. But what you can do is deliver something valuable. For a project to succeed what you deliver has to be valuable to users. This might be money, users might want to pay to use your system.

It might be attention, users want to use your system so much that they're prepared to watch adverts to use it. But it might be all sorts of other value that you're giving to users.

I've worked on government projects a lot. Governments provide lots of complicated services. The value could be all kinds of things. Knowing that you've paid your taxes, reporting a crime, pleading guilty to a crime. It's a complex world. There are lot of things that people want.

In order to deliver a successful project you need to connect together what the customers (the people who are paying you) want and what the uses (the people who are - in some way - paying the customers want). What do you connect them together with? A service. That service has software in it, it might also have people, organisation, passion, love, pain and heartache. rules and regulations, conflict, conflict resolution, but it has some software.

Here's another tricky bit. When you're delivering a project you need to try to connect something that the customers want ( the people who are paying you) to something the users (the people who are paying the customer) wants to form a service as soon as you can.

Here's what's tricky about that: the customers won't want that. They'll tell you that they don't want a bit of a service, they want the whole thing.

Here's why they say that: because starting to really think about how you might connect what the customers want to what the users wants takes the shine of the big shiny words.

In order to deliver the impossible, you have to both listen very carefully to what the customers want while simultaneously ignoring it.

In the interests of the project, and so, ultimately in the interests of the customer, and the users and so, ultimately in your interests as well, you want as soon as you can to build a "mini service" that connects what the users and the customers want. Customers will instinctively avoid this because it involves thinking and it involves attacking g the shiny idea.

But this is why deadlines are useful. If on the other side of a deadline you can had a mini-service, a small working thing that connects the interests of the customer with the interests of the users. Then you have managed something alchemical. You have moved the gaze of your customer from a shiny, big, abstract thing on to a thing that actually works. And if you're even more lucky, this connection with your customer's users has created "pull." Now your customers users want to see more of this service.