Fixed Scope, Fixed Timeline: How to Run a Software Project That Lands On Budget
A fixed scope software project lands on budget when the work is understood before the price is set. That takes a paid discovery phase, a written scope with acceptance criteria, an agreed rule for changes, milestones that end in working demos, a contingency reserve, and one person on your side with the authority to decide.
Key Takeaways
- A fixed scope and timeline are realistic only for work that can be specified and tested before the build starts. Discovery is how you find out whether yours can.
- A fixed price moves the cost risk to the vendor, who charges for carrying it. Time and materials leaves the risk with you and lets you change direction.
- A written change rule and a contingency reserve held by the client let a project absorb a change without reopening the approved budget.
- When the requirements are still unknown, fix only a short discovery phase and decide on the rest afterwards.
What a Fixed Scope Project Fixes, and What It Leaves Open
Scope is the list of things the software must do when it is handed over, broken into deliverables (the individual pieces of work you will receive). In a fixed scope project that list is agreed in writing before the build starts, normally with a price and a delivery date. Vendors also call this a fixed-price or fixed-bid project.
Project managers call scope, time and cost the iron triangle, because a change to one puts pressure on the other two. When a contract fixes all three, a surprise ends up in the quality of the work, in the vendor’s margin or in a dispute about what was included, which is why many software teams dislike the model.
A buyer usually has an approved amount and a date that matters to the business, so wanting a fixed scope is reasonable. Whether it holds depends on conditions that can be checked before anyone signs.
How Often Software Projects Miss the Budget
The Project Management Institute (PMI) surveys project professionals every year. For its 2025 Pulse of the Profession report, 2,254 of them estimated what share of their organizations’ projects from the previous 12 months finished within the initial budget: 68% to 73%, depending on the respondent group. For the original schedule the figure was 59% to 63%. Those numbers cover every industry, so read them as a baseline.
Large technology programs do worse. BCG surveyed more than 1,000 senior executives for a study published in November 2024 and looked at programs that absorbed more than 3% of a company’s annual technology budget. More than two-thirds were not expected to be delivered on time, within budget or within their planned scope, and only 30% of the companies running them met expectations on all three.
The more useful finding is about the shape of the risk. Bent Flyvbjerg and Alexander Budzier of the University of Oxford examined 1,471 IT projects, most of them large public-sector projects in the United States, and reported the results in Harvard Business Review in 2011. The average cost overrun was 27%, but one project in six went over budget by 200% on average and over schedule by almost 70% (authors’ copy). A 2022 study of 5,392 IT projects by Flyvbjerg and five co-authors found a similar pattern and tested interdependence as one possible explanation using computer simulation: a problem in one technical component can set off problems in the components connected to it.
For a buyer, the lesson is that a modest overrun is common and manageable, while the damaging ones are rare and grow out of dependencies: the systems a project has to connect to and the outside parties it has to wait for. Those deserve a hard look before a price is fixed.
Fixed Price or Time and Materials: Who Carries the Risk
Custom software is paid for in one of two basic ways. With a fixed price, you pay an agreed amount for an agreed scope. With time and materials, often shortened to T&M, you pay for the hours worked at agreed rates and the scope is free to move.
The U.S. government’s purchasing rulebook, the Federal Acquisition Regulation (FAR), describes the trade-off without a vendor’s stake in the answer. It says a firm-fixed-price contract “places upon the contractor maximum risk and full responsibility for all costs and resulting profit or loss” (FAR 16.202-1) and suits work that can be bought “on the basis of reasonably definite functional or detailed specifications” (FAR 16.202-2). A time-and-materials contract, in its words, “provides no positive profit incentive to the contractor for cost control or labor efficiency”. Federal buyers may use one only when the extent of the work cannot be estimated with confidence at the start, and only with a ceiling price (FAR 16.601).
| Fixed price, fixed scope | Time and materials | |
|---|---|---|
| Agreed up front | Scope, price and date | Hourly or daily rates |
| Who carries the cost risk | Mostly the vendor, who charges for it | The client |
| What a change means | A change request with its own price and date | A reordering of the work list |
| Fits best when | Requirements are known, stable and testable | Requirements are still being discovered |
| What to watch | Disputes over what was included, and shortcuts taken to protect margin | Spend that drifts with no finish line |
Neither model is cheaper by nature, because a vendor who accepts the risk of a fixed price charges for carrying it. The two can also be combined: time and materials for discovery, then a fixed price for a build that discovery has made predictable.
Seven Conditions That Make a Fixed Scope and Timeline Realistic
1. Discovery Comes First, and It Is Paid for Separately
Discovery is a short phase before the build in which the vendor’s team and yours work out what is to be built: who will use it, which systems it must connect to, what data exists and what could go wrong. Its outputs are a written scope, an estimate, a timeline and a list of risks. Contract for the right to use the discovery documents with another supplier, including any limits on ownership or reuse. Paying for discovery separately frees the vendor to report what it finds instead of defending a number it has already quoted; payment alone does not establish intellectual property ownership. That holds for a customer portal, a mobile app or the modernization of an old system, the work on our software development services page.
2. The Scope Is Written Down, With Success Criteria and Exclusions
A usable scope document lists what will be delivered, what is explicitly excluded, and the assumptions the estimate rests on (for example, that your accounting system can exchange data with other software). It also states the success criteria in terms someone could measure, such as “a sales rep can issue a quote in under five minutes”. The exclusions deserve as much care as the inclusions, because an item one side assumed and the other never priced is where a dispute starts.
3. Every Deliverable Has Acceptance Criteria
Acceptance criteria are the tests a deliverable must pass before you accept it. The U.S. Government Accountability Office (GAO), in its Agile Assessment Guide, defines them as the criteria by which a piece of work “is judged to be successful or not”, with no middle state between done and not done. For a password reset feature they might read: the user receives a reset email within one minute, the link expires after 30 minutes, and the attempt is recorded in the audit log. Without them, whether a milestone is finished becomes a matter of opinion.
4. The Change Rule Is Agreed Before the First Change
Requirements will change during the build: a regulator publishes a new rule, or a manager sees the first demo and has a better idea. A change rule is a written procedure for what happens next, and a workable one has four parts:
- Every request is made in writing.
- The vendor replies with the effect on price and date within a set number of days.
- One named person on your side approves or declines.
- An approved change is either swapped against a planned item of similar size or paid for from the contingency reserve.
The alternative is scope creep, the gradual addition of work nobody priced.
5. Milestones End in Working Software You Can See
Break the timeline into milestones of a month or less, and end each one with a demonstration of software that runs. The Scrum Guide, the reference text for Scrum (a widely used method of building software in short cycles), sets the length of a cycle at “one month or less” and says work that does not meet the agreed definition of done cannot be presented at the review. With a demo at every milestone, a slip shows up within weeks, while it can still be handled by trimming or reordering work.
6. A Contingency Reserve Sits in the Budget
A contingency reserve is money set aside for costs that are likely to occur but cannot be itemized in advance. The GAO’s Cost Estimating and Assessment Guide is blunt: “All development programs should have contingency funding because it is unreasonable to expect a program not to encounter problems.” In a fixed scope project the reserve belongs to you. It sits outside the vendor’s price and is released only through the change rule. The figure you take to your finance lead is therefore the fixed price plus the reserve, and “on budget” means landing inside that total.
7. One Named Person on Your Side Can Decide
A vendor working to a fixed date needs answers in a day or two. Name one person who can accept deliverables and rule on change requests, and protect a few hours of their week for it. The GAO guide says this person “must be empowered to prioritize decisions about development”. In the BCG study, 57% of respondents pointed to “the lack of dual leadership from both the business and technology sides” among the causes of trouble.
A Worked Example: Two Changes, One Budget
Illustrative example. Every figure below is assumed, to show how the change rule and the reserve work together.
Suppose a wholesale business commissions a customer portal. A three-week discovery phase, paid for separately, produces a scope of 38 deliverables, a fixed price of $180,000 and a 20-week timeline. The risk list has two open items, an old billing system with thin documentation and a payment provider that has announced an update, so the company approves a contingency reserve of $27,000. The approved budget is $207,000.
| Week | What happened | Decision | Reserve left |
|---|---|---|---|
| 7 | Finance asks for an export to the accounting system, priced by the vendor at $9,000 | Swapped against a saved-reports feature of similar size, which moves to a later release | $27,000 |
| 12 | The payment provider’s update forces $6,500 of rework | Paid from the reserve | $20,500 |
| 16 | A manager asks for a dashboard redesign after a demo, priced at $14,000 | Declined for this release and logged for the next one | $20,500 |
The portal is delivered in week 20 for $186,500 against an approved budget of $207,000. The scope changed twice and a third request was turned down, yet the cost rose by only $6,500 and the date did not move, because every request went through the same rule and one person made each call.
A Readiness Test to Run Before You Ask for a Fixed Quote
Answer yes only where you could show the evidence to someone outside the project.
- Can you state in one sentence what the software must achieve for the business and how you will measure it?
- Has someone who will build it examined the systems and data it depends on?
- Is there a written scope that lists exclusions as well as inclusions?
- Does every deliverable have acceptance criteria that a third party could test?
- Are the requirements likely to stay stable for the length of the build?
- Is the build a matter of months and not years?
- Is there a written change rule with a named approver?
- Has a contingency reserve been approved on top of the vendor’s price?
- Does one named decision-maker have time set aside for the project every week?
- Are payments tied to accepted milestones that end in working demos?
With nine or ten yeses, a fixed scope and timeline are reasonable to ask for. With six to eight, fix the first phase only (discovery, or a first release) and decide on the rest when it is delivered. With five or fewer, leave the scope open and run discovery on time and materials with a cap. These thresholds are a rule of thumb with no statistical basis.
When a Fixed Scope Is the Wrong Choice
Some work cannot be specified in advance, and fixing its scope only fixes the first guess. That is the case when you are building something new and expect real users to change your mind, when the project depends on a legacy system (an old one still in daily use) that nobody has documented, or when a third party controls a piece you cannot inspect.
Length is the other warning sign, because over a long program the business itself changes. Flyvbjerg and Budzier’s advice in the HBR article is to “break big projects down into ones of limited size, complexity, and duration”, and each smaller piece can then be fixed on its own.
There are middle routes: time and materials with a ceiling on total spend, or a fixed budget and date with a ranked feature list, where the lowest-ranked items drop off if the work runs long. Either limits what you spend without pretending the requirements are known.
Frequently Asked Questions
What is the difference between fixed price and time and materials?
A fixed price is one agreed amount for a defined scope, so the vendor absorbs the cost if the work takes longer than estimated. Time and materials bills the hours worked at agreed rates, which lets the scope move and leaves the cost risk with the client.
Can a fixed scope and fixed time project succeed?
It can when the scope is well understood and testable, the client holds a reserve, and decisions come quickly. It tends to fail when all three constraints are fixed before anyone has examined the work, or when changes are added without anything being removed.
What should you do when a project is going over budget?
Pause new requests and find the source of the extra cost first: unpriced changes, a wrong estimate, or time lost waiting for decisions. Then choose between cutting lower-priority scope, extending the timeline or approving more money, and put the choice in writing.
What to Bring to the First Meeting
Most of what decides whether a fixed scope project lands on budget happens before the vendor writes the quote. Take the ten questions above into your first meeting with any vendor, and treat every no as work to finish before you ask for a number.
Sarraf Talent begins its projects with discovery sessions that define the scope, the timeline and the criteria for success. You can read about the services we cover and, when you are ready to talk a project through, book a discovery call.
Sources
- Project Management Institute, Pulse of the Profession 2025: Boosting Business Acumen, 2025
- BCG, Most Large-Scale Tech Programs Fail: Here’s How to Succeed, 2024
- Harvard Business Review, Why Your IT Project May Be Riskier Than You Think (Flyvbjerg and Budzier), 2011
- Flyvbjerg and Budzier, Why Your IT Project May Be Riskier than You Think (authors’ copy on arXiv), 2011
- Flyvbjerg, Budzier, Lee, Keil, Lunn and Bester, The Empirical Reality of IT Project Cost Overruns, Journal of Management Information Systems, 2022
- Federal Acquisition Regulation, 16.202-1 Firm-fixed-price contracts: Description, current text
- Federal Acquisition Regulation, 16.202-2 Firm-fixed-price contracts: Application, current text
- Federal Acquisition Regulation, 16.601 Time-and-materials contracts, current text
- U.S. Government Accountability Office, Agile Assessment Guide (GAO-24-105506), 2023
- U.S. Government Accountability Office, Cost Estimating and Assessment Guide (GAO-20-195G), 2020
- Schwaber and Sutherland, The Scrum Guide, 2020
Research and drafting were assisted by AI. The linked sources support the factual claims; any worked examples and scorecards are illustrative guidance, not Sarraf Talent client results.