Digital projects scope, feature or requirements creep – everyone's nightmare

A lot of people really don’t like the word control.

It has such negative connotations in general and it implies squashing creativity. When you apply it to digital projects - or try to - it seems to be top of the list in job requirements. We have to accept that in our creative industry control in projects is highly important for the sake of the business. To put it frankly, without control the money coming into the business disappears into the æther. You end up working for nothing if the client takes control of your project, if they insist on getting more than they had implied at the start.

We can see from the title that project creep has been called different things. We need to understand that just because our processes for development might have changed over a few years, project creep remains a big issue. So even if you have moved away from the old waterfall approach to defining projects (that arose out of IT practices with its requirements specification and functionality specification) to Agile responsive development, or anything in between, or composite of these: whatever you call it, project creep still exists.

Llew Jury implies the waterfall approach to project creep in his blog, Scope Creep on Digital Projects (17.1.13) but gives a clear case about scope creep. Frank Cervone is very readable about an Agile control process in his presentation Lightweight project management for digital development projects (17.1.2012). See slides 27, 28 and 45 particularly.

Back to control then or maybe we should be calling it client expectation management as per Frank’s definition. Whatever approach you use, you need some control processes in place. Now these have to be agreed upfront or the client will move into a push cycle without the fear of penalties: just what you don’t want. The answer has been different for the different development processes. The older style approach advocated the time, cost, qualitytriangle where you educated the client that if they asked for anything that affected any one of these parameters, the other two would have to change. This can still work across all projects although it may be implemented differently.

In Agile development the client needs to agree that the bite-sized pieces of development (called sprints) that they agree to will be paid for even if they change their minds about needing them. The work can be redundant or altered but the time and effort to produce them has to be paid for. The project manager or team leader in Agile has a responsibility to protect the developers from any interference from the clients during a sprint.

Yes, these links are oldish in digital terms but this creep issue has not gone away. We shouldn’t dismiss advice when we think it is a bit dated. We need to think it through and apply it to now. We are all a product of previous world-experience whatever we would like to think. Just to reinforce that this is still a current issue take a look at Rachael Greene’s, A Good Scope Today Keeps the Scope Creep Away (27.8.13), and some tips for avoiding creep from Tim Ballard, Feature Creep (12.3.13).

Then if you really want to get to grips with this nasty issue (especially good in prep for any job interviews in a digital position) there are a series of articles in the PM Hut’s blog on Scope Creep.

Sweet dreams!