Publication Date: 5/8/2009 7:54:28 AM
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.
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 is a talented expert in her field. She has blended well with our team and built applications that we are proud to deploy to our associates. Her talents helped us execute a vision expediently and with quality. If we could do it all over again, we wouldn’t change a thing.
Peter Edstrom @ Renewal by Andersen
Copyright © 2013 Avonelle Lovhaug. All Rights Reserved.
Sitefinity ASP.NET CMS