Project Delivery – expectations vs reality 

Because theory rarely survives first contact with reality. That famous trio — “time, scope, quality” — assumes the project goal is fixed. But from the moment a contract is signed to the point of go-live, months or even years go by. During that time, the market changes, company priorities shift, and the client evolves, because they’re learning what they truly need. If the vendor rigidly sticks to a contract written years ago, they might technically deliver the project… but also ruin it. 

So you can’t fairly evaluate success based on initial conditions — because they almost never remain the same until the end. 

A contract is a starting point — not a sacred script. Project planning happens early, but success depends on the ability to adapt as things unfold. A client comes into a project with a vision, but that vision evolves. Often, they only begin to understand their true needs during implementation. Maybe the original plan called for a full platform rollout, but it turns out only one module brings real value. That’s where the focus should go. 

In large-scale implementations — like IT platforms for banks or telecoms — it’s common for the market, end users, or even key decision-makers to change during the long negotiation and prep phase. So new expectations start surfacing — usually not out of whim, but as part of the client’s learning curve. 

First and foremost: you have to stay in constant contact with the client. Don’t wait for formal status meetings. Be close, stay informed about what's happening inside their organization, how their goals are shifting, and where the bottlenecks are. And then respond. If the client is running out of budget or going through a restructure, you need to know as early as possible — so you can narrow the scope, reset priorities, and deliver actual value instead of just “checking the contract boxes”. 

In other words, figure out what really matters to the client. What milestone would allow them to declare internal success? What delivers the biggest value in the shortest time? Then align the team, priorities, and communication around that. And have the courage to talk about change instead of clinging to outdated assumptions. That’s what separates a “delivered on paper” project from one that truly succeeds. 

Of course, not every change request should be accepted blindly. If scope keeps expanding while deadlines stay fixed, you’re heading toward the kind of “unrealistic” project we’ve talked about before. That’s why we must respond appropriately to each situation. 

I know those scenarios well and they’re more common than people think. A company might lose funding, shift strategy, or prepare for a merger, but nobody says it out loud. Meanwhile, the schedule keeps running like nothing’s changed. It’s critical for the vendor to understand the client’s context — build relationships beyond the project manager, including with decision-makers. Sometimes one informal coffee chat is enough to spot a shift and adjust course before it’s too late. 

A project might kick off full steam and then, a year in, the client no longer knows why it’s continuing. You need to monitor the mood, talk to people at various levels, and watch for shifting priorities. And sometimes, you simply have to ask: “Does this project still make sense?” 

Very often. The client might care about a specific KPI — like shortening user onboarding time, going live before an audit, or cutting headcount in a department. 

The vendor, on the other hand, might define success as something else: minimizing financial losses, freeing up their team for another strategic rollout, or being able to use the product implementation as a base for future development. Without ongoing communication both sides might keep pushing ahead, completely misaligned. 

Focus on key milestones — the ones that bring actual business value to the client. Instead of trying to deliver everything at once, find the one element that allows the client to say: “This works. This makes sense. Let’s keep going.” That gives them a feeling of internal success and gives us the leverage to continue. That trust is what opens the door to adjusting the contract, resetting expectations and staying in sync. 

The key to all this? A relationship-focused dialogue. Think long-term. Don’t just enforce contract clauses line by line. 

Exactly. In IT project management “delivery” is a dynamic concept that needs to be constantly redefined — from planning to closure. If we treat a project like a checklist, we’ll miss the signals that it’s time to talk to the client and adjust to their new situation. 

The client might think: “They delivered… but not what I need now.” That leads to a system nobody uses and a contract nobody’s happy with. Real success isn’t “contract compliance” — it’s understanding what success means for the client and for us today, not just when we first signed the agreement.