back

How to Deliver an Unrealistic Project: Principles of Effective Execution

Inside IT Projects

Meet Marcin, he is CEO People More and author books: Managing IT Projects. How Pragmatically for External Customers and 10 Rules for Delivering Unrealistic Projects: How to Succeed in Complex and Challenging IT Projects. 

Tomasz Michalik: Let’s start from the top – what exactly is an unrealistic project? I won’t lie, that’s a strong term. 

Marcin Dąbrowski: It is – but it’s also very accurate. An unrealistic project is one that carries a high risk of failure from day one. The schedule is unachievable, the scope is vague or poorly estimated, and the business goals haven’t been clearly thought through. And the worst part? Everyone knows it… yet the project still gets sold. 

T: But we’ve got entire bodies of knowledge on how to run projects. Why don’t they work? 

M: Because frameworks don’t operate in a vacuum. In theory, everything makes sense – plans, timelines, resources, risk mitigation. But real-world projects are far more complex. If your starting assumptions are already flawed, no methodology – be it PRINCE2 or Scrum – will magically fix a contract based on impossible deadlines and unrealistic budgets

Discover more about why and how do unrealistic projects emerge

T: What are the typical red flags of unrealistic projects? How can you tell when you’re dealing with one? 

M: If we listed all the issues you’re likely to face on such a project, it would be a very long list. But here are some of the most telling signs: 

  • Constant delays, despite the team working overtime to stay on track. 
  • A “boiling” scope – new client demands popping up every week. 
  • A lack of available people or critical skills. 
  • Clients avoiding decisions, constantly changing their minds, or even actively undermining the team. 
  • A real threat of penalties, project freezes, or termination. 

These are projects where everyone knows the goal can’t be met – but no one says it out loud. 

T: So who decides to go ahead with such a project – and why? 

M: It’s usually a result of conflicting interests. Sales wants to close the deal. The client’s management wants to launch the transformation as soon as possible. But nobody asks the opinion of the people who’ll actually have to deliver it. Add to that overly optimistic cost estimates, unchecked assumptions, and time pressure – and you’ve got a project launching on shaky ground. 

T: What are the most common mistakes clients make when engaging with IT company? 

M: Most of all – they fail to clearly define the project’s goal. We often sign contracts based on vague expectations, like “a modern system,” without any concrete KPIs. Sometimes clients don’t know what they want – or want everything at once. Other common issues: lack of internal competence and impulsive changes during execution. 

T: And what about the vendors’ side? 

M: IT company often sign contracts knowing they can’t fully deliver on the terms. They hope they’ll “make it work somehow.” They accept low prices, agree to ambiguous scopes, or even sell a product that doesn’t yet exist – just to win the deal. Then they scramble to fix everything mid-project. That’s a recipe for disaster. 

T: Is there a pattern to these kinds of projects? 

M: Absolutely – and it’s surprisingly consistent. Here are a few recurring traits: 

  • Unrealistic timelines – the most common issue. The schedule isn’t based on team capacity or product maturity, but on business targets imposed from above. It’s often the result of sales-driven promises, not genuine project planning. 
  • Undefined or overly broad scope – a lack of clarity on what’s actually being delivered. This leads to scope creep, with the client interpreting the contract to their benefit, and the team learning about new requirements mid-way. That blows up the budget and schedule. 
  • Underpriced delivery – the project is sold below its true cost. Sometimes this stems from poor estimation, sometimes from strategic decisions to land a client. Either way, it leads to resource shortages, budget cuts, mounting losses, and team frustration. These projects quickly lose priority internally. 

T: What else pushes projects into unrealistic territory? 

M: Unfounded assumptions on the vendor’s side – like assuming a product is ready when it’s not, or that integrating with the client’s systems will be “easy” without actually validating that. This often comes from blind optimism or lack of domain expertise. 

Another issue: contracts without safeguards for the IT company – no defined acceptance process, scope control, or penalty terms. Clients can move the goalposts, delay payments, or keep rejecting deliverables, and the IT company has no leverage. 

There’s also the challenge of misaligned cultures. If the client and IT company have totally different decision-making processes, communication styles, or operational tempos – the project gets stuck. The bigger the mismatch, the greater the risk of misunderstandings and delays. 

Importantly – even one or two of these traits are enough to make a project unfeasible. 

Read more about the role of ethical practices in IT outsourcing

T: Give us three key pieces of advice for avoiding these traps. 

M: First – be honest from the start. If something sounds too good to be true, it probably is. The earlier you raise concerns, the better. 

Second – involve experts early. Bring in delivery or engineering leads during the pre-sales phase. Don’t make decisions without considering technical or organizational reality. 

And finally – make sure the contract is solid: clear scope, realistic timeline, and protections for both sides. That’s the foundation of any successful project. 

T: Thank you for the conversation. We hope this will help many teams avoid costly mistakes and navigate project risks with more confidence. 

Check out our case studies and see the projects we’ve delivered. 

You read conversation with Marcin, CEO People More.  

For more insights on delivering high-stakes projects, check out Marcin Dąbrowski’s book: 10 Rules for Delivering Unrealistic Projects: How to Succeed in Complex and Challenging IT Projects.  

author
Tomasz Michalik