Pay for Performance -- How Do You Measure It?
More enterprises have moved to pay-for-performance salary and promotion models that measure progress toward goals -- but how do you measure goals for a maintenance programmer who barrels through a request backlog but delivers marginal value for the business, or for a business analyst whose success is predicated on forging intangibles like trust and cooperation with users so things can get done? It’s an age-old question facing companies, now that 77% of them use some type of pay-for-performance model. What are some popular pay-for-performance use cases? A factory doing piece work that pays employees based upon the number of items they assemble. A call center that pays agents based on how many calls they complete per day. A bank teller who gets rewarded for how many customers they sign up for credit cards. An IT project team that gets a bonus for completing a major project ahead of schedule. The IT example differs from the others, because it depends on team and not individual execution, but there nevertheless is something tangible to measure. The other use cases are more clearcut -- although they don’t account for pieces in the plant that were poorly assembled in haste to make quota and had to be reworked, or a call center agent who pushes calls off to someone else so they can end their calls in six minutes or less, or the teller who signs up X number of customers for credit cards, although two-thirds of them never use the credit card they signed up for. Related:In short, there are flaws in pay-for-performance models just as there are in other types of compensation models that organizations use. So, what’s the best path for IT for CIOs who want to implement pay for performance? One approach is to measure pay for performance based upon four key elements: hard results, effort, skill, and communications. The mix of these elements will vary, depending on the type of position each IT staff member performs. Here are two examples of pay per performance by position: 1. Computer maintenance programmers and help desk specialists Historically, IT departments have used hard numbers like how many open requests a computer maintenance programmer has closed, or how many calls a help desk employee has solved. There is merit in using hard results, and hard results should be factored into performance reviews for these individuals -- but hard numbers don’t tell the whole story. For example, how many times has a help desk agent gone the extra mile with a difficult user or software bug, taking the time to see the entire process through until it is thoroughly solved? lf the issue was of a global nature, did the Help Desk agent follow up by letting others who use the application know that a bug was fixed? For the maintenance programmer who has completed the most open requests, which of these requests really solved a major business pain point? For both help desk and maintenance programming employees, were the changes and fixes properly documented and communicated to everyone with a need to know? And did these employees demonstrate the skills needed to solve their issues? Related:It’s difficult to capture hard results on elements like effort, communication and skills, but one way to go about it is to survey user departments on individual levels of service and effectiveness. From there, it’s up to IT managers to determinate the “mix” of hard results, effort, communication and skills on which the employee will be evaluated, and to communicate upfront to the employee what the pay for performance assessment will be based on. 2. Business analysts and trainers Business analysts and trainers are difficult to quantify in pay for performance models because so much of their success depends upon other people. A business analyst can know everything there is to know about a particular business area and its systems, but if the analyst is working with unresponsive users, or lacks the soft skills needed to communicate with users, the pay for performance can’t be based upon the technology skillset alone. Related:IT trainers face a somewhat different dilemma when it comes to performance evaluation: they can produce the training that new staff members need before staff is deployed on key projects, but if a project gets delayed and this causes trainees to lose the knowledge that they learned, there is little the trainer can do aside from offering a refresher course. Can pay for performance be used for positions like these? It’s a mixed answer. Yes, pay per performance can be used for trainers, based upon how many individuals the trainer trains and how many new courses the trainer obtains or develops. These are the hard results. However, since so much of training’s execution depends upon other people downstream, like project managers who must start projects on time so new skills aren’t lost, managers of training should also consider pay for performance elements such as effort, skills and communication. In sum, for both business analysts and trainers, there are hard results that can be factored into a pay for performance formula, but there is also a need to survey each position’s “customers” -- those individualswho utilized the business analyst’s or trainer’s skills and products to accomplish their respective objectives in projects and training. Were these user-customers satisfied? Summary Remarks The value that IT employees contribute to overall IT and to the business at large is a combination of tangible and intangible results. Pay for performance models are well suited to gauge tangible outcomes, but they fall short when it comes to the intangibles that could be just as important. Many years ago, when Pat Riley was coaching the Los Angeles Lakers, an interviewer asked what type of metrics he used when he measured the effectiveness of individual players on the basketball court. Was it the number of points, rebounds, or assists? Riley said he used an “effort" index. For example, how many times did a player go up to get a rebound, even if he didn’t end up with the ball? Riley said the effort individual players exhibited mattered, because even if they didn’t get the rebound, they were creating situations so someone else on the team could. IT is similar. It’s why OKR International, a performance consultancy, stated “Intangibles often create or destroy value quietly -- until their impact is too big to ignore. In the long run, they are the unseen levers that determine whether strategy thrives or withers.” What CIOs and IT leadership can do when they use pay for performance is to assure that hard results, effort, communications and skills are appropriately blended for each IT staff position, and its responsibilities and realities -- because you can’t attach a numerical measurement to everything -- but you can observe visible changes that begin to manifest when a business analyst turns around what has been a hostile relationship with a user department and you begin to get things done.
#pay #performance #how #you #measure
Pay for Performance -- How Do You Measure It?
More enterprises have moved to pay-for-performance salary and promotion models that measure progress toward goals -- but how do you measure goals for a maintenance programmer who barrels through a request backlog but delivers marginal value for the business, or for a business analyst whose success is predicated on forging intangibles like trust and cooperation with users so things can get done? It’s an age-old question facing companies, now that 77% of them use some type of pay-for-performance model. What are some popular pay-for-performance use cases? A factory doing piece work that pays employees based upon the number of items they assemble. A call center that pays agents based on how many calls they complete per day. A bank teller who gets rewarded for how many customers they sign up for credit cards. An IT project team that gets a bonus for completing a major project ahead of schedule. The IT example differs from the others, because it depends on team and not individual execution, but there nevertheless is something tangible to measure. The other use cases are more clearcut -- although they don’t account for pieces in the plant that were poorly assembled in haste to make quota and had to be reworked, or a call center agent who pushes calls off to someone else so they can end their calls in six minutes or less, or the teller who signs up X number of customers for credit cards, although two-thirds of them never use the credit card they signed up for. Related:In short, there are flaws in pay-for-performance models just as there are in other types of compensation models that organizations use. So, what’s the best path for IT for CIOs who want to implement pay for performance? One approach is to measure pay for performance based upon four key elements: hard results, effort, skill, and communications. The mix of these elements will vary, depending on the type of position each IT staff member performs. Here are two examples of pay per performance by position: 1. Computer maintenance programmers and help desk specialists Historically, IT departments have used hard numbers like how many open requests a computer maintenance programmer has closed, or how many calls a help desk employee has solved. There is merit in using hard results, and hard results should be factored into performance reviews for these individuals -- but hard numbers don’t tell the whole story. For example, how many times has a help desk agent gone the extra mile with a difficult user or software bug, taking the time to see the entire process through until it is thoroughly solved? lf the issue was of a global nature, did the Help Desk agent follow up by letting others who use the application know that a bug was fixed? For the maintenance programmer who has completed the most open requests, which of these requests really solved a major business pain point? For both help desk and maintenance programming employees, were the changes and fixes properly documented and communicated to everyone with a need to know? And did these employees demonstrate the skills needed to solve their issues? Related:It’s difficult to capture hard results on elements like effort, communication and skills, but one way to go about it is to survey user departments on individual levels of service and effectiveness. From there, it’s up to IT managers to determinate the “mix” of hard results, effort, communication and skills on which the employee will be evaluated, and to communicate upfront to the employee what the pay for performance assessment will be based on. 2. Business analysts and trainers Business analysts and trainers are difficult to quantify in pay for performance models because so much of their success depends upon other people. A business analyst can know everything there is to know about a particular business area and its systems, but if the analyst is working with unresponsive users, or lacks the soft skills needed to communicate with users, the pay for performance can’t be based upon the technology skillset alone. Related:IT trainers face a somewhat different dilemma when it comes to performance evaluation: they can produce the training that new staff members need before staff is deployed on key projects, but if a project gets delayed and this causes trainees to lose the knowledge that they learned, there is little the trainer can do aside from offering a refresher course. Can pay for performance be used for positions like these? It’s a mixed answer. Yes, pay per performance can be used for trainers, based upon how many individuals the trainer trains and how many new courses the trainer obtains or develops. These are the hard results. However, since so much of training’s execution depends upon other people downstream, like project managers who must start projects on time so new skills aren’t lost, managers of training should also consider pay for performance elements such as effort, skills and communication. In sum, for both business analysts and trainers, there are hard results that can be factored into a pay for performance formula, but there is also a need to survey each position’s “customers” -- those individualswho utilized the business analyst’s or trainer’s skills and products to accomplish their respective objectives in projects and training. Were these user-customers satisfied? Summary Remarks The value that IT employees contribute to overall IT and to the business at large is a combination of tangible and intangible results. Pay for performance models are well suited to gauge tangible outcomes, but they fall short when it comes to the intangibles that could be just as important. Many years ago, when Pat Riley was coaching the Los Angeles Lakers, an interviewer asked what type of metrics he used when he measured the effectiveness of individual players on the basketball court. Was it the number of points, rebounds, or assists? Riley said he used an “effort" index. For example, how many times did a player go up to get a rebound, even if he didn’t end up with the ball? Riley said the effort individual players exhibited mattered, because even if they didn’t get the rebound, they were creating situations so someone else on the team could. IT is similar. It’s why OKR International, a performance consultancy, stated “Intangibles often create or destroy value quietly -- until their impact is too big to ignore. In the long run, they are the unseen levers that determine whether strategy thrives or withers.” What CIOs and IT leadership can do when they use pay for performance is to assure that hard results, effort, communications and skills are appropriately blended for each IT staff position, and its responsibilities and realities -- because you can’t attach a numerical measurement to everything -- but you can observe visible changes that begin to manifest when a business analyst turns around what has been a hostile relationship with a user department and you begin to get things done.
#pay #performance #how #you #measure



·100 Views