Software Projects are like Wizards

During a recent heated meeting where we were discussing how we can measure whether the teams are ‘going fast enough’, I raised the question “fast enough according to whom?” Which was promptly met with, ‘according to the roadmap’. You mean, according to the arbitrary date which you, as an exec level director decided, based off the estimation in Man-Days a piece of work will take from a manager who not only won’t be delivering the work but didn’t have a well defined scope to go by? Sure, we can try to measure whether the teams are ‘going fast enough’ if you like, but I can promise you now that we will never meet that target.

This meeting then got me thinking, why do we put so much time and energy into trying to ascertain a date in which a project will be complete, when the only day you’ll know with 100% certainty when it will be delivered is the day that it is actually delivered. It’s not that the project is early or late, it’s that your expectations are wrong. I understand that it’s a hard sell to say that you don’t know when a software project will be completed, but bear with me for a minute and I’ll do my best to help you understand why you shouldn’t worry about the delivery date.

At the start of any project, and even all the way throughout it (if you’re working in an Agile environment) you will have no idea of what challenges, problems and hurdles are going to be thrown up. The team that is going to build that software is destined to encounter the problems it’s going to encounter, and if you try to predict every single one you’ll spend all the budget planning and still not even come close to an accurate delivery date. Even with the best foresight in the world, there is so many things that could slow down delivery, to name just a few:

• Sickness
• Churn
• Knowledge gaps
• Maternity/Paternity
• Natural disasters
• Outages
• Changing motivation levels
• Disruption to Flow
• Changes in priority
• Holidays
• Bereavement

And that’s just the tip of the iceberg, there is an exponentially longer list of things that could happen on the smaller day to day scale that could slow down progress.

So you’re probably thinking, but if I don’t have a delivery date then how can I work like that? And to answer that I put to you a question.

Would you prefer someone told you a completion date for a large project and then it ended up being either early or late (both as inconvenient as the other).

Or

Would you prefer to be informed at very regular intervals on how progress is coming along and have an emerging delivery date that becomes more crystallized as the project closes completion?

For a real world example that hopefully everyone can relate to, because not everyone would have dealt with large project ‘deadlines’. I recently ordered a Chinese through Just-Eat. The original estimate on the website for delivery was 60 minutes, so I set my expectations around that. Very quickly after ordering I was informed they’ve made an adjustment of adding an extra 20 minutes, so it will be 80 minutes. While a mild annoyance because I was hungry, I accepted that is the way it is and carried on with my evening planning my activities around the fact that I’ll be eating in 80 minutes time roughly. Well the 80 minute mark arrived and there has yet to be a delivery, so I gave it another 5 minutes because traffic might be bad. But after this, I resorted to ringing the restaurant to inquire where my food is, which was met with the generic response of “5 minutes away”, similar to that of every taxi you’ve ever ordered. So I waited patiently for another 5 minutes, 10 minutes… 15 minutes. We were now at 100 minutes from when I ordered and I was definitely beginning to become hangry, so I rang the restaurant again to inquire where my food is (fully expecting another generic 5 minutes response). But the phone call that ensued was so infuriating, I’ll allow you to experience it for all it’s glory:

Ring Ring… Ring Ring…

Resturant: *Insert restaurant name here* Can I take your order please?

Me: Hi there, I’m just wondering when my food is going to be delivered?

Restaurant: It’s on it’s way!

Hungup

Now what was truly infuriating about that phone call, was they didn’t even ask who it was calling to know whether it was in fact on it’s way or not! To cut a long story short, after 125 minutes I ended up cancelling my order and getting a refund because they didn’t come anywhere close to meeting my expectations. But there was one, small change, that the restaurant could have done very early on in order to secure the sale, and that was to be transparent and honest during the very first phone call.

If they had explained how it’s been far busier than usual and they were sorry but it’s going to be another 45 minutes, then I would have understood the situation and set my expectations accordingly. The time at which my food would have been delivered would have been exactly the same. My level of hunger would have been exactly the same. But my patience and willingness to accept the inconvenience would have been considerably higher because my expectations had been managed.

Expectations are a form of first-class truth: If people believe it, it’s true. — Bill Gates

This is a large part of Agile which gets overlooked I feel, a large focus on Agile is to deliver MVP’s and to get feedback as soon as possible in order to collaboratively deliver the project with the customer but the reasons for doing that are not only to validate you are in fact delivering what it is the customer wants, but also to counter the fact that you have no idea when it will actually be delivered. By having that discussion and constantly managing expectations through regular deliverables you are able to build a relationship where the customer is far more understanding of the challenges you’re facing. By involving the customer in the process you allow them the ability to feel empathy for the challenges you’re facing, and you’ll need that empathy when things do, inevitably go wrong.

Working with a mature Agile team, they will be able to give you a data driven high level estimate for a delivery date but it’s important to remember that it is exactly that, an estimate. Unless they follow the #NoEstimates movement then asking for one would be sacrilege.

So if you’re someone who regularly gets involved in any kind of software projects, the next time you’re talking about road maps or completion dates, try putting that to one side and asking to be involved at regular intervals to work with them to understand an emerging delivery date and see how that goes. You don’t have to go as far as to transition into a full Agile way of working, but just allowing the expectations to be managed honestly will be a first step in the right direction.

Do you have any experience with project completion dates that you’d like to share? Have you found a way of working different to what I’ve outlined above which you’ve had success with? I’d love to hear in the comments below.