I was struck by Dan McLean’s column in the August 24th edition of ComputerWorld Canada. In it he chides his sister’s company for not holding the “SI to the flame by insisting on an outline of measurable stages and a hard date for overall project completion, enforced by stringent penalties…” and states that “the committee should have insisted the SI spend time with each department” to better understand their particular requirements.
This seems to me to have been a failure of the company to create a complete and thorough RFP, rather than a failure of the contractor to perform. Time and time again, RFPs are issued with the three common, self-contradictory requirements: “Do it well, do it cheaply, do it yesterday” but without a complete statement of the requirements beyond the technical specifications involved.
It would probably be more critical to state that the contractor should expect to spend the first three months of the project interviewing 30 users to determine their requirements, than that the system should be developed in Oracle to run in a distributed Windows 2000 Pro environment. Better yet, the company, before issuing the RFP, should have done those interviews themselves, and published the results as an appendix to their project specifications, so that the contractor can submit a proposal with full knowledge of the end-user requirements and expectations.
Time and time again, IT organizations and consultants have pointed out that time spent in preparing a better, more complete RFP will bear fruit in a more controllable, better understood, and cost-efficient project. And time and time again, this message seems to fall on deaf ears.
David G. Smith
Halifax, NS
