Spec’ing Out A Project
We’ve been talking a bit about the process of taking on work – be it internal or external. Part of the key is setting expectations and defining what you need.
From Ralph: "K.J. said ‘5:The IT vendor foots the bill for work effort required for creating the fixed bid, and verifying that the specifications are satisfactory for the vendor to produce the bid."
In the past, I have dealt with customers who would provide what, to their way of thinking, were "satisfactory and complete" requirements but were not, in fact, sufficient to actually determine what had to be done to complete the project. In some cases I spent many hours trying to determine what was required based upon those "specs" only to have to go back to the customer and walk them through creating actual requirements documents. One customer that I dealt with was so consistently lax in developing requirements (with the expectation that I would eventually do the interviewing and requirements development) that I finally had to start requiring a "time and materials" contract for just developing the specifications. (The time and materials contract derived partially due to the fact that they occasionally gave the work to someone else after I developed the requirements and then had to try to get some of my time costs back in my bid while the other guy had no up front investment to recoup.)
If you are dealing with an organization that has the sophistication and man-power to develop decent requirements documents, then I agree that the vendor needs determine whether the requirements are sufficient and work up the bill as a cost of doing business. However, if the organization is not really familiar with IT projects and the requirements development phase, then the vendor may have to provide assistance and guidance in developing the requirements and, frankly, that is a consulting process that needs to be charged for, IMHO."
This whole idea of them (the customer) paying for the consulting/definition process is something I’ve done with customers many times. Usually unsuccessfully. 🙂 Most people don’t want to pay for that, they consider it part of the bid process. Unfortunately, in a bid-type situation, you’re actually faced with presenting a document that can be put to work – can be used to define the project for the other guy and that might not be something you’re willing to give away. I’ve had this several times where I’ve had to take the time to spec out a project, then essentially "dumb-down" the proposal so it defines things enough, but doesn’t give away the farm. A very fine line.
Where I have had success if outlining the project in this manner, then including in the proposal an "out" – after they select their vendor, we get the opportunity to present the solution we based the bid on (assuming we were successful bidder) and everyone agrees that that’s what we’re doing. At that point, we can already have built some compensation into the project to cover the discovery and definition work. Slightly different, but at least you’re not feeding your competition so they can bid low, then use your discovery and definition and scope and approach in their work.
Might be a bit cynical, but it works well, usually.
Featured White Paper(s)
Overcoming the Barriers to Business Intelligence Success
Read this EMC Perspective, Overcoming the Barriers to Business Intelligence Success, and learn how to create complete Busines… (read more)
Windows PowerShell: Why Developers Should Care
Windows PowerShell is Microsoft’s next generation scripting and shell tool. Find out more about this tool and why its importa… (read more)