TEEBTEK

Project Management

How to Scope a Software Project so It Finishes on Time

What a good scope contains, why workflows beat feature lists, how to handle change and how to choose between fixed price and time and materials.

· 4 min read · By

Software projects rarely fail because the developers could not write the code. They fail because nobody agreed, in writing, what was being built, what was not, and what would happen when something changed. That agreement is the scope, and getting it right is the cheapest insurance a project can buy.

What a Good Scope Contains

A useful scope document is short enough to read in one sitting and specific enough that two people would build roughly the same thing from it.

The goal. One or two sentences on the business outcome. "Reduce booking calls by moving reservations online" is a goal. "Build a booking app" is not.

The users. Who will use the system and what each type of user needs to do. A customer, a staff member and an owner usually need very different things.

The core workflows. Step by step, how the main tasks happen. How a booking is made, changed, paid and completed. Write them in plain language, not technical terms.

What is out of scope. Equally important and almost always skipped. Listing what you are deliberately not building now prevents months of slow expansion.

Acceptance criteria. How everyone will know a feature is finished. "A customer can book a slot, pay the advance and receive a receipt by message" is testable. "Booking works well" is not.

Milestones. The order things will be delivered in, with dates, and what you will be able to see and try at each one.

Write Workflows, Not Feature Lists

Feature lists look precise and hide most of the real decisions. "User management" could mean one screen or a month of work.

Instead, describe what happens: a manager adds a staff member, chooses their role, the staff member receives an invitation, signs in and only sees their own branch. Every question that sentence raises (Can a manager remove someone? What happens to their records?) is a question better answered now than halfway through the build.

Sit with the People Doing the Work

The best requirements come from watching the current process, including the workarounds. The spreadsheet kept beside the official system, the notebook at reception, the message group where approvals really happen. Those workarounds are usually the true requirements, and they rarely appear in a meeting room.

Put the Risky Part First

Order milestones so that the part carrying money, status or legal risk is built and used early. If billing is going to be the hard part, you want to discover that in week three, not week twelve. A project that saves the hardest work for last tends to finish late.

Agree How Change Will Be Handled

Change is guaranteed. Your business will learn things during the project, and some of them will matter. Agree up front:

  • how a change is requested and estimated,
  • who approves it,
  • whether it replaces something else in scope or extends the timeline and budget.

A simple, written change process keeps a project friendly. Without one, every change becomes a negotiation.

Fixed Price or Time and Materials?

  • Fixed price suits work that is well understood and clearly scoped. You know the cost up front, and the scope has to be tight.
  • Time and materials suits work where you expect to learn and adjust as you go. You pay for the time used, with regular visibility of progress and spend.

Many projects combine the two: a fixed-price first phase with a clear scope, followed by ongoing work billed by time once the product is in use.

Signs Your Scope Needs More Work

  • Two people describe the same feature differently.
  • Nobody can say what is out of scope.
  • There are no dates, or only one date at the very end.
  • "And it should also..." appears in most conversations.
  • The people who will use the system every day have not seen the plan.

A One-Page Test

If you cannot summarise the project on a single page (the goal, the users, the three or four core workflows, what is out of scope and the milestones), it is not ready to build yet. That page is worth more than a hundred-page specification nobody reads.

Scoping and managing delivery is a large part of what we do, whether we build the software or another team does. If you have a project that keeps growing before it has even started, we can help you pin it down.

Read next

Choosing a software development company: 12 questions to ask

Read the article

← All articles

Need This Done Rather than Explained?

We do this work for clients every week. Tell us where you are and we will tell you what we would do first.

Replies usually within a few hours, Monday to Saturday.

Chat with us