Resource Optimization
I often hear managers talk about wanting to optimize the resources they manage. Most of the time, they refer by that to the need to optimize the way their human resources (their employees) work. This is a perfectly legitimate goal. After all, you are running a business (or working for one). The problem usually lies in the strategy set for achieving this goal.
More accurately, the problem is that sometimes no one really sets a strategy in that context. The plan for driving such a resource optimization cannot be just to order people to work harder or faster. This does not really fall into the definition of “optimization”. Such a “strategy” might show some results in the short-term, but in time, it will cease to be effective. People cannot always “work harder” or “work faster”. There is a limit to how much harder to faster one can work, and for how long she can do this. So, as a long-term strategy, such an instruction can only cause frustration and mental weariness. Your employees will get the sense that whatever they do – it’s never enough: their management is never satisfied with them.
A much better strategy would be to first understand which concrete things could be optimized. This strategy does not suggest that people are not working fast enough. It is focused on the how the work can be made simpler and more effective, such that it would take less time to complete.
Let’s say you are managing an organizational unit with five development teams. How can their work be optimized? Well, no one can seriously answer this question without having some data about the work being done. How much time is spent on design? What is being designed? How much time is spent on testing? How is testing being performed? How many QC cycles are there per iteration? How changes are being handled? How much rework is being done? Etc. Each of these questions might affect the overall productivity of your teams. If you really want to optimize the way your development teams work, you must first fully understand it.
You might find out that there are many time consuming cycles with QC and, on the other hand, no time is dedicated at all to unit testing. You might find out that too much time is being spent on designing features, which are planned to be implemented in future iterations, but then constantly being changed. You might find out that almost no design is being done before implementation starts, and this causes the implementation to be more complicated then it should. You might find out that some of your teams are practically doing significant parts of the work repeatedly, instead of creating a shared infrastructure. You might even find out that extensive amount of time is wasted on context switching between projects and tasks.
Each of these potential findings leads to a different optimization solution: introducing unit testing, sharpening design practices, designing incrementally, designing at all, creating a shared infrastructure, or even recruiting more people (yes! This might also be an optimization step). Without compiling actual data on projects and teams and without thoroughly analyzing it how can you expect to come up with a real solution to the optimization problem? How can you optimize a process if you have no data about it?
The data you compile will rarely provide you with definitive answers. Most of the time, such an analysis will enable you to make an educated guess (which is by far better then making a random guess, or settling with a general instruction such as “work faster”). But gathering such data has an additional benefit to your optimization process: not only are you able to make an educated guess, you can also verify later on whether this guess was right or wrong. Comparing the data compiled before the change to the data compiled after the change is implemented can help you ensure that you’ve made a step in the right direction. Alternatively, it will alert you that a different optimization path needs to be taken.
Back to the human aspect of resource optimization. Making sensible and educated optimization decisions will not only have a better chance to drive a real change, it will also motivate people. People will see the benefit in the improvement process, and will eventually be more productive without feeling pressured to “always work faster”. This is a win-win strategy: management gains a real improvement in productivity, while the employees feel that the organization and the process enable them to work better (and faster). Employees are not just expected to work better; the organization provides them the facilities to do so for everyone’s benefit.
