Publication Date: 11/11/2008 9:49:57 PM
If you are involved in a programming project, sooner or later you will hear about creep – scope creep, that is. Typically, the conversation happens about half-way through the project, and it is an ugly feeling.
You: It is important that the system include the [abc] functionality.
Programmer: [ABC] feature wasn’t included in the proposal/requirements/design that you approved, so this is scope creep. Pay me more money for this feature.
You (mumbling): Now I know who the creep is!
This is a very common problem – more common than any of us would like to admit. And it can leave both the programmer and the customer feeling unhappy.
There are a lot of reasons for scope creep:
It is easy to blame the programmer – after all, this is their business, and they should know what questions to ask, right? However, programmers are often not subject matter experts, and they don’t always know what they don’t know. And what can seem like a perfectly reasonable assumption by the programmer can turn into a big problem during development.
That doesn't mean programmers are blameless. Sometimes a programmer will make an assumption that they shouldn't have.
In part 2, I will explain how minimize the possibility of scope creep, and things you can do to mitigate the problems when you discover scope creep on your project.
Think like a geek
Your URL (optional):
Type the code shown
Top 5 Programmers to Avoid
What everyone should know about bugs
How to tell if an estimate sucks
The Secret to Building a Crappy User Interface
The Problem with Selecting the Lowest Bidder
5 Ways to Control Software Development Costs
Avonelle has been a pleasure to work with. Working with someone that you know will always deliver is tremendous.
Mark McNamee @ Renewal by Andersen
Copyright © 2013 Avonelle Lovhaug. All Rights Reserved.
Sitefinity ASP.NET CMS