Why you should stop asking vendors for RFQ’s and how collaboratively partnering with them will better solve your challenges

To all those working in #procurement this post may be a little controversial, and is really intended to make all of our lives better, especially the end user of the type of solution people like me all over the world implement. And I am aware that this is aimed at the people who send us work that ultimately pays my salary, so take it in the spirit it is given, which is to try to help us all. I am writing this as an individual not my company, as there is a real personal element to this all. I will provide what I hope are useful suggestions. And to call out to you to see who wants to try bring about change.

#governmentcontracts and large organisations have been trying to solve problems by engaging vendors using a very formal procurement process for longer than any of us have likely been alive. This is necessary to ensure they and the public money is protected. And at the same time projects have continued to fail to deliver value to said organisations for as long as surveys on project success and maturity have been around. This takes an emotional toll on all of us who pour out hearts into this work.

One of the key reasons is that old, tried and loved (this is sarcasm by the way which anyone who has prepared or responded to an #rfq will probably appreciate) #process of preparing a request for quotation, sending it out, and then picking a solution that costs a lot of money, probably the public’s money, and impacts your working life and level of satisfaction and overall mood when you get home. And you do all that without actually talking about the problem, what can really add value, and the best way to go about it.

So this is what happens:

1. You spend a lot of time coming up with #requirements. But you may not have access to those who specialize in your problem and have wider experience;
2. You document them, often making sure to keep a lot of people happy by including their specific requirement. But because you are not an expert in what you are looking for, you keep it brief. Because the people telling you what they want don’t usually have experience in such a solution (in my case a PPM solution usually), they ask for vague requirements that may not solve their problem in the short to medium term which forms an incorrect impression of your true problems;
3. You follow a procurement process and send those out to the market. And procurement says you can’t really talk to the experts out there in vendor land to figure some of the details out, due to probity. Sure you can exchange emails but it is not the same as having an in-depth discussion round a whiteboard;
4. Someone like me spends from days to weeks replying. This is quite an investment, and obviously we have structured the company to handle it, but consider how half that time in free consulting to you could make a difference to actually getting to grips with your true requirements;
5. Someone wins the work, and then we all have to have hard discussions about what those requirements mean, if you really meant what you asked for, and what you actually need, and if the estimate is appropriate. If you are honest you will remember this happening at least once.

But this doesn’t work well all the time. Between us all often less effort is spent on an investment that supports your strategic goals than you spend on selecting a new car that costs a lot less. And at the end you make a decision based on a guess from a vendor based on what they gleaned from your spreadsheet, and based on your guessing how they will actually undertake solving your problem.

Maybe we can make this a little smoother and more productive. So to take the first step I provide here some honest and open feedback on some of the specifics that I often see, so that hopefully it can be done differently.

It all typically starts with a list of hundreds of questions in a spreadsheet (got to love Excel!) but you seldom describe what you actually want to achieve, what problems you want to solve, and what your vision is. Therefore you get a reply to what you ask for, but don’t leave room to see the true value a solution can bring. It’s like saying I want a car with four wheels, but you neglect to say that you want to use it to take 6 kids and a dog to the beach, so you get a little two door car proposed. And us vendors know this, and it breaks our heart knowing just how much information we could give you to help you, if only there was an opportunity to do so.

Sometimes someone thinks beyond this and knows what they want. So they specify the solution. But specifying the solution is not the requirement and often again doesn’t describe what problem you are trying to solve, and so you miss out on all the other options out there and the additional value that could have been brought by a vendor, as now the focus is very narrow. So don’t specify that?you need a specific button to do something. Rather describe how you like to work and what your process is and how you want to digitise it, and then see what the tool can do for you.

Here are some examples issues I have seen in RFQ inclusions that are really hard to provide you with a useful response for. I would love your feedback, either to agree or tell me where to improve myself:

1. You obviously need to understand more about the solution being proposed. But it is important not to focus only on the solution as it is today, and not the credentials of the company who will be making it grow into the future. The platforms have changed, with the Power Platform we expect to evolve solutions, but if you ignore that you miss the value it can bring as it matures with you. It is like selecting Lego based on the model that has been built with it and forgetting it can be reassembled into anything you want.
2. Not understanding the technology you have already invested in, and not allowing those who do understand it to help you understand it. This is specifically true for the Microsoft ecosystem which can do so much, but rather organisations create detailed requirements that can never be met, and more importantly should not be, as there are better ways to achieve them if they take the time to understand what their own Microsoft technology can do. So describe the problem, tell us what you have, and ask us to create the best mix and match for you.
3. The hardest one we get is to do with reports and dashboards. These are how your solution brings data to life. But you don’t tell me what decisions your reports should support or even what you think the reports should be. You just specify reporting tool functionality such as it should connect to a database and be able to have graphs and tables. Yes this is a real scenario. And then you want me to estimate how long it will take to build reports. What reports? I have no idea, and I can’t guess as you haven’t started off by describing why you want a solution at all.
4. You ask that the data will be displayed in a way that is logical and easy to read. No, I’m going to admit that it isn’t! Rather describe a process that is currently fractured and ask how they can help to enable that, and weed out the user interface during demonstrations.
5. Since the invention of the tablet: can it be used on a mobile device? Do you actually use a mobile device now? Why and where? If you tell me I can come up with a solution to actually help field workers. And to answer the question, everyone asks but no one does really use a mobile device for a schedule or financial planning so why ask?
6. Does it have the specific field X? Any vendor will say yes. What I rather say is that it does not matter as long as the platform allows for fields to easily be added and reported on. Rather describe the decisions you need to make using such fields.
7. Duplicated questions. Duplicated questions happen all the time. I suspect you have three people ask so you need to include all three identical requirements. But I also think it indicates a lack of understanding of how the requirements address a problem, so rather focus on describing the problem.

Now that you have read my ranting, you may still need convincing that change is needed. Well the way things work now, you actually pay twice for this process. Fees are increased to cover the cost of this presales, but then time is spent when the project starts to work out what you really want and need, so you pay for that too.

So how else can this be done? You do need to ensure that your organisation is fair and transparent and follows a process, else we would be in longer term trouble. But there are some options:

1. Make sure you describe the problem so that you give us a way to relate all of the detailed requirements together.
2. Describe the #problem in relation to how you work now and your process, not a generic list of nice to have things.
3. Take advantage of vendors. In my specific case our company is large enough and understands the problem well enough to be willing to invest in you upfront. So call us, ask us to help you figure it all out, and then go to market. Even if we don’t win the work after that everyone will ultimately be better off with a more realistic solution.
4. Stage it. Describe the #problem, and ask for an approach to the problem, not the actual solution. Once the approach that meets your needs and current and future maturity is worked out, go to market again for a solution. And this may be with another company. This saves us both from a rabbit hole of delivery problems.

I hope this stimulates some thought, and I would love to engage with you to share experiences and see if we can do it differently.

I have been quite influenced by Mahan Kalasa and Randy Illig in this, and recommend their book which makes for an entertaining listen (or read): Let's Get Real or Let's Not Play Audiobook | Mahan Khalsa, Randy Illig, Stephen R. Covey | Audible.com.au

Please feel free to comment on this, and either tell me I am wrong or right or share some of the examples you have seen.?