Negotiating Schedules with Customers
There’s a thing I was thinking about and discussing a lot these days. When you take typical project for a big company the process looks usually like that:
• We want to buy a project doing something. Deadline would be end of the next year and it should cost no more than half a million.
• Let’s fire the formal process – RFIs RFPs, all those blah, blah, blah. There’s heckuva lot of time.
• Oh, those two offers look the best. We can have the solution delivered in 4-5 months since the agreement is signed. Pretty cool. We still have a quarter to sign that darn thing.
• No need to hurry, we can spend another half a year squeezing vendors (on the last stage the chosen one) to lower the prices, add features and shorten delivery time.
• Oops, it happened so, we used most of available time negotiating the offer and won’t make it by the end of the year if we follow the original vendor’s plan. Maybe dates can be squeezed more by a couple of months. Oh, yes, they can.
• Hey, the vendor singed the schedule which was cut by a half. What a stunning success!
• That darn vendor can’t keep the schedule. They’re always like that. I told you on the very beginning they lie with dates they’d shown.
Yes, the customer is the boss. Yes, the vendor dances as the customer plays. And yes, the customer is the one who actually pays the money. But above strategy isn’t the best one I’ve ever seen. Most of vendors agree to whatever schedule is requested because they want to settle the deal. It usually ends up with big deadline overrun which costs both sides.
I’d understand it if it happen once or twice, but sometimes I think that’s industry standard. I’ve seen too many projects squeezed by a half which, at the end of the day, had 200% time overrun. I’ve seen too many projects where “signing the agreement” milestone was moved several times while “ready to acceptance tests” milestone looked like it was written in the stone. I agree the situation is organized in a way which kicks the vendor more than the client, but that’s still a lose-lose scenario.
What is your experience in that area? Do you often work for customers who share accountability for deadlines with the vendor?


6 comments:
I know what you mean :) In my personal experience it mostly went wrong with the supplier internally: sales person gets commision on closing the deal, project delivery not involved in making the deal. result: unrealistic expectations. For one company they based the sales commission on the margin of the project at certain time intervals. HUGE improvements.
With customers it is classic that 80% of the time availeble is spent looking for software, so that 20% time is remaining to do the project :) has to do with Parkinsons, Student Syndrome, and most of all affraid to take a decision. :)
Area you point - discrepancy between sales and technical teams goals - is worth separate post, but fortunately in my current company things are great on that line.
I see it happen and it usually disappoints everyone involved.
I have worked with a few vendors who are dancing the balancing act of quoting low but not too low. When things change, as they do, they sweat.
It's a shame more people don't work collaboratively but everyone is tryiong to maximise their profit.
Actually that last thought makes me think of Rowan Manahan's latest blog post
That's very interesting perspective you mention. I haven't thought about the subject that way. I was considering the process rather as short-sightedness than purposeful trying to maximize ones profits.
You have just describe my life, man...
What I sometimes see is that companies bring in large Indian outsourcing companies, which are able to outsource quite a bit of work abroad (at much lower rates) and therefore are able to work with more people on the same project, therefore able to reach the timelines sold by the sales person. But one caution as well. It is also the responsibility of the procurement department to not delay and squeeze the vendor to much. In the end it needs to be a win-win situation for buyer and vendor.
Bart
Post a Comment