Wrestling the Hobgoblin

"A foolish consistency is the hobgoblin of little minds"- Ralph Waldo Emerson "When I promise something to a customer, I deliver" - Elizabeth Holmes (former chairman and CEO of Theranos Inc., now awaiting trial on multiple charges of federal fraud).

"Do what you say you're going to do." This is like a spell calling up one of the most powerful forces that can be used on human beings: commitment and consistency.

In general life, honest, sane, people do what they say they are going to do. They keep their promises. We want to be seen as sane and honest, so where we can, we try to keep our promises. The kind of people who don't keep their promises are seen as bad people: dishonest, even crazy.

But the crucial thing about that last paragraph was its first three words - "In general life." A project isn't about general life. A project is about doing something new.

I always think of commitment and consistency as the electric cattle prod of project management. It's used by various people within a project to deliver a nasty jolt to those who they think aren't doing what they should be doing.

Because it's so powerful, and such a good way making people do things that they don't want to do, you often see it combined with what I call "Commitment and consistency jujitsu." A weird and convoluted twisting of logic where commitment to one thing is somehow also taken as a commitment to another thing. Something like "You promised A, and hidden in A is B and B implies C - well, in my mind it does, anyway, so in fact you promised C."

One really important part of being able to deliver the impossible, is being able to avoid the force of this kind of commitment and consistency manipulation.

How is that possible? One way is to understand that the principle of commitment and consistency is an "heuristic". That's Greek word for "rule of thumb." In most cases, as a rule of thumb, it's generally best to do what you say you're going to do. Amongst other things, it saves time and energy thinking about what you should do.

But software development projects aren't most cases. Software development projects are instances of low agreement and low certainty.

Another way is to understand that "just doing what you say you're going to do," doesn't work in software development. Why? Because discovering what the "what" is in that sentence, is a big and important part of the project.

No matter how detailed the specification to start with, the specification isn't working software. Turning words on a page into real software that people can interact with and will deliver value for them and value to the orgisation is not a straight-forward process.

Finally, it's important to undertstand that anyone who is trying to use commitment and consistency to get you to do something is messing with you.

It's hard. But one thing that makes it easier is to commit to other things.

Commit to transparency. Be open about the problems that you encounter.

Commit to doing the work of exploring the value landscape. Talk to the people who want the software and talk to the people who are going to use the software.

Commit to delivering working software early. Deliver something that starts to realise value.