Why IT projects overrun…

… and how EI can help

As a consultant, I worked on many assignments for corporates, such as the BBC, EWS Railways and many others, where my job was to be the interface between the clients and technical staff. I had to define the client’s requirements for a particular major software development in a way that the client understood fully (and could signoff) and which was detailed enough for the developers to take up.

‘Scope creep’ is the term for that situation where the client starts asking for extra things in the system while it is being developed.  I believe scope creep typically starts when the client wakes up in a cold sweat, halfway through development—or often later—and realises that what he has signed off (and is responsible for) will not actually meet his needs because A, B and C are wrong and X, Y and Z—which are essential—haven’t even been included.

There then ensues the undignified spectacle of some people trying to change the project close to implementation while others try to resist; blame and recrimination are thrown around; profit is reduced (or lost altogether) and implementation is delayed.

I think it is worth accepting as a principle that the reason this happens is always and only because the people whose job it is to assist the client define his needs doesn’t do a good enough job. And this is because they do not understand about psychology, particularly interpersonal communication, and don’t have the skills (and in some cases even the inclination) to enable the client to realise what is really needed.

There is a second reason (but it’s actually a consequence of the first): the consultant (for want of a better word) is unable to articulate what has been agreed in a way that the client understands. The client doesn’t know that anything better is possible and won’t admit he doesn’t understand it. In any case, he thinks, we’re the client and we can change our minds later if we want. The consultant is only doing what his company and many others have always done. So, the requirements definition, or whatever, is signed off, with all parties unsure about whether it is fit for purpose. You don’t have to look further than the news of what happens to NHS IT developments to get this.

(Of course, projects get screwed up for other reasons—usually insufficient and incompetent testing and poor day to day management—but we’re talking about scope creep.)

Now, it’s not actually true that every instance of scope creep is due to a failure to define the requirements adequately before sign off. In the case of the NHS, for example, major project developments which straddle a general election are at the mercy of the new government’s different dogmas. Clearly, there are “acts of God” which create the need for scope change—though anticipating these can and should be part of the requirements definition. But these are so infrequent—and occur far less often than is necessary or believed—that it is worth taking, as a principle, that when the client changes his mind it is always caused by the consultant.

The solution, I believe, is made up of at least all of the following:

1  all parties need to understand why, and accept, that more time and effort needs to be put into preparation than they think. Extra time and effort invested now, saves 10—a 100—times that resource later (to say nothing of the stress and anxiety reduced)

2  a methodology is needed which demonstrably can shift the client from their initial position of “this what we would like” (which is what they usually end up getting) to “this is what we, as people, need” to “this is what our business/organisation needs”

3  the consultant must be that relatively unusual person of someone equally at home in, and capable of communication with, the technical world and the client’s world (I appreciate I am focussing on IT projects here, but there is nothing I’ve said which doesn’t apply to any project)

4  the consultant understands that all that knowledge and expertise required for (3) are as nothing if he/she isn’t a good coach. In addition to the methodology, a coaching approach is essential if the dialogue between consultant and client is to get to the heart of the matter. But neither is sufficient on its own.

5  the consultant has to be able to describe back to the client what they are about to sign off in a way that is crystal clear to the client—not just to the individuals involved in the work to date, but to others (like the CEO, perhaps) for whom the draft requirements definition might be their first contact with the project.

Learn more:
> Train : a perfect, and entirely true, story to illustrate some of these points.
> Drill : a fable.