The Spinosa Factor

I want to offer a word of suggestion to all web development firms out there not opperating on an hours based agreement or one that’s built in an “Indefinite Delivery, Indefinite Quantity” (IDIQ) contract that it’s important you 100% define the scope of your project before submitting a proposal.

To most this seems like common sense but it’s rarely implemented correctly mainly because firms only describe general features and functionality that leaves room for a large amount of ambiguity. There are two reasons for this.

1. Clients in the small business sector quite often don’t believe that architecting the solution on paper is worth anything, and that it should be included free within the proposal in which that can accept or reject.
2. Sales and Project Management teams are rushed, lazy, or unconcerned with the details only completion of the development agreement.

The first is VERY difficult to overcome when dealing with small to medium sized businesses as besides them not wanting to be charged for allowing the development to firm up the “particulars” they feel things move to slow and need to get the project in production quickly. YOU MUST SCOPE THE WORK.If you don’t you’ll only end the relationship in a flurry of unmet expectations and what will be percieved to the client as “over charging” or “extortion” in many cases.

The key to all strong relationships aren’t necessarily hugs and kisses up front but tough facts that create reasonable and fair expectations on both sides not just in terms of scope but deadlines and much more.My recommendations are this:

1. Try to get the statement or scope of work (SOW) to be billable and offer it as a thorough piece of technical documentation that can be taken anywhere to be used as a guideline for going into the development stages. This helps the organization immensely and all parties are satisfied that free intellectual property wasn’t given away.
2. Deliver proposals and review them together so that anything to technical can be clearly understood by both parties. Define fields, business logic, modules, and much more so that it’s not left to the interpretation of the human mind. It’s astonishing how two people can truly view the same sentence and I say this without any sarcasm.
3. Some small projects are easy enough to thoroughly scope for free and don’t abuse a structure or system. If a small component can be defined for the client it’s ok to offer that value back if it’s not really requiring you to use a large amount of your imaginative thinking or be very time consuming.

Nothing is worse than putting edges on a project at th eleventh hour and having to explain to a customer that it’s not in the original scope of work. Now imagine if you don’t have anything to back that up, you’ve created a relationship built on tension and I offer this to the outside world as a voice of experience 10 years deep in developing IT, development, and business based projects!