Blogs

I was speaking with a potential client who said that one of their procurement problems was that project costs tended to grow and once started on the upward spiral, they were hard to control. I asked if they wrote RFPs and were there adequate specifications in the RFP? His answer was, “I don’t think we provide really detailed requirements – we typically don’t have the time and technical resources.”

And this lack of technical requirements is not out-of-the-ordinary in my experience. Let’s look at an actual example of an RFP “requirement” and the resulting questions that arise (BTW, this RFP was 35 pages long and 1 page was devoted to “requirements”. The RFP requirement listed below is actually two requirements rolled into one sentence – one for document imaging and one for workflow. There was no other elaboration in the RFP on this requirement which prompted vendors to ask questions. The first question/response is about the imaging requirements and the second is about the workflow requirements.

RFP Requirement: Vendors must describe their proposed system architecture to include imaging and document work flows. (believe it or not, this is the requirement)

Vendor Question (about imaging):  The type, size and cost of the hardware to perform document scanning depends upon many variables such as how many documents need to be scanned, how quickly do the documents need to get into the system, how many people will be available to do the scanning, are the documents all in one location or are they distributed across many locations, etc. Please provide more detail about the documents, the quantity of documents, their condition, and locations.

RFP Response: There are in excess of 1,500,000 existing archived documents. However all will not be imaged. Individual departments will decide which documents must be imaged. We anticipate the need for more than one scanner. Some departments may need more than one scanner.

Vendor Question (about the workflow): The RFP indicates the requirement for workflow capability but there are no technical specifications. Will workflow need to be a part of year one or two or three implementation? If so, how many different workflows and how many steps per workflow?

RFP Response: Workflow will begin with year one in each dept. Current workflows are from 5-20 steps. Integrated workflow environment should provide rapid customization, configurable user privileges, and automated routing and alert options, all in support of group collaboration

OK – not that we need to but let’s analyze what is wrong with this picture. First the document imaging issues.

The requirement clues us into the fact that they want a document imaging system but they provide no requirements that specify how many different paper types are involved, the quantity of each paper type, the condition of the paper, is it one- or two-sided, and a myriad of other questions. The vendor question relates to the lack of information but more importantly, without this information it would be impossible to price the solution both in terms of equipment needed and implementation costs. The RFP Response provides one piece of information but actually, for me, generates even more questions – such as: (1). Is this for the archive only or is there on-going work to be completed? (2). How many departments are there? Etc.

The second part of the requirement is for workflow, which can have very complex requirements, especially given the RFP Response which indicates there are many different workflows and each workflow can be simple to complex. Workflow, in particular, can be a very costly item to implement because a detailed map of the AS IS application has to be established and verified and only then can the TO BE be developed and implemented – the TO BE representing (1) the new and improved workflow and (2) the reengineering of the work processes, which is where the potential savings (the ROI) may occur.

Today, it is generally acknowledged that half, or less, of the system price goes to software with the rest being eaten in implementation costs. So, it is extremely important that the vendors be given enough information to estimate the implementation costs. Without this info (whether asked for or not) the cost of the implementation can very easily exceed the initial costs of the system.

With workflow, for example, if the AS IS work is not spelled out clearly, and left for the vendor to “discover” during implementation, you may as well give the vendor your checkbook. This is not to say vendors will take advantage of the situation but is to say when a vendor is doing requirements analysis and development for a new application, it is difficult to determine beforehand what problems are out there – the vendor is in discovery mode and you are paying the vendor to do your homework.

So, to get back to my conversation with the potential client who said that they have a difficult time controlling costs…this may well be why that is happening and a good example of why costs often exceed the proposal price. As shown above, the vendors did question the requirement and the response was still not complete. But what should a vendor do? In this case, the vendor most probably competed their proposal and put some contingency money in the bid to cover the unexpected. Even with the contingency money there is a 50-50 chance that it will not be enough and the vendor will have to ask for more money.

So with the job, let’s say, half done and vendor showing you that there are “new and unexpected requirements” are you going to say no? Most likely you will say yes and that the requests will keep coming until suddenly you realize that you have doubled your costs from the original bid price. From my direct experience, I recently worked on a project in which the system was never fully implemented and did not fully work (due to cost overruns). We also realized that the cost to complete it and maintain it would be much higher than buying a newer and more cost effective system. In this particular case, not only did my client pay more than the final proposal price for the original system, but they will now have to pay for a new system – overall cost for this “project” will most likely be four times the original budget.