Steps to be followed during the vendor identification and short-listing process –

1. Approach it with a healthy attitude

   • The engagement has to be a win-win for both the parties.
   • The goal at the end of the project or engagement should be that you have a quality software product at a reasonably good price, and at the same time the vendor should have made their margins.
   • Although price is a factor, it cannot be the predominant one, at least at the initial stage of identification of vendors. In most situations, the lowest bidder may not necessarily be the right one.
   • When squeezed on margins, vendor has several cards that can be played -- including less oversight and staffing the engagement will less skilled resources. It can lead to a no win situation for either party.
   • There is no point going down this route to begin with.

2. Do your homework

   • Ensure Requirements gathering exercise is complete

     • In an application development lifecycle, there are two distinct phases of requirements definition.
       a) Requirements Gathering
       b) Requirements Analysis.

     • Requirements Gathering is the process during which the scope of the application is drawn at a broader level.

     • This exercise typically involves the functional heads and other key users of the proposed software application.

     • There are not many offshore IT organizations that have not matured to a level where they can start in this phase and help bring in best practices into your firm.

     • If you intend to use this as an exercise of change, you are better off hiring the services of individual industry experts for this purpose.

   • Outcome of this process should form part of RFP

     • It should give enough details for the vendors to make a fair estimate of the effort and cost involved for the project.

     • The more detailed the requirements are, the better the estimates can be.

     • In many cases, the estimates are also lower and of course more stable when the requirements are detailed.

     • Given fuzzy requirements, the vendors tend to overestimate to compensate for the fuzziness.

3. Develop RFP

   • If this is the first time for the organization, an external consultant can be engaged to develop an RFP.

   • It should contain information about the proposed system, the overall business requirements and business case for the system.

   • Information provided should be clear, concise and aid the vendors understand the complexity of the system.

   • To start with, list down the ideal attributes of your vendor.

   • The various attributes could be size, domain expertise, technology expertise (although technology is more or less a commodity these days, unless it is a niche technology), management team and its philosophy, brand image etc.

   • Sometimes a Request For Information (RFI) is developed and sent out to multiple vendors.

   • An RFI is useful to narrow down a large potential vendor list to manageable limits.

   • Typically not more than 6-8 vendors are sent RFP as it is cumbersome to go through and review each proposal for its merits.

4. Don't confuse vendors with complex business language

   • Business language makes sense for your in-house project team resources and eventually the IT consultants should be talking the same language.

   • But introducing these business terms to the vendors at this stage, with limited documentation may backfire.

   • The IT consulting company may be confused with the terminology and again overestimate the complexity of the application to compensate for this confusion.

   • RFP can be a tool in building the bridge -- to transfer the business process knowledge to the technology professionals, but is not the only tool.

   • Develop your RFP document with simple layman terms, and if business terminology is used, ensure that there is a reference-able glossary for it in the RFP.

   • The glossary again cannot be in business language -- it won't help make the connection.

   • The business terminology has to be explained in layman terms so as to connect with the IT professionals.

5. Request for a ball park estimate

   • If the scope has not been frozen to a satisfactory level (which is true in most cases), request the vendors to provide a ball park estimate -- to be changed within a fixed tolerance window during Requirements Analysis stage.

   • This ensures that the selected vendor doesn't start the change management process right off the bat.

   • Negotiations on change and scope management can be complex and leave a bad taste for everyone in general -- you would want to delay the start of the change management process to a later stage by giving the vendor a chance to clarify the requirements.

   • A final fixed price can be negotiated after requirements have been analyzed -- after the scope is frozen.

6. Do your own in-house estimation and schedule preparation

   • It helps to have your own estimation done before sending the RFP out.

   • Do not depend on the estimates of the vendors who may not understand the scope of the functionality as well as you do, with in the limited RFP time period.

   • If you do not have the resources in house for such an estimation exercise, hire a contractor who can do this for you.

   • In case of a custom development of software, ensure that you get the details at a function point level -- a list of the screens, reports, business logic, interfaces and individual estimates for each.

   • You can request the same from your vendors as part of the RFP process.

7. Ask for a breakup of the estimates

   • Not at the module level, but very detailed at a function point level, in case of custom developed software.

   • Use an industry standard way of estimation -- also to be done by the vendors so that the estimates can be easily compared.

   • The estimate should not have many items in the "Complex" or "High" category.

   • Such an estimate indicates that the exercise was not done with due diligence.

   • Any such items should be broken up into multiple tasks to be estimated individually until such an extent that they cannot be broken up further.

   • The level of detail in the estimates is also an indication of the level of understanding of the intended functionality by the vendor organization.

   • There may be some items that have been assumed as part of scope, which you may be able to review and remove from scope.

8. Conduct a question/answer session

   • This will help the vendors understand the application better and ensure that they take into account all the scope during their estimates and proposal development.

   • Usually the number of questions from a vendor gives away the level of understanding or the amount of effort being spent by the vendor. But also evaluate the quality of questions.

   • Expect to see some questions that you may not have an answer for right away -- these are things that you have not thought of during the requirements gathering exercise.

   • In such a case, request the vendors to provide that functionality as an 'a la carte' estimate.

9. Review the detail in the proposal

   • Review the entire contents of the proposal.

   • The assumptions are the killers.

   • Request that the vendors document the assumptions in their proposals.

   • Understand the assumptions made and question why they had to be made.

   • If the assumptions prove to be significant for a complex and critical project, you may want to clarify the assumptions and ask the vendors to come back with a proposal that does not include the assumptions.

   • Read the fine print.

   • You will not be able to compare two proposals if each makes different assumptions.

   • Depending on the number and quality of assumptions, clarify the information so that the vendors can submit a revised proposal having worked the additional information into their effort estimates.

   • Most estimates may fall within a particular range.

   • But pay particular attention to proposals with outliers and understand the reason for them.

   • Are they really a case of under/over-estimation, or have the others missed out on parts of the solution?

10. Obtain feedback from references

    • Although it is obvious that the references provided by vendors are filtered by them, there is some merit to the exercise.

    • Concentrate on why that particular engagement/relationship was successful.

    • Identify the key players that were involved from the vendor team -- you may want to ask for those resources to be staffed on your projects later.

    • Ensure that you have a questionnaire that has several open ended questions targeting areas of improvement, success factors as well as closed ended questions.

    • You may also want to consider visiting the reference client site if such an option is available.

11. Proposal presentation

    • The presentation may not give you much more insight than the proposal itself.

    • But it does give you a chance to question the vendor team and understand their level of understanding -- both of your business processes/application scope and of the proposed technical solution.

    • Understand the rationale for the onsite/offshore team split, if such a delivery model is being proposed.

12. Interact with the potential project team

    • Talk to the project manager and the other key members of the potential team such as technical architects, quality managers and team leads.

    • Some of the questions can be:

      • Are they comfortable with estimates?

      • How do they plan to go about doing it?

      • How are they qualified?

      • Do you think they can handle it?