An agile budgeting proposal - Part I
tl;dr: Every project I have seen in outsourcing companies has a budget. But having a classic budget is not agile. It’s a static document that is not updated during the project. This is a draft of one of the potential solutions to this problem.
How can we translate agility into budgeting?
Let’s say you have a nice self-managed team that adapts and delivers value at a fast pace to a costumer of a given service-provider company. You have achieved the Agile nirvana. Haven’t you?
There was some bargaining between the service-provider and the costumer, and a budget was agreed upon, along with some broad scope and some high-level requirements to be delivered at a certain deadline.
Problems appear when budget seems not to be enough and/or deadline is coming and the customer is not satisfied with the whatever the team has delivered.
Problems also appear then the customer’s context changes so wildly that the original scope is no longer valid at all.
Problems also appear when the team is delivering but the customer feels that something is off. The team is not to blame, but the customer is not satisfied.
Should we keep the project going? Is the customer going to lose 100% of the budget regardless of the outcome? Is the provider going to lose 100% of the expected income plus the opportunity cost of blocking the team for a while?
I will explore here a potential solution to these problems. But first we need to define some constraints.
There is a way to fairly balance the spent budget up to a certain point, the savings of the customer and the compensation to the provider if any party decides to retire from the project before the deadline.
This proposal brings an equilibrium point between the customer’s and the provider’s interests. None of them will regret this agreement once the project starts in any reasonable scenario.
- Customer trusts the team
- Customer will prefer a viable product over a perfect one if that means:
- The product is delivered before the deadline
- The product is delivered for less money than the maximum budget
- Customer assumes that the scope will change as both them and the team learn more about what adds value and what doesn’t
- Provider is commited to educate the customer about the agile process
- Provider tries to minimize waste and maximize value per unit of time
- Provider has a queue of projects to work on and/or values the importance of free earned time
- Customer and provider assume that the context when starting a project will change during the execution of it and nobody should be blamed for that nor charged.
The model is concentrated into a single function that defines the balance between the customer’s and the provider’s interests at any given moment and how money and time are balanced.
I named it the Agile Budget Split Function, and it depends on the elapsed time.
This function is defined at company, department or project level. It’s a function that is defined by the company’s culture and the team’s values.
This function must be easy to understand and easy to explain to the customer. It must be easy to explain to the team as well.
In the next article I explain the basic theory behind the model and I give a concrete example, using a constant function.