Keeping a software project on budget: scope, security and Agile

Five things keep a commissioned software project on budget: write the scope as a prioritised list with acceptance criteria; fix the budget and let scope be the variable; inspect working software every cycle instead of progress reports; route every addition through a logged change request (CR) with an impact estimate; and choose a contractor that can prove its security competence from the start, so vulnerabilities do not turn into a large rework bill at the end.

This guide is for executives, project owners and procurement teams hiring a software house to build a system or a digital transformation (DX) project, including Thai government agencies buying through e-GP. It is about controlling the budget once a project is under way. Preparing a brief for quotes is covered in what to prepare before asking for a software quote, and choosing a company in how to choose a software development company: a 10-point checklist. Standards and legal texts cited were checked against their sources on 3 November 2026.

What causes budget overruns in software projects?

A cost overrun is when a project's actual cost exceeds its approved budget. In commissioned software we see four common sources: scope written so broadly that each side reads it differently; small additions nobody assesses for cost and time; rework because users first see the real system at acceptance; and security flaws found late enough to need structural fixes.

Many overrun figures circulate. The one whose source we could check is Flyvbjerg and Budzier's 2011 Harvard Business Review piece (Why Your IT Project Might Be Riskier Than You Think). Across 1,471 IT projects the average cost overrun was 27%, but that average hid a fat tail: one project in six was a "Black Swan" with an average cost overrun of 200% and a schedule overrun of almost 70%. The authors' point is that focusing on averages misses the real risk. These figures describe that study's sample, not Thai projects, but the lesson carries over: budget control is about keeping a project out of the extreme tail, not about squeezing the opening price.

For public-sector projects, process causes such as unclear specifications, price-led awards and user acceptance testing (UAT) without real users are covered in why government IT projects fail in Thailand. This article picks up from there: once the project has started, how do you hold the budget?

How should the scope or TOR be written to control cost?

Make every item testable and say what comes first. A budget-controllable scope need not be long, but it must answer which work is essential, which can wait and when each item counts as done:

• A prioritised requirement list that separates what the system needs to be usable from what would be nice to have. This split is the main tool when you must decide what to swap out. How to make it is covered in the quote-preparation guide.
• Acceptance criteria per item, written as what a user can do and what result they should see, not "the system supports data management". Criteria left vague get renegotiated at acceptance, which is where budgets start to slip.
• Assumptions and exclusions, such as whether the systems to integrate already have APIs, how many legacy datasets must be migrated and who prepares test data. Anything not written down as excluded tends to become an argument about whether it was in the price.

Fixed price, time and materials, or a discovery phase first each affect cost control directly; the comparison table is in the quote-preparation guide. For Thai agencies, TOR headings and procurement methods are in the government IT procurement guide, and maintenance of an existing system in writing a TOR for legacy system maintenance.

How do you choose a software house without inviting an overrun?

Look for evidence of how the vendor controls scope on real projects, not only its price or portfolio. The general 10-point checklist and proposal comparison are in how to choose a software development company. From a budget angle, also ask to see:

• A sample product backlog from past work (client names removed): how it was ordered and who ordered it.
• A sample change-request log showing impact on work and time, and the approval outcome.
• The team's Definition of Done, for example code reviewed, automated tests in the client's repository, and deployed to a test environment.
• The roles of the people who will actually do the work, and an agreement that replacing someone in a key role needs notice and consent, because every mid-project change of people carries a learning cost.

A vendor that can answer these with real documents usually has a working scope-control process. If the answer is only "we're flexible", ask how, and who pays.

Why is a vendor's security competence a budget issue?

Because vulnerabilities found at the end become unplanned rework. If access control was designed wrongly from the start, fixing it at acceptance can mean reworking several parts at once, followed by a dispute about who pays. Writing verifiable security criteria into the TOR or contract means problems are found and fixed while they are still small.

What security evidence should you ask for?

ASVS is a framework of security requirements for designing, developing and testing web applications and web services. The latest version is 5.0.0, published on 30 May 2025. The ASVS 5.0 text itself describes use in procurement: a buyer can require that the software be developed to a given ASVS level and ask the seller to prove it meets that level. ASVS 5.0 describes three levels:

• Level 1: the minimum, about 20% of the requirements.
• Level 2: what most applications should aim for (Levels 1 and 2 together are about 70%).
• Level 3: applications that must demonstrate the highest security.

When tailoring the standard, it advises starting from Level 1 as a baseline and moving up according to the application's risk.

It also notes that Level 1 is not necessarily testable by an outside tester without access to documentation or code, so the evidence you ask for should include code or design review, not only an external scan.

The OWASP Top 10 is now the 2025 edition. OWASP calls it an awareness document; use it to check that test reports cover the most common risks, such as A01 Broken Access Control, A03 Software Supply Chain Failures and A06 Insecure Design, and use ASVS as the list of requirements to accept against. For test methods, the OWASP Web Security Testing Guide (WSTG) is at stable version 4.2.

SSDF is NIST SP 800-218 Version 1.1 (February 2022). It groups practices into Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). RV is the group to raise with a vendor directly: when someone finds a vulnerability in delivered software, where is it reported, how is severity assessed, and under which part of the contract is it fixed? To gauge a vendor's process maturity more broadly, another framework in use is the OWASP Software Assurance Maturity Model (SAMM), version 2.2.0.

A published reporting channel, such as a security.txt file under RFC 9116, is a simple sign that a vendor has thought about receiving vulnerability reports. The RFC exists because researchers who find vulnerabilities often lack a proper channel to report them.

How does Agile delivery help control the budget?

Agile controls cost when it is used to see real software early and make scope decisions often, not as licence to change anything at any time. Five practices apply to the project management of most DX projects.

Fix the budget and let scope vary

Fixed budget, variable scope means setting the budget and time frame and deciding how much gets built by priority. When more important work appears, swap it in for the lowest-priority item not yet started rather than appending it and hoping the money stretches. Work that falls below the budget line is not lost; it waits for a later round or next year's budget.

An ordered product backlog with a single owner

The Scrum Guide (November 2020) defines the product backlog as an emergent, ordered list of what is needed to improve the product, and makes the product owner accountable for ordering it. In a commissioned project that person should sit on the client side and have real authority. If anyone in the organisation can give the vendor work, the budget leaks through work nobody prioritised.

Sprint reviews of working software

The Scrum Guide caps sprints at one month and uses the sprint review to inspect the sprint's outcome and decide what to adapt. What is inspected is the increment, which the guide calls a concrete stepping stone toward the product goal, not slides or screenshots. It matches the Agile Manifesto value of "working software over comprehensive documentation". Every round in which users try the real thing is a chance to catch a misunderstanding while it is still cheap.

A Definition of Done agreed before work starts

The DoD formally describes the state an increment must reach to meet the required quality measures. According to the Scrum Guide, work that does not meet it cannot be released or even presented at the sprint review, and returns to the product backlog. The budget effect is that progress is counted from work that is actually finished, not from dozens of items that are "90% done". In a commissioned project the DoD should include automated tests, code review, security checks at the agreed level, and code in the client's repository.

A change-request process with a log and impact estimate

Anything not in the agreed backlog should enter a CR log that records who asked and why, the impact on work, time and cost, what it will be swapped with, and who approved it. The Scrum Guide says no changes are made during a sprint that would endanger the sprint goal, while scope may be clarified and renegotiated with the product owner as more is learned. The CR log makes that renegotiation traceable.

For large projects, a general principle is to make them smaller. The US government's 18F guide (now archived) recommends budgeting and building iteratively, and carving a large project into several small ones funded in increments. Its contracting details are US-specific and do not transfer to Thai procurement, but the start-small principle applies to any digital transformation roadmap, and to modernising an existing system piece by piece; see from legacy to cloud-native.

Can a fixed-price Thai government contract use Agile?

Yes, as incremental delivery, but it has to be designed into the TOR before signing, because a signed contract can be amended only in limited ways. Three legal points matter (summarised from the texts published in the Royal Gazette, in Thai; not legal advice):

• Amendments are limited. Section 97 of the Public Procurement and Supplies Administration Act B.E. 2560 (2017) says a signed contract cannot be amended except in the cases listed in (1) to (4), at the approving authority's discretion. Any increase or decrease in value or time must be agreed at the same time.
• Amendments must stay within the original objective. Clause 165 of the Ministry of Finance Regulation on Public Procurement and Supplies Administration B.E. 2560 (2017) requires an amendment under section 97 to stay within the scope of the contract's original objective, and the agency must compare quality, work detail and price before amending. A change request cannot turn the contract into a different project.
• Acceptance follows the agreed evidence. Section 100 makes the inspection committee responsible for both contract administration and acceptance, and clause 175 (2) requires it to accept work correctly and completely against the evidence agreed, bringing in experts for technical testing where needed. Acceptance criteria for each payment period therefore belong in the TOR and contract from the start.

Taken together, this is what we suggest agencies consider with their procurement unit:

1. Make each payment period working software. Instead of periods such as "design documents", "system delivery" and "training", have each period deliver a set of functions users can try in a test environment. How periods are divided is something the TOR drafters can design; as far as we checked, the regulation does not prescribe a period structure for general service contracts other than construction and consultancy.
2. Write the acceptance evidence for each period. For example, a demonstration to the committee against defined scenarios, automated test results, code in the agency's repository and a security test report against the stated ASVS level: the "agreed evidence" that lets every committee member reach the same verdict.
3. Prioritise requirements in the TOR so the early periods deliver the essentials. If the project runs into trouble, the agency still has something usable.
4. Separate clarification from addition. Working out screen or step details within an existing requirement is normal development work; adding a new requirement is a change that may need a section 97 amendment. Write that boundary into the TOR and have the procurement unit confirm it before publication.

To be plain about the limits: an agency cannot freely re-scope a signed contract the way a private company can. Agile flexibility in government work lies in delivery order, inspecting real software every period and finding problems early, rather than in changing scope. Work outside the original objective belongs in a later project or budget round. The regulation clauses are cited from the 2017 (B.E. 2560) text; confirm the current version with the procurement unit or the Comptroller General's Department before relying on them.

If the system must exchange data with other agencies, what to prepare before drafting the TOR so bidders can estimate the integration work is shown in designing a welfare information system for Thai government data exchange.

Checklist: five warning signs that an IT project is heading for a budget overrun

These signs show up while the project is running, not before signing (pre-signing red flags are in the vendor selection guide). The earlier you see them, the more options remain.

1. Sprint reviews or period reports show only slides and screenshots, with no software users can try. Progress that does not meet the DoD is not progress. What to do: require every round to be demonstrated in a test environment and count only work that meets the DoD.
2. Work is being added with no change-request log, or the log has no estimate of cost and time impact. What to do: pause new additions, put every pending request into the CR log, then decide item by item what each one replaces.
3. Spending is outpacing finished work. For example, half the budget or time is gone but less than half the must-have work meets the DoD. What to do: reorder the backlog so the must-haves fit the remaining budget, and agree now which work moves out.
4. Acceptance criteria are being renegotiated at UAT or at period inspection. The criteria were not clear to begin with, and rework will follow. What to do: write clear criteria for the remaining work before it starts, and have the people who accept the work see it at sprint reviews, not for the first time at acceptance.
5. Security testing has been pushed to the end. Vulnerabilities found late are usually fixed by rework. What to do: put checks at the agreed ASVS level into every round's DoD and ask for test reports from the first period.

One more sign to watch: people in the vendor's key roles change without notice, such as the technical lead from the pitch no longer attending meetings. Ask directly and refer to the team clause in the contract.

Frequently asked questions

What is a budget overrun in a software project, and what causes it?

It is when the actual cost exceeds the approved budget. In commissioned software it usually comes from ambiguous scope, additions without impact assessment, rework because problems surface at acceptance, and late-found security flaws. Flyvbjerg and Budzier's 2011 study of 1,471 IT projects shows the danger lies in the minority of extreme overruns, not the average.

What does fixed budget, variable scope mean?

The budget and time frame are fixed and scope is the variable. Work is ordered in the product backlog, must-haves are built first, and new, more important work replaces the lowest-priority item not yet started instead of being added on top.

Can a fixed-price government contract use Agile?

Yes, as incremental delivery: define each payment period in the TOR as working, tested software with agreed acceptance evidence. A signed contract can be amended only under section 97 and within its original objective under clause 165, so the flexibility has to be designed in before signing, with the procurement unit confirming the approach.

What should we do first if we see the warning signs?

Pause new additions, count the work that actually meets the DoD against the budget spent, reorder the backlog so the must-haves fit what remains, log every pending change request with its impact, and agree with the vendor which work moves out.

Assess the scope and budget risk before you start

A controllable budget starts with an ordered scope and clear acceptance criteria. If you have a draft scope or TOR, or a project already showing the signs above, an assessment now shows which work is essential, which can wait and where the overrun risk sits.

UNIXDEV's custom software development work follows a process certified to ISO/IEC 29110-4-1:2018 by SGS Thailand (certificate no. TH25/00001024), covering a regular sprint cadence, code review, automated tests, retrospectives and a risk log. The company is also certified to ISO 9001:2015 and ISO/IEC 27001:2022 (certification details) and is registered as a vendor in e-GP. For government work we deliver against the TOR and hand over source code and documentation. If an agency wants us to review a draft TOR and also bid on the same project, it should first ask its procurement unit whether any restriction applies; comments on a published draft TOR can be sent during the public hearing.

Send a draft scope, requirement list or project status through the project brief form. Our target is to reply within two business days.

Sources and further reading

• Flyvbjerg, B. and Budzier, A. Why Your IT Project Might Be Riskier Than You Think: Harvard Business Review, Vol. 89 (2011), No. 9, pp. 23–25 (author copy on arXiv)
• OWASP Application Security Verification Standard (ASVS) 5.0.0 · ASVS 5.0: What is the ASVS (levels and procurement use)
• OWASP Top 10:2025
• OWASP Web Security Testing Guide (WSTG)
• OWASP Software Assurance Maturity Model (SAMM)
• NIST Secure Software Development Framework (SSDF), SP 800-218 Version 1.1
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure
• The Scrum Guide (November 2020) · Manifesto for Agile Software Development
• 18F: Buying development services (archived, US guidance)
• Public Procurement and Supplies Administration Act B.E. 2560 (2017): Royal Gazette vol. 134, part 24 Kor, 24 February 2017 (sections 97 and 100), in Thai
• Ministry of Finance Regulation on Public Procurement and Supplies Administration B.E. 2560 (2017): Royal Gazette vol. 134, special part 210 Ngor, 23 August 2017 (clauses 165 and 175), in Thai · copy published by the Comptroller General's Department
• Related: why government IT projects fail
• Related: designing a welfare information system for government data exchange
• Related: from legacy to cloud-native
• Related: how to choose a software development company in Thailand
• Related: what to prepare before asking for a software quote
• Related: Thai government IT procurement, e-GP, the TOR and maintenance budgets
• Related: writing a TOR for legacy system maintenance
• Related: MA and SLA contract checklist
• Related: switching software vendors, what to take over
• All articles on enterprise software development

By the UNIXDEV Team · 3 November 2026 · A planning summary, not legal advice.