Pre-Sales Activities

Since a long time, I was thinking to write down the pre-sales activities that we follow during some RFI/RFP. This is what I have learnt when I was working with Patni and got some great opportunities to work on some large size RFPs. Please let me know if this blog is useful for you and also I would be happy to receive the feedback. Let me know if you want me add/modify any of the activities below. Presales SPOC should be working between the delivery and engagement management. Sales person from onsite will be sending all the RFI, RFP and staff requirements to pre-sales person at offshore. Let us discuss them one by one: Following tasks should be handled by the pre-sales person. Presales SPOC should be working between the delivery and sales team. Sales person from onsite will be sending all the RFI, RFP and staff requirements to pre-sales person at offshore. Let us discuss them one by one: RFI (Request for Information) Usually this type of information is required by the vendee when they are selecting some vendors to start a new engagement. This exercise is usually done to check the capability of the vendor. When pre-sales person receives the RFI, he has to study the requirement. First thing, he has to prepare one query sheet to ask questions from sales person and the vendee (Customer) to gain the better understanding of the requirements. Now he has to build the team from different areas, who will be working on the RFI like Technical architect, domain architect (BA), legal, project management, finance etc. Once team is build, he has to kick off the RFI and set the expectations and divide the work between all the stakeholders. Each and every person should have a clear roles & responsibility, section ownership from RFI. Usually, all the information for RFI is readily available in most of the organization because this type of information is the general information regarding the companies. Vendee used the RFI for the final selection of the vendors, who will be working on the RFPs. But in some cases, if deal size is large. Vendee is taking some extra precautions in order to select the vendors. I have also worked in some RFI, which are equivalent to RFP. Vendee gives information related to the technology stacks and domain at a higher level. In this case, Vendor has to provide all the details on domain, and multiple technical & methodologies solutions etc. Approximately as per the trend the final document size in such cases ended up with around 100 pages. Sales person also has to decide the template or response format if Vendee do not restrict the response in some particular format. Response could be in the form of document or presentation. However, vendee usually gives a fixed format in case of RFI.

Most of the times, it is in the form of questions, which vendor has to respond. Questions are almost from each department of the company that includes domain expertise, technical expertise, available human resources on the domain and technical experience, organizational standard processes, TOM, communication model etc. Once pre-sales person will receive the response from all the stakeholders. He will integrate all the responses into the final template and will send to sales person after having a proper review of the final outcome from the stakeholders and senior management. Delivery team also has to work on the billing/cost model and rate card for a particular customer. Rate depends on the technology and domain for a particular country. RFP (Request for Proposal) Once vendee selects a vendor based on the RFI submitted. Customer sends the RFP based on the specific requirements. RFP will require more detailed responses from each stakeholder because it will be specific to a particular requirement/functionality. Decision for Bid or No Bid: When vendor receives the RFP, the first thing vendor has to do is to take a decision whether to bid or not to bid. It depends on the vendor's capability on the RFP technology or domain or above all the kind of complexity RFP requires in order to prepare the response. Remember this is very important. Sometimes, responding to RFP itself is a kind of project, which requires a lot of money to be spend on the RFP team. While forming the team, pre-sales person should try to identify people who have worked on the similar kind of the project/RFP. Query sheet, response template and RFP tracker (R&R sheet: who owns what) is very important for large size RFPs. Query Sheet: Query sheet should have the following information: o Document name - applicable in case there are more than one document in the RFP. o Section o Page (Optional) o Question o Response RFP Tracker: RFP tracker will contain each and every activities team will be doing for the RFP. o Each section that will be going into the response template; a kind of response TOC o Against each section, there should be a clear name written who will own the response from that section o Deadline for each section o Review date from each reviewer o Final submission date Response Template: High level TOC is given below. However, this will be a detailed in fact every detailed document. Most of the RFP document contain more than 100

pages. I still do not agree why do we create such a long document. I personally feel that customer would never read such a long document ever. o Executive Summary o Understanding of the requirements o Technical Solution - will contain the proposed architecture, tools etc. o Domain Solution - will contain all the applicable features and how will the future application/product represent them. o Execution Methodology o Governance Model o Schedule o Cost/price/rate card o Each section should be clear and crisp as per the vendee/customer requirement. However, if vendor feels that more details/supporting documentation should be provided in the response, that content can go into the appendix. Most of the times, there will be a lot of documentation as part of the RFP that need to read and understood while forming the solution. In such cases, documents are divided into different stakeholders for reading. There should be a war room created for each large size RFP. All the important stakeholders will work from a single location. Daily meetings will help to track the progress and tracker will help its progress. Debate on each and every topic will help to understand the requirements and come to a conclusion. Technical architect will work on the architecture, tools, software and licenses. Domain architect (BA) will work on the detailed functionality or to define the functionality scope. Project management person will work on the methodology, governance model, estimation, resourcing, costing, schedule, case studies, collecting profiles of the names resources etc Estimation, Costing, Resourcing, Risk, Assumptions inputs will be taken from everybody Final document/RFP should have Executive Summary (solution summary), Schedule, Objective, Scope, Proposed technology stack, proposed domain solution, Proposed technical solution, Engagement model or execution model, proposed project deliverables, Project Plan (Gantt Chart), Acceptance criteria, Roles & Responsibility, Assumptions, Risk Management, Commercial (Cost, pricing model, change control process), Appendix and case studies. Sometimes, you might have to work on the POCs to test the results of your solution. Post RFP Submission Once RFP is submitted. Selected vendors team need to present their solution at the customer location. This is a detailed discussion on each solution/section. Mostly done with the help of the ppt. Vendor usually travel to customer location with its critical stakeholders who will present their section on Technical, Domain, Project Management etc.

This is an important platform for the cost negotiations. Vendor usually negotiate on the rate card or fixed price cost that vendor has proposed. Selection of the vendor is not dependent on one parameter. It could be cost, solution, timeframe etc that decide the decision.