Why projects stall when there are many contractors

Problems in an IT project rarely sit neatly inside one clear work block. More often things break down at the seams: between hardware delivery, licenses, configuration and go-live. While each contractor is only responsible for their part, the overall result can easily get stuck.

A typical situation is simple. The hardware is already on site, but implementation doesn't start: activation keys aren't ready, the configuration isn't approved, access rights haven't been given. Formally the project is progressing. In reality — it's at a standstill.

Delays often begin when:

hardware is delivered but its configuration differs from what the implementation team expected;
licenses are paid for but not yet activated or set up under the correct scheme;
the integrator is waiting for access or approvals from another party;
installation can start, but nobody wants to take the risk early.

Because of this, the customer quickly turns into a dispatcher. They have to gather emails, check document versions, figure out what everyone meant, and find where things got stuck. Every change costs extra time because each participant focuses only on their piece and isn't responsible for the final result.

This is most visible in projects for government bodies, schools, clinics and large companies where acceptance is formalized. One contractor says, “we delivered.” The second replies, “we'll start after the stage is signed off.” The third is waiting for prior work to be closed. There may be no major technical problem, but deadlines still slip.

When nobody owns the entire chain end-to-end, the project almost always moves in fits and starts. And it's exactly along that chain — from hardware and licenses delivery to users being able to work in the system — that weeks are often lost.

When a single contract is actually more convenient

A single contract is especially convenient when what's important is not the delivery itself but a ready result by a specific date. You can't "partially" open a new office, branch, classroom or medical room. On launch day people need workstations, access, software and configured hardware.

With this approach the customer gets one schedule, one responsible party and one clear result. It's not always cheaper, but it's almost always easier to manage.

If hardware, licenses and configuration are delivered as a single package, there is less confusion about compatibility, timelines and acceptance. The recurring question "who should verify the configuration, who prepares the workstation images, and who is responsible if everything is purchased but the launch failed" disappears.

A single contract is especially handy when the launch is tied to a hard date, many identical workplaces must be deployed quickly, the internal team has little time for coordination, and downtime after launch is costly.

Imagine a new branch for 50 employees. You need to bring computers, prepare the server or cloud infrastructure, install licenses, connect users, check the network, printing and basic security policies. If three different companies handle this, the customer has to coordinate the whole route. If one team handles both delivery and implementation, the launch usually goes smoother.

Another benefit: issues are resolved faster. After installation there is no argument like "the hardware is ours, the configuration isn’t." For the customer that's the main thing — they need a working service, not a long exchange about responsibility boundaries.

This approach is especially useful where the in-house IT team is small or busy with day-to-day tasks. Instead of dozens of approvals there is one line of communication and less manual control.

For such projects it's usually convenient to have a partner who can cover hardware delivery, licenses and implementation in one loop. In Kazakhstan, for example, GSE.kz supports this model: the company manufactures PCs and servers, provides system integration, and operates through a nationwide service network. That doesn't mean one contract is always the best, but for deadline-driven launches this format often proves the most reassuring.

When it's better to split lots

Splitting lots can also be reasonable. It helps when the customer already has a strong in-house team and doesn't need a single contractor to run the entire project.

If your specialists make architectural decisions themselves, control schedules and can coordinate suppliers, there's no point buying an all-in-one project management service together with the delivery. In that case hardware, licenses and implementation can be procured separately.

A common reason to split is different budgets. Servers and workstations may fall under one cost item, licenses under another, and implementation services under a third. When you try to bundle all that into one contract, approval can take longer than the delivery itself.

Separate lots also make sense when one part of the project is standard while another requires rare expertise. Basic infrastructure, workstations or servers can go to a major manufacturer or system integrator. Implementation of a specialized medical, banking or manufacturing system should go to a team that does such projects every day.

Splitting usually works well under three conditions: your team has experience running a project in blocks, responsibilities are defined in advance, and the dependency between stages is low. If any of these conditions is missing, you can easily trade potential savings for disputes between contractors.

You should also consider tender rules and internal procurement policy. Sometimes a hardware lot is easier to justify by delivery times, localization and service, while an implementation lot is justified by the team's qualifications and experience with the required system. For formal procurements this is often more practical than one large contract.

A simple example: a company updates its PC fleet, buys a server and renews licenses while simultaneously implementing an industry-specific system. Standard hardware delivery can be put in a separate lot, and the specialized implementation left to a niche contractor. The key is to split not for form's sake, but when it truly simplifies budgeting, control and selecting the right specialists.

How to decide — step by step

Start not from a list of items, but from the end result. Not "buy 50 PCs, a server and licenses," but "open the branch by September 1 so employees can work from day one in the accounting system, email and a secure network." When the goal is phrased like this, it's clear that it's not enough to bring hardware — it must be configured, checked for compatibility and delivered in working order.

Next, separate mandatory work from optional work. Mandatory items usually include hardware and license delivery, installation, basic configuration, connection to existing infrastructure and acceptance testing. Anything that doesn't directly affect the launch should not be overloaded into the main contract unless necessary.

Then look at dependencies. If servers, workstations, licenses and implementation are tightly linked, splitting contractors almost always adds risk. If delivery is standard and implementation is barely dependent on a specific supplier, splitting can proceed smoothly.

Answer a few simple questions:

what outcome must be ready by a specific date;
which tasks are essential for launch;
where one contractor critically depends on another;
who accepts the result as a whole, not in parts;
what is preferable from a risk and timing perspective: one contractor or several.

Acceptance is especially important. If there is no person or team to confirm that the project actually works as a whole, a good delivery alone won't save you. Documents will be closed, but users will still lack access, configuration or support.

What to define in advance

Even with one contractor, a project can go off course because agreements are unclear. Single responsibility works only when it's clear in advance what is included, within what deadlines, and under what rules the project is considered finished.

The first thing to fix is the exact scope of delivery. Not "server and licenses," but specific models, quantities, configurations, software editions, license validity periods and the list of services. If the project includes servers, workstations, operating systems, office suites, installation, commissioning and training, list each block separately.

The second mandatory document is a schedule. It should include not only the final go-live date but also milestones: when the specification is approved, when hardware arrives, when licenses are ready, when configuration starts, when data migration happens and when the project goes to acceptance. Without these markers disputes usually start with "we thought that would be later."

It's equally important to define roles in advance. Who installs hardware on site, who configures the system, who migrates data, who connects users, who trains staff. If the customer performs some tasks, that should be stated explicitly.

Acceptance should be measurable. Not "system implemented," but a clear set of criteria: hardware installed, licenses activated, users can log in, printing works, data is migrated, issues are closed or moved to a separate stage. The clearer the criteria, the fewer disputes at the finish line.

One more important block is post-launch support. Who accepts requests, who is responsible for hardware warranty, who handles license issues, who fixes implementation errors and in what timeframes. If these rules aren't defined, the project may be formally finished while real problems start once the system is in use.

A simple practical example

Imagine a common task: a school needs a new computer lab ready by September 1. It's not enough to bring the hardware — each workstation must be ready so teachers and students can start lessons on day one without disruption.

There are almost always three dependent stages: deliver computers, activate licenses and configure each workstation. If any step is delayed, the others stall. Boxes may be sitting in the classroom, but you still can't use them.

When procurement is split into separate lots, one common outcome appears: one supplier delivers PCs on time, another is still finalizing licenses, and a third waits for hardware and access to configure. Formally everyone did their part, but the classroom still isn't ready.

If one contractor is responsible for hardware delivery, licenses and commissioning, it's much easier to keep a single schedule. The school doesn't have to figure out whose responsibility it is if an image doesn't fit, a license won't activate, or a shared printer isn't visible. There's one responsible party and one remediation deadline.

For typical education projects this is often more convenient than managing multiple contractors. The customer receives not a set of separate stages but a working classroom.

Common mistakes when combining a project

The main mistake is bundling hardware, licenses and implementation into one contract without a shared launch plan. On paper it looks tidy, but in practice things quickly desynchronize: hardware has arrived, licenses aren't ready, and the implementation team is waiting for access and approvals.

A second frequent problem is that the customer has no internal project owner. Even if the contractor offers a single point of responsibility, without someone inside the organization making daily decisions matters get stuck between IT, procurement, security and management.

Another mistake is mixing standard delivery with unclear customizations in one stage. Basic items like delivering PCs, servers, standard licenses and typical configuration can usually be planned in advance. Disputed integrations and non-standard requirements should be taken out into a separate stage so they don't block the whole launch.

Finally, choosing the scheme based only on price is risky. Low cost may mean weak service: slow responses, vague responsibility boundaries, no buffer in schedules or poor post-launch support. Then initial savings quickly turn into losses after deployment.

Mistakes usually look like this:

only the contract date is fixed, not the readiness date for each stage;
mandatory minimum isn't separated from optional work;
it's not clear who is responsible for service after launch;
the escalation procedure if something goes wrong isn't described.

Quick checklist before starting

Before signing a contract it's useful to run a short check. It quickly shows whether the project is ready for launch or already contains potential delays.

First, make sure the outcome is stated in simple terms. Not "delivery of hardware and licenses," but for example, "100 workstations are ready to use, users can log in, email and required software are configured."

Then check if there's one unified plan. Server delivery, license activation, configuration, testing and launch shouldn't live in separate spreadsheets without a single finish line.

Then answer three more questions. Who brings the whole project route together? Are commonly forgotten blocks like basic setup, data migration, training and acceptance tests included? And is post-launch support clear: who accepts requests, who fixes failures and in what timeframes?

If you can't clearly answer at least two of these questions, the project is still immature. It's much better to spend a day aligning things before start than to lose weeks later on disputes between a hardware supplier, a software vendor and the internal IT team.

What to do next

Don't start by choosing a contractor. First map the project briefly: what hardware is needed, which licenses, what work must be done and by which dates everything must be operational. Even a simple one-page list helps reveal risks in timing, compatibility and responsibility.

Then split the project not by habit but by logic. If servers, workstations, licenses and implementation are tightly interdependent, a single point of responsibility usually saves time. If parts of the project operate almost independently, you can split lots without extra risk.

For projects in Kazakhstan ask one practical question: is there a partner who can cover not only delivery but also implementation and ongoing support? This is especially important for governmental, educational, medical and large corporate projects where downtime and unclear responsibility are costly.

Look at actual capabilities, not promises: does the contractor have their own service base, integration experience, a clear support scheme and resources to deliver on time. A useful next step: make a table with four columns — hardware, software, works, support — and for each item list either one responsible party or a reason why this block should be a separate lot. After that the decision usually becomes much clearer.