Sticky situations in sales negotiations
There is an oppressive silence hanging over the conference room. The Client has just asked a Question with a capital Q. The Sales Rep clears his throat nervously trying to search the eyes of the Technical Expert sitting next to him for any signs of help. Unfortunately the engineer is completely wrapped up in the wonderful world of applications architecture and module configurations and stares back with empty eyes.
The Sales Rep ventures "Maybe something like a hundred...", but notices the Client's eyes bulging and hurries to correct himself. "Maybe a little less, if everything goes smoothly and there's no need for lots of changes." Sweat pours down the back of the Sales Rep's neck, even though the air conditioning seems to scream through the uncomfortable silence of the conference room like a race car on the home stretch.
The ball is now in the Client's court. The Technical Expert stirs from his thoughts and turns his attention to the Client, who, by the look of it, has started to suffer from an acute case of heartburn.
This is not a true story. And even if it is, it happened a long, long time ago, and not to us. Sometimes we get asked for an estimate for the amount of work needed in a project, and in those situations it is courteous to at least try to turn the three bullet points the client has provided through email into a sort of backlog and send back an Excel lottery ticket filled with disclaimers for the client to mull over. Usually these guestimates are of no use to anyone, since the client doesn't normally know what they are buying, and we don't know what we're supposed to be selling.
The traditional procedure is that the client decides in advance what sort of application is going to be built, how it should be put together, and when it should be finished. Then they compile these specs, that have now magically morphed into the truth, into a project plan, which they proceed to mail to the party responsible for carrying the plan through. The supplier then follows the plan slavishly, strings together the necessary code and hopes that the client won't register too many complaints about the final product.
Nowadays things are thankfully different. All of our projects are run using agile methodology, which means true co-operation between the client and the supplier. By maintaining constant dialogue, we can learn to understand the client's business model, and together with the client we can weed out from the agenda all the features that do not directly benefit their business.
Implementing things in order of importance and launching them quickly is also financially smart. By building the most critical block first, conversion-wise, the client gets to enjoy the cash flow generated by their service, while we can still fiddle around with secondary pages. And all the while we are gathering user feedback that's worth its weight in gold and distilling it into workable improvements for the service.
Agility is difficult to retrofit into a waterfall project model, whose details, up to the colors used to highlight hyperlinks, might in a worst case scenario have been predetermined by the client organization's board of directors. A concurrent back and forth with professionals usually leads to a more cost efficient end result.
Don't hesitate to share your thoughts with us, and we'll tell you how a seed of an idea is cultivated into the best service you can provide.