Delivering the Impossible. Who is it for?

So I'm writing a book called "Delivering the Impossible." These blog posts over the last week have been a way of breaking the writers block that I've had for the last six or seven weeks.

The irony isn't lost on me that I'm saying exactly the kinds of things that people say to excuse not releasing incremental bits of software.

"I really need to the have the whole thing for it to make sense."

"Just releasing this will be embarrassing."

But of course the truth is that actually releasing the book into the wild attacks my idea. My pristine idea of having written a book. I can see it in my head. It's a white-covered hard back it's on a plinth, it's being photographed against a white background so it appears to float. OK, that's enough of that.

So, besides me, who is the market for my book.

Delivering the impossible is mainly intended for people like me. People who have found themselves in the position of having to deliver a software development project. You might not think that that's a big market, but a lot of software gets written and so a lot of people must be in that situation. And my guess is that most of them find it difficult. Because it is. None of what I'm writing here is claiming that if you see software development in the right way, it will be easy. Rather, what I'm saying is that if you see things in the right way, it might be possible. Might be possible. That's the best I can offer you really.

So yes, this book is for people who find themselves given the job of managing a software development project.

Another group of people who, in my experience are also interested in reading about new ways of looking at project management are software developers. That's because, like project managers, they've worked on a lot of impossible projects. They've also probably slaved against ridiculous deadlines, they've probably been asked to work weekends and evenings.

To my eternal shame, I've asked developers, very occasionally, to work weekends, it was 10 years ago. I was young and naive, but I still feel bad about it.

So, yes, this book is for project managers, developers and any other members of the development team who, if they didn't understand the dynamics of how projects get funded, might think that somehow it was their fault that the project had absolutely no chance of being delivered on time.

And so, yes, this book is for the people who work on development teams. Go home on time. Don't work at the weekend. Take holidays. Work at a sustainable pace.

But finally, this book is for the people who fund and commission projects and for the people who "own" those projects, because in my experience, many of those people literally have no idea what they are doing.

OK, that might sound harsh. But it's true. But by saying that they "don't know what they're doing", I'm not saying that there ignorant, or stupid, or malign. I'm also not denying that I've used those adjectives to describe the people who have commissioned the projects I've worked on in the past. I'm just saying that they literally don't know what they're doing. They don't know what a software development project is, or how it functions.

Most people who commission software projects don't know what is involved in making a software development project successful.

But to be fair, neither do project managers, or the people who work on development teams. If they did, they wouldn't feel so bad when things went "wrong".

That's rather the point of the book, that if everybody involved in commissioning and delivering software development projects had a better idea of the kind of thing that they were doing, the whole process would be a lot quicker, a lot cheaper, a lot more effective and a lot less emotional.

Why don't people know what they're doing? Because what they're doing is at the same time one of the most ordinary and straight forward things in the world and one of the weirdest and incomprehensible.

What we're doing when we try to deliver a project is that we're taking something that's an idea and make it into a reality. What's so weird about that? We do it all the time. I'm sitting in my kitchen now, and I'm thinking about making my second cup of coffee...

...and there we are - I just made it. What was so hard?

But if someone gave me a million pounds and asked me to make a new beverage? That would be quite hard, assuming we've guessed right that we've picked up some unmentioned requirements that it should be at least drinkable and not poisonous.

I want a coffee.

Is a statement that can cost as much as eight or nine pounds (the Starbucks in Zurich airport).

I want a novel, non-toxic, competitive alternative to coffee.

Could cost more than the US space programme.

So this book is for anyone who's in the business of taking things that don't exist and making them into things that exist. It tries to show potential crazy and paradoxical aspects of taking an idea and turning it into a reality. And by doing so it tries to make everybody involved in the process feel better about what they're doing and be better at it. That's sounds good doesn't it?

Delivering the impossible, is of course a contradiction. It's actually several contradictions. The impossible can't be delivered - that's a logical contradiction. But also, paradoxically, "Delivering the impossible" sounds a lot more exciting and interesting that "Delivering the possible."

Project management is full of paradoxes and contradictions. They are slippery and elusive. It's easy to miss them. When you do see them, it's easier to avoid them rather than acknowledge them, pointing them out to others can make you see rude, difficult or just plain crazy. But every one that you let get passed you makes the project you're working on less and less likely to succeed. The paradoxes of project management, certainly if you're a project manager, need to out in the light where they can be controlled and managed. That's what this book is about.