One of the problems that gets blamed a lot for project failure is 'scope creep'.
Scope creep is a diplomatic way of saying that management don't know what they want from a project and keep on changing the requirements until the whole thing falls apart in an exciting blame explosion. Invariably when this happens the project manager is fired, the actual requirements are finally documented, and the project pushes on to either success or another iteration of the scope creep spiral depending on how much work remains.
There are all sorts of tools and techniques that can help manage this exact situation, ranging from strict and formal change control processes in the waterfall model to the 'deliver before they can change their mind' approach of agile practices.
These tools help manage sponsor induced change, but laying the blame for scope creep at the feet of managers is not always fair. Project staff can be guilty of introducing change too as I shall demonstrate.
On a related subject I went to the XForms user group last night. The guys from WebBackplane were demonstrating some very neat functionality in Ubquity that would be quite useful for The Plan Is. I found myself thinking 'you know, if I just made these few changes here and there, I could use this...'
Scope creep warning! This change would simplify the internal structure of my application, but the solution I have works and is tested.
This kind of technical rework is vital in the long run, because it makes the solution more complete and maintainable. However in the short term:
- It costs time and often money.
- It introduces risk, especially of new bugs, which cost time and money to fix.
It's not just technical staff who do this kind of thing, departments such as Customer Service will often use a project to try and slip through 'small' improvements to existing tools. In big companies this kind of behaviour is justified by pointing to a lot of different types of organisational dysfunction. People who feel like important work is being overlooked will try and fly the changes they want to make into the project under the radar.
I don't have this problem - it's just me after all. I set the priority and the feature list for each release based on customer feedback, so if I feel that something really needs to be done then it can be scheduled in. The fact that one person working on their own can also be tempted into letting the scope creep without properly thinking about the costs and benefits suggests to me that it might be something we blame on the organisation rather than something that is caused by it.
What should project managers do about this tendency for everyone to expand the project? For my project I'm going to attempt to stick with a relentless protection of project scope, get out version 1, and then schedule the time I need to properly assess what's important for the next iteration. Do that a few times and the good behavioural pattern might get ingrained.