A constant lament within organizations relative to the performance of the information technology (IT) department is a high level of dissatisfaction with the delivery of IT projects. Too often, that dissatisfaction, on some level, is justified. The reality, as often happens when things go wrong, is that some of the causes of the problems relative to IT project delivery tend to be obscured. Given its high visibility, coupled with the basic responsibility for the project, IT will always take the hardest hit when a project experiences difficulty. Of course, the fact is that in most cases, everyone involved with the project (business area project team members as well as members of the IT staff and sometimes members of the senior staff) probably should share some level of responsibility for the failure.

If the problem were simply that of a failure on the part of IT to provide a high level of project development, the solution would be easy: simply replace the people in the IT department. Sometimes, that is the problem and replacing some IT people brings a partial solution. Generally, however, the failures of IT development projects are the result of a combination of factors, of which IT is going to be one — but certainly not the only one.

Considering the empirical evidence with regard to the movement to improved IT project development success, it can be argued that it is time to try some new approaches. Historically, most of the approaches that have been used to make progress in the delivery and quality of IT projects have focused on the introduction of more precise management methods or on technology-based approaches. One approach that has not been given very much attention, but which is worth trying, is that of changing the way IT development teams are compensated for their work.

This articles explores the benefits that can be obtained from addressing the topic of improved IT project delivery through the process of tying financial incentives directly to improvements in the delivery of IT projects. In reality, there are no silver bullets. However, in thinking through the issues involved, the idea of specific financial rewards tied to clearly defined results, holds sufficient promise to encourage organizations to given the topic careful consideration.

SOME CAUSES OF THE DISAPPOINTMENT WITH IT PROJECT DELIVERY

IT development projects fail for any variety of reasons. Usually, those failures are not the result of a single circumstance, but the result of a combination of causes. Some of those causes include:

-   Poor project planning

-   A lack of well-done project requirements and specifications

-   Inadequate project funding

-   A failure of appropriate senior management involvement and support for the project

-   Limited involvement on the part of the people who have requested the project.

-   A failure to accept proper “ownership” for the project

-   The use of inappropriate technology

-   The assumption of excessive project risk

-   An inability to develop an appropriate sense of urgency among the members of the project team

-   Instances of distraction with other business needs on the part of members of the project team

The preceding is not intended to be a comprehensive list of the causes of IT project difficulties. What is intended is to illustrate that IT project difficulties can arise from many causes and from many areas. It also demonstrates that technology is not always the cause of the difficulties. It is safe to speculate that, more often than not, the technology is not the primary cause of IT project difficulty.

Although many approaches have been used to address the issue of IT project failure, the results have been uneven. Some organizations have made progress in some of the problem areas; some have had success in other problem areas; and some have had success in a number of areas. However, it must be admitted from an overall perspective, that few organizations have enjoyed high levels of consistent IT project development success. Very few organizations have been able to sustain high IT project development levels over a long period of time.

CONSIDERIG A NEW APPROACH TO IMPROVING IT PROJECT DELIVERY

Given that the various approaches to improve IT project development have not been wholly successful, it is time to consider new approaches. One of those approaches is to rethink the way people are rewarded for their work on development projects. An unfortunate aspect of IT project work is that because it has not been as successful as it should, less than strong performance in that area has become accepted in many organizations. That circumstance has generated a situation in which people are not particularly surprised when IT development projects fail to meet expectations. Over time, a lowering of expectations results in a lowering of performance.

The dilemma here is that, despite the expenditure of considerable amounts of time, energy, and money, not only has the goal of improved IT project delivery not been met, but in many organizations the expectations associated with that delivery have fallen. The high incidence of IT project failure and the associated costs, both hard and soft, mandate attempting new methods to improve the situation.

One aspect of that lowering of expectations and performance is that, although the work on a particular project may be viewed as less than successful, there is seldom any penalty imposed on the members of the project team. Yes, managers do from time to time face termination if the situation is sufficiently difficult. On occasion, people may be chastised for poor performance; but on balance, little in the way of pain comes from a failure to meet project expectations.

However, it is also the case that when good work is done, when IT projects are delivered in a professional manner, that good work is not always recognized. It does occur that a project can come in early, it can be under budget, it can meet all the requirements and specifications, it can exceed the expectations of the IT customers, and the team members may receive a “thank you.” Although the work has been exceedingly well done, the paychecks of the team members are probably not going to be any larger than normal. They were, after all, only doing their job, right?

One of the problems associated with the lack of a concrete distinction — other than some probably minor level of praise or criticism — between well-done IT project work and poorly done work is that over time the incentive to push for improved performance is diminished. Doing IT projects well, in addition to having strong management, the right technology, and the appropriate tools, requires a strong commitment to the project. In addition, there must be a willingness to work hard and to assume a reasonable level of risk. When the financial rewards are the same for success or something less than success, it is difficult to motivate people to make a strong commitment, to work hard, and to take risks.

Think about the typical reality of project work. When it is discovered that a project is falling behind schedule, a common occurrence, usually some attempts will be made to bring the work back on schedule. However, too often, the answer is to extend the due date of the project and at the same time open up a new project phase (phase two) to reduce some of the deliverable in the current phase. Usually, in such a situation, the organization’s senior management will approve the approach, in part because that approach has been used in the past. Sadly, no one will be too surprised by the delay.

If no distinction exists between the monetary reward for doing good work or for poor work (the reality in many IT departments), there is going to be little incentive to strive for higher project quality or to meet tight delivery dates. An argument can be raised that good people will, regardless of monetary considerations, strive for higher quality work. While that assumption has merit, it does not seem to work quite that way in the real world of IT project development and delivery.

TYING MONETARY REWARDS TO PROJECT PERFORMANCE

Given that people pay attention to what they are rewarded for, it follows that changing the compensation system would change the focus of those working on the project. If the focus on the improved delivery of higher quality IT development projects can be sharpened, it is reasonable to believe that the results will be improved. No one could successfully dispute the contention that the level of IT delivery of projects needs to improve in many organizations. Developing a different compensation approach and giving it a fair trial is worth serious consideration.

Why doesn’t the argument that compensation incentives aside, good people will strive to do good work pertain to IT project development? The answers can be found in several project development circumstances. First, most IT project efforts consist of a team of people. To assume that all the people on the team are going to be wellmotivated and highly interested in striving to produce high-quality work would be unrealistic.

Second, too often at least some of the IT project team members will have to deal with a dual set of responsibilities. Where team members are assigned to the project, but are also expected to continue their normal duties (or at least some aspects of their normal duties) during the life of the project, problems are certain to arise. Dealing with those other duties, because the reality is that handling those duties is what their performance is going to be judged upon, is likely to remain their first priority. That situation is often reinforced by subtle or overt signals from the employees’ manager. The message often is that the work on the IT development project carries less importance than other duties.

Finally, IT projects often come to rely upon several key people to bring them to completion. It is not unusual to see projects where, part way through the effort, one or two of those key people decide to leave the project and as a result, difficulties quickly mount. The issue for those people is often that the project is clearly in trouble and now is the time to move on. That circumstance, coupled with a likely more attractive salary offer from someone else, is often enough to encourage a search for new opportunities. Now, the situation is that an IT project in difficulty has to struggle to find new leadership.

So what happens is that the organization has a disrupted IT project team. In addition, the project team members understand that the outcome of the project, well done or not, is not going to have any particular effect on their compensation. It will also be understood that a poorly done IT project is probably not going to have an adverse effect on any career opportunities in the future. Understanding that scenario, it may be a bit easier to understand one of the causes of IT project failure.

A key component in IT project development success is that of focus. To succeed at project development a strong focus has to be brought to bear and it has to be maintained throughout the life of the project. Because focus is a key component in project success and because, as has been shown, project teams tend to be structured with a limited focus on the project, it follows that a sharpened focus, maintained throughout the project, will bring increased rewards. When a clear, substantial system of financial rewards is in place and is tied to the delivery of highquality IT projects, the focus on those projects is going to improve. If the potential rewards are sufficiently attractive, that improvement in focus can be dramatic.

COMPENSATION PLAN GUIDELINES

To make the process of increasing financial incentives for increased IT project delivery quality a practical approach, a specific set of criteria must be tied to the process. In addition, the administration of the process must be seen as being fair and consistent. Items that must be in place prior to beginning the implementation plan include:

1. A method that can be used to objectively and consistently measure the results of the particular project compared to the original project specifications.

Where an incentive plan is to be used, there will have to be a high level of precision in the development of the project budget and corresponding time frames. The goal here has to be to come away with realistic estimates. As the compensation incentive plan gains favor, there could be a tendency to “pad” project estimates and time frames. What is likely to occur is an attempt to enhance the probability of project success and, as a result, increase the chance for additional income, by building in longer time estimates than would be considered reasonable.

One way to counter the padding of estimates is to have them reviewed by a competent, uninvolved third party. Understanding that such a person is going to review the project estimates will help reduce the tendency to pad the estimates. In any event, the use of a third party will provide sound benefits in coming to reasonable project time estimates.

The idea relative to project estimates is that they should be realistic, yet they should, in order to be met, require the project team members to increase their effort. A part of the process is going to be evolutionary, in that as projects are developed under the system, empirical data can be gathered to assist in developing a more precise set of estimating guidelines in the future. Care will need to be taken to make certain not to allow an environment to be built where anyone — employees or management — feels that the other group comes away with an unfair advantage.

One of the ancillary benefits to be found in the project development compensation approach will be that, because an increased emphasis is going to have to be placed on the development of project estimates, over time that process is going to become much more precise. When people understand the relationship between sound project estimates and their additional compensation, they are going to be very careful about the estimates they develop. In addition, they are going to look for tools and techniques that will strengthen the estimating processes. As a result, confidence in the ability of IT to accurately size projects early in the development cycle is going to grow.

2. The development of a scale for additional compensation, based on agreedupon performance for each project. At the onset, one of the criteria with regard to the topic of compensation should be to recognize the importance of flexibility. Until some experience has been gained, whatever is decided about compensation should be seen as being subject to change.

A key issue is that the compensation plan should be sufficiently generous (within the framework of a high level of performance) to make the plan attractive to the participants. The purpose of the plan is to drive for improvement in reducing the time required to deliver IT projects and, at the same time, to improve the quality of those projects. In reality, that goal would no doubt be seen as all but impossible in many organizations. When significant rewards can be obtained for meeting those goals, the probability of realizing those goals is going to greatly increase.

AN EXAMPLE OF AN IT PROJECT COMPENSATION APPROACH

One example of the structuring of a compensation plan might be as follows.

1.  A medium-sized project is estimated to require 14 months of effort, a total staffing level (from all areas, IT, and business sections) of 18 people, and a total budget of 3 1/2 million dollars. In addition, as a reasonable precaution, this project carries a contingency fund of ten percent, or $300,000.

2.  Each member of the project team is assured, provided all conditions of the incentive program are met, a bonus of $7500. Those goals include:

a.  Meeting the 14- month timeframe to complete the project. Meeting the timeframe precludes the shifting of any part of the original project into a follow-on phase.

b.  Total project expense cannot, if the incentive rules are to be met, exceed the estimate of 3 1/2 million dollars.

c .  The quality of the project must meet the established and agreed- upon quality standards that were set at the beginning of the project.

It will be understood, as a part of the original agreement with the project team, that determination of the success of the project will be made by an independent third party. That determination will be based on the agreed- upon project time, function, and quality criteria of the project that were established at the onset of the project.

3.  In this example, if the project meets the incentive standards set for the project, the total bonus expense will be 18 x $7500.00, which equals $135,000.00. Success with this project will mean that the project will be delivered on time, on budget, and in accord with the established quality standards. Although paying the incentives will increase the expense of the project by $135,000 that can be considered to be a small price to pay for a project of that size delivered on time, on budget, and at a high level of quality.

4.  There are two other aspects to the example that should be recognized. One is that the total expense of the project, even with the incentive payments, is going to be less than that estimated if the project had run over and the contingency fund had to be used to complete the project. The other is that when completed, the project will have been fully completed. It is by no means uncommon to see IT projects, as they move through the development cycle, and begin to fall behind schedule, broken into “phases.” What happens is that some portion of the work in the original project is shifted to phase two, or perhaps phase three, in order that some aspects of the original project can be moved to production.

In developing the incentive plan, every full-time member of the project team, whether from the IT or the internal customer areas, should participate in the plan. The incentive shares should be exactly the same for everyone on the project. Providing equal shares to everyone involved will build a strong sense of teamwork.

In addition, as the project moves forward, the team should have the option to remove any member of the team (through a vote by team members) deemed not to be making an adequate contribution to the project.

One of the pluses of the inclusion of all team members in the incentive plan is, obviously, to ensure a strong focus on the project. Another plus is that it will be clear that, in order to share in the incentive plan, everyone is going to have to make a strong commitment to the success of the project and to work hard to meet the project goals. When the team focuses on the incentive to do the work well and on time, peer pressure is going to correct any difficulties associated with a lack of commitment on the part of an individual team member.

That increased project focus, particularly on the part of people in the business areas is bound to have a positive effect. One of the problems with IT project development is that of involvement in the project of those who request the project. Too often, the feeling outside IT is that the project is an IT project and those who requested the project have limited responsibility with the work or, with the results of the project. Moving to a clear financial incentive for everyone involved to pay appropriate attention and to help push the project can only be good for everyone.

It should be made clear that the installation and use of the IT project incentive plan is to reward people for going beyond the normal effort to make projects succeed. That being the case, people should understand that if they do not meet the standards established for the incentive plan, they will not be faced with the prospect of having their regular salaries or benefits reduced. Moving to the incentive plan should be based on the positive position of encouraging people to raise the performance bar, not as a potential club to change behavior. Indeed, if the incentive plan works as proposed, then over time, behavior is going to change; but those changes will come voluntarily — from the employees — rather than being forced on them by management.

The process must be clearly understood by the organization’s senior management and must be supported by that group. In order to gain the required approval, it is going to be mandatory that the senior management group be fully informed of the plan, why it is being recommended, how it will work, and the potential pitfalls associated with changing the way IT projects are funded.

MOVING TO A NEW APPROACH

When the criteria for the IT project development project incentive plan have been identified, documented, and approved by senior management, the next step is to begin to install the process. Moving to the process should be done in a careful, controlled manner. To begin, a project should be selected as the pilot for initiating the plan. As with any pilot, the goal is to prove the feasibility of the process with a successful implementation. Whoever assumes responsibility for the project must do everything possible to ensure that the pilot will be a success.

As with any pilot approach, the first project under the new compensation incentive plan must be very carefully managed and controlled. Two goals should be considered in developing the pilot. First, it will be important to have the pilot succeed in order to convince those with doubts that the process has merit. The reality here is that this is going to be a plan to sell the concept, and whatever needs to be done to strengthen

the probable success of the sale should be done. Toward that end, the project selected should be small enough so that it can be easily managed. Another advantage to starting with a small project is that it will not require an excessive amount of time to come to conclusions about the value of the process.

Second, the employees who take part in the pilot must be convinced of the merit of the plan. They must also be enthusiastic about the potential value of the approach and be willing to work hard to make the pilot succeed. Obviously, the selection of the people to participate in the pilot should be very carefully managed.

Although this will be the first attempt to use the incentive plan, it is going to be critical that as much work as possible is completed on the details of the approach to be used prior to beginning the pilot. Given that this is going to be the first time the incentive plan is used, it will be impossible to cover every detail. However, taking the time to think through the issues associated with the process, and addressing as many of those issues as possible at the onset, represents the correct approach. There will be items to be adjusted, added, or corrected at the conclusion of the pilot. That adjusting process will no doubt continue through other projects as more is understood about what works and what does not work; but the more that can be addressed prior to the introduction of the pilot, the better for everyone.

THE BENEFITS OF THE APPROACH

A number of benefits are going to accrue from the use of the incentive plan. Some of those benefits are going to be easy to quantify — hard benefits. Some of the benefits are going to be more difficult to quantify — soft benefits, but they are also going to be important and should be recognized. It will help to identify benefits in both categories.

Hard Benefits

-   A reduction in the expense and time associated with the development of IT projects, and the ability to move IT projects through the development cycles at an increased pace

-   The ability, as the result of the process, to produce more IT project work without a concomitant increase in the size of the IT staff

-   Increased, measurable levels of IT project quality, including an improved understanding of the project in those areas that have requested the work

-   Over time, an improved willingness on the part of the organization’s senior managers to support new IT initiatives

Soft Benefits

-   An increase in the overall level of the work, and the quality of that work, produced by the IT department

-   Improved morale within the IT department (This is will occur for two reasons; of course, the opportunity to obtain additional income is going to be a positive factor. Also, as the process gains acceptance, the performance bar is going to be raised. As people see that by properly focusing on the project, they are able to accomplish more and they can take more satisfaction in their work, they will be motivated to reach higher levels of performance.)

-   A probable lowering of IT personnel turnover as the benefits of the process come to be understood (People like to do good work, and to gain a feeling of satisfaction from the work they do, as the level of IT performance rises, people who might have left are going to be encouraged to remain.)

-   Increased teamwork and communication between the IT department and those for whom the department does development work

-   Improved levels of IT service throughout the organization -   An increase in the levels of IT service to the customers of the organization

DEALING WITH THE CULTURAL ISSUES

Considerations about moving to an IT project development incentive program should include careful thought about the cultural issues involved in making the transition. Going to this new approach means change. Whenever change is introduced within an organization, it brings out issues that will have to be recognized and resolved. Many of the issues associated with a new compensation approach to the development of IT applications projects have been identified in this portfolio. That is not to imply that additional issues will not arise; every culture is different and each presents its set of unique concerns.

The salient concern, relative to the cultural changes involved, is to develop an awareness that they will create some level of discord and that as they arise, they need to be addressed. Those concerns that are raised should be given a fair hearing and carefully considered. Much of what is going to be done here will probably be new to the organization, and as such it should be recognized that it will require time and some adjustments to come to a sound approach.

One of the cultural issues certain to arise is that of the fairness of providing people working on IT development projects an opportunity to earn additional income. This is going to have to be explained within the context of why they are being given additional consideration for what might be considered “normal” work. One way to address this issue is to explain the benefits that are going to accrue to the organization if the plan is put in place and it succeeds. Another way to help this situation is to develop a process that will, if the plan proves workable and is adopted, allow others an opportunity to join projects in the future.

As has been indicated, an underlying issue with the plan is that the project team, in order to obtain the additional income, is going to have to put forth extra effort to meet its goals. As people come to understand that getting the additional payments requires extra effort — in some cases, considerable extra effort — some of them are going to lose interest in becoming involved.

There will be some element of inherent unfairness in moving to a compensation incentive program. However, if doing so makes good business sense, the plan should be put in place. The difficulties associated with some level of employee discontent at the onset are going to be more than overcome by the eventual success of the process.

An important key to dealing with the cultural issues is for management to be as candid and as fair about the process as possible. When disagreements arise, if the managers are willing to take people through the logic of the plan and answer any and all questions as fully as possible, they will have discharged their responsibility. At that point, the onus for accepting or rejecting the process resides with the employee.

CONCLUSION

If the correct environment is developed, the right people are chosen to participate, and the compensation incentive plan is well- managed, it can produce benefits (perhaps significant benefits) for the entire organization. Putting the plan in place, overcoming whatever difficulties may arise, and documenting the result will take time and patience. Several versions of the process might have to be tried to find the best approach for a particular organization.

The potential payoffs within the plan: improving the quality of IT projects, bringing those projects to completion on time, and within the original budget, should be seen as of paramount importance to the IT department and to the organization. Achieving those rewards is worth the effort required. They are also worth enduring any cultural strains that may have to be faced and overcome in order to reach the desired goals.

The subject of changing IT development project compensation should be considered on the basis of risk versus reward. Using that approach, a favorable argument can be quickly developed that balancing the risk (the approach fails) against the reward (significant improvements in IT project management), there is no reason not to move to a changed compensation plan. New ways must be found to improve the IT project development process; going to a new compensation approach represents a sound way to move toward that improved environment.