 |
|
|
 |
||
 |
||
 |
||
 |
||
 |
||
 |
 |
|
 |
||
 |
||
 |
||
 |
||
 |
||
|
||
 |
Your independent resource on business integration and network computing through middleware and message brokering
IT and middleware project success: an unscientific survey
Peter Bye
Consultant
Unisys Systems & Technology
Management introduction
There is a widespread view that IT project failures are common, with complete success (on-time, within budget and full functionality) all too rare. However, a recent article (Note 1) questions the pessimistic picture of failure - or only partial success - painted by, for example, the Standish Group. It also points to other sources as doubting that all is quite as bad as some people think.
In this analysis Peter Bye seeks to throw some additional light on the subject by considering the outcome of a number of IT projects he has encountered over some 40 years in the industry. These projects date from the late 1960s to the present day and are ones where his contact with them has varied between having worked on them as a programmer, manager or consultant, to a passing acquaintance only, where the project was entirely carried out by another company or organization.
Such a review is unscientific for a number of reasons:
he has not been able to treat each project equally, as what he knows about them varies
here are considerable differences in size
they reflect one person's experiences and contacts, and are not in any way selected to be a representative sample.
Figure 3.1: Projects covered, in summary
Management conclusion
This analysis suggests that perhaps IT project failure is not quite as bad as some suggest. Partial success may be viewed too pessimistically; such projects may meet all requirements when in operation, even though they are delayed beyond the original promised delivery and/or are over budget.
But there is no reason for complacency. The current state of the industry is unsatisfactory. About a quarter of this somewhat arbitrary selection of projects discussed in this paper failed. Examination of the reasons for their success, or failure, produces some common, interconnected themes...
Stable and well-defined requirements, including non-functional requirements such as performance, are critical. Lack of stability or completeness nearly always leads to problems. This is especially acute in large projects.
Estimating schedules and resource requirements is particularly difficult. Most of the partially successful projects in this analysis were subject to delays based on over optimistic scheduling. The earlier examples could perhaps point to lack of experience, but matters did not seem radically to improve with the passage of time, in spite of the availability of increasing numbers of estimating tools and techniques. Procurement processes (Note 3) do not help, as they tend to inhibit the necessary discussion between client and implementer, often leading to a 'lowest cost shoot-out'.
Well-defined, stable software/middleware environments that suited to the task in hand - and with a methodology for use - greatly improve the chances of success. Airline 4 was the first time I encountered this methodology/software combination, which is why I dwelt on it.
Implementation teams who understand the business requirements, architecture, and the technology involved are necessary. Methodologies and software/middleware frameworks greatly help, as noted above, but they are not a substitute for quality people. Two of the failures in the list of projects used well-defined software frameworks - JEE and .NET - and yet both failed to deliver.
The number of significant external dependencies should, where possible, be kept to a minimum. Having to deal with other organizations adds complications. In particular, relationships with software suppliers can be difficult with new releases, which may be unstable.
Packages are not always the best choice. Choosing a package, or even whether to use one, should be carefully considered. Questions that should be addressed include tailoring and how to handle new upgrades. Performance expectations have to be discussed. One of the delayed projects in the list was based on a package, by request of the client. The implementation of the requirements would have been better satisfied if delivered from scratch.
Finally, small to medium sized projects tend to be more successful than very large ones, as they are likely to be associated with the other success factors in this list. Very large projects should, therefore, be taken in small steps wherever possible, with frequent reviews of requirements and schedules, correcting for unexpected and changing circumstances.