In an earlier post, I described six business leadership touchpoints for IT projects, where business leadership makes the critical difference between success and failure:

  1. Create a clear unambiguous definition of the problem, need or mission.
  2. Define a shared, richly described project vision to serve at the project’s ‘true north’.
  3. Demand a delivery strategy and solution design that delivers regular business value throughout the project, not just at the end.
  4. Use constraints to generate a range of genuinely different solution options.
  5. Create a one-page business case summary, including key business case assumptions, to be reviewed monthly.
  6. Be a driver not a passenger during project delivery, evaluating value deliveries versus expectations and personally driving regular reviews.

This post covers the third of these: insist on a value-based delivery strategy. Looking at the six touchpoints listed above, you might think that #3 and #4 are in the wrong order. Shouldn't delivery strategy follow from solution options, not the other way around? Don't most projects define a solution and then work out a strategy to delivery it? Well most do but I think they are wrong to do so. Think about Ikea furniture. Their designers don't design big, solid lumps of furniture and then try to figure out how to flat-pack it. They know that their delivery strategy is to flat-pack and the furniture is designed with that strategy in mind. The delivery strategy acts as a solution constraint. The analogy holds good for IT projects. Insisting that the chosen solution must be delivered in chunks of value forces the design team to be creative and define solution options that can be delivered in chunks of value. These solutions may be very different from options that are designed to be delivered in one monolithic block. Thinking in terms of value-delivery establishes a different mindset to that of requirements or benefits delivery. First, because it precedes the definition of the solution, it encourages the project team to design solutions that optimise the combination both benefit and cost, not just one of them. Secondly, it encourages the customer and the team to prioritise the sequence of delivery based on value not the technical design of the solution. I covered the case for value-based delivery in an earlier post on lean project management but let me reprise the key benefits here:

  • Business value is seen as the project's raison d'etre
  • Usable  business value is delivered early and regularly
  • IT projects usually overrun their budget and schedule, so waiting to get all of the value at the end is not a good idea, especially if budget and time are constrained

In addition, regular value delivery enables projects to regularly evaluate:

  • the value delivered versus expectations;
  • the actual cost compared to the forecast;
  • the actual duration compared to the forecast;
  • the actual solution delivered versus what you thought you would get;
  • the quality of what was delivered.

So don't wait until a solution has been defined to think about the delivery strategy. And don't assume that it's a technical task to think about it. Business leaders need to stay involved and lead. Never be fobbed off with, "well it would be very difficult and expensive to do it that way". Make the supplier quantify "very difficult" in terms of cost and time. And don't forget to let them know that other suppliers might take a different view. Image sources: Thanks to for the original image that appears at the top of this article. The other two images in this article have been taken from the Double Loop Limited website. FURTHER INFORMATION AND RESOURCES

  • If you would like to discuss this topic further, please contact Jenrick IT on 01932 245 500.
  • Please click here to visit the Double Loop Limited website