Scoping Software Development Services by Outcome

Author : James Smith | Published On : 01 Oct 2026

Our first three software development services engagements were scoped as feature lists. Each was delivered as specified, and two of them did not change the thing we had hoped to change. The partner built what we asked for. We had asked for the wrong thing.

Scoping against an outcome instead of a list has changed what we get back. It also changed how cloud computing services get scoped alongside the software. Here is how we do it now.

When you write a list of features, you have already decided how the problem will be solved.

The partner can then only deliver or not deliver the list. Their experience, which is often the most valuable thing you are buying, has nowhere to go.

Our second engagement built a customer portal with fourteen features. Users engaged with four. A partner scoped against the problem would likely have told us that in week two.

Our briefs now contain four things.

Who has the problem. What they do today. How long it takes and what it costs. And the number that must move for us to consider this a success.

For the portal, that would have read: customers call us to check order status, around four hundred times a week, and we want that below one hundred within a quarter of launch.

That brief produces a very different proposal. One of the partners who received it suggested a status email rather than a portal, which would have been cheaper and arguably better.

The baseline is not optional. It is the only thing that lets you know later whether the engagement worked.

We spend a fortnight measuring the current state before the partner begins. Volume, time, cost, error rate.

Without it, every benefits conversation afterwards becomes an argument about impressions, and the partner has no fixed target to aim at.

Outcome scoping sometimes surfaces infrastructure needs nobody anticipated.

Our order status outcome depended on data being current within minutes. The existing platform refreshed overnight. That was not a software problem, and no amount of application work would have fixed it.

We now involve our cloud computing services provider in scoping any outcome that depends on data freshness, scale, or availability. Software development services cannot deliver an outcome the platform underneath will not support.

That conversation added a week to scoping once. It saved a failed engagement.

Outcome scoping works best in short phases with a decision point between each.

Our first phase is usually six to eight weeks and produces something real that users touch. Then we measure, and decide what the second phase should be based on what happened.

That feels less certain than a single long plan. It is considerably more certain in practice, because the long plan was written before anyone knew anything.

The commercial structure has to match.

Fixed price for a short, well defined first phase. Time and materials afterwards, once both sides understand what is being built.

A long fixed price contract against an outcome is a contradiction. It forces the partner to resist the changes that outcome scoping is designed to allow.

Our phase reviews used to open with what had been delivered. They now open with whether the number moved.

That reordering changed the conversation. A phase that delivered everything and moved nothing is a problem worth discussing, and the old format made it look like a success.

The behaviour that tells you whether outcome scoping is working.

If a partner agrees with everything in your brief, either your brief is perfect or they are not applying their experience.

Ours now challenges something in most first meetings. Occasionally they are wrong. The conversation is always useful, and it happens before any money is spent rather than after.

Outcome scoping applies to configured platforms as much as to custom builds.

Our CRM programme started as a list of objects and fields. We rescoped it around one outcome, reducing the time for an adviser to prepare for a client meeting, and the configuration that followed was about half the size.

The partner advised on how to implement salesforce against that outcome rather than against a feature inventory, which is a different conversation and a better one.

• Who has the problem, and what they do today.
• The baseline, measured before the partner starts.
• The one number that must move.
• The constraints we already know.
• An explicit invitation to challenge any of it.

Does this apply to infrastructure work?

Yes. Our cloud migration was scoped against cost and availability outcomes, and we classified every system using the 6 Rs of cloud migration before deciding what to move.

Does this take longer to set up?

About two weeks longer, mostly the baseline. It saves considerably more than that by avoiding work nobody needed.

How do we hold software development services to an outcome?

Put the number in the phase review. Software development services judged on delivery of a list will deliver the list.

What if we cannot name a measurable outcome?

Then the project is probably not ready to start. That is a useful thing to discover before spending money.

How do we compare proposals against an outcome?

More easily than against a list. Each proposal explains how it will move the number, and you can judge the reasoning.

Does every engagement suit this?

Most do. The exception is genuinely well understood work where the solution is known and the only question is delivery.

Our last four engagements were scoped this way. Three moved their number. One did not, and we stopped it after the first phase rather than after the whole programme.

Software development services scoped by outcome cost roughly the same as those scoped by feature list. The difference is that you find out early whether the work is changing anything, and the partner's experience gets used rather than ignored.