Agile Funding vs. Traditional Project Funding

When organizations make the decision to move from a project-based delivery framework such as waterfall, to a more product-based framework like Scrum, they often overlook or underestimate one of the larger hurdles to success: changing the funding model from traditional project-based funding to Agile funding, which is based on product teams.

The problem with project funding

In a project-driven world, this is the standard process:

1. You identify a problem and define the work required to solve the problem, often with a target date or deadline by which the problem needs to be solved. Typically, you set the date before fully understanding the work needed to solve the problem, meaning you can’t accurately estimate how long solving it will actually take.
2. Once you define the date and work, the next step is to establish a budget for the project. This requires determining how many people it will take to complete the work in the given timeframe. You tally the headcount and cost for each ‘head’ for the expected project timeline. Sometimes you think you’ll only need certain people for part of the time, so they become a fractional ‘head’, somewhat reducing the overall cost of the project. You secure these people for the duration of the project, bringing them to the work at hand.
3. Now that you have the time frame, work, and people identified, you have your budget. This budget gets approved and locked in by the powers that be before any work can begin. 
4. Then, you assemble the team, begin work and track and report the burn rate for the project until you complete it. Due to all the above, you likely need to ask for additional time or funding to complete the work, which is usually underestimated.
5. When you finally reach the end of the project, having spent many hours and dollars towards the effort, you release the solution and hope that it solves the problem you previously identified. 
6. You disassemble the team, scattering the individuals to new work as part of new teams on new projects. 
7. If your big bet fails to meet the need, you begin the cycle again to define ‘phase two’, however you may need to find a new team as the previous team members are now working on new projects. Worse, none of them may be available as they are allocated to other higher priority projects, and you need to wait in line before the next phase of your project is approved, leaving the needs unmet until this happens.

We normally attack the project cycle described above annually, predefining all the work or problems to solve for the year. Since we do this at a single point in time, it leaves no room for flexibility and changing priorities as we discover new information. We chart the course and see it through until we reach the predefined destination. New items identified need to wait until the next annual approval cycle, and they may or may not make the cut for the next course.

The benefits of product funding

When we talk about funding a product rather than a project, the model is completely different. You are no longer focusing your attention on single problems to solve or allocating people and budgets to those singular efforts. You are looking at your portfolio of products and determining where you want to invest over longer periods of time.

Those differences translate to the obvious superiority of product funding in an Agile environment:

1. You invest in the product by standing up a team or teams that have all the skill sets necessary to enhance and maintain the product over its lifecycle, regardless of the individual problems to solve or opportunities you decide to take advantage of along the way. 
2. These teams become aligned to the product, and you bring them new work in a prioritized list based on expected value. So, the work now flows to the team in a continuous stream based on newly identified problems or opportunities, fixes to previously delivered solutions, or maintenance to the platforms that support the product. 
3. You no longer have important work that might turn into valuable solutions sitting waiting for people to free up from other obligations or for budgets to be approved. 
4. You’ve set your investment—you’re paying for a set head count at a set rate on an ongoing basis—and now the team is free to work on the most important and valuable items for the product and your customers.
5. Since the teams stay together and aligned to the product, they build subject matter expertise, further enhancing their ability to contribute to solutions. They now get to be part of the product’s short- and long-term vision, helping it grow and mature.

This is far superior to traditional project funding because product development is not a one and done singular effort that we can walk away from at the end of a project, it is ongoing for the life of the product.

To reap the benefits of moving to product delivery, changing the funding model is essential.

Dive deeper into product-based Agile funding and product thinking with our white paper, “Project to Product: Building the Right Thing in the Right Way”.

Duane Kenney, Contributor