How to scope a custom software project without the usual overruns

Why software projects overrun

The numbers on large IT projects are sobering. McKinsey and the University of Oxford studied more than 5,400 IT projects with budgets above $15 million. On average they ran 45% over budget and 7% over time, and delivered 56% less value than predicted.

The average isn't the whole risk. Bent Flyvbjerg and Alexander Budzier looked at 1,471 IT projects and found an average cost overrun of 27%. But one in six was an extreme case, with cost overruns averaging 200% and schedules running almost 70% late. Their advice includes breaking big projects into pieces of limited size, complexity and duration.

Your project is probably far smaller. The causes scale down anyway: a vague goal, requirements that keep moving, surprises in the data and one big launch that tests everything at once. Each of them can be handled in the scope.

Start from the problem and a number

“We need a new portal” is a solution. “Customers wait three days for a quote, and some of them buy elsewhere” is a problem. Scope from the problem.

Write two sentences: what's wrong, who feels it and how you'll know it's fixed. Then pick the number. Days to quote. Hours a week spent retyping. Errors per hundred orders. Measure it now, so you can compare it later.

A clear outcome is your best defense against scope creep. When someone asks for a new feature, the question becomes simple: does it move the number?

Map how the work runs today

Follow a few real cases from start to finish. Write down each step, who does it, which system or spreadsheet they use and where the work waits.

Then collect the exceptions. The rush order. The customer with special pricing. The form that arrives half filled in. Keep asking “what happens when…” until people run out of answers. Exceptions are where estimates go wrong, so get them on paper before anyone quotes.

Keep copies of the real documents, screens and reports people use today. A builder learns more from ten real invoices than from a page of requirements.

Separate must-have from nice-to-have

Sort every requested feature into three groups.

• Must have for the first release: without it, the problem isn't solved.
• Should have soon: valuable, but people can work around it for a few weeks.
• Nice to have: wait and see whether anyone still asks for it after launch.

Be strict. If the first group runs past a handful of items, the release is too big. A useful test: could the team use this on a real Monday morning, even if some parts are still done by hand?

Plan a first working release in weeks

Aim to put something real in front of the people who will use it within weeks, not months. It should handle the common case on real work, with people covering the gaps by hand.

This does three things. Users find what the scope missed while it's still cheap to change. You see whether the builder delivers. And you can stop or change direction with most of the budget still in hand.

Plan the later releases as rough outlines, not detailed specs. You will know far more after the first one ships.

A made-up example. A regional insurer wants a claims system. The wish list covers intake, checks, payments, a customer portal and a dozen reports. The first release does one job: it reads incoming claim emails, files the documents against the right claim and tells a handler what is missing. Payments, the portal and most reports wait.

Four weeks later, handlers use it every day. The team also learns that a quarter of claims still arrive by post, which nobody had mentioned. That changes the plan for the second phase, and nobody had to rewrite a long spec to find out.

What drives cost

A handful of things decide most of the price. Three of the biggest:

• Systems connected. Each connection needs access, testing and a plan for when the other system is down or changes.
• Exceptions. The unusual 10% of cases often takes most of the effort. Ask what happened in the strangest real case last month.
• Data cleanup. Old records with duplicates, gaps and odd formats need fixing before they can move.

Roles, permissions and reports add to the bill too. How much each one weighs depends on your organization, and sizing them honestly is part of what an experienced builder brings to the first conversation.

These are also your levers for a smaller bill. Connect one system instead of four. Handle the most common exceptions in software and send the rest to a person. Start with two roles, not six.

Fixed price, time and materials, or phased

Phased work fits the research above. Smaller pieces, each with a clear point where you can decide to keep going, change course or stop.

What to ask any builder

Three questions tell you a lot.

• Who owns the code? In the US, software written for you by an outside firm isn't automatically yours. Software isn't one of the nine kinds of commissioned work that can be “made for hire,” according to the US Copyright Office, so ownership usually moves to you through a written assignment in the contract. Have your lawyer check the wording.
• Where does it run, and in whose account? Ideally the hosting, domain and data sit in accounts your company owns.
• What happens after launch? How quickly problems get fixed, what support costs and how small changes are handled.

Documentation, handover and who will actually do the work deserve questions too. A good builder answers all of them without being asked, and puts the answers in the contract.

Red flags

A detailed fixed quote after one short call, with no questions about exceptions or data. Nothing working to look at until the very end. Code and hosting kept in the builder's accounts with no plan to transfer them. And every request answered with “yes” and no trade-offs, which usually means the trade-offs arrive later as a bill.

What a good scope document contains

A scope can be a few pages long and still do its job. It starts with the problem in a few sentences, the number that shows it's fixed and today's baseline. It separates the must-haves for the first release from everything that comes later. And it says what is explicitly out of scope.

Beyond that, the contents depend on the organization: which systems connect, which roles exist, what data needs cleaning, what your own team commits to and how changes get priced. Writing that part well is the work of someone who has scoped projects like yours before.

If a scope doesn't say what's out, assume someone believes it's in.

What most guides miss

Your own team's time is often the biggest hidden cost. Workshops, testing, decisions and data cleanup all land on your people. If nobody has hours set aside, the project stalls no matter who you hire.

Slow decisions cost more than slow code. A question about pricing rules that sits unanswered for two weeks costs two weeks. Name one person who can make everyday calls, and give them the authority to do it.

Reports are part of the scope, not a finishing touch. Teams often leave them to the end, then find the new numbers don't match the old spreadsheet. Agree on definitions early, and compare against real past figures before launch.

Estimates are ranges. Ask for a low and a high figure, and what would push the project toward the high end. A single number hides the risk instead of removing it.

Sometimes the answer isn't software. Mapping the process can reveal a step that exists only because of an old rule. Removing it is the cheapest project there is.

How we do it

Most projects start with our process audit, from $2,500 and credited to the build, where we map the work and write the scope with your team. Then we work alongside your people on custom software that ships a first working release in weeks, the way our approach describes. After the first release we stay on to support and extend the system, which is where most of the long-term value shows up. Tell us what you're trying to fix and we'll help shape the first release.