Employee Productivity and Parkinson’s Law – Part 1
posted by David Sward on January 26, 2007
Employee productivity is a hotly debated subject. Measuring employee productivity is straightforward. Valuing employee productivity is difficult. I’m going to deal with the easy part first and cover the hard one over the next few weeks.
We define this business value dial as follows: Employee Productivity = gains in headcount efficiencies or effectiveness. Headcount is expected to produce more through these gains due to the additional time-based efficiencies. It is calculated using (number of employees affected) x (time) x (average cost of an employee) x (50%).
When developing plans to measure employee productivity and in determining how IT solutions impact it, we have found it useful to think along these lines. Define employee productivity operationally. By this we mean to look at how the employee interacts with the current technology and how the new solution is going to change that. An IT solution might result in incremental or innovative changes. Incremental changes might be:
- Removal of an activity an end user performs
- Reduction in the time it takes to complete an activity
- Reduction or removal of end-user errors either by reducing the number of processes to achieve the same outcome (thereby lowering the probability of an error) or by reducing the cost associated with making an error
- Reduction in time needed to gain proficiency in an activity
Don’t forget to take into account any fundamental restructuring that eliminates all or a portion of activities, these are often innovative changes. For example:
- Replacing manual asset handling with RFID tagging
- Replacing standard password authentication using a data input device with a biometrics reader
This approach should help you distill the business value dial to a set of basic
measurable indicators of productivity improvements.
With a bit of practice, outlining how IT solutions impact employee productivity
and operationally defining how to measure it gets easier. Over time you will
easily recognize whether it is: time to process transactions, steps eliminated,
increased output, etc. that produce the gains. Once these are identified they
can be quantified and measured then you have to move on to the hard part -
figuring out how to value it…
Comments (2) (closed)
tagged: business, business value dials, employee, employee productivity, IT, productivity, value
Comments
Feb 02 | Eleanor Wynn said:
Nice post, David. I would refine your comments to include “elapsed time” it takes to complete a transaction, and user interface transparency of infrequently used but critical applications. Say there is a transaction I need to use that the vendor assumes will be done by an expert. That expert knows where the links are hidden and in many cases, workarounds to how the application is presented. The infrequent user doesn’t. So a task that ought to take ten minutes winds up taking a half an hour, before help is sought. If the help SLA is 24 hours, the elapsed time for a ten-minute task is one day. Plus the frustration cool-down that so closely matches the discussion on regaining context after interruptions.
This leads me to a new research topic: the difference in regaining context between a pleasant and an unpleasant interruption!
Feb 14 | David Sward said:
Eleanor, great question. I think we have “elapsed time” covered with time on task. The question of “total elapsed time” to complete the task with respect to the cost of getting re-oriented is another issue. I would suggest considering user interface transparency and frequency of use as two separate, but related issues. Within user-centered design this scenario should be explicitly designed for to avoid the problem by clearly identifying the end-user groups and what they will be doing with the system. The simple solution is that the infrequent users should get more structure or help around the transaction (e.g., a question and answer type dialog). The transaction will take longer, but that is not the point for these users, you want to make sure they can complete the task without issues or having to return to the task the next day. The expert users in this case should have another route to complete the transaction and this route could be dependent on a fair amount of training. Clearly the situation you outline is not desirable and would be considered a usability issue. The next question is how many users are impacted, how much time is lost, are errors getting introduced, and what is the level of user frustration?