Get in touch
For a long time I thought the only way to manage an Internet agency efficiently from a cost point-of-view was comprehensive controlling. In an agency it is mandatory that this be based on time actually spent by the employees who are tasked to projects. Over time, however, I have come to realize that that which is supposed to be the basis for decisions to increase efficiency and drive improvement is actually counterproductive. Read on to find out why.
Those of us in the digital economy have been billing our services according to time expended since the beginning of the digital era. We determine a price per time unit according to the role of the employee (developer, integrator, project manager, consultant, etc.) and invoice the time used accordingly. Employees must work a specific time period and receive a salary for the time defined. Thus, in this manner, they cause the main portion of the costs for the agency in the P&L statement. In and of itself this seems consistent and logical.
The client, on the other hand, wants to receive a deliverable. He wants a product or a result he can use for his business. It should be of high quality and delivered as quickly as possible. It should provide a benefit that creates an advantage for the customer in his own business. In other words, the deliverable should have a business value. Ideally, the fee that the client is willing to pay for the business value of the deliverable should cover the price that the agency demands for the sum of the time needed to produce it. Everyone is happy.
Unfortunately, the ideal case is about as common as snow in July – it is very rare. The rule is rather that either the client or the agency must scale back their expectations. In most cases the cost estimate of agencies looks nothing like the reality. The reality is usually significantly worse.
Regarding this issue many agencies therefore tend to become active at some point. The employees sensitize each other for the subject, calculate what kind of margins one would have and what one could do with all that money if one could only invoice all the hours for the project that were also logged onto the time keeping system. I've rarely found a solid service controlling system. This isn't surprising as those people who are in agency management rarely have the necessary knowledge to calculate costs. That the industry with all of its peculiarities (as viewed from the perspective of the Old Economy) is still young also contributes to the dissatisfaction. There is simply a lack of established concepts comparable to what can be found, for instance, in industrial production. Thus concepts – some more, some less sophisticated – are being used to provide at least some measure of a project's profitability.
I find it particularly fascinating that the results are usually interpreted differently from project to project. Those projects that are favored but in the red usually get all kinds of soft factors “monetized” into them (at least mentally). Projects that become unpopular usually remain so, even if they are profitable. Personally, I don't even find this to lack a certain “simpatico” factor, even if it is, objectively speaking, utter nonsense, as it shows that the economic component doesn't always dictate everything.
The mother of all cost accounting is timekeeping. Very unpopular with most of the staff. For one thing, it requires quite a bit of discipline from the employees and, secondly, it's inappropriate for the way most employees work. An agency lives from impulses, from rapid and slow phases. Constant time tracking tries to create facts here where no clear ones actually exist. The reason? Time need usually has only a very abstract connection to the deliverable and therefore to the business value for the client. And that exactly is the essence of the problem. Because, for the most part, the client doesn't understand why feature A means that x hours are needed. Not because he can judge it, no, because Feature A has a certain business value to him. If the costs bear no relationship to the business value then he doesn't understand the effort expended. (Not to be confused with the client type “Doesn't know much of anything”, who simply considers everything to be easy and questions every effort).
It becomes even more difficult if the time needed varies. But that is exactly the case in software development, where effort can only be roughly estimated. Anyone who claims otherwise has only been integrating templates until now. But, the client presumes that every step can be precisely calculated and estimated. He isn't aware of the – sometimes – explorative nature of this type of work. And, as if the (conscientious) developer didn't already have enough to worry about, here comes the agency and forces him into timekeeping strait jacket. And what is also a lot of fun are the exact reports and the discussions based upon them when times are bad. Truly good developers will try to avoid all of this, as if it were the plague. At least that's been my experience.
And it is exactly this timekeeping that promotes false read-outs. If time is tracked precisely and every error reprimanded or “discussed”, then the developer will inflate his estimates. Agency management will go into two or three pitches with these estimates and realize that they are far too expensive. Then, at the next pitch, they let the developer's estimate stand without comment and lower the price. Controlling, though, is based on this price and again the developer is open for criticism. These are the typical beaten paths that are created. An ideal breeding ground for frustration.
Also, if working hours are tracked in detail, usually a lot of overtime is accrued. Those employees who need a lot of time and are therefore in the office longer, have many overtime hours, those who logged relatively less time are viewed negatively. The problem is that is lies in the nature of a good developer to deliver better deliverables in shorter timeframes. If one measures using the scale of “more time logged equals more commitment”, then one consistently rewards the wrong employees. And the good developers will leave sooner or later.
What can you do about it? An awful lot, I think. I would start by only logging working days, and these days only by the team leader, not the developer. This requires a few conscious adjustments:
In my article about Labor Day I wrote that we must find a model for our economy that doesn't link the value of work primarily to the time we spend working, since the gains in efficiency through technological progress has been shortening the worktime necessary for decades. If we look at this system, we must realize that this cannot work in the long run. Less and less time is needed for people to generate value.
The human being, however, continues to be needed. We would therefore be well-advised to link remuneration for a person's work to business value as soon as possible. I know that this is no easy task. It is no coincidence that more and more services are rendered as product or flat-rate services. The customer is simply a better judge of the connection between business value and money to be paid.
This can be implemented relatively easily in agencies with strongly-repetitive work by offering services in modules and by trying to create configurable and therefore universally usable code in development and production. In this way timekeeping becomes less and less important, because such an approach strongly reduces the effort expended for creating features anyway. The price for functionality continues to be determined by the business value for the client.
And this value is not lessened just because one expended less effort to provide the feature. Now we have finally reached the point again that we actually try to reach in agencies: more healthy efficiency, more satisfied employees and customers and more profit at the end of the year.
