Phased releases allow a company to reduce risk, increase buy-in, and build a system that is closer to the company’
s business needs. The lower apparent costs may make
a “big bang” approach appear desirable, but the hidden costs and greater ris ks may prove unacceptable in the longer term. It is vital that management involved in this decision carefully weighs the costs and risks of either approach.
CONCLUSION
When beginning the review of large complex systems, the author’
s first thought was
that the most important thing to do was simply to figure out how to eliminate the complexity. Based on the two years of review, the author is convinced that eliminating the complexity is not possible. One needs to accept complexity as a part of the systems development world for the future. The size of projects that affect the enterprise as a whole tends to be large and it will continue to increase. A project that affects the entire enterprise will increase complexity. Only when one accepts the complexity can one come to grips with managing that complexity.
Finally, today’
s business environment — with its increasing focus on business partners, virtual enterprises, and the global span of business — makes complexity a reality that cannot be overcome. Delivering quality solutions in this environment must start with a recognition that complexity is inescapable. From that point, then one initiates a set of strategies to manage the complexity and risk. There is no
“silver bullet” in these strategies. The three points discussed in this article are examples of such strategies. Each one of them is necessary; but none of them alone is sufficient to guarantee success. From a base of well-defined and -directed strategies, managing the ongoing complexity must become the focus on management in such large complex systems.
Chapter 33: Developing IT Projects on a Pay-for-Performance Basis
John P. Murray
OVERVIEW
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 chapter 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’