Agile Enterprise Part 2 - Project Funding Vehicles Can Be the Enemy of Agility
What model for funding change does your organisation use? In this era of crowd funding, bitcoin and blockchain, when striving for business agility, surely there is a better change funding model than the classic project-based model that was inherited from the property sector?
In part 1 of my series on the agile enterprise I talked about the various operating model changes needed to foster agility. I think one of the most critical adjustments needed, is to move away from project-based funding, towards envelope funding for the vast majority of change. Why? Because a project-based funding model tends to sacrifice speed of delivery and innovation in favour of schedule and cost certainty. In the property sector there are good reasons for this which I outline below. By contrast, when it comes to technology and process change, agile enterprises need to focus on the customer experience, lean execution and speed to market, coupled with high levels of experimentation and learning to foster innovation.
Project-based funding is fit-for-purpose when constructing buildings
Now to be clear, I do believe a project-based funding model has its place, which is for situations where “concrete is being poured”, both literally and figuratively.
In the property sector there are very large costs associated with the construction of a house and any errors that result in rework during the construction phase, like pulling down a wall and rebuilding it, can be prohibitively expensive. Due to this reality it makes good commercial sense for the project-based approach to invest significant time and money in upfront requirements gathering, design and approval activities.
If you have a business change challenge ahead of you that will figuratively be “pouring concrete”, it will typically display most or all of these building a house-like characteristics:
there will be mandatory up-front third-party approvals that can’t be delegated or deferred,
rework costs will be very high in the construction phase if not done right the first time,
owners will require a high level of certainty about cost and schedule before construction starts,
a large proportion of the scope will need to be deployed before any benefits can be derived, and
the team to do the work will only be needed for the duration of the project and then will be released.
In this case a project funding model is probably still the right vehicle for your situation.
Most business change looks nothing like constructing a house
My key point is that the vast majority of the process and technology-enabled business change I’ve been involved in looks very different to what I’ve described above in that:
Many upfront approvals are linked to funding milestones within large corporate bureaucracies but actually the quality of these decisions can improve if made by cross-functional teams closer to the customer and/or the delivery date.
The cost of both the initial build and any rework needed is relatively modest such as customising or configuring software, tweaking sales processes, experimenting with different pricing structures, changing a rostering system, adding a feature to a website, building a new report, etc.
Business benefits aren’t certain and therefore progressive delivery is preferable: Certainty of benefits is not reality for most business change so it’s better to pilot, test learn and reserve the right to pivot, and then deploy again. Also, most organisations don’t want to bet the farm with a large amount of scope all bundled into one go-live like building a house. As much as possible, they’d prefer regular deployment of smaller changes to mitigate change risks while at the same time delivering benefits progressively.
Scope doesn’t need to be fixed: Often scope is only being fixed for the purpose of securing project funding. More value can usually be derived by fostering an environment of creativity where everyone involved is encouraged to come up with new ideas that can be added to the backlog and then prioritised based on their relative merit.
Change is a constant: Most importantly change seems to be either a constant or is accelerating. It’s certainly not going away at the end of the project. Once the current slate of priorities is delivered, we’ll need the team to get onto the rest of the ever-changing backlog of work. Maybe we’ll need to ramp the team up or down a little over time but essentially the core change team will be needed for the foreseeable future.
If your change agenda feels more like this than a property project then it will be well suited for an agile continuous delivery model, funded by an ongoing envelope. Under the envelope model the team becomes a relatively fixed cost structure and the frequency of their change deployments should also be fixed at a regular cadence. The variable then becomes the scope delivered in each cycle of change. Over time the volume and throughput of change as well as the associated customer and business results become the things that management and teams obsess about, rather than budget and schedule.
Project funding models tend to strive for certainty of cost and schedule over speed and require scope to be fixed. When “pouring concrete” the project-funding model creates efficiency by avoiding rework during the construction phase, but when applied to software or business process changes it will drive up, not down the unit price of change. By contrast funding envelopes tend to fix cost and delivery frequency in order to then focus on continuous improvement of throughput and quality together with the associated business and customer outcomes.
If you need help with your operating model for agile change feel free to reach out to me on email@example.com.
About the author: David Boyle’s IT career over 30 years spans both the buy side and sell side of technology services. He’s worked with Accenture, EY, Commonwealth Bank of Australia and until recently was the Group CIO at NAB. David is now the Managing Director of CAP2ITS, a technology advisory firm focusing on technology strategy, performance and risk.