Technology project risks to resolve before you choose a provider

Make the business result part of acceptance

A completed installation does not tell you whether the business problem has improved. Agree on the result the organization expects, how it will be observed, and who can confirm it.

PMI’s 2025 Pulse of the Profession examines business acumen and project success. It supports looking at business value alongside delivery measures. The checks below are practical prompts, not a statistical ranking of failure causes.

For a contact center change, use a realistic customer interaction. For a network change, use the application behavior a site needs. Record what is acceptable and what would prevent rollout.

Resolve decisions that have no owner

Write down who approves scope changes, who coordinates providers, who accepts the service, and who can authorize rollback. “The project team” is too broad when a decision is time-sensitive.

Ask each owner to identify the information they need and the time they require. If a sponsor is unavailable at a key point, agree on a delegate before the transition begins.

Make dependencies visible before setting the date

List carrier installation, site access, number porting, integrations, licensing, staff availability, and security approvals where they apply. Give each dependency an owner and an evidence-based status.

A requested date is different from a provider-confirmed date. Keep that distinction visible in the plan. Discuss the effect of delays on parallel service costs and existing contract commitments.

Test the difficult operating conditions

Use the pilot to challenge the assumptions behind the purchase. Ask how the service behaves when a connection fails, an integration is unavailable, an administrator leaves, or support has to involve more than one provider.

For recovery projects, ask the responsible specialists to agree the recovery objectives, test scope, and evidence required. Record the difference between a successful backup job and a demonstrated recovery of the business service.

Put adoption and handover into the scope

Decide who trains users, updates procedures, manages access, and answers questions after rollout. Ask the receiving team to review the support process before it becomes their responsibility.

Create a short handover record with open issues, escalation contacts, reporting dates, and the person responsible for each next action. Set a business-outcome review alongside the technical service review.

• The sponsor agrees the outcome and scope.
• Every critical dependency has an owner.
• Providers agree their handoffs and escalation route.
• The pilot has written acceptance and rollback criteria.
• The operating team has the capacity and information to take over.

An unresolved item is a reason to investigate. These checks help structure the conversation; they do not guarantee project success.