Business-focused custom software

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.

What happened?

There are a lot of reasons for scope creep:

• The programmer spend enough time asking all the right questions.
• The customer provided incomplete or incorrect answers to the questions that were asked.
• The customer changed their mind, most likely because they didn’t fully understand the implications of their original choice.
• Miscommunication between the programmer and the customer.

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.