The horror stories are always the same. The project that was supposed to take six months took eighteen. The budget doubled. The thing that was delivered didn't match what anyone asked for. We've heard these stories from every enterprise client we've worked with. Most of them happened because of what went wrong before a line of code was written.
What You Need to Know
- Most enterprise project failures trace back to scoping, not execution
- Discovery workshops, user research, and technical feasibility assessments prevent the costliest mistakes
- Honest scoping takes time and costs money upfront, but it's cheaper than the alternative
- "We'll figure it out as we go" is the most expensive sentence in software development
Why Scoping Goes Wrong
Scoping goes wrong for three reasons, and they usually all show up together.
The brief is a wishlist. Someone wrote down everything the system should do without prioritising. There's no distinction between "must have for launch" and "would be nice someday." The development team builds to the full list because that's what was agreed, and the timeline blows out because nobody said "not yet" to anything.
Nobody talked to the users. The brief was written by managers, sponsors, and business analysts. The people who'll actually use the system eight hours a day weren't consulted. The result is a system that makes sense on paper and doesn't work in practice.
Technical feasibility was assumed. "It should integrate with our existing system." Great. Has anyone checked whether that system has an API? Whether the data is structured in a way that supports what you want to do? Whether the security requirements of both systems are compatible? These questions don't get asked because everyone assumes the technical team will sort it out during the build.
39%
of enterprise IT projects experience significant scope changes after kickoff
Source: PMI Pulse of the Profession, 2016
That number shouldn't surprise anyone who's worked in enterprise. Nearly four out of ten projects have their scope change significantly after work begins. That's not agile adaptation. That's scoping failure.
The IDESIGN Approach
We've refined our scoping process over sixty-plus projects. It's not complicated, but it requires discipline and a willingness to invest time before anyone starts building.
Step 1: Stakeholder Alignment
Before we design anything, we make sure the people paying for the project agree on what it's for. That sounds obvious. It isn't.
We run a stakeholder alignment session early, usually a half-day workshop with the project sponsor, key decision-makers, and anyone who controls budget or timeline. The goal is to agree on three things: what problem are we solving, who are we solving it for, and what does success look like.
If the stakeholders can't agree on these three things, building anything is premature. We've paused projects at this stage. It's uncomfortable, but it's better than discovering the disagreement six months and $200K into the build.
Step 2: User Research
Once we know what the project is for, we go talk to the people who'll use it.
This isn't a survey. It's sitting with actual users, watching how they do their job today, understanding their frustrations, and identifying the tasks that matter most. We typically do 6-10 user interviews depending on the project size. The investment is small relative to the project budget. The insight is enormous.
User research consistently reveals things that stakeholders don't know. Workarounds that have become invisible. Tasks that take ten minutes but should take one. Features that the brief says are critical but that nobody actually uses.
The best scoping sessions we've run are the ones where we learn something the client didn't know about their own organisation. That usually happens when we talk to the people doing the actual work.
Isaac Rolfe
Managing Director
Step 3: Technical Feasibility
While user research tells us what the system should do, technical feasibility tells us what it can do within the constraints.
We audit the existing technology environment. What systems exist? What data do they hold? What APIs are available? What are the security and compliance requirements? Where will this be hosted?
This isn't a full architecture exercise. It's enough to identify the risks and dependencies that will affect scope, timeline, and cost. Integration complexity is the most common source of scope blowout, and this is where we catch it.
Step 4: Prioritised Scope
With stakeholder alignment, user insight, and technical assessment in hand, we build a prioritised scope.
Not a flat list. A tiered one.
Must have. The features without which the system doesn't solve the core problem. This is the launch scope.
Should have. Features that significantly improve the experience but aren't blocking. These come in the first enhancement cycle after launch.
Could have. Nice to have. These go on the roadmap, not in the budget.
The discipline is in the "must have" tier. If everything is must-have, nothing is. We push back on this. It's our job to.
Step 5: Honest Budget and Timeline
The budget and timeline flow from the prioritised scope. Not the other way around.
This is where most scoping processes fail. The budget is set before the scope is understood, and the team tries to fit an undefined amount of work into a fixed number. The result is either a compromised product or a budget overrun.
We present a range, not a single number. The range reflects genuine uncertainty, because at the scoping stage, uncertainty is real. We'd rather give a client a range of $150K-$200K that we can hit than a point estimate of $120K that we can't.
The Cost of Good Scoping
Discovery and scoping isn't free. For a significant enterprise project, it might take 3-6 weeks and represent 5-10% of the total project budget.
That investment buys clarity. It surfaces risks before they become crises. It aligns stakeholders before disagreements become expensive. And it produces a scope that the development team can actually build to.
The alternative, starting the build with a vague brief and a fixed budget, is how the horror stories begin. We've inherited enough of those projects to know.
One More Thing
Scoping isn't a phase that ends. It's a discipline that continues through the project. New information surfaces during development. Users test early versions and reveal new needs. Technical constraints emerge that weren't visible during discovery.
The difference between a well-scoped project and a poorly scoped one isn't the absence of change. It's the ability to handle change without derailing. When the foundation is solid, when stakeholders are aligned, when the priorities are clear, adapting to new information is a course correction, not a crisis.
That's what good scoping buys you. Not certainty. Confidence.