So here’s the story…I was called in to meet a new client from my SEO and marketing guy (and good friend), Derek from SquareDMarketing.com to help out one of his smaller clients. They had a simple need to set up a shopping cart on the web, and they were not happy with the implementation from their previous web developer. He was not really a programmer, and couldn’t provide the custom functionality they wanted to run their business. Unfortunately, the guy never really took the time to learn anything about the client’s business…thinking a cart is a cart…We arrived and pointed out where the missing functionality belonged, in this case, it was in affiliate tracking. OK, pretty darn straightforward…but the cart that they were using was CSCart, a PHP/Linux based cart….wrong platform for us, as we’re .Net developers. I explained to them that we would need to do a complete re-implementation using a cart that was on a .net platform since we had to do some custom work to make ANY cart fit their business (they were not willing to change their business workflow).
Based on our understanding of their needs, we came up with a short scope of work which was: move the existing cart, inventory, and data to the new cart, and then add the functionality to match up a customer with a referral source. Sounds like a simple “drop-down” was required to let the customer select the referral source, right. LOL!!!! Here’s where the big mistake started: I said these fatal words: “It’s easy, and shouldn’t take very long at all”.
Derek then looked at me across the table, and said innocently enough “Do they still need to pay for the scope and discovery work?”…and I, unfortunately, said: “No, I get it, and I don’t think that’s necessary.” (Note: Don’t EVER say that, either!!!) The fact is that I “thought” I understood, but I didn’t take the time to ask more questions about how they operate…
So we agreed on a fixed price for the work, and I wrote up a really short bulleted work-order contract, and we did the work. We did a great job, too, BTW, and when we delivered it, everyone was very pleased! (Right up until they started using the new implementation, and asking me “where is this feature?”.
You can probably guess how things went next: I said “what feature?”, and it was just a small thing, so I said: “Oh, we’ll just fix that…” (Anyone knows the rest of the words to this sad song yet?). Fast forward to a month later….they’re still asking where the “features” are, and I’m telling them that these things they were asking for was not part of the scope, and they just don’t understand!!! “You said it would do everything we wanted it to do…”
Needless to say, things went in a downward spiral, but I was not willing to “take a fail” on any project we engage, so I tried to provide explanations as to why I want to bill them an additional $23,000 to marry their web-cart to their inhouse fulfillment system! I even brought in competitors to get them other quotes to show them that I was not crazy, nor trying to extort money from them.
Finally, after a long meeting with another 3rd party vendor of pre-packaged software that will do “everything” they need, they came back to me and said something amazing: “We should have taken the time to build the scope so we could make sure everyone understands what we wanted.”
We have since built the scope of work, which covers every bit of functionality, screen layouts, deliverables (reports), etc. and have a plan, a timeline, and a “fixed” price.
Here’s the moral of this long story:
You can’t build a building without an architectural blueprint….just like you can’t build software without an architectural plan and scope of work. This is the one corner that everyone wants to “cut out” in software development, because it’s perceived as an additional, non-required expense, especially to those smaller clients that have never worked with developers to create a custom system.
Our scope and requirements document provides the client with a checklist of all items that we are contracted to build. It explains how things work, how information moves through the company, and how this system may integrate with other systems in use at the company.
The act of scope and discovery forces us to learn about the company. We spend time with the employees and watch them work to understand WHY the client is asking for specific features and functionality. WE MUST UNDERSTAND THIS IN ORDER TO BE SUCCESSFUL SOFTWARE DEVELOPERS.
Unfortunately, this work DOES take a lot of time. We usually allocate no less than a 2 week discovery period, but at times it may take 6 weeks or more. This IS part of our job, and it’s important to communicate that to the client, and it’s also important for us as developers to know to “walk away” when the client refuses to comply with the scope and requirements process.
I want to be a nice guy. We all do. But what’s more important to me is keeping that track record we have 100%, satisfied clients. Taking the time to learn is the ONLY answer. I hope I learn from this mistake I made, and I hope you can also take something from my words here. Love to hear your comments!