Supplier Management

Supplier management across the relationship

How to Manage a Web Development Project

Managing a web development project through an external supplier is fundamentally about reducing uncertainty. The business knows what it needs; the supplier knows how to build it. The gap between those two positions is where projects stall, budgets overrun and relationships break down.

Start by agreeing a single point of contact on each side. A project manager or product owner on your side, and a named lead on theirs. When questions flow through multiple people, decisions slow down and contradictory instructions reach the development team.

Establish three things before any code is written: what will be built, how you will know it is finished, and what happens if it is not. The first is the specification or scope. The second is the acceptance criteria, covered in detail elsewhere in this guide. The third is the contract term that governs rework, defects and dispute resolution.

Break the work into milestones that map to usable states of the software, not arbitrary calendar dates. A milestone titled "week four" tells you nothing about progress. A milestone titled "user registration and login working on staging environment" gives you something concrete to verify.

Retain access to the environments, repositories and infrastructure from day one. Read-only access is sufficient during development, but you need the ability to see what is being built without waiting for a scheduled demo. If a supplier insists on full control of all access credentials, treat that as a risk to be managed, not a normal arrangement.

Communication Expectations with Software Suppliers

Communication problems are rarely about volume. They are about clarity, timing and traceability. Agreeing expectations upfront prevents most of the friction that derails projects later.

Define which channels are used for what. Instant messaging suits quick clarification. Email suits decisions and instructions that need a record. A ticketing system suits bug reports and change requests. When everything happens in a single chat channel, important decisions get buried and impossible to find weeks later.

Agree response-time expectations in writing. A supplier committing to "we will get back to you" is meaningless. A commitment to "we will acknowledge queries within four working hours during UK business hours and provide a substantive response within one working day" is something you can hold them to.

Clarify who is authorised to give instructions. If three different people in your organisation email the supplier with conflicting requests, the supplier is not at fault for following the wrong one. Document the decision-making hierarchy and share it with the supplier at the start.

Decide how change requests are handled before you need one. The moment you ask for something outside the agreed scope, the supplier must have a clear process: log it, estimate it, get approval, then build it. If change requests are handled informally in conversation, you will both lose track of what was agreed and what was extra.

How to Run Effective Project Status Meetings

A status meeting should answer three questions: what has been completed since last time, what is blocked, and what decisions are needed from the business. Anything beyond that belongs in a different conversation.

Keep them short. Thirty minutes is usually sufficient for a focused update. Longer meetings tend to drift into technical discussions that should happen separately with the relevant people, not in front of the entire group.

Request a written status update before the meeting, not during it. When the supplier reads out progress in the call, you cannot verify it, challenge it or refer back to it. A brief written update circulated a few hours beforehand lets you come prepared with questions.

Separate status updates from technical problem-solving. If a developer starts explaining why a particular integration is difficult, gently park it. The status meeting is not the place to debug architecture. Note the issue, assign it to the right people and move on.

Always confirm actions and owners at the end. "We will look into that" is not an action. "Sarah will confirm the API credentials by Thursday" is. If the meeting ends without clear next steps, it was a conversation, not a project meeting.

When to Change Development Suppliers Mid-Project

Changing suppliers partway through a build is expensive and disruptive, so the threshold must be high. But continuing with a failing supplier is more expensive still. The decision turns on whether the problems are fixable or structural.

Fixable problems include a slow start while the team ramps up, early misunderstandings about requirements that get resolved through better specification, or temporary resource gaps. These are frustrating but normal. Structural problems include persistent missed milestones without credible explanation, refusal to provide access to code or environments, unresponsive communication over a sustained period, or discovery that the supplier does not have the technical capability they claimed.

Before making a change, check your contractual position. What does the contract say about termination? Is there a notice period? Who owns the work produced so far? If you do not have clear answers to these questions, resolve them before you trigger a dispute.

Verify that you can actually take the work elsewhere. This means confirming you have access to the source code repository, the database, the infrastructure credentials and any third-party service accounts. If the supplier controls all of these, you are not in a position to switch cleanly. Secure access first, then terminate.

Document everything. If you reach the point of a formal dispute or transition, contemporaneous records of missed deadlines, unclear communications and unfulfilled commitments will matter far more than your memory of events.

Managing Multiple Software Suppliers

Using more than one supplier on a single project or system landscape introduces coordination risk that does not exist with a single vendor. The main challenge is not technical; it is contractual and procedural.

Define clear boundaries between suppliers. Which one owns the core application? Which one handles integrations? Which one manages infrastructure? When boundaries are ambiguous, both suppliers may assume the other is responsible for a gap, or both may make changes that conflict.

Put integration responsibilities in writing. When Supplier A builds an API and Supplier B consumes it, who writes the specification? Who tests the integration? Who is responsible when it breaks in production? These questions need answers before the work starts, not after something fails.

Appoint a single technical authority. Even if you trust both suppliers, someone needs the final say when their approaches conflict. That authority might be an internal lead, a freelance architect or one of the suppliers with a clearly defined scope. Without it, you become the reluctant arbitrator of technical disagreements you are not equipped to judge.

Be cautious about intellectual-property boundaries. If Supplier A writes code that Supplier B then modifies, determining who owns what becomes complicated. Your contract with each supplier should state that all work produced for your project is assigned to your business, removing ambiguity.

In-House vs Outsourced Development Teams

The choice between in-house and outsourced development is not a simple cost comparison. It is a decision about control, speed, capability and long-term flexibility.

In-house teams offer direct control over priorities, deep institutional knowledge of your systems and immediate availability for changes. They also require recruitment, management, equipment, ongoing training and retention effort. The true cost of an in-house developer includes salary, employer contributions, office space, management overhead and the cost of vacancies when people leave.

Outsourced teams offer access to skills on demand without recruitment overhead. You pay for the work, not the idle time. But you lose direct control over daily priorities, introduce communication overhead and face the ongoing risk of supplier dependency. Knowledge about your systems lives partly outside your organisation.

Hybrid models are common and often pragmatic. A small internal team manages the product direction, owns the architecture and oversees suppliers who handle development capacity. This keeps strategic control inside the business while avoiding the need to staff an entire development department.

The right choice depends on how central software is to your business. If your product is software, in-house capability is usually justified. If software supports your operations but is not the product itself, outsourcing with strong supplier management is often the better starting position.

How to Onboard a New Development Team

Onboarding a new supplier or team is where many businesses underestimate the effort required. The assumption that a competent team will simply pick up the work leads to weeks of low productivity and frustration on both sides.

Prepare a structured handover document before the new team starts. This should cover the business context, the current system architecture, the technology stack, the deployment process, known issues and outstanding work. If this document does not exist, creating it is your first priority.

Grant access to everything the team will need on day one: code repositories, staging environments, databases, third-party APIs, project management tools and communication channels. Access delays are the most common cause of a slow start and are entirely preventable.

Introduce the team to the right people, not everyone. They need to know their direct contacts, the product owner or business stakeholder, and anyone responsible for adjacent systems they will integrate with. Large introductory meetings with the whole company waste time and overwhelm.

Set a clear first deliverable. Rather than a vague "get up to speed" period, define a small, concrete piece of work that the team can complete in their first one to two weeks. This forces early engagement with the codebase, reveals gaps in access or documentation and gives both sides an early signal of how the working relationship will function.

Managing a Distributed Development Team

Distributed teams, whether in different UK locations or across time zones, introduce specific challenges that colocated teams do not face. The management approach needs to account for these explicitly rather than assuming normal practices will translate.

Establish overlapping working hours. A team with no overlap with your business hours cannot make progress without delayed decisions. Even a two-hour window where both sides are available makes a significant difference. Document this window and protect it from being eaten by other meetings.

Shift towards asynchronous communication. If every question requires a live conversation, progress depends on calendar alignment. Written briefs, recorded walkthroughs and detailed ticket descriptions allow the distributed team to continue working while you are offline.

Be explicit about expectations that colocated teams take for granted. Response times, preferred communication channels, how to signal that something is blocked and when to escalate are all things that happen naturally in an office but must be deliberately established with a distributed team.

Verify output, not activity. When you cannot see people at their desks, there is a temptation to monitor activity as a proxy for productivity. This is counterproductive. Instead, define clear deliverables for each period and assess whether they are met to the required standard.

How to Escalate Issues with a Software Supplier

Escalation is not the same as complaining. Effective escalation is a structured process that moves a stalled issue to someone with the authority to resolve it. The goal is to unblock the project, not to punish the supplier.

Start by confirming the issue is genuinely stuck. Has it been raised clearly, in writing, with enough detail for the supplier to act? Has a reasonable deadline been set? If the original request was vague or the deadline was implicit, the supplier may not recognise it as a problem. Before escalating, ensure you have a clear, documented request with a stated deadline that has passed.

Follow the escalation path defined in your contract. Most well-drafted agreements specify a sequence: operational contact first, then project manager, then account director, then senior management. Skipping levels damages the relationship and may give the supplier grounds to argue you did not follow the agreed process.

Keep escalation communications factual and specific. "This project is a mess" gives the supplier nothing to act on. "The login feature was due on 12 March per milestone three of the statement of work. As of 28 March, it is still not functional on the staging environment and no revised date has been provided" is something their management can investigate and address.

Know what outcome you want before you escalate. A revised timeline? A replacement resource? A contractual remedy? If you escalate without a clear request, the supplier's management will respond with reassurance rather than action. State the problem, state the impact on your business and state what you need to happen next.

Document the escalation and the response. If the issue eventually leads to a contractual dispute or a decision to change suppliers, your escalation record demonstrates that you followed a reasonable process and gave the supplier opportunity to resolve the problem.

The business remains accountable

• Appoint one empowered owner on the business side.
• Keep decisions, risks and commitments in a shared written record.
• Judge progress by accepted outcomes, not activity volume.
• Maintain direct control or protected access to critical assets.
• Prepare for transition before the relationship becomes difficult.