Again, Asians have a different sensibility, so it's important to make it clear you're not trying to point out their individual mistakes and make them loose face, KPI's are there to get a general view of the situation, to help them improve themselves and existing processes. It's important to make clear that KPI's are for their own benefit as well, to make their life easier.
To address the why, how, what and where, I will divide this post into all those parts, but starting with a short-ish introduction to give you a general idea.
First of all, KPI's are a required tool in the managerial arsenal, without a metric, you're blind on how your plans and processes are doing. You're blinded to possible improvements and slip-ups, you have no visibility regarding who's doing a good job and who is not, etc.
It's great to have information and the more the better... but no, you don't need to know everything and most importantly, you can't absorb too much information. How you gather information it's important as well, and you don't want to create an overhead that will cause people to stop doing what they're supposed to be doing, you also need focus, you can't identify everything or take action on everything at the same time.
Let's say you're go into a start-up or a company without KPI's, what to do first? Well, you need to start from somewhere, so the best would be creating a general KPI to give you a general view of the situation, and after a while - having enough information - identify areas in which you want to have more information for either, improve or set new processes or take preventive or corrective actions on obvious things.
So, how to generate the information necessary?
There are basically 2 ways, automatically and manually. Automatically generated stats are in general more reliable than manual, but not always. A machine can tell you how many circuit boards it made, but not how many didn't pass QA, a software can tell you how many hours and person had certain windows opened in their computer, but they can't tell you how long they were thinking in improvements ideas or if they did things correctly. So starting from the basis that automatically and manually generated information require manipulation and checks, and that both generate overhead, the key here is generating information as accurate as possible, generating the smallest amount of overhead possible.
One of the best ways of keeping accurate manual information, is keeping a weekly or daily calendar divided by hours, at the end of each hour, a minute or two are required to fill in the tasks done within that hour and their duration, and since that task is fresh, you avoid 'remembering'.
One important note on this. People work better when they're not multi-tasking and in periods of 45 minutes each. Encourage your people to minimize checking their e-mail or other distracting tasks all the time, but instead to add that into their hourly schedule a 5-10 minute break, to check their e-mail, Facebook, fill in the sheet, etc. I promise you that will increase productivity.
Why generating a KPI?
In my opinion, the most important thing to have in consideration when generating a KPI is the 'why', a KPI just for the sake of having information doesn't make sense, your metrics MUST have a purpose, i.e. improving something. You may think a KPI to report the status your company or department to the board is only informative, but you should think differently, that metric should be part of your own KPI, maybe, in a more detailed way, which allows you make decisions on particular things, but it should be the same KPI, presented differently.
The why can take many forms, depending in many factors, but again, they should be in alignment of certain goals and objectives, preferably sat by the upper management or the board.
In conclusion, the why must be very well defined and the objectives must be clear.
What to measure is probably the most complex part of a KPI, what you think it may be the perfect thing to track, may not represent what you want to improve, correct or prevent, so the first thing is to identify your goals and objectives, secondly, identify the subset of information you want to focus on, then identify your control points (is your data coming out correctly? is it accurate?), and then how you will represent that information (graphs? tables? written reports?). Only then you will know if the 'what' is getting you what you were expecting.
The 'Where' has 2 parts, where will you be measuring, and where will you be presenting the information.
Let's imagine we want to measure individual tasks inside a project, we can ask the developer to measure these tasks, we can ask the project manager to measure these tasks, we can ask the developer's supervisor to generate the stats, but 'where' we ask for this to be measured will affect both, the overhead and the accuracy of the information, so we need to be clear on how accurate we need the information to be versus how much overhead we're willing to cause.
For this example, asking the developer will be the most accurate way of measuring this KPI, but will also cause the biggest overhead, because he will have to stop to measure exactly how long it took to do something every time he did it, and if there are many tasks involved, he will have to stop a lot, just to register stats. Now, if we ask the project manager, he will get a good estimation for particular tasks in his project, accuracy will depend on how often he will get a status update of his project, given that memory is fragile, also if the number of tasks to be measured is considerable, then the overhead can be considerable as well, but one-time-only, unlike the developer's metric, creating less distraction, ergo, less overhead. If we ask the developer's supervisor, probably he will gather this information in a department or team meeting, using a mix of experience and actual memory, and maybe several people's experience, which will make this metric a bit more of an average than a metric for a particular project, in this case, overhead will be minimal, but accuracy may suffer.
Now the second part. Where you will be presenting this KPI will also dictate how you have to prepare it. I said before, most goals and objectives SHOULD be cascaded down from the high-management and/or board, in some cases your KPI will be merged with others to create a more general view of the situation of a department, area or company, so formatting will be very important and the level of detail will vary from the level in which it will be presented, but the objective must remain the same. Let's continue with the example of the project metric above, we have a goal cascaded down from the board of directors, which is, reduce the implementation time of a particular type of project in 10% within 1 year without increasing resources and/or effort.
For this case our KPI will work perfectly:
- We know the target is 10% reduction in time
- We will have a good idea of the overhead of generating the stats (depending on the method we chose), and this time should also be factored into the project itself (and informed to the high management)
- After some time gathering information, we will know which tasks consume the biggest amounts of time, and we can take actions to try to reduce those times (with automation, improving training, improving processes, etc.)
So as you can see, the same KPI will do for all levels of the organization with small alterations.
The developer will know his/her time frames, the PM will know how much to reduce in each phase of the project and will be able to keep track better of deviations, the supervisor will have a clear view of the projects on time and delayed and the board will receive a report with the average time projects are now taking.
So far, this all sound pretty easy to achieve, but in most cases is not, and the main reason is because KPI's are very likely to be linked with your and your staff's performance bonus, which makes it a bigger challenge to gather accurate stats, and this is when you have to start thinking in cross referencing KPI's. A good example for this would be people staying later than normal, just to make it appear like a 10% reduction in effort was achieved, when in reality no improvement was made, just extra effort from the people involved. So here you could cross check with something like the IN/OUT report of the door. If something there doesn't add up, you know you have to look at it more closely. You also need to be vigilant of tampering, and this is why 'Sell, not tell' is so important here, if people believe in what they're doing, they much less likely to alter results and numbers...
One advantage regarding KPI's while managing in Asia is the highly developed concept of honor and the ability of Asians to follow well stablished processes better. In my experience, if you're able to find ways to reduce time or improve things that you can add into a well defined process (or process improvement), people here will be able to follow it and reduce time pretty much all the time.
So from this you can deduct that KPI's and processes are closely related. One of Newton's laws, actions and reaction, red or yellow numbers will almost certainly require an action from the manager and those actions most probably will require some sort of process in place.
Some people would say "if it's not broken, don't try fixing it", and this can be truth most of the time. Trying to add improvements into existing processes, can cause problems and overhead, but being able to interpret small fluctuations in numbers in a KPI correctly, can also indicate preventive actions are needed... just apply your common sense and prioritize what's important.
No comments:
Post a Comment