How are third-party suppliers managed during an IT project?

Third-party suppliers are managed as controlled participants in the IT project, with their work assessed, commissioned, monitored and integrated into the overall delivery plan. This includes suppliers such as connectivity providers, cloud service partners, hardware installers, software specialists and external consultants. The objective is to ensure that each supplier contributes to the intended outcome without introducing unmanaged technical, security or operational risks.

Supplier selection and assessment

Before appointing a supplier, the project team should establish what specialist capability is required and whether the proposed supplier can meet it. Assessment may cover:

• Relevant technical experience and understanding of the organisation’s environment
• Compatibility with existing infrastructure, applications and security controls
• Support arrangements, escalation routes and ownership after implementation
• Data handling practices and the level of access the supplier will require
• Capacity to meet the project’s planned sequence and dependencies
• Evidence of suitable insurance, qualifications or sector-specific obligations where relevant

Supplier choice should not be based solely on price. A lower-cost option may create additional integration, support or security work if its solution does not fit the wider environment.

Defining the commercial and technical agreement

Each supplier’s engagement should be documented in a statement of work, purchase order or contract that is specific enough to be managed. It should describe the required outputs, assumptions, acceptance criteria, responsibilities, costs, exclusions and any conditions that could affect delivery. The agreement should also state who owns configuration data, licences, documentation and other project assets when the work is complete.

Acceptance criteria are particularly important. They provide an objective basis for deciding whether a supplied system, service or installation is ready to be accepted. For example, acceptance may depend on successful configuration, completion of agreed tests, production of required documentation and confirmation that administrators can operate the service correctly.

Controlling access and information

Supplier access should be limited to the systems, information and period necessary for the assigned work. Access requests should identify the individual, purpose, permission level and approving person. Privileged access requires particular care because it may allow changes to servers, cloud services, network equipment or business data.

Practical controls can include named user accounts, multi-factor authentication, approval before access is granted, activity logging and removal of permissions when the task ends. Sensitive information should be shared only where it is required, using an agreed and appropriately protected method. These controls reduce the risk of an account, credential or misunderstanding affecting the wider project.

Co-ordinating technical work

Supplier activities should be sequenced around the organisation’s operational requirements and the work of other contributors. The project manager or IT project consultant acts as a point of co-ordination, confirming what information each supplier needs, identifying decisions that require client approval and checking that one supplier’s changes do not undermine another’s work.

This is especially important where a project involves several connected components. A connectivity change may affect remote access; a cloud configuration may depend on identity settings; and a hardware installation may require network, power or security changes. Keeping these relationships visible helps the project team investigate the right cause when an issue appears, rather than treating each supplier’s work in isolation.

Managing changes and problems

Supplier requests that alter the agreed solution, cost, timescale or risk profile should go through the project’s change process. The impact should be recorded and reviewed before approval, rather than allowing an apparently minor adjustment to become an undocumented change to the wider design.

When a supplier reports a problem, the project team should record the issue, its effect, the responsible owner, the next action and the route for escalation. Technical disagreements are best resolved using evidence such as configuration records, test results, logs and the agreed acceptance criteria. If a supplier cannot resolve an issue within its remit, ownership should be transferred clearly rather than allowing the matter to remain between organisations.

Testing and acceptance

Supplier deliverables should be tested in an environment and sequence appropriate to the project. Testing may include functional checks, access validation, integration checks, performance observations, backup or recovery verification and user acceptance. The exact tests depend on the change being delivered and the risks involved.

Results should be recorded, including any defects, restrictions or outstanding actions. A supplier’s statement that work is complete is not the same as formal acceptance by the organisation. Acceptance should occur only when the agreed criteria have been met or an authorised decision has documented what remains unresolved.

Closing the supplier engagement

Before a supplier’s project work is closed, the organisation should confirm that it has received the information needed to operate and support the result. This may include network diagrams, configuration details, asset records, licence information, administrator arrangements, support contacts, maintenance requirements and relevant test evidence.

Access that is no longer needed should be removed, temporary accounts disabled and any borrowed equipment returned. The project team can then review the supplier’s delivery, record lessons for future projects and confirm whether ongoing support belongs with the supplier, the internal team or an IT services partner. This makes the transition into normal operations deliberate rather than leaving the organisation dependent on undocumented supplier knowledge.