Scope creep happens when what a service provider thinks they are delivering (and is in the process of developing or implementing) gets changed by the client at short notice demanding that extras and changes are infiltrated into the specification.

I don’t think it is so much scope creep as scope blur, when one blurred view of one set of the client’s requirements is replaced by a different blurred view of a different definition of requirements.

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 sign off) and which was detailed enough for the developers to take up.

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 or she has signed off (and is responsible for) will not actually meet the needs of his/her business because A, B and C are wrong and X, Y and Z—which are essential—haven’t even been included. There then ensues the prolonged and undignified spectacle of some people trying to change the project close to implementation (the client) while others try to resist (the supplier);  blame and recrimination are thrown around;  stress rises;  profit drains into the sand;  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/her needs don’t do a good enough job.  Sorry.  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, these 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, if the client changes his mind, it is always the consultant’s fault.

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.

This is a perfect, and entirely true, story to illustrate some of these points.

And another story—this time a fable.

Related material:
>  How can my business deliver above average service?

by Jeremy Marchant . This blog originally appeared on Ron Rosenhead’s website.