Originally posted on 02Feb10 to IBM Developerworks where it got 15,259 Views
On the Wednesday of the week before last (the week before my leave) at about 1am my time, I got an urgent request for a RFI response to be presented back to the customer at Friday noon (GMT+8 – 3pm for me – 2.5 business days for the locals in that timezone). This RFI was asking lots of hypothetical questions about what this particular telco might do with their Service Delivery Platform (SDP). It had plenty of requirements like “Email service” or “App Store Service” and so on. These ‘use cases’ made up 25% of the overall score, but did not have any more detail than I have quoted here. Two to four words for each use case. Crazy! If I am responding to this, such loose scope means I can interpret the use cases any way that I want. It also means that to meet all the use cases (14 in all) ranging from ‘Instance Messaging Presence Service (IMPS)’ to ‘Media Content and Management Service’ to ‘Next-Generation Network Convergence innovative services’ the proposal and the system would have to be a monster with lots of components. The real problem with such vague requirements is that vendors will answer the way they think the customer wants them to, rather than the customer telling them what they want to see in the response. The result will be six or eight different responses that vary so much that they cannot be compared which is the whole point of running the RFI process – to compare vendors and ultimately select one to grant the project to.
On top of the poor quality of the RFI itself, the lack of time to respond creates great difficulties for the people responding. ‘So what, I don’t care, it’s there job’ you might expect them to say and to an extent you are correct, but think about it like this: A short timeframe to respond means that the vendor has to find whoever they can internally to respond – they don’t have time to find the best person. A short timeframe means that the customer is more likely to get a cookie cutter solution (one that the vendor has done before) rather than a solution that is designed to meet their actual needs. A short timeframe means that the vendor may not have enough time to do a proper risk assessment and quality assurance on the proposal – both of which will increase the cost quoted on the proposal.
All of these factors should be of interest to the Telco that is asking for the proposal because they all have a direct effect on the quality and price of the project and ultimately the success of the project.
I know this problem is not unique to the Telecom industry, but of all the industries I have worked with in my IT career, the Telcos seem to do it more often. I could go on and on quoting examples of ultra short lead times to write proposals – sometimes as little as 24 hours (to answer 600 questions in that case), but all it would do is get me riled up thinking about them.
The whole subject reminds me of what my boss in a photolab (long before my IT career began) would say “Quality, Speed, Price: Pick two”. Think about it – it rings true doesn’t it?
