Agile and Business Cases

I was about to start this post with “remember the days, oh so long ago, when business cases were 60 plus pages long and written with no collaboration?”, when I realised that, although those days are far behind many of us, this sort of practice STILL exists! Big, long documents talking about things that are only valid in a single moment and quickly outdated. Signed off (sometimes still manually with a pen), then put in a drawer. Full of promise, but sketchy on actual delivery.

Why Business Cases?

It makes me sad that this bureaucratic process goes on. On the upside, it creates jobs for people, but on the downside, it wastes time. The purpose of a business case is to identify what the project is all about, and be one of the many communication tools to the project’s team and stakeholders in letting people know what they can expect. The problem is, they get used for so much more than that, and are used more as a ‘cover your a#$%’ exercise than a tool of real value. They are important, because when done well, are a great way of summarising what the project is expected to deliver. When done well, they become the contract between the project sponsor and the project manager – the project manager committing to deliver to the business case, and communicating early if there is some reason whey they cannot (changed conditions, realised risks etc). A contract is important, as it’s easy in all the excitement of a project to lose track of what is going on. A small divergence can become a huge scope change, and before you know it, the project’s reason for being is not being achieved. Without a business case, the project has no direction.

There has to be another way

So, we have established they are necessary, but there must be a better way to put business cases together. Whenever I have an organisational problem to solve, I dip into my Agile tool kit and wonder “how could Agile principles solve this problem?” One of the cool things about Agile is that it doesn’t allow you to get overwhelmed with a whole elephant to eat. It encourages us to approach a problem iteratively. Think of a business case. We don’t know everything when we first start, but we don’t really need to. We just need to have an idea that we can gradually develop out. Agile also encourages us to ‘take it to the team’. Why should if just be up to one person to not only come up with the idea but bring it to life. They say it takes a village to raise a child, I say it takes a team of motivated, inspired people to bring a project to life.

Focus on the Conversation

We humans love interaction. We are not meant to be isolated (at least not for long). The survival part of our brain knows that without others we cannot eat and be protected from predators. So let’s apply what we love to business cases and talk to each other. Share ideas. Come up with the best outcomes. For everyone. Your business case then becomes the culmination of great interaction and conversation. It is also relevant. Oh, and brief. Who has time to read a 60 page business case? No one.

My book goes into more detail on how to do this. I can’t wait for you to read it!