Business-focused custom software

Go Back

Why the scope creep monster doesn’t frighten me

Most independent programmers have a fear of scope creep. Actually that’s not completely true. Most have a fear of scope creep they won’t be paid for. For those who are doing a fixed bid project, the fear is that expanding scope will eat away at any profit until they are making about $1.30/hour. Yikes.

To compensate, some programmers get very aggressive about delineating project scope. They become militant when even a small feature change is suggested. And I have a lot of sympathy for that position.

But I don’t share it.

Look, everyone I know who has been in this industry more than a couple of years has experienced a bad project. A project where everything was out of control, no one knew what the project was supposed to include or exclude, and the customer was frustrated because the project manager kept saying “that’ll be $1,000 more”. Ka-ching. I’ve been there.

But the truth is: if you don’t have a true partnership with your customer, where you both trust and respect each other and want the project and the relationship to succeed, scope creep is just a symptom of a much larger problem. And you aren’t going to solve that trust deficit by telling them that every little feature will cost extra.

Yesterday I met with a customer to show them an updated version of an application I am building for them. The system is light on specs, because we are basically re-implementing an existing Access application using .NET. I’ve been focusing on the former Access application itself, but there are some basic Access features they need as well. And we talked about them.

No I’m not going to re=create Microsoft Access. But I am going to give them some additional functionality that we didn’t specifically identify initially. That is okay. I trust them to not ask me to lose my shirt on their project. And they trust me to tell them when I feel that they’ve crossed the line.

And I’m not saying that programmers should give it all away. If you ask any of my customers, they will tell you that I often charge extra for changes in scope. But not always.

The bottom line is that software projects exist to solve business problems. If the project doesn’t solve the problem, then I haven’t done my job.

  • Facebook
  • Twitter
  • Digg It!
  • StumbleUpon
  • Technorati
  • Reddit

Comments  2

  1. Peter Edstrom 08 May

    It is true that software projects exist to solve business problems. But it is also true that sometimes (often? every time?) no one on either side of the equation really understands how big, how hard, or where the problems will be. You can estimate, you can approximate, and you can look at the past to have a good idea of how it _might_ happen, but at the end of the day it is still fortune telling.

    Think about it this way: A project took 100 hours to make and then the entire thing was lost when a harddrive crashed. How long does it take to rebuild? 20 hours? 30 hours? The reason it doesn't take 100 hours again is because 70-80 hours of the time was spent _discovering_ how and what to build, not building it. It's hard to reliably predict a project when the bulk of the effort is in its discovery.

    From a business perspective, I quite like the tangibility and finality of the fixed bid. From a developer perspective, I'd vote time & materials every time -- with open, honest, and frequent communication to keep expectations in line with reality.
  2. Avonelle Lovhaug 09 May

    @Peter - you are absolutely right that in some cases it is impossible for either side to really understand the full scope of the project. And I'll also admit that the larger the project, the more difficult it is to effectively estimate.

    I understand the allure of time and materials work for developers. Everyone wants to feel like they are being compensated fairly. But tracking the hours doesn't really provide the full picture. Your 100 hour project might take me 120 hours if I have a lot of interruptions (so I lose my train of thought and have to ramp back up again.) Should the customer pay extra because my schedule makes me less efficient?

    While charging for projects on a fixed bid basis has not been without its risks, I'm still quite happy with the results. I think it has been better for my customers, and it has definitely been better for me.
Post a comment!

Formatting options

Wanna Subscribe?
Here's the RSS Feed

What the critics are saying...

As someone with over 20 years of software development experience and currently a small business owner, it has been a pleasure working with Avonelle. In addition to being a talented developer, Avonelle also has database expertise and system design skills. Avonelle is open minded and willing to discuss various methodologies for achieving a project goal. She is also not afraid to ask questions which is vital in a software development project. Her up-front project cost (not estimate) is very helpful in budgeting for a project.

--Dwayne Wolterstorff, Owner @ Fair