Setting the criteria for a new software development project … and selecting the appropriate vendor to build and implement the plan … may well be one of the most important decisions your company ever makes. Choosing the right combination of both should be based on objective, hard data … and an in-depth knowledge of the capabilities and expertise of the people you will be working with. Yet without an efficient method of evaluating both, the process can just as easily lead you astray and be counterproductive to your goals.
Here are ten reasons you might use a Request For Proposal (RFP) to select the most appropriate Software Development Company … but also why that same rationale may work against you.
1. Provides Clear Software Project Definition
Pro: Stakeholders clearly define and prioritize their software development needs in the RFP. Specific requirements can be itemized and deliverables can be independently weighed and decided upon.
Con: The basic assumption that RFP writers can (always) define their needs and, in addition, are also able to specify the best approach to accomplish them is (in many cases) flawed. Information Technology is changing at an incredible pace … only those service providers who are completely on top of the latest technological advances will be aware of all available and/or applicable possibilities. This is where the expertise of your service provider becomes invaluable … as they will be better able to predict whether the specified required approach will indeed be the best ones to get you from where you are to where you want to be. RFPs don’t always give the vendor enough latitude to offer such suggestive advice, to offer cost saving alternatives, or to be a true project advocate.
2. Software Development Project Results Guaranteed
Pro: The RFP can be referenced in your contract to solidify the promised software functionality and the time frames of deliverables.
Con: Every web development project has unforeseen complications that arise from functionality requirements, system integration and technological issues … and that is where an adversarial relationships can easily begin to develop. Yes, you want your specifications to be met, but when an unforeseen issue causes delays or changes, you need that service provider to be an advocate not an adversary. Too many contract administrators want to point fingers at a time like that.
3. Competitive Software Development Pricing
Pro: An RFP increases price competition among software companies and helps to eliminate obviously flawed bidding practices and unrealistic promises.
Con: Today’s market and the associated bidding practices have changed substantially from just a few years ago. At one time there were a lot of jobs up for bidding and a lot of competition for those jobs … and it was common practice to undercut the competition by reducing profit margins. Today, the first question on a bidders lips is not “What do we have to do to win this bid?” it’s actually become “If we win the bid … how can we still make money on the project?” Flawed bidding practices and unrealistic promises clearly do not serve the issuer of the RFP or the bidding entity … Competitive bidding doesn’t necessarily result in better pricing in the complicated software development industry.
One other worthwhile note; what may appear as a genuine lower priced bid may in actuality be your worst choice. An unscrupulous bidder may choose to use lower quality offshore resources where miscommunication are commonplace. In the meantime, your reputation is being put in jeopardy.
4. Proposal Comparisons, Made Easy
Pro: Since the RFP has specific guidelines, it allows “apples to apples” comparisons between vendors and easier evaluations of their proposals.
Con: The “specific guidelines” prevent bidders from include out of the box suggestions for fear it will eliminate them from the process. Oddly, this is true even in the cases where they do not believe the guidelines will result in the desired outcome. They are actually comfortable with the idea that when the software application doesn’t work … they will be in a better position to tack on the needed upgrades, and costs … this leaves you with few other choices then to approve the suggestions.
5. Focus on Objectivity
Pro: Eliminates a secondary focus on which sales rep. has the best personality or presentation style and brings the attention back to the objective data and performance standards.
Con: Personality and presentation style should not be eliminated from consideration … if kept in the proper perspective. As it happens, both can be a very informative look at the professionalism of the bidder, the bidder’s staff, and the overall attitude they take in their approach to new business. Plus it gives you an in-depth look at whether those you are in contact with have a genuine interest in the success of your project.
6. Reduces Software Development Project Risk
Pro: Helps to minimize the possibility that essential system functionality or service company shortfalls might be overlooked. Writing the RFP, the system requirements, and the proposed delivery dates certainly lends itself to a well thought out project.
Con: Unfortunately, reducing risk is an ongoing activity that continues to occur through the life of the project. Contract Managers must continue to have an active role in the project and cannot place all responsibility on the vendor once contracts are signed. It is much better to have a well structured ongoing problem solving attitude and less of a fault finding approach. Don’t expect your RFP or vendor to completely eliminate software development risk.
7. Reduces “in-house” complaints
Pro: In-house staff can be instrumental in structuring the functionality of new website or web application therefore they will obviously like it.
Con: The fact that in-house personnel were given a level of input during the design and/or RFP stage doesn’t necessarily mean there is a willingness to change procedures or to consider outsiders ideas. In-house complaints can be minimized and buy-in maximized by allowing users to take a more active role throughout the software development life cycle. Cut them out of the process and they may see that the new system is being forced upon them.
8. Better Development Vendor Participation
Pro: RFPs tell potential service companies that you are serious about your project and that you are approaching it in a very professional and defined manor.
Con: In today’s market an RFP is no longer seen as a sign a project is assured of approval. Properly responding to the RFP can be quite challenging and time consuming. Bidders are less likely to take part if they think the competition is too stiff, too ingrained or if expectations are too high. The time involved in developing a bid can be costly with little hope of recovering those costs … and equally, in many cases it is seen as an attempt on the part of the issuing company to obtain free consulting information (and even project specifications).
9. Enhances Your Professional Image
Pro: Structure, definition, clarity, and a well managed RFP process can, and will, enhance your image within the company … indicating your good judgment and professional organization skills
Con: Can you believe that some contract managers actually go through this whole process mainly considering how the RFP will make them look? Project success may be a secondary concern! Yet it is true that self aggrandizement is a major benefit to those who can appear as if they a working very hard toward those ends. When we did our research on the potential of a “Top Ten list” we were shocked this even came up … but it did … thus it earned a place at number nine … and begs for a heads-up at all corporate levels.
10. Software Development Project Funding
Pro: Highly structured, well defined software projects have a greatly increased opportunity to obtain funding. Detailed reports, exhaustive documentation and well defined project parameters often justify themselves within the corporate family … and that is just where you want to be … promoting a project that has incredibly obvious advantages and benefits.
Con: Funding is where many good ideas (highly structured, with detailed reports, exhaustive documentation, and well defined project parameters) … go bad. This project killer … this corporate anomaly … carries the corporate stamp of approval … but when the dust settles, the file is stored in a bin labeled “under-funded”, or “back burner”, or just plain “cancelled”! And this is not where you want to be.
