I'm helping a large company build a requirements document and RFP for a forecast and budgeting system. Initially, the thought was that we would solicit proposals from vendors for off-the-shelf applications. However, in the process of developing the requirements document, it has become clear that some of the desired functionality may not be president in an off-the-shelf application. As a result, we are considering soliciting proposals from custom software developers as well. so, I am scrambling to find local developers that have the skills, experience, and process maturity. In an effort to identify qualified software developers, we are considering an informal RFI. once qualified software developers have been identified, the idea is to include them in the RFT process, along with the off-the-shelf software vendors. Of course, the weight of various selection criteria will differ somewhat for custom vs. off-the-shelf solutions; but the thought is that overall it will be simpler to manage one RFP process rather than two.
there are three topics that I'm hoping someone out there can help me with.
First, do you have any general advice for us, knowing what little you do know about the circumstances?
second, since we are only trying to qualify software developers for bidding on the RFP, what are the top 10 questions you would ask in the RFI?
Third, as a software developer myself,I think I have a pretty good understanding of the risks and vagaries of combining custom and off-the-shelf solutions in one RFP. However, there is considerable political momentum in favor of a combined process that it will be difficult for me to overcome. How would you deal with this situation?
thank you for your time,
Bob Crimmins Saving Changes...
Sort By:
Anonymous
To answer question 1, in my experience worrying about custom built or off the shelf functionality is secondary to having a robust business requirements specification. If your requirements are vague, ambiguous, or speculative, you run the risk of letting the vendor control the RFQ process. For off the shelf vendors, their product functionality will be used to do this. For custom developers, they will state that they can do anything. It's a trap that unfortunately most companies fall into.
For question 2, you need to utilize a proven analysis methodology to document business requirements specifications in order to establish the context for assessing the 'make vs buy' decision. The one I am experienced in provides a complete business system requirement specification in 1/5 the time of conventional methods. The documented business requirements are then synthesized to provide accurate criteria for publishing the RFQ and assessing responses to whether the business need is satisfied or not (your ten + questions). I use a matrix for this assessment once the responses are returned. I can do this because I have something concrete to measure against.
For question 3, interestingly, the process referred to above actually accommodates the "combined" idea. The assessment of responses and options is based on individual business requirements which are independent of solution. Saving Changes...
Anonymous
I struggled with a similiar issue not that long ago when I was looking for a payroll system for use in a multi-union environment. I finally decided the most important aspect, as the other comment suggests, was to very clearly document what the requirements were. Once I had the requirements documented, I identified those that were mandatory, those that were significant, and all others. I cross-referenced those with multiple choice selection for the vendor to come up with a rating scale. The vendor's choices for answers were:
1. Our application as it exists has that functionality.
(vendors were advised that they would be asked to demonstrate all mandatory and significant requirements at a product demonstration)
2. Our application does not have that specific functionality but we are able to demonstrate a work-around that accomplishes the same result.
3. Our application does not meet that requirement but we recognize the value and would be willing to build it into our standard application at no charge.
4. Our application does not meet that requirement but we would be willing to customize the application for you at a cost specified here or to be determined following a more in-depth requirements gathering meeting.
This approach actually worked very well for us, hope it at least gives you something to think about.
Saving Changes...
