Speaker 1: If you have worked in any IT service based industry I'm pretty sure you might have heard about these terms time and again RFI, RFP, RFQ, SOW but being in a technical role sometimes we don't understand what exactly it is how exactly it comes into picture and what exactly transform these things into actual technical work which we do. So in this video I'll try to give you an overview of these processes what exactly it does to enable the business to do the technical stuff which we do and then earn money out of it. So let's understand these terms with the help of some simple examples and I'm pretty sure by the end of this video you will be in a position wherein if your manager comes and tells you that we have got the TAO you'll understand how. Friends before we start with our example let's understand few basics. Whenever there is a transaction a business transaction there is always a customer and a supplier or a vendor how what does that mean if you go to the market to buy anything you go to a vendor's shop and you buy the stuff so what exactly is happening is you are purchasing something or we also call it procurement so this is all comes under procurement process suppose this is the customer who works on this Excel report with VBA macros to automate certain stuff. But now he wants to show the data within this Excel to the senior management. And he wants this to be converted into more user-friendly BI, business intelligence report, where he could show the data on a trend line, on a pie chart, like that. And then he could automate this to be sent over an email to all the business stakeholders. Now, that's the requirement he has. And now he wants someone, some supplier, to do this job for him. So right now, just imagine that he has a vague understanding of what he wants, but he's not sure of whether he wants to buy something or not. So what he will do is, under the first step, which is RFI, and when I say first step, not necessarily it is followed in sequence, but I'm just trying to give you a very basic understanding of this. That's why I'm taking it as a step-by-step approach. So under RFI, which is called as request for information, the customer will go into the market to explore the option he has. So far, he has not made up his mind that whether he is going for a certain solution or not. So he will float the RFI with some open-ended questions as to if this is kind of the problem I have, how you would resolve it. And these will be some open-ended questions about what kind of options I have and what kind of options I can go for. So RFI by nature is casual. It is like asking your friends what I need to do in my life. It's so generic, OK? So then your friends would say, I don't know what you want to do in life. Tell me more about it. Maybe you could try this. You could try that and all that, right? So similarly, customer at this point of time does not know exactly what is the solution for his business need. But these RFIs would open that channel, and he would start thinking more clearly as to what could be the potential solutions for his business problem. And that's why these set of questionnaires are sent to the suppliers, and they just reply back within a time frame or to all those queries. And once those queries are sent back to the customer, customer has a clear idea of the potential solutions they might have for this particular requirement. So the advantage with RFI is it is a very fast method to get the information you need from the market before you take a more serious decision or a serious look towards your solution. So once you have RFI, and once you have received a response for that particular RFI, then you go to the next step. And when I say next step, again, I'm saying you could skip certain steps. It depends on the relationship you have with a prospective customer as a supplier. So there are scenarios where RFI does not take place at all. People know each other. customer knows the supplier so well that he or she could directly go to the RFP stage. But more importantly what is RFP? RFP stands for request for proposal. So in RFP things starts to get more serious because now the customer is taking a serious look on whether he needs to go for a certain supplier or not. This is the point where the decision would be made and that's why it is more formal and more detailed the RFP process which is request for proposal process is more detailed you might have to as a supplier come up with your own proposal prepare a presentation to showcase how you would meet the customer needs and that's where the your BRM's your business relationship managers your BDM's business development managers your sales executive and your tech team come together to form a proposal which could be sent to the customer so that customer could make that advised decision thing which differentiates RFI with RFP is in RFP you expect the vendor to share the unique strategies they would opt for in order to deliver you a better solution so let's say take an example suppose this is a vendor one vendor two and vendor three all three of these could take this problem statement and come up with their own specific solution so for For example, vendor 1 might come up with a solution wherein he says that, okay, let's migrate this into a Power BI because both are Microsoft products, wherein vendor 2 comes up and says that, okay, you're talking about this Microsoft Excel, but what else you want to automate in this area? Is this the only report? Do you want a cloud solution to be built where you can run all your analytics workloads, including this Microsoft Excel? It is more visionary, right? they are thinking far ahead and all that will be part of your RFP discussion there would be a timeline given to you you have to form your proposal and then present it to the customer and ask certain questions if you if you wish to and then propose this solution which you have come up with. Vendor 3 could come up with a completely different approach so it is more about analyzing which vendor has that vision which aligns to your vision as far as delivering this solution is concerned. So RFP enables the customer to take a very wise informed decision. So once your RFP phase is over you go to the next phase which is RFQ which is called as request for quotation. So suppose if you want to buy a laptop you go to three different shops to ask for quotation. You need to understand what exactly it costs to buy a laptop of a certain configuration. RFQ the stage where customer understand how much it will cost them to get this solution and many a times RFP and RFQ are combined together so not necessarily it would be the third step it could be combined with your RFQ wherein in your proposal you also share how much it would cost but the idea is it has to be a structured breakdown of how much time how much effort how much cost it will take to deliver this and how much you would charge the customer and that would impact the purchasing decision. Sometimes it might happen that vendor one has a very good solution for the customer but it's very costly wherein vendor two is just about doing the job but then it is falling within the financial budget allocated for this particular project. So in those cases this could be a game changer because eventually everything boils down to the cost and the price of the product right. So once RFI, RFQ, RFP all these processes purchasing processes are over we expect to come out as a winner from the supplier side. So suppose customer chooses supplier to or vendor to as a prospective winner of this particular deal then comes the next phase and that phase is to prepare a statement of work which is also called as SAO or SOW. A lot of times you might have seen the SAO. It is a contractual agreement between the customer and the supplier on the exact deliverables that needs to be delivered. You would have your legal obligations as a supplier, you would have your in scope, you would precisely highlight that these are the activities we will deliver as a part of the project, these are the things which are out of scopes, these are the the assumptions and the dependencies which the customer needs to take care of. For example, in this particular case, SOW might say that the functional knowledge of how these VBA macros and Excel are being created is the responsibility of the customer to give. So maybe the customer has to align his business analyst to work with the vendor team. I'm just giving an example. SOW is a very serious business, guys, because this has legal implications. Now you are going into a legal contract and that legal contract binds the customer and the supplier together for the term of that contract which is stated in SOW. Your legal team has to validate what has been agreed upon and what could potentially result in some sort of a legal trouble if in case customer is not happy. So when the SOW is being signed by the customer and the supplier you are ready to start going So, potentially when your RFI, RFP, RFQ process is ongoing, your sales, pre-sales team, your consulting team would be heavily involved, your BRMs, business relationship managers would be heavily involved, your solution enterprise architects, solution architects from your pre-sales team would be involved. But once this whole sales process or this whole procurement process is over and once it comes to the delivery phase, your delivery team has to get involved and that's where your project manager will come in, understand what is the requirement and then starts delivering it as per the scope. So generally as technologists, as technical people, we do work as a part of a statement of work but we don't understand it because maybe we are quite junior so we are not involved in those discussions, sometimes as you grow up the ladder, you start understanding, you start helping your seniors prepare the statement of work. So it is just the process. But as a as a newbie in IT industry, as a person who's just entered into the IT industry, if you know these things, which personally I took ages to understand, I was always told that okay, these are the deliverers you have to deliver, but I never understood the business context behind it. So sometimes it happens that being the technical people, we start working on the deliverables, but sometimes we do not meet the scope, sometimes we go out of the scope, although this is the responsibility of the project manager or the delivery manager, but then you should also have the visibility of what is written in the statement of work. You could ask for it, it might be shared with you, it might not be shared with you, but the moment you ask for it, it will show that you know what you are doing and you know what you're talking. So I hope guys this video was a useful one I hope I know this is not a technical video but as I said ITK Funday channel is about making IT interesting for everyone and this includes these kind of processes as well so until next time guys keep learning keep sharing all your knowledge and yes keep hustling bye for now