How an Agile business case differs

This week Elise Stevens from Fix My Project Chaos and I spoke about the difference in a business case for an Agile project.

This is the overview of our discussion.

The use of the ‘Agile’ approach to project management has an impact on an organisations ability to deliver successful projects if the whole business is not fully supportive and educated in the way that this method works.  Business Owners, key stakeholders and project team members alike each need to fully understand the way in which the project will operate.  Everyone needs to understand the changed nature of their role, as well as the different way that the project will be delivered i.e. in a more fluid manner. Naturally the process starts up front with the business case and the approach to that is also different.

The traditional business case contains information about a problem or an opportunity.  In the perfect world the business would have developed business requirements, which detail exactly what there needs are.  We know that this doesn’t always happen, but we are going to treat this as something that is done more times than not.

Costing for the project is then estimated on what it will take to deliver those entire set of requirements, creating in the case of software an end to end application, delivered in its entirety.  Estimates are provided and funding requested based on a recommendation of the best option to deliver the businesses needs.

In the Agile world of project management the approach is very different.  No longer would the business deliver a full set of requirements.  The Business Owners is asked to define how much money he has to spend.  This figure is then taken alongside a base set of prioritised basic requirements from the business and this becomes iteration one.  This is what becomes the starting working point for delivery.

What this means is that the business is likely to end up with a working prototype sooner, as long as the work is managed and the estimates for delivery of the base elements is correctly estimated.   The business can then gain feedback on this working prototype and evolve the solution.  From a software perspective it means that the outcomes for the business and customers might then become very different to what might be delivered if a full end to end product was defined.

There is far more flexibility in the output.  The negative side of this approach is the financial aspects, as there is no up front estimation of what the total end product is going to cost.

The impacts on the business are two fold.  The positive impacts:

  • the business has a product out in the market faster
  • because of this the business can start to accrue benefits faster
  • risks are mitigated as they go, and whilst there may be more risk, there is also more opportunity to see the rist and deal with it faster
  • there do not need to be as many options proposed in a business case, as options are evolved as the different iterations of the project are worked through.

The negative impacts:

  • There is not clear understanding of the all up, total cost, of the outcome to meet the business needs – be that a piece of software or change of operating model, for example
  • As things are evolving, people who are risk averse will not feel comfortable in not having risks and benefits identified up front.

The key thing is for the business stakeholders to be fully educated in this new approach, and different way of working.  This will then mean that the initial business case will become an evolving document too, with each iteration called out and the total outcome scoped as it is being worked on.

Quite a different way of creating a business case, more agile!

You can listen to the podcast too if you are interested to hear our whole discussion.

Karen

Written by Karen Munro