Every successful IT project starts long before the first sprint. From early RFI stages to final contract clauses, we will outline what every decision-maker should know before choosing an IT service provider.
If your organization is about to launch a major project or modernize systems, this practical overview with Marcin Dąbrowski, CEO of People More, will help you approach it with clarity and confidence.

In many organizations, choosing an IT service provider is treated as a formal necessity, a checkbox in procurement. But you’ve said before that the sales process is actually a decisive phase of a project. Why is that?

Because in most cases, everything that determines the success or failure of a project is already decided before the actual work begins. We like to say the project starts with the kick-off, but by that point, key parameters are already fixed: the scope, the price, the timeline, the way we’ll manage the project.
Even the tone of the collaboration is often shaped by what happened during the supplier selection process. If that process is rushed, unclear, or purely price-driven, there’s a high chance that problems will surface later.

So what does a good selection process look like? What should organizations keep in mind when thinking about how to choose an IT supplier?

A structured process makes all the difference. In mature organizations, choosing an IT service provider typically follows several stages: Request for Information (RFI), Request for Proposal (RFP) and Request for Quotation (RFQ).
Each stage has a different purpose and builds on the previous one.

Let’s walk through them, starting with the RFI.

Right. This is the broadest stage. At this point, the client is researching the market, trying to understand who’s out there, what solutions exist, and what’s even possible. The goal isn’t to choose a vendor yet – it’s to gather insight.
RFI responses help clients identify trends, potential approaches, and rough pricing brackets. It’s an opportunity for the supplier to position themselves as credible and experienced, not to oversell.

And then comes the RFP?

Yes, this is where things get serious. The client has a better understanding of their needs and is ready to engage in deeper conversations. In a solid RFP process, there will be workshops, detailed discovery sessions, even technical deep-dives. This is where the client should share their business context, current IT environment, challenges, and goals.
In return, suppliers prepare detailed proposals; including architecture plans, delivery models, schedules, and estimates. The RFP is not just about “what” will be delivered, but also “how” and “why.” This is the most valuable point of the sales process.

And how does RFQ fit into that?

The RFQ is usually the final calibration before contract talks. Here the client typically focuses on pricing and commercial terms. They already know which IT service provider is technically capable, and now they’re optimizing scope, budget, and sometimes timeline. It’s important to say that this is also the moment where the pressure increases on both sides. Suppliers often face a dilemma: reduce prices to stay competitive, or walk away from a potentially risky engagement.
What often happens, unfortunately, is that the most aggressive offer wins – even if it’s unrealistic. And that’s dangerous, because it leads to under-delivered projects, strained relationships, and ultimately higher total costs for the client.

Let’s talk about contract negotiations. A lot of people see this as a formality. But it’s much more than that, right?

Absolutely. Contract negotiations are the final chance to align expectations. It’s not just about the legal framework. It’s about making sure the operational reality is covered: payment milestones, collaboration models, governance, and so on. This is also when we define the quality metrics and clarify who does what, and when. A lot of risk can be mitigated here or created, if this phase is treated as a rush to signature.
For example, if the payment schedule was backloaded, that would put an enormous strain on the IT service provider’s delivery team, delay onboarding, slow down progress. A good contract structure supports project success, not just legal compliance.

What are the most important things that should be absolutely clear before signing contract with an IT service provider?

First: the scope. Not just a high-level description, but a concrete breakdown of deliverables and assumptions. Second: the timelines. Even if they’re rough, they must be grounded in reality. Third: the financial model – is it time and material, fixed price, hybrid? Each comes with different risks and flexibilities.
And finally, let’s not forget culture and communication. Choosing an IT service provider isn’t just about capability – it’s also about fit. Will they collaborate well with your internal teams? Are they transparent? Can they adapt?

It seems like a lot of these things come down to trust.

Exactly. Technical competence is important, but trust and alignment are what make or break a project. At People More, we put a lot of emphasis on this. We want clients to see us not as a vendor, but as a partner. We’ve been through this process dozens of times – we know the pitfalls, and we help clients avoid them.

Final question: what’s your advice for someone preparing to go through the supplier selection process?

Take your time. Don’t treat it like a procurement checklist. Choosing an IT supplier is one of the most strategic decisions a company can make. It’s worth doing right.

Thanks for the insights, Marcin!
You’ve just read a conversation with Marcin Dąbrowski.
Are you looking for a long-term IT partner, not just a vendor? With our Managed Applications offering, you gain not just implementation, but sustainable, scalable support for your systems.
And for more insights on delivering high-stakes projects, check out Marcin Dąbrowski’s books:
- 10 Rules for Impossible Projects. Surprising – But True – Advice on How to Successfully Deliver Difficult and Complex Projects
- Managing IT Projects: How to Pragmatically Deliver Projects for External Customers.

Tomasz Michalik



