It is very easy for feature creep to occur; to just add this one extra feature or to continuously change your mind about the architecture . It can be very disruptive and expensive if requirements keep changing and it can have disastrous consequences to a project.

If you have managed a large project then you will be familiar with formal change management. After the plans have been signed off they are baselined and any future changes have to go through formal change management. That means that you have to argue your case that the change is fundamental to the project meeting its objectives.

However agile methodologies teach that requirements are always changing and you should expect them to change, so how do you deal with these two conflicting points of view.

I sit somewhere in between these two points of view. We work in a very agile way, short iterations (sprints), constant client feedback and a very collaborative team effort. However in order to make profit on project you need to make sure that you do not overspend in terms of project hours.

We are very flexible in the design phase, will facilitate lots of rounds of changes and multiple routes to solve the client’s brief. Then again when we wireframe we keep to a very agile methodology, and it is relatively easy to change a Photoshop file or a HTML mock up.

However when we move from the prototype to the build phase we make sure that the client signs off on the work to date and then on try to keep changes to a minimum. Changes then have to be submitted in writing and may incur extra charges if they materially change the project time scale. That way when we get to the phase that is difficult to change we are not wasting time and money making lots of changes.

I do not think there is a one size fits all approach and the reality is that client requirements will change. The sooner you accept that the sooner you will find a way to make the job work.

No related posts.

Bookmark this page: Delicious Digg StumbleUpon Facebook LinkedIn RSS Feed