Budgeting vs. agile

In my previous post I have shortly introduced some basic financial principles. It might look odd that I talked about business and markets in the space that should be reserved for agile posts, but I felt that one of the reasons why many agile transformations fail in big corporations is not well understood.  Failures to introduce agile are often associated with lousy managers, complexity of organizations, corporate culture etc. That is all fine, but I believe that the root cause is in another place – in the way corporations run their businesses. This is how normally business process works, and nothing looks that fancy at the first sight:

Investors that govern large corporations look to increase their investment on a yearly basis, and in process every business unit within the organization tries to get to similar grow figures. Since companies try to get more revenues from existing markets (as emerging markets never produce enough revenues at very beginning), majority of company resources are always locked to their existing customers. One of the effects of such dynamics is that big organizations are incapable of following disruptive markets (ref: book “Innovators Dilemma”).

But there is one more important problem, and it starts with budgeting. Let’s imagine for the moment that your part of organization has made 100 million last year and that new target for this year is 110 million. The first logical thing to do you might think would be to ask sales guys (who else can bring you another 10 million next year?) is which features or products this unit needs to develop in the coming year to get to the target. Based on their feedback, in top down fashion, budget will be distributed over different projects depending on the business needs. By the time that project manager got his budget (people, material etc.) promises to the customers have been already made – how otherwise would sales guy come with 10% higher revenue for the next year? So, famous triangle of the fixed cost, timeline and content is there already at very beginning of the fiscal year!

That is not complete story. Projects that generate less money over years will get fewer budgets, without actually paying too much attention whether they still have customers on that product – who can still request new features or bug fixes. In B2B environments customers can retaliate in unexpected places and in what I call management by escalation mode, such projects can start suddenly sucking resources from other projects.

Finally what is there for project managers? On one side there is a huge pressure to make the features with committed dates and given budget, and on the other hand uncertainty that comes from running any software project. Temptation to manage projects using waterfall is clear, as managers badly need to believe that complexity and chaos of running software project can be only be put under control by paper work and Gantt charts.

There is also another option you might think would work. Let’s imagine you want to do bottom up approach, or even better, put all folks in the same room: business guys, sales guys, project managers etc.. Dynamics that you can often see then is that project managers will start whining and asking always for more resources – which will be followed by challenges from higher management to remove all “fat” which will in the end produce very nice working atmosphere for the rest of a year.

Not surprisingly, most of the books and blogs which introduce agile practices use in the examples smaller groups and single products. For many garage like companies agile brings discipline and focus to already flexible and motivated environment.

In larger established organization, dynamics can be quite different and breaking existing culture which is required to adopt agile is much harder than people might think. Very often, the problem is already there at beginning of the year, at the time that sales guys meet executives.

I always find asking the right questions more important than finding magic solutions. In my next blog post, I will add few more questions you may want to ask yourself, before you walk in the room with your agile slides.

Leave a Reply