Software project estimation fails more often than it should. Projection is unicrew’s estimation tool, designed to standardize how teams scope work, capture historical data to improve forecasts, and convert technical estimates into commercial proposals in one place. The goal is fewer failed projects and a consistent process that gets more accurate with every engagement.
Why Software Project Estimation Is So Difficult
The numbers are well-documented and consistently discouraging. According to the Standish Group’s CHAOS Report, only around 35% of software projects are delivered on time, within budget, and with the originally agreed features. McKinsey research found that large IT projects run an average of 45% over budget and deliver 56% less value than predicted. The Project Management Institute estimates that organizations waste an average of $97 million for every $1 billion invested due to poor project performance. Poor estimation is one of the primary drivers of these outcomes — not because the teams are incompetent, but because estimation is genuinely hard and rarely treated as a structured discipline.
Most estimation happens without a consistent process. Teams estimate from memory or intuition, often with no way to reference what comparable projects actually cost versus what was projected. Every estimate starts from scratch. Without a feedback loop connecting estimates to actual outcomes, there is no mechanism for improvement. The same mistakes repeat across project after project, and organizations continue to accept that level of failure as normal when it doesn’t have to be.
At unicrew, we work closely with clients across custom software development and advisory engagements, and we see the effects of poor estimation regularly — in scope creep, in eroded client trust, and in delivery teams trying to execute against targets that were never realistic to begin with. Projection was built to break this cycle.
What Projection Does
Projection is an estimation tool we developed at unicrew to bring transparency and accuracy to what is, in our view, the most decisive stage of any software project. At its core, Projection integrates established estimation techniques into a structured workflow, giving teams a consistent method for working through a project scope and producing realistic time and budget expectations. Rather than relying on each team member’s individual approach, everyone follows the same process, which makes estimates comparable, auditable, and improvable.
What separates Projection from a spreadsheet or ad-hoc approach is what it does with estimation data after the estimate is complete. Every estimate is stored in a central repository, organized in a way that makes it easy to reference when a new project comes in. Over time, this builds an organizational knowledge base: a record of how similar projects were estimated and how closely those estimates matched actual outcomes. When a comparable project arrives next quarter or next year, teams have real data to calibrate against rather than a blank page.
The analytical layer in Projection is designed to leverage those historical insights actively. Teams can look at past projects with similar characteristics — scope, complexity, technology involved — and use those patterns to forecast new work with higher confidence. This is the kind of institutional memory that most software organizations lose between engagements, even when they try to capture it through retrospectives or post-mortems. Projection makes it structural rather than optional.
Collaboration Across Teams
One of the consistent failure modes in software project estimation is that it happens in isolation. A project manager or business analyst produces a scope estimate without sufficient input from the engineers who will actually build it or the QA team who will test it. The estimate looks coherent from the outside but falls apart in execution because the people with the deepest technical knowledge were not meaningfully involved in creating it.
Projection is designed to make multi-stakeholder estimation straightforward. Project managers can bring software engineers, quality assurance specialists, and other contributors directly into the estimation process, ensuring their input is captured in a structured and traceable way rather than filtering through informal conversations. Each contributor’s assessment becomes part of the official record, which makes it easier to understand after the fact why a particular time or cost figure was chosen and whether the original assumptions held.
This also matters for accountability in a constructive sense. When the people whose judgment shaped an estimate can see how they contributed and track what actually happened, estimation becomes a shared responsibility rather than something one person owns and everyone else second-guesses in retrospect. Our business analysis practice emphasizes exactly this kind of structured early-stage collaboration — Projection is the tooling that makes it operational.
From Technical Estimate to Commercial Proposal
There is a persistent friction between development teams and sales teams when it comes to project estimates. Engineers produce detailed technical breakdowns of what a project requires. Sales managers need a client-facing commercial proposal. The two rarely map cleanly onto each other, and the manual effort of translating one into the other introduces delay, duplication, and the risk of errors appearing in the document the client actually sees.
Projection addresses this directly. Once a technical estimate is complete, sales managers can convert it into a ready-to-send commercial proposal in a single step. The breakdown of scope, timeline, and budget is preserved accurately, without requiring anyone to re-enter data or reformat it manually. This reduces the time between completing an estimate and delivering it to a client, removes version-control issues that come with maintaining parallel documents, and ensures the proposal accurately reflects what the technical team actually scoped.
For organizations where turning proposals around quickly is a competitive factor, or where sales and development teams have historically operated with too much distance between them, this integration is one of the most practically valuable aspects of Projection.
Connecting Estimation to Execution
Getting the estimate right is only part of the problem. Once a project is approved, there is significant administrative work that typically happens before the first sprint: high-level tasks and requirements need to be transferred into a task tracking system, estimates need to be populated, and the delivery team needs enough visibility into the plan that they can track progress against it meaningfully. In most organizations, this is largely manual, time-consuming, and creates opportunities for information to get lost in transcription.
Projection handles this handoff automatically. Once a project is approved, it can transfer the high-level tasks and requirements to the task tracking system of choice, populate estimates into that system, and then provide visibility into progress against those figures as work proceeds. The data captured during estimation does not sit in a separate document that delivery teams rarely open again — it becomes the foundation for active project management.
This end-to-end continuity — from initial scoping through estimation through execution — is the fuller version of what Projection is designed to do. Estimation is not only a sales or planning activity; it is the first in a chain of commitments that runs through delivery. Keeping that chain connected, rather than letting it break the moment a project is signed, is what transparency in software development looks like in practice.
Projection at RISE, Hong Kong
In 2017, we presented the Projection prototype at RISE in Hong Kong, one of Asia’s largest technology and startup conferences. Presenting there reflected our view that the estimation problem is not specific to unicrew or to any particular type of organization — it is a structural challenge across the software development industry, and one that deserves to be addressed with the same rigor applied to any other engineering problem.
The core of what we brought to RISE was straightforward: most organizations, regardless of size or maturity, have not established even a minimally standardized approach to project estimation. Projection was our attempt to make that standardization accessible and practical rather than something that requires a dedicated project management office or years of process-building to implement.
“We promote business transparency at each level of technological partnership. It’s a part of our business philosophy to continuously improve our operations by leveraging the power of simplicity. Estimation is, essentially, the most decisive stage of a project that is often to decide its chances to succeed and, unfortunately, very few organizations can claim to have at least barely standardized approaches of projects’ evaluation leading to a phenomenal amount of failures. Our primary mission with Projection is to radically change such state of things in software development industry.”
Tural Mamedov, Co-Founder and CEO, unicrew
Frequently Asked Questions
What is software project estimation?
Software project estimation is the process of forecasting how much time, effort, and budget a software development project will require before work begins. Accurate estimation involves analyzing scope, identifying risks, drawing on historical data from comparable projects, and involving the right stakeholders — including developers and QA engineers — in the process. It is consistently identified as one of the most critical and most frequently mishandled activities in software delivery.
Why do software projects fail due to poor estimation?
Poor estimation produces unrealistic timelines and budgets that teams cannot deliver against. When an estimate is too low, projects run over budget and schedule, client expectations go unmet, and trust is damaged. Without a structured process that captures and learns from past estimates, the same estimation errors repeat across projects indefinitely. McKinsey research found that large IT projects deliver 56% less value than predicted on average — a gap that traces directly back to what was promised during estimation.
How does Projection differ from managing estimates in a spreadsheet?
Spreadsheets are static and isolated: each estimate lives in its own document with no connection to past estimates or future forecasting. Projection stores all estimates in a shared repository, enabling teams to reference historical data when scoping new work. It also integrates team collaboration during the estimation process, generates commercial proposals directly from technical estimates, and connects to task tracking systems for post-approval execution. The result is a continuous, improving process rather than a series of disconnected one-off documents.
What types of organizations benefit most from standardized estimation?
Any organization that regularly estimates and delivers software projects benefits from a standardized process — but the gains are particularly significant for software development companies, product teams that ship on a recurring cadence, and any organization where sales and technical teams need to collaborate closely on scoping. The more projects an organization runs, the more valuable the historical data becomes: estimation accuracy compounds with every project that gets tracked and learned from.