Share This!

Sunday, September 16, 2012

Scope Creep: How to Go Out of Business.

Scope Creep.

It is the nature of our business that the fine details of what we need to accomplish are not fully known until we are writing the code.  Now and then, there is some element of what we are doing that we thought would take a few minutes (i.e. creating a scheduling screen) end up taking longer (because Microsoft decided that their DateTimePicker control cannot handle nulls, and instead displays today's date - bogus data).  Seriously - that one ate 2 days of coding time for me.

But the problem we encounter is that the client wants the entire project quoted up front, is not willing to dive into the details, and only reads the bottom line, and in their head, they come to understand only that "finished software" will cost $N.

So we work hard, trying to meet our deadline, and then we release the software only to receive a list of 200 items that they want changed.  Their expectation is that all these changes should be covered in the original cost you quoted them.  Even if you told them that the quote was an estimate and you were working hourly.  Even though none of the 200 items were anywhere in the specification that you painstakingly wrote and that they never read.

"You quoted me $8,000". They treat you like you're trying to scam them.  You know that if you let this get away from you, that you'll be working for free for the rest of your life every time they get an error message.  

This is called scope creep, and left unchecked, it will cause all your software projects to take forever, never release, and eventually die.  This is awful in a corporate environment, where a business unit just keeps drawing out the project forever because they are afraid that they have left something out, but it's even worse as an indy developer, as the client never accepts the release and will always refuse to pay.  Months of development time and now you're fighting them about what is and is not in scope.  Meanwhile you have bills to pay and you've put off other potential work to focus on this client. 

NO FIXED BIDS

Never quote any job, unless it will take less than a day as a fixed bid.  You're setting yourself up for a disaster.  They WILL try to keep you working forever under the terms of the original agreement.  You will become a slave.

WRITE EXACT SPECIFICATIONS

If your project spec says "Make an order entry application, 100 hours, $N", you are going to get the kitchen sink thrown into that project.

"Of course you can't have order entry without an entire ecommerce website, and inventory control and contact management, and integration with Quickbooks, and connected to the Weather Channel and an auto dialer and ...  That's just common sense!"
Your spec should say exactly what screens,web pages, databases, and all the rest that you plan to create.  It should specify what platform the app will run on.  If new equipment is needed, specify what kind of equipment and who will pay for it.  Make sure and state what is included in the estimate.  Later, when they come back and say "Hey, we thought it was going to do X", ask them what line item in the quote led them to think that.  Then offer to add that to version 2.

I once had a meeting with a guy that took 4 hours and was talking about a Visual Studio app, taking down his requirements to replace a DOS app from the 1970's.   We shook hands, I promised him a quote, and as we were leaving the room, added "of course this will run on Windows, Apple, Linux, smart phones, Ipads, and everything, right?"  When he got my quote back for all the time it would take to engineer for every possible platform, he had an aneurism.  But it would have worked brilliantly on his smart toaster.

GET IT IN WRITING

Write up - in mind-numbing detail - what you plan to do.  Make them sign it.  Go over it item by item - before they sign - and if they think you've left something out, add it.  Makes sure it says that this is the entire scope of the project, and once these items are met the terms of the project are satisfied.   Make sure it says that you are working hourly and the prices quoted are estimates only.  Make sure they understand that whatever changes they want afterwards will become a new project.


ARRANGE PAYMENT UP FRONT
Set a schedule for payment.  I know you're a coder and you don't like telling a client that they need to hand you a giant wad of cash, but you need to grow a pair and get comfortable saying it.  DO NOT be a nice guy and tell them, oh, it's ok, you can pay me whenever.  Say things like "We require $600 non-refundable up-front, and the rest is due 30 days after completion.  Just say it like "That's our policy.  We can't start a project without that."

KEEP THEM IN THE LOOP
Ok, so you're falling behind, because something you estimated has become a nightmare.  You're all over the internet trying to resolve some issue.  You promised them delivery - or a demo and the damned thing just refuses to coalesce.  You're working later and later into the night and now you're getting very late.  So you stop calling the client, because you are tired of telling him you're having problems and you are going to miss the schedule, and you think that just one more day and you can work it out.  Now it's been a week and you're still struggling.

The longer you put off telling them, the worse it gets.  You need to call them as soon as you realize there is a problem.  I know you want them to think that you are loaded with mad programming skillz, and this is like calling them to volunteer for a firing squad, but IT WILL ONLY GET WORSE THE LONGER YOU WAIT.  There. You have been warned.

UNDERSTAND THEIR PERSPECTIVE
When business clients outsource to a small contractor, they are worried if they can trust them to deliver on time and on budget.  They have to swallow that worry every time they  enter into a contract like this. They hand you their corporate data, and in faith they engage you to make their business better.  They have to quell that nagging worry that you are going to overcharge them or miss all your deliverables.   You need to work with that understanding.  Keep their expectations realistic.  Tell them they need to be involved in the design process.  Only by working together can you avoid the never-ending time eating path of perpetual scope creep.


...

Bryan Valencia is a contributing editor and founder of Visual Studio Journey.  He owns and operates Software Services, a web design and hosting company in Manteca, California.

No comments:

Post a Comment

Contact Us

Name

Email *

Message *