Requirements Modelling and Specification for Service Oriented Architecture

1.1. Why Projects Fail

The Standish conclusions are further illuminated by the data represented in Figure 1-1, which shows the fate of US defence projects Connell and Shafer, 1989). It must be remembered that these systems were mainly mainframe systems written in languages such as PL/1 and COBOL and it may be unfair to make a comparison with systems developed with modern tools. However, the point that something was wrong, even back then, cannot be avoided. Furthermore, the modern evidence seems to suggest that, sadly, not that much has changed.

Figure 1.1. The outcome of US defence projects according to US government statistics.

The Standish surveys also looked into the reasons why people involved in the sample projects thought such projects fail. The reasons given included, inter alia:

• lack of user involvement;

• no clearly stated requirements;

• absence of project 'ownership';

• lack of clear vision and objectives.

Why should this be? If the cause really is lack of user involvement (leading to the other three) then we must ask why users are so reluctant. If the system is worth building (and paying for) then, surely, it must be worth spending some time to ensure it does what the user really wants. Is it because they have had bad experiences with IT in the past, perhaps?

Could it be that previous projects involved copious amounts of time spent with that clever C++ programmer (you know, ...