Funding New Projects

In a prior blog entry I noted the traditional approach to funding new development efforts:

  1. the business gets an idea and writes a few sentences of description,
  2. IT tries to figure out what the business really meant and comes up with an estimate based on their best guess, and
  3. this amount gets locked in as a "committed" estimate to which IT is held accountable. 

The only thing that should be committed is the people who think this is a sane approach to funding projects.

A better model works like this:

  • The business identifies a set of desired business outcomes that they would like to achieve, along with the net present value of achieving those desired outcomes.
  • Based on this value, the business decides how much it is willing to spend to achieve those desired outcomes.  Usually this is based on the required rate of return of investments in the business.  This amount establishes an upper limit on the project that could deliver those outcomes.
  • The IT planning process then focuses on determining whether the desired outcomes can be achieved within the constraints established by the business planning process.  If they cannot, further funding for the project is stopped and more worthy projects are funded.  Several alternative approaches may be tried and rejected, and deciding project feasibility may require some prototyping and evaluation to determine viability.

This is how research and development funding works and, let's face it, software development has a lot in common with R&D: both deal with a lot of unknowns at the start of a project, so much so that it is usually not possible to precisely define the exact work that will be needed to achieve a particular end.  Both R&D and software are essentially exploratory: at the beginning of the effort the exact result is not known with a high degree of assurance so we have to evolve toward a solution.  The current funding model's assumptions that the solution is easily definable and therefore should be easy to estimate just doesn't work for most new software development efforts.


2 Comments
  1. Kurt Bittner | May 31, 2012 at 9:16 am Reply

    avatar

    Incremental funding of agile projects is a good idea and actually helps to improve success. It gives everyone an incentive to participate and to verify that the project is demonstrating/delivering value. It is especially useful when there are a lot of uncertainties about the business value and/or the technical approach and it helps keep everyone focused on demonstrating business value and resolving technical risk.

    The potential drawback of incremental funding is that the funding process may be painful, bureaucratic and time-consuming. The pain of having to go through the funding process may be sufficient that you don’t want to go through it more than you have to.

  2. Skip Pletcher | May 17, 2012 at 2:54 pm Reply

    avatar

    Kurt,

    Have you seen a relationship which exercised “iterative and incremental” funding?

    In other words, knowing that the destination may change in the course of the journey, can a project or program be funded for just one increment (release) at a time and still succeed? Or does the lack of financial commitment to an ultimate goal jeopardize success?

    Thanks,
    Ski;p