Breaking Bad – Beating Analysis Paralysis

We’ve all been there, right? A large project or even a project that’s part of a bigger programme of works that seems to be stalled and stuck in an infinite loop because there is so much worry that something deployed may prove to be “wrong” further down the line. Meeting after meeting goes by, nips and tucks go into designs, more stakeholders are pulled into the process and the WITWIT cycle becomes a cycle you can’t seem to break.

Barack was unimpressed as the project meeting deferred yet another decision

WITWIT? Yep, it means “What if this? what if that?”. I made it up myself, as you can probably tell. There is also a further damaging introspection stage I like to call WITWOO (“What if this?”, “What Other Obstacles?”), but that is so silly and so contrived that I’m not going to mention it again. No, it’s not an April Fool’s Day post!

“WITWOO! Your project is dooooomed!”

So anyway, back to the project that is stuck in the thought process because everyone is terrified of making the wrong decision. I suppose in some ways, dealing with it depends on the deliverable of the project. If it’s something new, the TR (Terror Rating) is usually pretty high. This is because we’re dealing with a bit of a nebulous concept – we can’t see it, touch it, play with it. We don’t know what it can and can’t do, less how it can help deliver value to our organisation. We’ve seen demos and it looks cool, we signed off on that bit, but now how can this technology help the business grow?

Let’s start breaking down the problem then into more digestible chunks. I’ve spent a lot of time recently looking at things like Lean, Agile, Kanban, Scrum and Lean Coffee (look that one up, it’s interesting!). All of those things are frameworks, much like ITIL and PRINCE2. That means they aren’t prescriptive and you need to pick and choose which parts of the framework suit the needs of the project deliverable.

Agile type frameworks don’t need to represent software code as such – we’re talking about a product with features we want to consume. This could be anything – Office 365, in house software, even a drinks vending machine for heaven’s sake. We have this big “thing” in the distance, how do we get there in the best way? Keep it in your sights, but deliver smaller pieces quickly and start delivering value much quicker.

I’ve talked before about the Minimum Viable Product process and I’ve had folks rebut this argument with models such as RAT (Riskiest Assumption Test). Either way, if you start arguing about stuff like this, you’re totally missing the point. Similarly if you embrace a full Agile/Kanban method with daily standups, camp fires, burning joss sticks and rounds of “Kum Ba Yah” without having anything tangible to show for it other than “Hey! We do DevOps!”.

The DevOpsiest DevOps team in the world. Singing Kum ba yah. Possibly.

Frameworks are buffets – this means we can pick a bit of this, a bit of that and leave the rest because we have no use for it. Keep it as simple as you can to start relieving the paralysis log jam so it doesn’t make the problem bigger.

Start delivering value

To start with, using the MVP analogy, ask yourself “what is the minimum set of features this product must have on day one to start delivering value to the business?”. Going back to the earlier product deliverable itself, this could be:-

• Office 365 Product – Just SharePoint Online
• In house software – A login GUI for end users, linked to LDAP and a dashboard with one chart on it
• A drinks vending machine – Sell cans of diet cola (any brand will do)

Already we know that if we’ve done our requirements capture properly, these features are just the tip of the iceberg. That being said, by producing this MVP, we now have something our customers can consume. Users can start to add SharePoint sites or login to the new in house software and see a dashboard with a key chart on it or go to the vending machine and buy a can of diet cola.

At this point, we can then talk to our customers and find out if the MVP delivers the initial deliverable and if not, how it might be changed. For example, in the drinks machine scenario, customers like that the machine is there, but would prefer a branded diet cola rather than the own brand version from a large cash and carry warehouse.

Each time we make a change or add a feature, we go back to the customer to find out their thoughts. We also commit to delivering changes regularly, such as weekly or bi-weekly. This is a key Agile concept. We don’t wait until the whole thing is finished before we let people consume it.

Customers would like to be able to buy bottled water and ice tea from the vending machine. Great! However, in the next week, we can only commit to getting one of these drinks in. How do we know which one to add?

Any project board or design authority board will have people on it with strong opinions. In fact, you should want this. In my experience, passive “passengers” sit and say nothing and only complain once something has been delivered and it’s harder to make changes. Members will also be passionate about things that don’t matter to other board members. Brand of cola versus bottled water, for example. How do we break this cycle? This is most likely to be the main bottleneck to progress.

Defining value

We need to have a framework to defining value to the business of what the product is delivering. On the project board, for the next release, Gomez wants to stock Diet Pepsi instead of the unbranded diet cola and Morticia doesn’t drink cola but thinks bottled water is essential in any vending machine. Oh, and Gomez is the CTO and Morticia is the CEO.

“Get some water in. What do we say? Now!”

We can’t make both people happy, but we still have to keep delivering value. How can we do this? The best measure of anything is analytical, empirical and measurable. Take out instinct, opinion and gut feeling. Everyone’s is different. By assigning a numeric value to proposed features, we can be dispassionate about the design decision and also demonstrate to stakeholders that we are delivering maximum value to the business.

Firstly, we need some criteria by which to score the proposed features. We know we want to add Diet Pepsi, bottled water and pre-mixed protein shakes (I forgot to mention the CFO is a gym rat). We have three “wants”, each requester is C-Level and we have to keep delivering maximum value to the business in the shortest amount of time.

“I need your clothes, your boots and your protein shake”

Keep the criteria definitions short and simple. Between 5-8 I would say, this way you have enough criteria to give a well defined score, but you also aren’t listing 20 criteria on which you have to decide. Using this principle, we arrive at the following criteria:-

• Compatibility of product with vending machine slot
• Delivery of product in 3-5 days from supplier
• Availability of stock
• Demand for product
• Health benefits to staff

So we now have our criteria, but how do we score it? Remember, KISS! Not the glam rock band, but Keep It Simple, Stupid! One process that works well for me is a simple low, medium and high. So 25, 50 and 100. This way, the rating is easier to decide on, plus there is enough gap between the numbers to help decide ordering of the deliverable.

“Keep it simple, or we’ll tour again. Mmm-kay?”

Based on both the criteria and the scoring values, we can now rate features for the next iteration.

	Diet Pepsi	Bottled Water	Pre-Mixed Protein
Machine Compatibility	100	100	25
Item delivery lead time	100	100	25
Availability of stock	50	50	25
Product demand	50	100	25
Health benefits	50	100	100
TOTAL	350	450	200

Quickly once scoring is done, we can see a clear set of priorities defined for the next three releases but how did we arrive at these scores? Well, the following happened during discussions:-

• The protein mix is in a large bottle that doesn’t fit in a standard slot (so scores low for compatibility)
• Cola and water is in stock with the supplier but the protein mix has to be ordered from the manufacturer
• Cola and water is in stock but there are not enough bottles to fill the machine to capacity and will need to be back ordered
• An internal poll on the company intranet showed all respondents wanted to buy water, 65% also wanted to buy cola and 10% also wanted to buy protein, so we round the values accordingly
• Water and protein is healthy and nutritious, diet cola not so much (it can damage bones, apparently)

So there you have it – now we have dispassionately provided an ordered list of features, we commit to delivering bottled water, Diet Pepsi and pre-mixed protein into the vending machine during the next three releases. Customers are informed of this and are informed of the dates when they will be added (one item per week over three weeks).

What you should then find is that any arguments stop, because we have applied strict rules to our criteria and weighted them accordingly. Also, we know we want to stock all kinds of goodies in the vending machine, but that is a longer term goal. We have the machine, we want to stock it as quickly as possible and with products we know there is a clear demand for. A happy side effect of this process is we don’t waste time stocking a product nobody wants.

For example, we could add a new Marmite drink to the machine on the first day. It’s healthy, fits in a standard slot, on a special offer at the warehouse and can be with us tomorrow. It also tastes like an old sock, so nobody buys it. The value we add is that we are making the best use of time and keep waste to a minimum. Plus, the business is out of pocket because the Marmite drink is rank, nobody wants to drink it and it doesn’t sell a single item.

What Marmite tastes like.

Remember that the scoring does not reflect importance, it reflects business value and speed of delivery. You may do this for an IT project and you find DR scores lower than most other features. This is not because DR is not important, but more likely because there are other delays or constraints caused by factors such as licencing, compatibility and physical infrastructure. This means DR, while important as a deliverable, will take longer than enabling a new line of business SaaS application for example.

Bringing it all together

I know that drinks vending machines have bugger all to do with IT projects, but the concepts and the constraints remain exactly the same. You have a big thing – Office 365 (think vending machine), you have things within it that people consume – Outlook, SharePoint, Yammer (think drinks types) and you need to deliver it to end customers as quickly as you can without second guessing which features they want. Let’s say you don’t add Teams because you already use Slack (you hipster, you!). We’d know this because Teams would have a low score.

In summary, the way to break out of analysis paralysis is to a) break the project down into small, deliverable chunks and b) use weightings, metrics and empirical data to define the decision making processes on what to deliver and when. This makes the whole process so much more visible.

Remember that most decisions are reversible, don’t be afraid to get it wrong once in a while and have an open culture within all members of the project board and teams. Finally, don’t embrace frameworks like a cult – choose what works for that project and put away the guitars and joss sticks!