Vendor Selection Case Structure (e.g., CRM/ERP)

Question

Hi coaches/experts :),

I'm preparing for BCG Platinion/McKDigital-style IT strategy interviews and would appreciate some feedback on how you would structure a typical vendor selection case (e.g., selecting an ERP or CRM solution).

My current approach is:

Define business and technical requirements
Prepare and execute the RFI/RFP process (identify vendors, issue the RFP, collect proposals, conduct demos/PoCs, and create a shortlist)
Evaluate the shortlisted vendors (functional, technical, commercial, strategic, and delivery fit)
Build a recommendation supported by a high-level business case and implementation roadmap

A few questions:

Does this structure reflect how you would approach such a case in an McK-Digital/BCG Platinion interview?
Would you include the RFI/RFP as a dedicated step, or would you incorporate it into another part of the framework?
Is the level of detail around the RFI/RFP process appropriate for an interview, or is it sufficient to mention it only briefly?
Are there any key steps or evaluation dimensions that you think are missing or I should rather leave out?

Looking forward, thank you!
Noah

Answer 1

Hi Noah,

I would be happy to share my thoughts on your questions:

First of all, your steps are correct, but they read like a project plan and not like a case answer. In these interviews they test your business judgement, not your knowledge of a procurement process. I would advise you to start from the business goal, so what problem to be solved and what a good outcome could loook like, and then pull the requirements out of that.
Moreover, on the RFI/RFP part, in a real interview I would keep it very short. One line like "we run a structured shortlisting" is enough, then move fast to the evaluation and the recommendation. Nobody wants to hear the procurement mechanics. What is missing in your version is the risk and change management side, because most ERP or CRM projects fail on adoption, not on technology, and interviewers like to see you raise it.
Lastly, I would strongly advise you to consider working with an experienced coach like me on your structuring skills. I developed the "Case Structuring Program" to help exactly such candidates like you who struggle with case study structures.

If you would like a more detailed discussion on how to best prepare for your upcoming BCG and McKinsey interviews, please don't hesitate to contact me directly.

Best,

Hagen

Answer 2

Hi Noah,

Solid structure. The main shift I'd recommend is to frame it as how the decision gets made, not how the project runs. These interviews test business judgment, not knowledge of a procurement process. Answering to your questions:

Directionally yes, but start from the business objective (what problem, what does good look like in outcome terms), then derive requirements. That is what makes it a strategy answer rather than an IT checklist.
Fold it into step 1. A big chunk of real work, but pure mechanics in an interview. Keep it as part of defining requirements and move fast to the evaluation.
Mention it briefly, then bring the depth to your five evaluation dimensions instead. That is where the judgment sits and where you want the airtime.
The one I'd add is change management and adoption. Most ERP/CRM programs fail on adoption, not technology, and interviewers like seeing it raised.

Hope it helps. Feel free to drop me a message if anything is unclear and good luck with the prep!

Answer 3

hey Noah!

For Platinion or McK Digital, your structure is already exactly what they want. Vendor selection cases are meant to be simple, business‑driven, and high‑level. They don’t expect you to walk through a full procurement cycle; they just want to see that you can think clearly about requirements, options, evaluation, and recommendation.

In interviews, keep the RFI/RFP step short. Mention it as the way you gather comparable information, but don’t dive into process detail unless they ask. What matters most is showing that you start from business needs, translate them into technical and functional requirements, evaluate vendors against those needs, and then recommend one with a clear rationale and a basic roadmap.

Your four steps are enough. You don’t need more layers. The only thing to watch is not getting lost in procurement mechanics. Stay focused on what the client actually cares about: fit, feasibility, cost, risks, and how to implement smoothly.

Alessa

Answer 4

Your approach covers the right bases, but it reads like an administrative procurement checklist rather than a high-impact consulting framework.

What most people get wrong in digital or Platinion interviews is detailing the RFI/RFP mechanics. Interviewers do not care about the paperwork or scheduling demos. Drop the RFI/RFP bucket entirely and focus purely on strategic trade-offs and value.

What actually matters is connecting technical fit to business value and change readiness. Here is how to structure it concisely:

Strategic & Functional Fit: Aligning vendor features directly with business goals and core user needs.
Technical & Architectural Fit: Assessing legacy integrations, security, scalability, and platform lock-in risks.
Commercials & TCO: Analyzing total cost of ownership licensing, implementation, and maintenance against the business ROI.
Delivery & Change Readiness: Evaluating the vendor's track record alongside the client's internal ability to handle data migration and staff adoption.

Hope this helps, and good luck with the prep

Answer 5

Overall, your approach make sense.

Of course, it depends how you develop each point and sub-point of the structure. How granular you go and how specific you are. But, high-level, the approach can work.

Make sure that you engage with the interviewer in a dialogue. That you don't only 'deliver' your approach but engage them in a discussion and align on what is a way of co-creating the approach.

Best,
Cristian