Let us take a real-life example.
The AC in a car is an overhead. It eats into the petrol that is used to run the car. However the benefits and pleasure that the owner of the car derives from the AC far outweighs the additional expenditure in his perspective. His wife may still scold him that AC need not be switched on in the car during the evenings
. Thus an overhead is mostly a matter of perception.
Here, when the projects are executed in an organizational environment, we have to consider one more factor — long- term vs. short-term benefits. Having the code in CVS and taking on the overhead of CM; or the overhead of adding comments to the code have now become second habit to us so maybe we do not see them as overheads. We have burnt our fingers or seen others suffer when this overhead was flouted so we are now avid exponents of using CM on our projects — the same goes for good comments in the code.
In time-critical projects there is a tendency is looking at meetings as an overhead. This is again a perception problem. The problem lies in the fact that we are not good meeting organizers and therefore we waste a lot of time in meetings — that does not mean that meetings are a waste of time.
Good meetings need just 10 to 15 minutes of the team’s time. The onus is on the manager to find out the individual status before-hand — maybe even circulate it to the team and then just have a “standing meeting” for 10 to 15 minutes where the team arrives at a consensus as to how the problems and issues can be sorted out. Further discussions could be the Action Items emerging from the meeting. This is a practice advocated by the Agile processes.
Consider “the work is not completed until the paperwork is done”. This overhead is what we owe to our fellow colleagues and to the organization. Since the customer comes first, sometimes a manager has to make a decision as to how much of such overhead he will tolerate. Here also the emphasis should be on getting the new tools required to automate the repetitive tasks, rather than not keeping the records. Here the long-term requirements of the organization and what it gains from the project has to be kept in mind before doing away with any of this paperwork.
When you love something and are passionate about it, you do not mind spending extra hours and days to complete that work e.g. when we enter the Testing stage we see the team members staying late nights because they want to fix the bug. We may also see team members spend more than half an hour for a lunch-break or even keeping in touch with friends through email. I am not saying these are bad. What I am saying is that when you see value and love to get together with your friends you will do it — no matter what the overhead to you is in terms of time and effort. You don’t call it overhead in the first place: you feel that they are your rights. Similarly you owe it to the organization to keep records.
We should look at these processes not so much as QUALITY but as enablers, which allow us to excel at what we do. If we have a passion for excellence, we will naturally move towards doing all our activities with perfection so that customer does not crib when he gets a deliverable. With a passion for excellence driving us, and a desire to give the best of ourselves to the work at hand, we will naturally move towards Software Quality Management and Six Sigma principles. In case we find that the existing Software Quality Management is coming in the way of our productivity we will speak to Quality Team and define a better process or template.
Some activities become an overhead when they are piled up & delayed too much. Take the case of code review. In most projects this is not done properly since at the end of coding we go into code review. Instead look at what Agile process advises and how it was applied in a project. Every day 3 people would code and 1 would review all code produced the previous day. The code review comments were circulated to the team and it was expected that these same comments would not appear in the rest of the code produced for the remaining of the coding phase. The team appreciated this “overhead” since it achieved the purpose of reducing defects early. It allowed them to do a better job.
It is now up to each and every engineer and manager in the engineering departments to ensure that overheads are manipulated to become the icing on the cake. The icing is not a necessary feature of the cake but it enhances the value of the product. The processes and constraints of Software Quality Management have to be perceived in the same way. If they are not the icing on the cake today, what is it that we engineering staff need to do to transform the processes: this Quality Team or Top Management cannot tell us! It is the grass roots who now how to transform overheads and unpleasant activities into the icing on the cake.
Naseem Mariam is the editor of “Management that Soars” Newsletter & author of “Project Serenity – How to gain happiness and peace”. Her ritings draw life from her 18 years experience as software Project Manager. Let her guide you towards Faster All Round Success and a Stress Free, Joyous Life. Her free ebook and Newsletter tell You How. Subscribe with mailto:projectdioxide@sendfree.com Visit her at http://www.123projectmanagement.com
