Drip Funding, Slicing, Decomposing Large Projects Into Small Projects are popular platitudes of the agile community and have been picked up by the #NoEstimates community as the response to questions about funding work, business processes, managerial finance and making decisions in the presence of uncertainty.
A domain is always needed before any suggestion for anything can be assessed to be applicable and useful beyond personal anecdotes.
Let's look at an actual program for a Health Insurance Enterprise system provider network system. The diagram below shows what capabilities neeed to be produced in what order for the system to be of any use to the business.
This by the way is a critical issue in the agile development paradigm. The customer may prioritize what Features come first. But there is a business architecture in place for any enterprise system. The order of the work is not arbitrary. Partially completed software components are of little use. Drip funding and Drip delivery may be fine for simple applications. But a System of Systems no longer has an arbitrary order of the work. It's a working system and the capabilities need to appear in the right order for any value to be produce. This order of delivery is engineered not emergent.
In the example below, the systems starts with a legacy suite of applications. The final system is an ERP style claims processing system, provider network integration, and a Data Mart for the information associated with processing claims from the provider. This type of development, integration, and evolutionary deployment is common when there is a mix of legacy and new components. Even in the new components - say green field deployment of SAP. But rarely today is there an Green Field deployment in any non-trivial environment.
The way this diagram reads is things in Boxes are system capabilities, complete with Definition of Done - not in the simple Agile DoD. But with Measures of Effectiveness, Measures of Performance, Technical Performance Measures, and Key Performance Parameters. All defined upfront. These are not requirements, they are what Done Looks Like in units of measure meaningful to the decision makers.
The connections between the boxes - moving left to right - are the sequences of the needed capabilities to have them be useful to the business. For example having a Pilot alone isn't much use. Having the Pilot and having real data for that Pilot to work on for a Demonstration of the Conversation process and Member Reconciliation is useful. This notion is how to read the chart.
By the Way this chart is just a different version of an Integrated Master Plan. This is not by accident. Several of the senior managers on this program, along with our team, work in the Space and Defense business as well, where Software Intensive System of Systems are the norm. The Integrated Master Plan / Integrated Master Schedule programmatic architecture looks like this. Where tangible business benefits are at the Event Level, the Significant Accomplishments needed to produce those benefits are next, and the Accomplishment Criteria are the exit criteria for the Work Packages (Features in Scrum) needed to produce the working software that can be put to use by the business.
The connectivity between the IMP elements (Events, Accomplishments, and Criteria) and the Work Packages in the IMS looks like this:
All This is a Set Up for the Questions In the Title
If we have the typical enterprise legacy integration with new enterprise application - the vast majority of work in IT, ...
- Can Drip Funding be used to deploy this enterprise system?
- Can the work be sliced into smaller incremental deliveries?
- Can this big project be broken down into a bunch of small projects?
Drip Funding
Drip Funding is claimed to be a way of developing software without having to estimate how much it will cost in the end. Of course this ignores the basic managerial finance principles of any enterprise effort. That principle says, someone, somewhere in the organization who is accountable for spending money has a fiduciary need to how much will be spent, when that expenditure will turn into productive use for accounting purposes of FASB 86, and what is the cash flow for expense curve look like against the bookable value to the firm.
So Drip Funding also needs Drip Benefits, in the terms of revenue if this is an external project or bookable benefits if this is an internal project. Expense and Capitalization opportunities are also needed for the integrity of the balance sheet every month. How much did we spend, how much will we spend, when will we start to see the rewards from that spend so we can start to balance the books on that expenditure?
Looking back to the Capabilities flow picture, we can certainly incrementally fund work to produce a working capability. But dolling out money in Drips may or may not get us there. How big do the Drips need to be? When do they need to arrive? There is a difference between allocated funds and committed funds. There may be budget for the work, but authorizing the spend for the work is different.
While Drip Funding is a popular term in Agile, those accountable for the firms spend - cost accounting and the CFO - need to weigh in on the balance sheet aspects of providing incremental funds with some expectation of when they will get their money back. This is standard Managerial Finance and also the basis of decision making in the paradigm of Microeconomics. If I have a fixed amount to spend, what are the choices that can be made that will produce a tangible beneficial outcome in exchange for that spend? The first number is fixed (usually), the other numbers (benefits and when) are uncertain and require estimates to be made to close the loop of the decision making process.
