We lost money on a project this year. Not because we under-delivered. Because we under-scoped. The client got exactly what they asked for. The problem is that what they asked for was about 40% of what they actually needed, and we didn't catch it early enough. That project changed how IDESIGN scopes every engagement since.
What Happened
The brief looked manageable. A mid-sized organisation needed a custom web application to replace a manual process. They had a clear idea of the features. They had a budget. They had a timeline. On paper, it was a solid project.
We scoped it based on the features they described. We quoted it. They accepted. We started building.
Three weeks in, the scope started moving. Not because the client was difficult. Because we hadn't asked the right questions. The "manual process" we were replacing turned out to involve five different spreadsheets, two legacy systems, and a set of business rules that lived entirely in one person's head. The features the client described were the visible part of the problem. The invisible part was twice the size.
We finished the project. We delivered something they could use. But we absorbed the overrun because the scoping failure was ours, not theirs. The client didn't hide information. We didn't dig deep enough to find it.
The Lesson
Scoping isn't about listing features. It's about understanding the problem completely enough to know what the solution actually requires. That sounds obvious. It isn't, in practice.
When a client says "we need a system that does X," the natural instinct is to scope X. Estimate the screens, the data model, the interactions, the testing. X is concrete. You can put hours against it.
What's harder to scope is everything around X. Where does the data come from? Who enters it? What happens when it's wrong? Who approves what? What are the edge cases that the daily users know about but the project sponsor doesn't? What are the integrations nobody mentioned because they assumed we already knew?
That's where the real scope lives. And that's where we failed on this project.
The client didn't move the goalposts - we put the goalposts in the wrong place. That's a scoping problem, not a client problem.
Isaac Rolfe
Managing Director
What We Changed
After that project, I changed our scoping process. Three things are different now.
We scope the problem before we scope the solution. The first phase of any engagement is understanding the current state. Not what the client wants to build, but what they're doing now. Every spreadsheet, every manual step, every workaround, every exception. We map the current process in detail before we propose anything. This takes longer. It also prevents the kind of surprise we hit on that project.
We name the things that are out of scope. It's not enough to define what's in scope. We now explicitly list what's out of scope and confirm it with the client. "This project does not include migrating data from your legacy system. That's a separate project with a separate scope." Clients appreciate the honesty. They also sometimes respond with "actually, we need that too," which is exactly the conversation you want to have before signing a contract, not three weeks in.
We say "that's a different project" more often. This was the hardest change. When a client asks for something mid-project that's outside the original scope, the instinct is to accommodate. You want to be helpful. You want to keep the relationship strong. But absorbing scope creep damages both. The project runs late, the team is stretched, and the client starts to wonder why something "simple" is taking so long.
Now, when scope expands, we name it. "That's a valuable addition and we should absolutely build it. It's a different project. Here's what it would take." Some clients push back. Most appreciate the clarity. All of them get better outcomes than they would from a team that says yes to everything and delivers late.
The Cost of Getting It Wrong
Under-scoping costs more than the money you lose on the overrun. It costs trust. The client starts to wonder whether you understood the problem. Your team starts to wonder whether the project will ever end. The next project gets over-scoped because everyone is compensating for the last one.
There's also an opportunity cost. Every week spent on unscoped work is a week you're not spending on the next client, the next project, the business development that keeps the team employed. Small studios like IDESIGN don't have the margin to absorb overruns casually. One badly scoped project can shape a quarter.
Honest Scoping as a Competitive Advantage
Here's what I didn't expect. Being more honest about scope has won us work. Clients tell us they chose IDESIGN because we were the only team that told them their project was bigger than they thought. Other firms quoted low and planned to handle the overruns later. We quoted accurately and explained why.
That's not a sales tactic. It's just honest. But in an industry where optimistic estimates are the norm, honesty stands out.
We still lose money occasionally. Complex projects have genuinely unknowable elements. But we haven't had another project where the scope was wrong because we didn't ask enough questions. That client taught us to ask them.