We are a Microsoft partner ourselves, so read this with that in mind. We still think it is worth writing, because most selection processes we see ask the wrong questions, and it is the customer who pays for that afterwards.
Certifications say less than you think
A certification shows somebody read the syllabus and passed an exam. That is not nothing: it says something about the breadth of the knowledge. But it says nothing about judgement, and judgement is what you are actually buying.
Ask instead to speak to a reference whose project went sideways. Everyone has one. How it was handled tells you more than a list of course certificates.
The six questions
1. Who does the work - and am I meeting them now?
At larger suppliers the people who sell are not always the people who deliver. Ask specifically who will sit on the project, and ask to meet them before you sign.
2. What happens if the estimate breaks?
The answer reveals the whole business model. A supplier who says "then we have a conversation about scope" is being honest. One who says "that does not happen" has not delivered enough projects.
3. Who owns the solution afterwards?
Everything should run in your own tenant, and the code and configuration should be yours. If the answer is vague, ask what happens the day you end the agreement.
4. What is documented, and when?
Documentation written at the end is rarely read and often not written. Ask whether it is produced as the work goes, and ask to see an example from another project.
5. What does operation cost in two years?
The project price is the easy part. Ask what managed services cost once the solution is live, who is responsible, and what the response time is when something stops.
6. When would you have said no to this project?
The best question on the list. A supplier who cannot answer, or who answers "we solve everything", has just told you something important.
Signs that should stop you
A fixed quote given before anyone has seen your systems. A demo that solves everything without a question about how you actually work. Vagueness about who owns the code. And a supplier who never says something is a bad idea, that usually means they have not understood what you asked for.
Large supplier or small?
Both work, but they fail differently. A large supplier has capacity, process and people to put in when somebody leaves, and the risk is that you become a small customer in a large portfolio. A small supplier gives you the same people throughout, and the risk is capacity.
Ask both the same thing: what happens if the person who knows our solution best leaves?
About us, since you are reading this on our site
We are a small team, we stay inside the Microsoft ecosystem, and you talk to the people who build. We say so when the scope should be smaller than you had in mind, and sometimes that you do not need the project yet.
To test where you stand before talking to any supplier, we built a Microsoft maturity assessment that takes a few minutes. Or get in touch.
Common questions
How many suppliers should we ask for a quote?
Two or three is usually enough. More than that rarely produces better decisions but costs a lot of time, yours and theirs, and that time ends up in the price.
Should we choose the cheapest?
Not without understanding why it is cheapest. The most common answer is that the scope was read more narrowly, in which case you are comparing two different projects. Have everyone price the same thing, in writing.
What should a managed services agreement say?
Who is responsible, what the response time is, what is included and what is billed separately, and what happens to access and documentation if the agreement ends.
Is it a problem that the supplier has its own products?
Not in itself, but ask when the product is the wrong answer. A supplier who has a product and can still say plainly when the standard platform is the better fit has thought about the question.