A Commonplace

What is a commonplace?




Who are the dramatis personae in this book?


I, me, mine. I'm the one writing this book. I'm trying to write a book about managing software development, which instantly becomes a book about managing software delivery, which instantly becomes a book about product delivery.

I've been in the software industry for 26 years. I've been doing project management and delivery for 10 years. In those ten years things have happened to me. In those ten years I've had experience of delivering software, of delivering projects, of things that are valuable to people being but in their hands. But in those years I've also had experience of projects that have cost millions, hundreds of millions and have gone nowhere and delivered nothing. Crazy emergency meetings, "War rooms", impossible deadlines, accusations, recriminations.

This book, no doubt, is about me. It's about what I think, it's about what I feel, it's about what I want to tell you. It's about what I did, it's about what happened to me.


But this is book is also about you. It's about your story, it's about your journey. Somehow you've ended up on the hook for delivering a software project. You can feel the hook can't you? You can feel it between your shoulder blades, in the knot of muscles that the Ayurvedic masseur that I once visited called "the responsibility muscles."

I'm not going to pretend that this book isn't here to help me tell my story and explore my thinking. But it only really works if it's some use to you.

And that puts "I" - me, in a bit of a quandry. Because I know what you want. You want to be told that it's gonna be OK, just follow these simple steps, follow this methodology and everything will be fine. You will be fine. In all honesty, I can't tell you that. All I can really promise you is that if you read this book, you will have a much better way of seeing what project management is, what software development is. That's what I'm trying to give you. A way of seeing.

The computer pioneer Alan Kaye said that "point of view is worth 80 IQ points." That's what I'm trying to do for you. I'm trying to make you smarter, so your chances of success are increased, also, maybe so if you're involved in a project that's a failure, you can either make your excuses and leave, or not blame yourself too much as the express train ploughs into the buffers.

This is book is for you. I want you to better at software development, I want you to be better and project management, I want you to be better at product delivery. Why? Because you really need to know. Because...


When I talk in this book about 'it', I'm talking about software development and project management, of course. But I'm also talking about the wild, crazy, philosophically puzzling business of taking an idea and turning it into a reality. But of course, when I'm talking about doing this with software, I'm talking about a thing that we're making that isn't there. You can't kick it, you can't weight it, you can't smell it. But it dominates your world.

Where is the software? Really? Is it the code? Is it the UI? Is it the way that it changes our behaviour and comes to dominate every aspect of our lives. The people who have the best command of software development have literally come to rule our lives.

How do we take ideas and turn them into "reality"? Why is it so hard to talk about this without descending into platitudes or nonsense? Why, every time you look it this and you don't fall into the trap of yelling a slogan at it, do you start to see that it's paradoxical, contradictory, elusive, chimerical.

This is book is about 'it' the weird, weird, business of turning ideas into reality, especially when that reality is delivered as such an unreal thing as software.


You know that thing that I just talked about? It? Project management? The whole business of turning ideas into a reality that involves software and then changes reality. We all need to get better at it.

As a species.

Why? Because if we don't, we'll be utterly dominated by those who do. If we don't get good at delivering software projects, we will be dominated by people who are good at delivering software projects, and those people aren't necessarily good people.


You all. English doesn't make it clear from the one word "you", whether I'm being intimate or exclamatory.

Part of what this book does shout a bit.

This book tries to explain to anyone who will listen that taking the idea for a project and turning it into a reality is a messy, unnerving and unpleasant business. It tries to explain that this can't really be done without exposing yourselves to risks. It tries to make you all understand that what appears to be the safe (ha!) course of action, will necessarily end in disaster.

It tries to do this without scaring you off.


This book is also about "they". This book is absolutely about "they". What do "they" want? The people who want the software. Them.

This book is about the people who paying for the software. What do they want? Can we give it to them? It is possibly? Is it afforable and deliverable in any realistic timeframe.

It's also about the person or people that were given the money to deliver the project. The product owner? The product manager? The product owner's manager or boss? This book is about this other person who has a hook in their back, feeling the responsibilty. What do they want. Think how they feel.

But. If this book is about anything it's about connecting this set of "they"s - the people who pay to deliver the software and the people they pay - with another set of "they"s - the people who use it, the people who might use it.

This is about connecting and delivering what they want. All of them.