Late and Over Budget: Commitment and Consistency

Commitment and consistency is a big thing in project management.  It’s the reason that calling a book “Late and Over Budget” has any kind of power. Here’s the gist.  Plans are poor models of the world and, very importantly, they don’t exist. But very often, when people think about project management, they imagine that what project management is, the whole point of project management is delivering according to a plan – on-time and to-budget.  Even though plans don’t exist, plans are in great danger of becoming something.  A plan is in great danger of becoming a commitment.

On the whole people like to stick to their commitments.  Robert Cialdini’s book “Influence: The Psychology of Persuasion.” Has a whole chapter on “Commitment and Consistency.”  This chapter is hard to write because it just feels so wrong suggesting that any kind of success can come from not honouring your commitments.  In one experiment that Cialdini talks about in his book, people who made a very low-grade commitment – they agreed on the phone that charity was a good idea - were EIGHT TIMES, let’s say that again EIGHT TIMES more likely to agree to volunteer for a charity collection in a follow-up phone call than people who weren’t asked the original question.  What this experiment, and lots like it shows is that we all desperately want to honour our commitments and be consistent with our beliefs. Why are we all so desperate? Because we don’t want to be regarded as either dishonest or insane, and on the whole, that is how society regards people who don’t keep their word.

Commitment and consistency is a huge thing and even though plans are vague, poor models of the world;  even though plans are created at a point when we have the least knowledge about a project, they tend to get interpreted as commitments.  Estimates tend to get regarded as commitments, as promises.

Why? Why would so many people continue to treat plans like this despite all the evidence that plans do not get adhered to?  I think there are a couple of reasons.  Firstly, the people who are pressurising project managers to commit are themselves under pressure to commit.  The only way they can think of to relieve this pressure is to pass that commitment onto you. They too imagine that it is part of the identity of a manager of projects to deliver on-time and to-budget.

Secondly, I know this is controversial, but that doesn’t mean it isn’t true.  There is something comfortable about having your employees permanently in a situation where they are in danger of failing to honour their commitments.  It puts them on the “back foot”, it makes them more compliant and more eager to please.

The flip side of this is that many, many project managers are spendthrift with their commitments.  They are consistently “optimistic” and “positive” in their estimations of how long a project might take.  They are willing to make promises about delivery on the vaguest of specifications. Because of a desperate urge to please, to appear positive, to look like a team player. They promise the earth when they haven’t even checked if they can deliver pizza.  They promise to deliver on a project at a point when they have absolutely no idea when they can deliver or not.

What’s the answer?  The answer isn’t to duck commitment.  The answer couldn’t be to duck commitment, not only because there is little chance we could resist the urge to commit for very long but also because ducking commitment goes down very badly with senior management.  The answer is rather to commit to the right things.

COMMIT TO MEASURING AND REPORTING REAL PROGRESS

This is the most important one.  Keep explaining what is really happening.  There are a bunch of things that you have to do every day as a manager of a software development project to do this.  You have to have a daily stand-up meeting and at that meeting you need to track the real progress of work.  The best way to do that is to break the work down into stories and plan it in iterations and not allow extra work to creep into iterations, all that good Agile stuff.  If you do that, at the end of each iteration, you will have a number.  Number of stories, if they’re roughly the same size.  Number of ideal days, number of complexity points if you’re getting fancy.  It doesn’t really matter.  What you also need to have is a backlog of things that you are going to do that is numbered in the same way.  Using those two numbers you can do some fancy predictions.  You can divide your actual progress by the number of things left in your backlog and get an estimate of how many iterations it is going to take to get through your backlog.  Let’s say your project has been going for four months and it’s got through 16 stories, you’ve got 20 stories still on your backlog.  Guess what? That project is very likely going to take another 5 months.

 So, that’s why iteration planning and counting velocity are so vitally important.  This is the one thing that you really should be comfortable committing to.  Real progress. 

Things your bosses will try to do to stop you reporting real progress:

That can’t be your real progress, you must have counted incorrectly

When the bosses don’t like the progress that you tell them about they will try to get you to count things differently.  They will especially try to get you to count half-done things, they will try to get you to play fast and loose with your “definition of done”.  Don’t let them do this.  I’ve given in and done this, it’s a disaster.

You are not a professional, you are bad man, you are a pitiful fool

It’s your fault, if you don’t buck your ideas up you’re out.  This is the clincher.  What they are actually saying is “lie to me or I’ll fire you.” They probably don’t know that’s what they’re saying. They probably aren’t going to fire you. Do you know how hard it is to recruit project managers who are any good, even in the most dire of economic climates. Unless you really are in the most desperate of job markets, don’t lie.  You’ll only be in a worse place if you do.  Actually, even if you do lie to them, don’t lie to yourself.  Even if they do persuade you to count work that’s just been started as “99% finished.”  Don’t lie to yourself. Tell yourself what the real figure is.  Try to mention the real figure, even if you instantly follow it with the inflated figure that your boss has insisted on.

Yes, I know this is the real figure, but we can’t possibly show that to my bosses, what if we move these over here, multiply by PI and then take away the number we first thought of?

Let your bosses fiddle the figures (i.e. Provide a management steer) however they see fit. But always provide them with the real figures, then provide them with the “summary” figures.

I talked to every member of your team until I found someone who would tell me that things aren’t as bad as you say they are

Good, you’ve got no problem with members of your team being optimistic.  But these are the figures.

I talked to an insane person that I met outside on the street and they said that this project shouldn’t take this long [Something like this really happened to me, OK, he was an insane person in the same office, but the gist was the same]

Good, that’s nice.  These are the figures.

Can’t you ask the team to try harder?

Yes, I can (it won’t make any difference).  These are the figures.

So, this is the commitment that you have to make if you want to stay sane, and also, very importantly, if you want to do absolutely the best job possible for your bosses, for your organisation and for the team.

I commit to consistently collecting and reporting the real progress of the team to the bosses.

Maybe you’re the kind of person who’s more motivated by the fear of bad things happening rather than of good things happening.  If you are, let me try to scare you.  If you don’t know how you are progressing in the project, if you don’t know how your team are doing against the backlog, you don’t really have any business not agreeing to whatever aggressive deadline the bosses suggest.

Here is some other stuff that you CAN commit to.

Plumb into Value

 The bosses think that what’s important is that the project is on time and to budget.  It isn’t. What’s important is that the project delivers value.  For that reason whenever you can, you should push for the software that you’re working on to be delivered.  The truth is that the value of software can only be realised after it has been used by its real users.  Once that has happened and the bosses start to get feedback from real users, you will very often find the shape of the project completely changes.  The endless vague features that were on “the plan” are suddenly forgotten and enhancements to a feature that you did release suddenly become far more important.

So here’s something else that you can commit to, whilst staying healthy and sane:

I commit to work with my team to deliver valuable working software to my project’s customers and end-users as soon as we possibly can

GetDirection and feedback from the product Owner and the Stakeholders

Along the way, you need to always make sure that you get a steer on what the priority is for the backlog.  Hopefully, you should get this from someone called a “product owner.” But it’s my experience that lots of organisations don’t like the sound of this title.  The term “product owner” sounds like someone who has real power. So many organisations either avoid appointing product owners, or give the job to somebody who clearly can’t do it – somebody very junior who’s not in a position to take a decision, somebody too senior who simply hasn’t the time to consider the detail, somebody who already has four other jobs.

Another vitally important way to get an idea of what is actually valuable and what is a priority from the bosses, is to hold regular showcases at the end of every iteration.  These can be a rough ride and cause all sorts of problems.  Turns out, very often, the bosses are far too busy to look at demonstrations of working software. When they do turn up, they are apt to make totally random comments.  Also, you never get the same collection of bosses from one showcase to the next.  Still it’s worth doing because it is the best of way diving what is actually valuable in the software your team is writing.

So here’s another thing that you can commit to:

I commit to consistently getting guidance on priority from my product owner and collecting feedback from my stakeholders

Work to Speed Things Up in the Only Way that Works – By Removing Blockers

Faster! Faster! This is a legal requirement! We’ve already promised this to our customers!  You said it would be ready by now. You are not a professional. Goddamnit! Can’t you go faster?  Can’t you all try harder?

Any of this sound familiar?  There are actually very few things you can do to speed things up.  Almost all of the things that get suggested by the bosses, adding more people or “resources” to the team, co-opting a hangar full of third-party developers on the other side of the globe, trying harder, typing faster (yes, really) don’t work.  What does work though is finding out what things are slowing down the team and fixing as many of them as can be fixed.  In Agile terms, these are called “blockers.”  These should come out at the stand-up meeting that you’re running with your team every day.  Some of the more “meta” problems will only come out at the retrospectives that you should be running at the end of every iteration.  If you’re the kind of person who is good at keeping lists, you could keep a running log of blockers that come up in stand-ups and then assign actions and resolutions to them.  You could also do the same in retrospectives.  If you’re not so good at keeping lists, you can do a loose prioritisation of blockers from each stand-up by picking the top one or two that you’re going to work on each day after the stand-up and reporting the top three issues from the retrospectives at the end of every iteration to the bosses.  What you find is that, very quickly, you rip through the things that you can change and end up with a list of things that you can’t change, and maybe even your bosses can’t change without making some kind of special effort.

These things should be the first things out of your mouth whenever the bosses start complaining about the progress of the team.

So here’s your final commitment:

I commit to consistently fixing the blockers that I can fix for my team and making sure that the bosses are always aware of the blockers that I need their help to fix

Commit to the Right Things

OK, so let’s review.  Plans are fantasies. Bosses are going to try to get you and your team to sign up to these fantasies for two reasons. One: they’re under pressure from their bosses to commit to these fantasies. Two: people who are on the back foot are easier to manipulate.  People who don’t meet a plan, even if was a totally fantastic, unrealistic plan feel bad about themselves and desperate to please.  Signing up to an unrealistic plan, and guess what? - in software development, they’re all unrealistic - is an instant recipe for feeling bad and being late and over budget.

What’s the cure? Don’t sign up to an unrealistic plan unless you really have to (you probably will have to). When you do sign up to such a plan cross your fingers and toes and mentally understand the kind of dodgy manipulative bad-faith bargain that it is.  At the same time, DO commit to the principles that I’ve outlined here which will actually help you and your team do the best that you can for your bosses.

1)       Track the real progress of your team, calculate what that means for the projects progress against the backlog.  Report this to your bosses, even when they don’t want to hear.

2)       Deliver the software that you’re working on to the end users and customers as often as you can and as soon as you can.

3)       Get guidance on priority and feedback on value from product owners and stakeholders in all the right places i.e. iteration planning and showcase.

4)       Fix the blockers you can fix, report the blockers that you can’t fix to people who can fix them.