In a previous article I wrote
The actual decision (of a software architect) should lead to a solution that meets availability, performance, reliability, scalability, manageability and cost criteria. (Btw: the first six critera should be met, the last one should be at least met and minimized, but that is a different story.)
Many times the criteria are met and there is no intention to minimize the cost. “There is a budget and we have to fit into it.” This is the approach teams follow. There are several reasons for it. But the reasons do not neccessarily mean that the approach is ok. I may even accept the argument that this behaviour is unavoidable in large organizations.
Why is this approach bad?
When you sell something you want to sell it the highest price you can. Cost represents a minimum for the selling price: if the reachable price is lower than the cost to reproduce then production will stop. Budget is also a limiting factor. You go to the food shop and you buy the bread that meets your likes and is the cheapest among those if you have the money. If your money is limited you will select one that you can pay for. Why would one buy the more expensive if all other criteria they need are met?
(Do not start to talk about Apple products: feeling you are rich is also a need.)
The same is true for development projects even if the customer buying the development is in the same company. Your customer is either “business” if you are an in-house team or sales in case your company develops software for customes. In the latter case the “customer customers” are the customer of the company. The customer of the development team is sales. Same company. Customer provides the budget that you have to fit in but
nobody ever complained that a project was under budget.
I am not talking about lower budget commitment. All projects have risks and all risks have financial impact. One way of risk mitigation is to have contingency in the budget. But again: that is the budget and not the actual spending. Still teams, departments tend to fill their budget. Why do they do that? There can be several reasons and sure I will not be able list all possible.
Reasons to spend more
1.
The more a department spends the more important it looks. I have seen such company. The company was a large expanding company heavily investing into assets, building infrastructure for years (like telecom infrastructure, roads or railways, I won’t tell you which one) and the one who was building the more miles the better performer was. The measurement was the spent money and this culture remained when it was IT spending. Weird.
2.
In some companties budget not spent will lessen the financing possibilities of the department for the future. If you, as a software architect can save up from the original estimates it means your estimation was not good. That will be taken into account next time you estimate. Thus the department rather wastes (usually towards end of the year) the budget left over than giving it back to treasury. It is like fixing a bug creating anoter. (How about unit testing departments?)
3.
Some companies underfinance maintenance, developer trainings, education, equipment or some other IT related activities and departments tend to amend the situation from other sources: overbudgeting projects. Things certainly will happen. If you want to have something you do not pay for you will not get it. If you got it you paid for it just you do not know where, when and how much. Developers, architect, project managers may even not realize that they follow this practice in some cases. I have heard a few times the argument: “We select the more expensive technology X for the project because this way we can learn it.” This is also crossfinancing. You use the project to finance the developer’s education.
All these are bad practices. I do not need to explain the first example. The second is also quite obvious. The last one, cross financing is not that obvious.
Why cross financing is bad
When you select the more expensive technology (it may be more expensive because it has license fees, or needs more development, learning) you decide to invest the company money into something. As an architect it is not your reponsibility. You may suggest that to management but you should not decide even if you are in the position that you can (unless you are also the management in a small company, but in that case you decide with your management hat on). It is only management who can decide how to invest the money. Investing into people is always a good investment even if they leave your company later. (But what if you do not invest and they stay?) But as a matter of fact management may see even more lucrative investment possibilities at that very moment.
Don’t feel bad
Do I suggest that you rush to management now and ask them to lessen your budget? Do I think that you, as a software architect should feel bad if you fill the budget and cross finance?
Not at all. I said that crossfinancing is bad practice but I did not say that it is YOUR bad practice. It is a bad practice implemented in a company. The larger the organization is the more difficult it is to change it. And it is not your task, and more importantly you may not have the capabilities to do that.
The only thing you have to: know that you follow a practice that is not optimal, so to say. If there is any chance to improve it just a little bit, go for it. Everybody making one small stepp will save the world.
| Reference: | Do not (only) meet the budget from our JCG partner Peter Verhas at the Java Deep blog. |
