Procurement of Consultancy Services: A UK SME’s Guide

A lot of East Midlands businesses reach the same point at roughly the same time. The internal team has kept systems running, patched the urgent issues, and stretched Microsoft 365 further than anyone expected. Then a bigger need lands. A Dynamics 365 rollout. An Azure migration. A cyber security review. A Copilot AI pilot. Suddenly the question isn’t whether outside help is needed. It’s how to buy that help without wasting time, money, or goodwill.

That’s where the procurement of consultancy services often feels heavier than it should. You might only need a focused IT partner for a clearly defined project, but the language around procurement can make a straightforward buying decision sound like a public inquiry.

For SMEs, the primary challenge is usually simpler. You need to separate genuine expertise from polished sales talk. You need a process that’s structured enough to reduce risk, but not so bureaucratic that the project stalls before it starts. And if you’re responsible for budgets, operations, or IT delivery, you need to show that the decision was sensible, commercially sound, and practical.

The good news is that this process becomes much easier once you break it into parts and treat each part properly.

Your Guide to Finding the Right IT Consultancy

If you’re sitting in Nottingham, Leicester, Lincoln, or anywhere else in the region with a pressing IT project and no clear path to market, you’re not alone. Most leaders don’t buy consultancy every week. They buy it when something important is at stake and the internal team either lacks capacity, specialist knowledge, or both.

That could mean:

• Replacing legacy systems with Microsoft Dynamics 365
• Improving reporting through Power BI and Power Platform
• Moving workloads to Azure without disrupting day-to-day operations
• Strengthening security controls around Microsoft 365, endpoints, and identity
• Testing where Copilot AI fits without opening governance problems

The trick is not to turn this into a bigger exercise than it needs to be. Consultancy procurement works best when the buyer stays close to the business outcome. If the goal is to reduce manual work in finance, shorten customer response times, or make your data estate more secure, keep pulling the conversation back to that.

A useful starting point is understanding what technology consulting entails, especially if you’re weighing up whether you need strategic advice, hands-on delivery, or a blend of both. Those are different services, and they should be bought differently.

For some businesses, a project consultancy engagement sits alongside broader operational support. If that’s your setup, it helps to understand how an ongoing managed IT services firm can complement project-based expertise rather than overlap with it.

Practical rule: Buy consultancy for the gap you actually have, not for the capability list in the supplier brochure.

Good procurement of consultancy services isn’t about sounding formal. It’s about making a clear decision, with enough structure to protect the business and enough flexibility to keep momentum.

First Steps Defining Your Project Scope

Most consultancy projects go wrong before any supplier is appointed. The problem isn’t usually poor intent. It’s fuzzy scope.

A business starts with a broad need such as “improve reporting” or “move to the cloud”, then asks consultancies to fill in the blanks. That sounds efficient, but it often produces bids that look polished and aren’t directly comparable. One supplier assumes a discovery phase. Another assumes migration only. A third includes training, change management, and support. The buyer thinks they’re reviewing like-for-like proposals. They aren’t.

Poor scoping is a common pitfall in consultancy procurement. A 2022 review by the UK’s National Audit Office of a £2.5 billion spend found that scope creep was responsible for 28% of cost overruns, and while 75% of competitively tendered projects met their objectives, only 62% delivered their full benefits, largely because of initial scoping failures (reference on consultancy procurement scoping).

Start with the business problem

Don’t begin with the technology. Begin with the pressure inside the business.

If you’re considering Dynamics 365, the underlying issue might be fragmented customer records, weak reporting, or a sales team working from spreadsheets. If you’re planning an Azure project, the issue might be resilience, rising maintenance effort, or poor visibility across servers and applications. If you’re looking at Power BI, the issue is often inconsistent management information rather than dashboards themselves.

Write the problem in plain English. If a non-technical director can’t understand the opening paragraph of your scope, it isn’t ready.

A strong opening usually answers four questions:

1. What is happening now
2. Why it is a problem
3. What the business needs to be different
4. What happens if nothing changes

Define outcomes before deliverables

Many buyers jump straight to a shopping list. Migrate these mailboxes. Build these dashboards. Integrate this data source. Those details matter, but outcomes matter more because they tell a consultancy what “done” should mean in commercial terms.

For example, instead of writing “implement Power BI”, define what leadership needs to see, how often, from which systems, and who owns the reports after handover. Instead of “deploy Copilot”, define which roles will use it, what acceptable use and governance look like, and what success looks like after the pilot.

Use a simple internal checklist:

• Business objective such as better reporting, stronger security, or reduced manual administration
• Operational outcome such as one joined-up CRM process or a cleaner Microsoft 365 tenant
• Technical boundary including systems in scope and systems explicitly out of scope
• Ownership so everyone knows who approves decisions and who signs off delivery
• Dependencies such as licences, internal resource, legacy software, or third-party vendors

A consultancy can help refine a brief. It can’t rescue a client who hasn’t decided what problem they want solved.

Set the edges clearly

Many SME projects escalate in cost. Leaders assume the consultancy will “work with us on the details” and stay commercially sensible. Good suppliers often do. But if the scope is loose, change becomes hard to manage.

For a Microsoft project, define specifics such as:

• Platforms in scope including Azure, Microsoft 365, Dynamics 365, Power Apps, or Power Automate
• Locations or teams affected such as a single office, a whole group, or one department first
• Data and integration points including finance systems, document stores, or telephony platforms
• Security expectations around access controls, GDPR handling, and audit requirements
• Training and handover needs so the internal team isn’t left dependent after go-live

Create one scope document everyone can live with

The best scope documents aren’t long. They are clear. A concise document with agreed objectives, assumptions, exclusions, timeline expectations, and decision-makers is far more useful than a vague deck full of ambition.

Include these headings:

Scope element	What to include
Background	Why the project exists now
Objectives	The business results required
Deliverables	What the supplier must produce
In scope	Systems, teams, processes, and locations covered
Out of scope	Items excluded from this engagement
Risks and constraints	Budget, timing, internal capacity, dependencies
Governance	Decision-makers, meetings, approvals, escalation
Success measures	How you will judge whether the project worked

When this document is done properly, every later stage gets easier. Supplier conversations improve. Proposals become comparable. Costs become easier to challenge. Delivery becomes more predictable.

Navigating Your Procurement Options

Once the scope is defined, the next question is practical. How do you go to market?

For an SME, there are usually three sensible routes. None is automatically right. The best route depends on the size of the project, your governance requirements, and how much market testing you want.

The UK has a long history in this area. Procurement of consultancy services in the UK has roots going back to the 11th century, and modern frameworks now sit at the centre of public buying. In the 2022/23 financial year, UK central government spent £2.5 billion on consultancy, with many high-value contracts bought through frameworks such as the Crown Commercial Service, designed to secure value for money and become more accessible to SMEs (overview of UK consulting services trade and procurement).

Direct engagement

This is the route many private businesses prefer for specialist IT work. You identify a consultancy through referral, prior experience, or market knowledge, then move into scoped discussions and commercial terms.

It works well when the project is focused and you already have confidence in the supplier’s capability. A targeted Azure security review, Dynamics 365 configuration piece, or Power Platform advisory engagement often fits this route.

The strengths are obvious:

• Speed because you aren’t running a large formal exercise
• Continuity if the supplier already understands your estate
• Lower admin burden for smaller internal teams

The trade-off is that you need discipline. If you don’t challenge assumptions, test capability, and document scope properly, direct engagement can drift into comfortable but weak buying.

Framework agreements

Frameworks help when you need more structure without starting from scratch. Public sector bodies know them well, but some charities, regulated organisations, and larger groups also prefer them because pre-vetted suppliers and standard terms reduce administrative effort.

For Microsoft-focused projects, a framework can be useful if you want a shortlist of suppliers with known delivery capability and a more controlled route to award. That matters when procurement teams, trustees, or boards want assurance that the process was fair and defensible.

Frameworks are strongest when:

• Governance matters and your organisation wants a documented route
• Time matters but a full open tender would be too slow
• Risk matters and standard commercial structures reduce negotiation friction

The downside is fit. A supplier may be on a framework and still not be right for your project. Framework access should narrow the field, not make the decision for you.

Competitive tender

This route makes sense when the project is large, business-critical, politically sensitive, or likely to attract scrutiny. It’s common in bigger charities, mid-sized PLCs, and organisations where finance or procurement teams need a clear audit trail.

A proper tender gives you broader market visibility and a stronger basis for comparison. It also forces the buyer to become clear, which is often useful in itself.

That said, open tendering has costs. It takes internal time. It can attract generic bids. And if the brief is weak, you get a larger stack of poor responses.

A simple way to choose

Route	Best fit	Main advantage	Main risk
Direct engagement	Smaller or specialist projects	Fast and practical	Weak challenge if buyer is not disciplined
Framework agreement	Regulated or process-driven buying	Structure with less admin than a full tender	Supplier fit can be assumed too easily
Competitive tender	Larger or highly scrutinised projects	Better market comparison and governance	Slower process and heavier internal workload

If your procurement route adds more delay than protection, it’s probably the wrong route.

For many East Midlands SMEs, the answer isn't to copy public sector process line by line. It’s to borrow the parts that improve decision quality and leave out the theatre.

Creating a Compelling Request for Proposal

A good request for proposal does one job well. It gives capable suppliers enough context to produce a meaningful answer, and it makes weak suppliers expose themselves early.

An RFP isn't a test of how formal your organisation can sound. It’s a practical document. If you're buying Microsoft consultancy, the supplier needs to understand your environment, your business constraints, and the standard of response you expect.

What an effective RFP includes

Start with company context. Keep it brief, but useful. Say what your organisation does, where it operates, how the relevant team is structured, and why the project matters now.

Then move into the scope you’ve already defined. The key is precision without overloading the reader.

Include:

• Background to the project and the business problem being solved
• Current environment such as Microsoft 365 setup, Azure footprint, Dynamics 365 usage, or third-party integrations
• Required outcomes rather than only technical tasks
• Deliverables expected including documentation, workshops, build work, testing, training, or support
• Constraints such as timing, governance, budget boundaries, access limitations, or operational windows

If you need a starting document, an IT RFP template can help structure the essentials without forcing your project into generic wording.

Ask technical questions that reveal delivery capability

Generic questions produce generic answers. If the project involves Dynamics 365 Sales, Azure Virtual Desktop, Microsoft Intune, Power BI, or Copilot, name those technologies directly and ask how the supplier would approach them in your setting.

Examples of better questions include:

• How would you structure discovery for our current Microsoft environment before design begins?
• Which parts of the project would you deliver with in-house consultants and which, if any, would involve associates or third parties?
• What assumptions are you making about licences, integrations, user readiness, or internal resource?
• How do you manage testing and rollback for changes in production Microsoft environments?
• What documentation will we own at handover and in what format?

These questions force specificity. They also help you distinguish a consultancy that understands Microsoft delivery from one that mainly resells licences or writes strategy papers.

Ask for proof, not promises

A polished proposal often hides a thin delivery bench. Ask for evidence that matters to your environment.

Request:

• Relevant case studies that match your project type and complexity
• Named team roles with clear responsibilities
• Microsoft certifications relevant to the services proposed
• Security credentials and working practices including how data will be handled
• Support and escalation model after implementation

For organisations handling sensitive data or vulnerable users, also ask about staff vetting and operational controls. If you need DBS-checked consultants or clear onsite access processes, say so in the RFP rather than introducing it late.

Strong RFPs don't ask “Tell us about your company”. They ask “Show us how you would deliver this project in our environment”.

Make responses easy to compare

Suppliers write better responses when the format is clear. Ask them to answer under fixed headings and to separate assumptions from confirmed scope. If commercials are mixed into long narrative sections, bid comparison becomes harder than it needs to be.

A simple response structure works well:

RFP section	What you want back
Understanding of requirement	Their interpretation of your brief
Proposed approach	Discovery, design, delivery, testing, handover
Team	Named roles, skills, availability
Assumptions and exclusions	What is not included
Commercials	Pricing model and terms
Risks	Delivery concerns they foresee
References or examples	Relevant proof of similar work

If your team wants a plain-language overview of what makes supplier responses useful, this short video is worth reviewing before the bids arrive.

Common mistakes that weaken the whole exercise

Some RFPs fail because they are too thin. Others fail because they are too rigid. Both create poor buying outcomes.

Watch for these problems:

• Vague language such as “digital transformation support” without systems, outcomes, or boundaries
• Over-prescribed solutions that stop a capable consultancy suggesting a better approach
• Missing commercial instructions so suppliers price in different ways and cannot be compared
• No room for assumptions which drives hidden risk into the proposal
• No evaluation criteria leaving bidders unsure what matters most

The best RFPs are honest. They show where the client is clear, where decisions are still open, and where supplier expertise is wanted.

Evaluating Bids and Selecting Your Partner

Once proposals arrive, the temptation is to skim for price, jump to the shortlist, and move on. That’s exactly where expensive mistakes begin.

A lower fee can still mean higher total cost if the supplier misunderstood the brief, staffed the job lightly, or buried assumptions that become change requests later. Procurement of consultancy services works better when you evaluate bids as delivery propositions, not just commercial offers.

Build a practical evaluation matrix

Keep the scoring model simple enough to use and detailed enough to defend. For an SME Microsoft project, four areas usually matter most:

• Understanding of the brief
• Technical and delivery capability
• Commercial fit
• Working relationship and communication

You can score each proposal against these headings and write short comments alongside the score. The comments matter. They capture why one supplier scored higher, and they become useful later if stakeholders challenge the decision.

A bid that says the right words but ignores a key integration, user adoption issue, or security dependency should score down even if the price looks attractive.

What good bids usually have in common

Strong proposals tend to do a few things consistently. They reflect your scope accurately. They challenge weak assumptions. They show how delivery will operate, not just what the outcome should be.

Look for signs such as:

• A clear methodology with discovery, design, build, testing, and handover stages
• Named consultants instead of a generic “delivery team”
• Project risks identified early rather than hidden in legal small print
• Realistic assumptions about internal involvement, data quality, or change control
• Commercial clarity on what triggers extra cost

Compare commercial models properly

Price only makes sense when paired with the model behind it. The same project can be sold as fixed price, time and materials, or a retained advisory arrangement. Each has strengths and weaknesses.

Choosing the Right Commercial Model

Model	Best For	Pros	Cons
Fixed Price	Well-defined projects with stable scope	Budget clarity, easier approvals, strong discipline around deliverables	Less flexible if the brief changes, suppliers may price in risk
Time and Materials	Discovery-led work, evolving requirements, complex integrations	Flexible, practical when scope is still emerging	Requires stronger client oversight, total cost can drift
Retainer	Ongoing advisory input, fractional expertise, phased improvement work	Access to expertise over time, useful for strategic support	Can become vague if priorities and outputs aren’t reviewed regularly

Buy the commercial model that suits the certainty of your scope. Don’t force a fixed price onto a project that still needs discovery.

Use presentations carefully

Supplier presentations can help, but only if you make them answer the hard questions. Don’t treat them as theatre. Ask each bidder the same core questions and keep the panel consistent.

Useful prompts include:

1. What have you assumed that could materially affect delivery
2. Where do you think our brief is weakest
3. Which part of the project carries the most risk
4. Who will lead the work day to day
5. What would make this engagement fail

Those answers reveal more than a polished slide deck ever will.

AI can help, but it can't decide for you

AI tools are starting to influence consultancy selection. UK government trials in 2025 showed AI tools reducing consultancy selection time by up to 40%. But a 2026 report also noted that 55% of IT managers in Nottingham and Leicester cited unaddressed algorithmic bias risks (report discussing AI-assisted consultancy selection and bias concerns).

For East Midlands organisations, the message is straightforward. Use AI to summarise, organise, and highlight gaps in submissions if you wish. Don’t let it make the award decision unchallenged, especially where sector knowledge, supplier behaviour, and contextual judgement matter.

A sensible approach is to let AI support administration while humans test substance. If a bid looks strong on paper but the team can’t answer practical questions about Azure governance, Dynamics integration, or security ownership, the technology hasn’t helped you.

One option businesses often consider in this market is a Microsoft-focused delivery partner such as F1Group for projects involving Microsoft 365, Azure, Dynamics 365, Power Platform, cyber security, or Copilot-related work. The same evaluation rules still apply. Check fit, scope understanding, delivery model, and commercial clarity.

Contracting Onboarding and Ensuring Success

Selecting the consultancy is only half the job. The value of the engagement is often decided in the first few weeks after signature, when expectations become operating reality.

That’s why the contract matters. Not because legal wording is exciting, but because poor wording creates avoidable arguments later. If the scope is clear but the contract is loose on support, data handling, change control, or ownership of outputs, the project can still go sideways.

Clauses worth checking carefully

Most SME leaders look at price and term first. Reasonable. But several other points usually deserve equal attention.

Focus on:

• Statement of work that matches the final agreed scope
• Acceptance criteria so both sides know when deliverables are complete
• Change control covering how new work is identified, priced, and approved
• Data protection and confidentiality especially where Microsoft environments hold sensitive information
• Intellectual property clarifying ownership of documents, configurations, code, and custom assets
• Exit provisions so the business can transition cleanly if the relationship ends

If you use a wider contractual wrapper for multiple projects, it helps to understand how a master service agreement can sit above individual statements of work. That structure can make repeat consultancy engagements easier to manage.

For businesses using individual consultants or specialist contractors alongside consultancy firms, tax status can also matter. It’s worth understanding navigating IR35 rules for engaging consultants before the work starts, particularly if your delivery model mixes service providers and named individuals.

Onboarding should be deliberate

A signed contract doesn’t create delivery momentum by itself. Good onboarding does.

The first working session should settle practical points quickly:

Onboarding area	What to confirm
Governance	Project sponsor, delivery lead, escalation route
Access	Systems, tenant permissions, security approvals, devices
Communications	Meeting cadence, status reports, decision log
Delivery rhythm	Milestones, dependencies, testing windows, sign-off points
Documentation	Where project material will live and who can update it

A good consultancy will usually ask for this information. A good client won’t assume they can infer it.

Protect the relationship from preventable friction

Most project relationships don't fail because someone is malicious. They fail because assumptions go unspoken.

A few habits help:

• Keep one live action log so decisions and blockers are visible
• Resolve ambiguity early rather than “seeing how it goes”
• Escalate on facts with dates, impacts, and options
• Review business outcomes regularly instead of only technical progress
• Treat handover as a deliverable not an afterthought

The smoothest onboarding isn't the one with the nicest kick-off meeting. It's the one where everyone leaves knowing who decides, who delivers, and what happens next.

Turn a purchase into a working partnership

Some consultancy engagements should be strictly transactional. That’s fine. If you need a contained technical deliverable, keep it tight.

But many Microsoft projects touch operations, training, process design, security, and future support. In those cases, supplier relationship management matters. Ask whether the consultancy raises issues early, documents work properly, and leaves the internal team stronger than before. If they do, you've bought more than project labour. You've bought usable capability.

Frequently Asked Questions About Consultancy Procurement

Do SMEs need a formal procurement process for consultancy?

Not always. They do need a disciplined process.

For a small advisory engagement, direct buying may be perfectly sensible if the scope is clear and the supplier is well understood. For larger Microsoft projects involving security, data, integrations, or board visibility, a more formal process is usually worth it because it creates clearer comparison and stronger governance.

What’s the biggest mistake buyers make?

They go to market before they’ve defined the problem properly.

That usually leads to proposals that look similar on the surface but are built on different assumptions. The result is confusion during evaluation and disagreement during delivery. Clear scope beats clever procurement language every time.

Should we choose a consultant with the lowest fee?

Only if that bid also gives you the best value.

A lower-priced bid may exclude discovery, training, documentation, or post-go-live support. Another may rely on junior delivery staff. Another may have left obvious risks unpriced. Compare what you are buying, not just the front-page figure.

What should we ask for in a Microsoft consultancy proposal?

Ask for detail that matches your project.

If the work involves Azure, Dynamics 365, Microsoft 365, Power Platform, or Copilot, request a proposed approach, named delivery roles, assumptions, exclusions, relevant certifications, and handover expectations. Also ask how the consultancy will handle security, access, testing, and operational continuity.

Is a framework better than a direct appointment?

Sometimes, but not automatically.

A framework can reduce procurement effort and provide comfort where governance matters. A direct appointment can be faster and more practical for focused work. The right route depends on your internal requirements, not on which option sounds more official.

How many suppliers should we invite?

Enough to create proper comparison, but not so many that evaluation becomes noise.

If you invite too few, you may not test the market properly. If you invite too many, you can lose time reviewing weak submissions. A tight, relevant shortlist is usually more useful than a broad sweep.

How do we know if a supplier really understands our business?

Look at the questions they ask.

A good consultancy will probe your scope, challenge assumptions, ask about internal ownership, and test how the technology fits the business process. A weak one will move quickly to a standard proposal and avoid specifics.

What happens after the contract is signed?

That’s when the actual work starts.

You need a proper kick-off, agreed governance, system access, reporting rhythm, and clear ownership on both sides. If onboarding is rushed, even a good supplier can struggle to deliver cleanly.

Ready to Start Your IT Project?

If you're weighing up the procurement of consultancy services for a Microsoft project, don't try to solve everything at once. Get the scope right, choose the right route to market, ask sharper questions, and evaluate bids on delivery value rather than headline cost.

That approach gives you a stronger project before any work begins. It also makes conversations with potential partners far more productive, whether you're planning a Dynamics 365 rollout, Azure migration, cyber security review, Power Platform project, or Copilot initiative.

---

If you'd like a practical conversation about your next IT project, speak with F1Group. Phone 0845 855 0000 today or send us a message.