How Can You Prepare for Version 2.0?

Today, we welcome back our popular guest author, Renée Elizabeth Mineart.

It has taken me a considerable amount of time to get my head around this topic. I’m not sure, even now as I place fingertips to keyboard, it is the right direction for this blog. But I think it’s an important topic to cover and is perhaps not talked about often enough. So, I ask you to please, bear with me as we broach the murky waters of … (queue dramatic music) … Project Failure. 
Many years ago, I came up with a saying that I apply to almost every aspect of the Information Technology world. I’ve since come to realise that this is an applicable saying for just about everything we do in life. For example, when I took up sailing a few years ago, I found that this saying proved to be even more apt on a yacht than it is in IT but that’s a story for another blog story. 

My super clever saying goes like this:

If it can break, it will break. If it can’t break, it is only more shocking when it does. Because everything can and ultimately will one day, break. Everything. Yes, that too. No, trust me, one day it will break.

One of the keys to success, with this rule in mind, is to be prepared for when things break and have a tried and tested plan for how to repair it or learn to get on with life without it. If you stand there, scratching your head while looking quizzically down at the broken ‘thing’ wondering what in the world could have possibly gone wrong, you’ve kind of already missed the point. It broke. It was always destined to break one day. Deal with it and move on.

Ok, that’s a very simplistic view of the issue and I don’t mean to insult your intelligence by summing it all up in a single sentence. There’s actually a whole lot of things going on in “deal with it and move on.” So, let’s unpack that a bit.

Exactly what do you do after the project has hit the fan? How do you pick up and reassemble those broken pieces and get the project moving forward again? How much do you have to understand about what went wrong before you can move forward?

What I would like to do in this series is talk about some of the challenges you can face after a project has failed. I’ve already mentioned a few of the topics I plan on covering in more detail, but here’s the formal list:

1. Looking back at what went wrong, what do we need to know?
2. Communication.
3. Providing a safe environment for failure in order to promote success.
4. Redefining success.

The reason these questions are playing so heavily on my mind is because I’ve recently been asked to reassemble and deliver a project that is laying in pieces downwind of the proverbial fan. I wasn’t very involved in version 1.0 of this project, in fact, I was technically the customer, one of the key stakeholders. I even arrived late to the game, joining the organisation not long before its planned go-live date. But now, I’m the Scrum Master. No pressure, right?!
So, let’s get started.

1. Looking back at what went wrong, what do we need to know

Life, as a software developer would be great if someone would just give you a fist full of money and all the time you needed and let you go off and develop your software. But, we don’t live in a bubble. We have to develop, test and deliver code in an often very complex and ever-changing world.

You can have the most robust and dynamic Agile methodology in place. You can be working with the best developers and Scrum Masters that have ever lived and your Beta and UAT testers can be so amazing that they are the crème de la crème of testers. Even so, your project can still fail. (Please refer back to my golden rule: If it can break, it will break. If it can’t break, it is only more shocking when it does.)

So, why did the project fail? One answer might be because of outside forces beyond your control. Financial unrest, staffing issues, time constraints, work centre planning conflicts and a worldwide pandemic are just a few of the possible causes.

Perhaps some bad decisions were made, such as poorly estimating the time required to complete a task. Maybe, someone just messed up. It happens. It’s a randomly occurring function of this whole human project thing we have going on.

I think looking back at what went wrong should always be focused on what can we learn to avoid it in the future. Sometimes, unfortunately, people mess up to the extent that it impacts on their standing with the organisation, which isn’t fun for anyone involved. Trust me. If we can stop that from happening, it’s a win. In the next section, we’ll talk more about how I’m not a fan of playing the blame game and if done right, it is possible to reduce bad decision-making and foster good decision-making. So, we’ll set the human element aside for the moment.

2. Communication

Communication will always be a critical point of failure in any endeavour involving more than one person and it is an element of a project that should always be under review. The purpose of communication is to set expectations and customer expectations often defines success or failure.

The reason Agile is packed with; planning meetings, daily stand-ups, Scrum meetings, User Acceptance Testing, review and retrospective meetings, is because the creators of the methodology understood the importance of communication to the success of a project.

What expectations did you set for your stakeholders? More importantly, did they know?

When you order a package from Amazon, you get an email confirming the order and an estimated delivery date. Then you get an email when the order is completed and out for delivery. After that, you'll receive an email the morning of the delivery saying your package will be delivered that day with a link to a webpage estimating delivery to within 3 hours. As that time approaches, the webpage changes to a map and you can actually watch the driver move from house to house, getting ever closer to your door.

Why does Amazon do this? Is it to give customers a nice warm and fuzzy feeling of knowing when their package is going to arrive? I think not. I think an Amazon manager read a report about how many failed deliveries they had and realised that better communication with their customers could fix that. I would love to see the stats of how many failed deliveries they had before and after the current notification process went live. Amazon uses this system to set and manage our expectations of their service and does so rather successfully in my experience.

In my next blog, we’ll explore the topic of communication a bit further and look for other obstacles that might sink your project and how to improve them for version 2.0.