Jaisunder Venkat posted a clever blog on scope creep recently which got me thinking.
I have been burned by scope creep in the past, so I am very careful to emphasize this issue when quoting/starting any new project.
Scope creep can get you in many ways.
As a sales guy/project manager, I gather some detailed requirements. I consult with engineering to determine the hours required to get the job done [done right]. I give the customer a quote.
So, we start the project and the customer changes the scope.
My first challenge is to price what the change will be. Then I have to sell the price change to the customer. This often requires me to explain why this change entails extra work. This is never easy – now my customer has to get a change to the purchase order approved.
On my company’s side, I have to speak with engineering to get them to take on this new scope. As you might imagine, this isn’t always received with great enthusiasm. When discussing scope creep, I always explain to my customers that it is very difficult to code to a moving target.
Changing the scope only one time may be something that you can get through without a lot of trouble. However, multiple changes can push the patience of both the customer and the developers. What started as a very cool project can become a real headache.
My advice, make sure that you have a scope creep discussion with your customer. Consider it an integral part of expectations management.
What has been your experience?