As I work through my thesis, interesting discoveries are made. I have the opportunity to study different methodologies for project management, not only agile, and test the theory against real life IT projects on a broad level. This provides a lot of feedback and information. So far, when talking about agile projects, there’s a lot of focus on the technical aspects of agile development. In many cases, developers live in an agile world within a rigid waterfall-like bureucratic sphere around them with requirements-first, plan-first tendencies. In order to get the full benefit from agile, the surrounding ecosystem needs to adapt to agile as well. This will not only benefit the business but the developers in unity. The first tip is get your focus set on the Business Case (BC), and keeping the BC alive through project. How many agile methodologies even talk about the business case for a project?

Project methodologies like Prince2 stress the importance of business cases to validate the project initiation. It specify expected value over cost as a net value. The value may not be economical of course, but it need to be clear that the added value clearly outweighs the cost of the project, and preferably gain more than the alternative cost of investing that money in something else. Business cases vary in detail, but as everything specified up front it carries a risk of being inaccurate. However, the drawbacks of formal methodologies is that after the business case is completed and accepted, it’s often forgotten.

An agile approach would be to work, rework and reestimate the business case throughout the project:

  1. Before an iteration starts, the priority of features should be based on the business case
  2. Decisions or clarification during an iteration should always be made with the business case in mind
  3. When an iteration is complete and has added value to the project, the business case should be reviewed for two purposes:
    1. Can we improve the existing cost or value estimations?
    2. Have we identified any new value adding features we’d like to add to the business case?
    3. Should we remove any features from the business case in the name of hindsight and experience?
  4. The living business case can serve as a validation to complete another iteration, or finalize the project and move into deployment phase. As a worst case, the business case cannot validate the project and calls for immediate termination. It’s better to realize this as early as possible rather than later.

Key Success Factors for a Living Business Case:

  1. Understand that the Business Case is a way of communicating why the project is done in the first place. Everybody involved in the project, being developers as well as stakeholders, must be able to understand the content and the underlying reason for doing the project, as well as the expected value from the project.
  2. Include a business developer on the project to keep the business case alive and help communicate the content to developers. The business developer will also easily pick up learning points from the project to include in the business case.
  3. Be sure to measure impact from iterations on the business case. Preferably, the business case should improve through iterations and hence provide an even better outcome than initially expected.