03 March 2007

Scope Change

Having been a researcher in computer science until recently, and despite fairly extensive programming experience, I had actually never written a program for a client other than my own self before. In my new job as a programmer at the IT branch of a well-known industrial group, I was given the responsibility to develop an internal project all by myself, from negotiations with the customer over drafting specifications, to implementing and deploying the working system. Apart from actually building the system, this was all new to me, and, being interested in those other aspects of the software development métier, I started the project with good spirits.
One of the issues I'd been reading about, and was being warned for by my more experienced colleagues, was scope change: if not watched extremely carefully, the scope of a software project may balloon uncontrollably into all directions simultaneously, until it integrates everything in sight with everything else in or out of sight and makes the whole world happy. A project where this happens can quickly degenerate into a mission impossible in which lots of money get pumped, and lots of work gets done, but nothing actually happens. Not to mention making the deadlines.
Sure enough, not long after writing and agreeing on the initial specifications and project timing, I got requests from my customer to modify specifications, add things, etc. In between the itoldyousos and tokens of sympathy from colleagues that had been down the same road, I started thinking about the requests I got from my client. Comparing them with the way I worked before at the university, where I gradually fleshed out my own specifications while already starting to program, I actually found my client's requests to be quite reasonable. Essentially, they each fell into one or several of the categories below.

Communication issues

Clients are not programmers, and they speak a different language than you and I. While I consider it my task to translate between the client's language and mine, and try my best at it, I often do not succeed in getting it exactly right, at least not from the first time. This starts with names. Do you call the same things by the same name? In my current project this is not the case; I give names to parts of the project that they don't. The same names they use cover a larger part of the project than when I use them. But in this case, we know the differences in nomenclature, and we can "translate" on the fly. This even allows for the odd joke every now and then.
Usually though, follow-up discussions will often be needed to "put the dots on the i". I wouldn't call these scope changes per se, because I see them as further establishing the original scope, even if the project has been going on for a while. However, in that case they may have the same effect as an actual scope change, causing lots of work to adapt the current state of the system to the desired state.

Vagueness

Every programmer knows that in order to arrive at a working system, even the smallest part of the specification needs to be concrete and explicit. Often, things that seem clear initially, both to the customer and the developer, may turn out to be too vague to implement after all. Decisions relevant to a program's behaviour, and thus relevant to the customer, need to be made even at the level of the individual statement, while coding. I don't think they can all be made in the initial stage of a project, so that the client will need to be involved during coding as well to resolve these issues. Here too, I wouldn't call these scope changes per se, but again they may have the same effects.

New opportunities

My current project is composed of one central component that generates reports for different groups of users, and several other components that receive reports from the central component and distribute them to each user group in a specific way: by sending e-mail, through HTTP,... One part of the project involves cleaning up expired reports. This part was well-defined in the original specifications, but when new groups of users and methods of delivery were added, the cleanup part could be specified in a new, more elegant way that covered all delivery methods better and more uniformly than the original specification.

Unforeseen problems

Many projects I've worked on, both software projects and other projects, have needed adjustments along the road when certain ideas turned out to be impractical or impossible to implement. I think it is impossible to predict all circumstances in the specification stage. Except maybe in the NASA space program, but their kind of budget is not what most software projects have available. Some of these problems can be considered programmer problems, e.g. when they concern purely technical decisions, but others can lead to changes in the overall system design, and in that case they may be considered scope changes.

There are probably more classes of scope changes, but at least the ones mentioned above seem to me to originate from the limits of human communication and the human intellect rather than the client "not knowing what he wants" or something similar. Sometimes they may be oversights by the client; sometimes, you yourself may have overlooked something.
In any case, I think scope change is unavoidable. Moreover, I have actually come to think scope change is a natural phenomenon, that we should try to incorporate in the project flow, rather than try to combat. Of course, there will always be the borderline client who puts unreasonable demands on his developers, but they should not constitute the majority of software customers.
In my case, I'm trying to work with the client by drafting, for each "scope change", a document which details the reasons for change, the new problem/solution description, and how it affects the current state of the project. A brief estimation of time required rounds out this document, and indicates to the client what the actual impact is of what he is asking for. More administrative work, yes, but I think the client will appreciate knowing where his money goes to and what the touchy areas of a project are. Plus, they make fine additions to the project's documentation.

Labels: , ,

2 Comments:

Anonymous said...

test

06 March 2007 18:06  
Jeff Staddon said...

Excellent thoughts! I like the concept of scope creep as a natural phenomenon that should be formally included into project plans. After being involved in numerous small projects over the years I agree completely. I normally include an informal creep element in projects I work on. (Typically they aren’t big enough for formal planning which is good since it would be hard to defend a 30% creep number!)

I would like to expand on the “New Opportunities” concept (which I like to call the "I just thought of a great idea" scope creep.) On the surface this type of creep can seem to be the most “evil” of them all since it is completely unnecessary. But, it’s also the easiest type of creep to manage. When a customer is asking for more they usually go into sales mode and overplay the importance of the new feature. (Part of that is an effort to convince themselves) Deep down inside the customer knows new features always “cost” and they are a little afraid of how much it does cost. (And afraid of loosing their great new idea and perhaps looking stupid in the process) So, in spite of the rhetoric, customers usually appreciate an honest cost analysis and more importantly, affirmation that they did have a good idea. (Even if it turns out to be too expensive to implement)

Also--New Opportunities (if implemented) tend to become the things everyone gets excited over and becomes the main selling point of a new system. So don’t suppress them—they can be worth their weight in gold.

I really appreciated this article, keep up the good work!

08 March 2007 18:52  

Post a Comment

<< Home