How Scope Grows in SI Projects and How to Design Change Management to Contain It

Toward the end of a project, both sides tend to be thinking something similar.

The client thinks, "Surely this much was included from the start," and the contractor feels, "We kept being asked for things that were not in the contract." Both are sincere. That is what makes it harder to resolve.

The cause is usually not the fault of either side. The scope was not sufficiently fixed at kickoff, and the project started without either side realizing it.

This article sets out the typical paths by which scope grows in systems integration (SI) projects, and how to bring that growth into a manageable form. It is written to apply to both the client's project owner and the contractor.

1. It did not grow; it was vague from the start

A large share of scope disputes come not from "additional requests" but from differences in interpretation.

The same sentence is read differently

Suppose the requirements definition contains this sentence.

An administrator must be able to view and manage member information.

Reading it, the client pictures search, filters, sorting, Excel export, bulk editing, change history and permission-based visibility control. That is how the systems they normally use work.

The contractor reads the same sentence and pictures a list view, a detail view, edit and delete. Exactly what the sentence says.

Both read the sentence in good faith. Yet the effort they estimate differs several times over.

Certain expressions create ambiguity

The expressions that cause differing interpretations in requirements documents are largely predictable.

Type of expression Example What has to be fixed
Catch-all verbs manage, process, integrate Which specific actions are meant
Adverbs of degree quickly, reliably, conveniently A measurable threshold
Unspecified scope all kinds of, various, other The full list of items covered
Unspecified quantity several, multiple The maximum number
Unspecified actor automatically, the system What executes it and when
Reference to a similar system at the same level as Company A Which functions, and how far

If these expressions remain in the document, that part will become a dispute later. They need to be removed one by one before kickoff.

Screen design exposes the requirements

At the level of a function list everything appears to be agreed, and then the differences surface once screen design begins. A screen has to show concrete fields and behavior.

These are the questions that come up at that point.

  • How many records does this list show at a time
  • Which search conditions are needed
  • If this value is edited, does other related data change with it
  • Are there fields that must be hidden depending on permissions
  • What happens when two people edit at the same time

Answering these questions is the process of elaborating the requirements. There has to be a criterion for deciding whether what comes out of it is original scope or an addition. Without one, each case is decided by the balance of power at that moment.

Criteria for separating elaboration from addition

The criteria are agreed at the kickoff meeting and recorded in the minutes. If the criteria are created after a dispute has arisen, the criteria themselves become a subject of negotiation. We apply the questions below in order from the top.

Order Question If so
1 Is the function or item written out in the baseline document Elaboration
2 It is not written, but is it indispensable for a written function to work (e.g. pagination that goes with a list view) Elaboration
3 Does the number of functions, screens, integration targets or data fields in the baseline increase Addition
4 Does a new user type, permission scheme or external system appear Addition
5 Does design or implementation that has already been confirmed have to be redone Change (rework cost arises)
6 Does none of the above apply Refer it to the joint board as an agenda item

Question 2 is where disputes arise most often. "Indispensable" has to be read narrowly, as meaning that the written function cannot be used without the item. If it is merely convenient to have, move on to question 3. In the member management example above, pagination of the list falls under question 2, while Excel export and bulk editing fall under question 3.

The outcome is recorded even when the conclusion is elaboration. How many items have been absorbed as elaboration becomes evidence in later schedule discussions.

2. The paths by which scope actually grows

Apart from differences in interpretation, there are also paths by which genuine additions occur. These can be anticipated in advance.

Stakeholders appear late

At kickoff, discussions are held only with the lead department. Then, around the interim report, other departments join and new requirements come in.

  • The accounting department asks for a particular way of handling vouchers
  • The information security officer presents access control standards
  • Front-line staff point out that it differs from the actual workflow
  • The audit department adds history management requirements

These requirements are generally reasonable. The problem is that design is already well advanced by that point.

The preventive measure is to identify stakeholders at the kickoff stage. Listing who uses the system, whose approval is needed and which departments' rules apply reduces late arrivals.

Circumstances change at the systems being integrated

Integration involves a counterpart. It does not go according to our plan.

  • The interface specification turns out to differ from what was expected
  • The counterpart system is being overhauled at the same time and the schedule slips
  • The counterpart's staff do not respond to requests for discussion
  • The permissions or network lines needed for integration are not ready

For integration items, it is safer to check at contract time whether the specification has been obtained. Estimating integration scope without a specification is only a guess. The items to check on integration paths are covered separately in Where External System Integrations Fail — Principles of Interface Design.

Data migration brings surprises

Moving data from an existing system is almost always bigger than expected.

  • The actual data, once received, turns out to be inconsistent
  • A large amount of undocumented exception data exists
  • The code scheme has changed several times over the years
  • The period to be migrated has not been agreed

When data migration is included in scope, actual data samples have to be checked first. An estimate based only on record counts is usually wrong. What to look at before migration is covered in Legacy Data Migration — What to Check Before You Move Anything.

Small requests accumulate

There are requests that, taken one at a time, give no reason to refuse.

  • Could you just move this button
  • Could you just add one field here
  • It would be nice to have an Excel download as well
  • Could this screen also be viewable on mobile

Each takes half a day. So most are simply done. The problem is that such requests continue throughout the project.

When dozens pile up they amount to effort that cannot be ignored, but because they are not recorded anywhere, they cannot be used as evidence later when the schedule runs short. The contractor says, "There were small requests all along," and the client replies, "We never asked for anything big." Both are true.

The solution is not refusal but recording. If the requests are handled but kept on a list, the accumulated volume can be shown in numbers. There is a large difference between being able and not being able to say, "We will take care of what you asked. However, there are currently 32 such requests, and the total effort comes to this much."

Schedule pressure can also enlarge scope

Paradoxically, the tighter the schedule, the more the scope sometimes grows.

If the analysis and design period is cut and development starts first, things are built without having been fixed. When they are reviewed after being built, differences are pointed out, and new requirements attach themselves in the course of fixing them. The result takes longer than if things had been decided before starting.

Time gained by cutting the early phases comes back later as a larger cost. If the schedule is tight, reducing scope is safer than reducing the analysis period.

Laws or regulations change

When a project runs long, the relevant regulations may be amended in the meantime. A response is then needed, but it is work that was not in the contract scope.

To prepare for this, it is better to include a policy for handling changes in laws and regulations in the contract. Simply stating that such changes are subject to consultation reduces later disputes.

3. The aim is to manage change, not to block it

Change itself cannot be eliminated. The goal is to stop change from seeping in unseen.

Fix the baseline and record the point in time

Judging a change requires something to compare against. The approach is to fix the requirements definition and screen design documents at a specific point in time and treat any difference after that as a change.

These are needed when fixing the baseline.

  • Document version and date of finalization
  • Confirming signatures or approval records from both sides
  • An agreement that changes after finalization go through a procedure

Without this baseline, both sides claim "that was what we agreed originally," and there is no way to check.

The baseline is not set all at once. At each phase a more specific document replaces the document of the previous phase.

Point in time Baseline documents What counts as a change from this point
Contract signing Contract, statement of work (requirements definition), cost breakdown statement Increase or decrease in functions, integrations or migration targets
Analysis complete Requirements specification, first edition of the requirements traceability matrix Addition, deletion or modification at the level of a requirement ID
Design complete Screen design document, interface definition document, data model Modification of screen fields, interface messages or table structures
Start of integration testing Test scenarios, version to be deployed Every modification except defect fixes

The later the phase, the more deliverables have to be reworked for the same change. That is why confirmation at design completion is obtained most strictly. Baseline documents are kept in a repository with restricted edit permissions, and the finalized copy carries the version and date both in the file name and inside the document. Time really does get spent working out which of the files exchanged over a messenger is the finalized one.

Receive change requests in writing

Once requests that arrive verbally or by messenger start being applied as they come, management becomes impossible. A procedure for receiving them in writing is needed, even with a simple form.

These are the items that go into a change request form.

Item Content
Request number and date Identifier for tracking
Requester and affiliation To confirm the request comes from an authorized person
Description of change What is changed and how
Reason for request Business need, regulatory compliance, error correction, etc.
Type of change Which of elaboration, addition, change or deletion
Existing content and changed content The sentence in the baseline document and the proposed sentence, side by side
Related documents Affected requirement items and screen numbers
Impact if not applied The business problem that arises if it is not applied
Impact Effort, schedule, cost and effect on other functions
Basis of calculation How the effort and amount were calculated
Response deadlines Date for the impact response and date for the approval decision
Outcome Approved, rejected or on hold, with the reason and the decision-maker

The impact item is the key. When a request is received, presenting what changes and by how much, instead of answering "it can be done" or "it is difficult," moves the discussion from emotion to judgment.

The field that sets "existing content and changed content" side by side is easy to leave out but worth keeping. Sometimes the requester, while filling it in, realizes that the content is already in the baseline document; conversely, it sometimes reveals a requirement the contractor missed.

Here is a sample. The numbering scheme and figures are values made up for illustration.

Change Request CR-014
Request date        : 20XX-05-12        Requester : OOO, Client Operations Team (authorized to request changes)
Type of change      : Addition
Related items       : REQ-ADM-012 Member list view / Screen ADM-MEM-010
Existing content    : An administrator can view the member list. (Search conditions: name, sign-up date)
Changed content     : Add a function to download the search results as an Excel file.
Reason for request  : Used to prepare the monthly member status report
Impact if not applied : Screen content has to be copied by hand when preparing the report
Impact              : See attached impact analysis IA-014
Response deadlines  : Impact response 05-15 / Approval decision 05-19
Outcome             : (to be entered after review)

The point to note in this sample is that the downloaded file contains personal information. The request is a single line, "Excel export," but the impact analysis also brings up download permission, entry of a reason and logging of download history. It is a typical case where the actual scope is larger than the sentence written in the request.

What to look at together when estimating impact

A single change reaches further than expected.

  • Revision of design documents
  • Development effort
  • Revision of test cases already written
  • Renegotiation with the systems being integrated
  • Handling of existing data when the data structure changes
  • Updating of training materials and manuals
  • Effect on other functions

Counting only development effort gives a figure smaller than reality. In particular, the cost of undoing work already completed is easily left out.

Non-functional items are checked on the same list. They do not show up in the request but come back as costs in the operation phase.

Perspective Questions to check
Personal information Do the items collected, viewed or downloaded increase. Does the purpose of processing or the retention period change
Security Is a new permission or role needed. Is this an action for which access records must be kept
Performance Do the number of records queried, concurrent users or batch processing time exceed the assumptions made at design
Operations Do the monitoring items, backup targets or incident response procedures change
Maintenance Is an external library or paid service added. Who bears the cost after the contract ends

Impact analysis procedure

Impact analysis is work whose results easily vary from one person to another. Fixing the sequence reduces the variation.

  1. Confirm the request — Talk to the requester by phone or in person for about 10 to 20 minutes and fix the behavior before and after the change in sentences. Analyzing with the interpretation still split means doing the analysis again.
  2. Determine the type — Using the criteria set earlier, determine whether it is an elaboration, an addition or a change. If it is an elaboration, just record it and finish, without an impact analysis.
  3. Trace the affected scope — From the requirements traceability matrix, extract the screens, modules, tables, interfaces and test cases linked to the requirement ID concerned.
  4. Break down the work — For each affected deliverable, write new work and rework separately. Modifying a deliverable that has already been confirmed is rework.
  5. Estimate effort and schedule — Add up the effort per task and check whether the task lies on the critical path. Even when the effort is small, the delivery date slips if it collides with the integration test schedule.
  6. Write up alternatives — Start from three as the default, apply in full, apply in part, and defer to the next phase, and write the effort and schedule for each. With only one alternative, the discussion narrows to approve or refuse.
  7. Respond — Send the impact analysis within the agreed deadline. If the analysis needs more time, give notice of the reason and the new deadline before the deadline passes.

The analysis itself takes effort. For a request that will take a day or more to analyze, it is better to obtain approval first on whether to begin the analysis at all. Writing into the contract who bears the analysis effort removes any dispute at this stage.

Here is a sample impact analysis for change request CR-014 above. The effort figures are for illustration, and actual values depend on the system structure.

Affected item Work Category Effort (person-days)
Screen design document ADM-MEM-010 Add download button and reason entry dialog Rework 0.5
Member management module Excel generation API, download permission check New 2.0
Permission definition document Add download permission, criteria for granting it by role Rework 0.5
Audit log Record download history (user, date and time, reason, record count) New 1.0
Test scenarios Add scenarios by permission and for large record counts New 1.0
Administrator manual Update the relevant section Rework 0.5
Total 5.5
Alternative Content Effort (person-days) Schedule impact
A Apply in full 5.5 Start of integration testing delayed by 2 days
B Apply the download only; exclude reason entry and history 3.0 None. No history of personal information downloads is kept
C Exclude from this scope and register on the next-phase backlog 0 None

An alternative like B, which strips out the controls, is easily adopted because the effort is small. The analysis states explicitly which controls are dropped and what follows from that, and notes that confirmation by the client's information security officer is to be obtained. How to build access records and download controls into the design is covered in Designing a System That Meets Document Security Requirements: Access Control, Watermarks, and Audit Logs.

Define the handling procedure and authority

Who reviews a change request and who approves it has to be decided.

Request received → Impact analysis → Review meeting → Approval/rejection → Baseline update → History retained

Approval authority can also be divided by size. Requests at or below a certain effort are handled by agreement between the PMs, and anything above that is escalated to a separate joint board. If every change is decided at the highest level, the procedure becomes a bottleneck.

Below is an example of tiered approval. The threshold figures have to be set to suit the size of the project, and the values written here are only to show the format.

Tier Conditions (any one of them puts the request in the higher tier) Decision-maker Response deadline Handling
Simplified Effort of 1 person-day or less, no schedule impact, no change to data structure, integration or permissions PMs of both sides 2 business days Proceed after recording in the change log
Standard Effort over 1 person-day and up to 10 person-days, no impact on major milestones PMs of both sides, approved at the weekly meeting 5 business days Change request form and impact analysis
Major Effort over 10 person-days, impact on delivery date or contract amount, change to data structure, integration targets or security requirements Change board (responsible managers of both sides) 10 business days The above documents plus comparison of alternatives, and review of a contract amendment

With only a per-request threshold, small requests end up being split and submitted as several. A cumulative threshold is set alongside it. For example, once the cumulative effort handled under the simplified tier reaches a certain percentage of the contract effort, subsequent requests go to the joint board regardless of tier.

The criteria used when discussing whether to approve are also set in advance.

Criterion Toward approval Toward hold or rejection
Necessity Regulatory compliance; work cannot be performed without it Merely convenient to have; an alternative means exists
Timing Before implementation of the function concerned has started After integration testing has started
Extent of impact Contained within one screen or one module Changes the data structure or interface messages
Funding A contract amendment or a trade against another item is possible No means of adjusting amount or period
Deferrability Must be in place before going live No problem if added after going live

For a request that falls mostly on the hold or rejection side, moving it to the next-phase backlog is easier to agree on than refusing it. The request does not cease to exist; its timing moves back.

For an approved change, work starts after the change has been reflected in the baseline document and the version has been raised. If urgency means work has to start first, that fact and the deadline for completing the paperwork afterward are written on the request. Something built first without a record is hard to have recognized as a change later.

To grasp the affected scope quickly when a change comes in, requirement items have to be linked to the actual deliverables.

Requirement ID → Screen number → Development module → Test case

With this link, "what is affected if this requirement is changed" can be traced. Without it, everything depends on people's memory each time, and omissions occur.

Here is a sample requirements traceability matrix. The ID scheme is for illustration.

Requirement ID Requirement Source Screen Module / API Table Test Status Change history
REQ-ADM-012 Member list view RFP 3.2 ADM-MEM-010 member/list MEMBER TC-ADM-031~034 Implemented
REQ-ADM-012-1 Member list Excel download CR-014 ADM-MEM-010 member/export MEMBER, AUDIT_LOG TC-ADM-035~037 In design Added on approval of CR-014
REQ-ADM-013 Edit member information RFP 3.2 ADM-MEM-020 member/update MEMBER, MEMBER_HIST TC-ADM-040~044 In testing
REQ-IF-004 Organization data integration with the HR system Technical negotiation document 2.1 N/A if/org-sync ORG, IF_LOG TC-IF-010~015 Pending Specification not received

These are the rules followed in operating it.

  • The source column is never left empty. A row whose source is not the RFP or a contract document must have a change request number. A row with neither is scope that came in without a record.
  • A requirement left unlinked to any screen or test is an omission. Conversely, a screen not linked to any requirement was built without a basis. Check in both directions at the end of every phase.
  • For a deleted requirement, change the status instead of deleting the row. Once deleted, it becomes impossible to explain why it disappeared.
  • When a change is approved, update the traceability matrix first. Trying to bring the matrix into line after the design documents and code have been changed usually fails.

The links are also used to check completion. When the requirements list and the deliverables are linked, it is possible to see at a glance which items have not yet been implemented and which still have tests outstanding. It also serves as supporting evidence at the acceptance stage.

No separate tool is needed. Managing it in a single table is effective. What matters is that this table is updated whenever a requirement is added or changed. A document that is not updated quickly loses trust, and nobody looks at it.

Record what was decided not to apply, too

If rejected requests are left out of the record, the same request comes in again later. Keeping them with the reason for rejection cuts the time spent on re-discussion.

Items agreed to be carried over to a follow-on project are also organized separately. At project close, this list becomes the draft requirements for the next project.

Use a change log to see the cumulative total

Separately from the individual request forms, keep a change log in which every request is entered on one line. Requests handled under the simplified tier and requests judged to be elaboration also go in here.

No. Received Request summary Type Tier Effort (person-days) Schedule impact Outcome Decision date Baseline version reflecting it
CR-013 05-08 Default list sort to sign-up date, newest first Elaboration Simplified 0.2 None Applied 05-08 Screen design document v1.3
CR-014 05-12 Member list Excel download Addition Standard 5.5 2 days Approved (Alternative A) 05-19 Requirements v1.2
CR-015 05-14 Add affiliates to the organization chart integration targets Addition Major Under analysis Under analysis On hold

Four numbers drawn from this log go into the weekly report: the number of requests received, the cumulative approved effort, its ratio to the contract effort, and the number of open requests past their deadline. When the numbers appear in the report every week, the responsible managers on both sides learn of the accumulation early, and nobody ends up proposing to settle everything in one go at the end of the project.

The log contains requesters' names and details of their work. Viewing permission is limited to those involved in the project, and the retention period after project close and the method of disposal follow the contract's clause on the return of materials.

4. Public-sector projects have a separate system

For a public software project, there is a statutory procedure for task changes. The content below is organized on the basis of the provisions as checked at the Korean Law Information Center (국가법령정보센터) in October 2026.

Task Deliberation Committee

The Software Promotion Act (소프트웨어 진흥법) provides that the head of a State agency, etc. (국가기관등) is to establish a Task Deliberation Committee (과업심의위원회) to deliberate on matters concerning the conduct of software projects. (Software Promotion Act, Article 50)

The matters subject to deliberation are the finalization of the task content, and the finalization of changes to the task content together with the resulting adjustment of the contract amount and contract period. The head of the State agency, etc. must reflect the deliberation results in the contract unless there are special circumstances, and the business operator may request that the committee be convened when a change in the task content makes a change to the contract necessary (paragraphs 2 and 3 of the same Article).

The committee consists of at least 5 and no more than 10 members including the chairperson, and members who do not belong to the agency concerned must make up a majority. (Enforcement Decree of the Software Promotion Act, Article 45) This is where it differs from an internal meeting of the contracting agency.

One point matters in practice: the system itself provides that a task change can be the basis for adjusting the contract amount. If changes are not kept on record, this procedure cannot be used.

Change procedure and deadlines

The flow laid down in the Enforcement Decree and the public notice, set out in order, is as follows.

Step Content Basis
Request The business operator submits a task change request form (Attached Form No. 13) to the contracting agency. For a joint contracting group (공동수급체), the lead member applies with the consent of all members Guidelines, Article 26, paragraphs 1 and 2
Request to convene On receiving the request form, the contracting agency requests the chairperson to convene the committee. Where the change is needed on the contracting agency's side, it likewise notifies the contract counterparty and requests that the committee be convened Guidelines, Article 26, paragraphs 1 and 3
Deliberation The committee deliberates on the appropriateness of the reason for the change and the appropriateness of the adjustment of the contract amount and contract period. Resolutions are passed with a majority of the incumbent members present and the consent of a majority of the members present Guidelines, Article 27, paragraph 1; Enforcement Decree, Article 46, paragraph 2
Notification of result The contracting agency notifies the business operator of the result of the deliberation and resolution and of its action plan within 14 days from the date it received the request to convene. In cases such as where further investigation is needed, this may be postponed once, by no more than 14 days, in consultation with the business operator Enforcement Decree, Article 47, paragraph 5
Contract amendment The business operator may request a contract amendment on the basis of the action plan, and the contracting agency must make the adjustment within 30 days from the date it received the request Guidelines, Article 28, paragraph 2
Re-deliberation A party that objects to the content of the notice may request re-deliberation within 14 days from the date it received the notice Guidelines, Article 28, paragraph 3
Record The contracting agency prepares a task change management record (Attached Form No. 15). Where the contract amount is adjusted, it must be prepared Guidelines, Article 28, paragraph 1

The underlying provisions are the Enforcement Decree of the Software Promotion Act (Presidential Decree No. 36338, in force June 3, 2026) and the Guidelines on Contracts for and Management and Supervision of Software Projects (소프트웨어사업 계약 및 관리감독에 관한 지침) (Ministry of Science and ICT Public Notice No. 2023-15, in force May 15, 2023).

There are three things in this procedure that the contractor easily overlooks.

  • The procedure for a change must be completed before the part concerned is performed. Article 26, paragraph 5 of the Guidelines lays this down as the principle, and exceptions are recognized by applying the General Conditions for Service Contracts (용역계약 일반조건) mutatis mutandis. Building first and asking for settlement later departs from the principle.
  • If it is not requested, the committee may not be convened. Article 24-2 of the current Guidelines allows the contracting agency not to convene the committee where the business operator has not requested it. If the request is put off out of concern for the relationship, the procedure itself never starts.
  • Check whether the procedure is written in the bid notice. Article 47, paragraph 6 of the Enforcement Decree requires the bid notice to state the task change procedure, including the fact that the business operator may request that the committee be convened. Checking this wording at the proposal stage makes it easier to invoke the procedure after kickoff.

What is recognized as a change

The baseline for the judgment is the contract documents. The Guidelines provide that, once the task content has been made specific at contract signing through a project execution plan or statement of work agreed between the contracting agency and the contract counterparty, the content of that document is deemed the finalized task content after the contract is signed (Guidelines, Article 25, paragraph 5). This is why the project execution plan must not be written and submitted as a formality.

The task deliberation guide divides appropriate task changes into three types. (Guide to Task Deliberation for Public Software Projects, January 2021 edition)

Type Example Handling
Change resulting from a change in law or system, such as a statutory amendment Change in the way work is handled under the law Committee deliberation, with follow-up measures such as adjustment of contract period and amount
Change resulting from a change in the technical or policy environment Cases where the budget is reduced, or convenience or administrative efficiency is improved, compared with running it as a separate project Committee deliberation, follow-up measures
Minor change that the contracting agency and the business operator agree can be made without adjusting amount or period Minor modification of the user interface May proceed without committee deliberation

The same guide recommends that, even for a minor change, the agreed content be kept in meeting minutes signed by both sides or in the requirements traceability matrix. It also lists, as a matter to be checked in deliberation, whether something is a task change or a task elaboration. The distinction between elaboration and addition set out earlier becomes a deliberation item in public projects.

On what basis is the contract amount adjusted

The Guidelines require the basis for adjusting the contract amount in line with the changed task content to be calculated by applying the software project cost standards (소프트웨어사업대가의 기준) mutatis mutandis (Guidelines, Article 27, paragraph 3). The task deliberation guide explains this as applying the "Guide to Software Project Cost Estimation (SW사업 대가산정 가이드)" mutatis mutandis, and advises that the size of the change be stated in function points (FP) in principle, with a function point calculation statement attached.

In practice this means the following.

  • The cost breakdown statement from contract time becomes the baseline for adjusting the amount. The guide explains that the cost breakdown statement is prepared with the function points agreed between the client and the contractor and is used as the baseline for adjusting the contract amount. If the function list and function points are not agreed at contract time, there is no unit in which to count how much has been added.
  • A change history managed only in effort is hard to use as it is. Recording the number of affected functions and the function points in the change log alongside person-days makes it easy to carry over into deliberation materials.
  • Increases and decreases within the total function points may be treated differently. The cost-bearing recommendation in the guide (January 2021 edition) proposes that additions and changes exceeding the total function points be borne by the contracting agency, and those not exceeding it by the business operator. This is why removed functions and added functions have to be tallied together.
  • If there is no budget, the adjustment goes in the direction of reducing the tasks. The guide also describes a method of readjusting the tasks within the existing contract period and contract amount where adjusting the contract amount is difficult.

The cost estimation guide is published by KOSA, and at the time this article was revised (October 2026) the most recent full revision posted on the association's website was the 2025 revised edition. (Guide to Software Project Cost Estimation, 2025 revised edition) The unit price per function point and the adjustment factors change with each revision, and the applicable standard may differ according to the year in which the budget was drawn up, so no figures are given in this article. When estimating, the guide for the year that applies to the project concerned has to be checked directly.

What changes from February 2027

Article 50 of the Software Promotion Act was amended on August 11, 2026 (Act No. 21865) and takes effect on February 12, 2027. (Software Promotion Act, version in force February 12, 2027)

Item Current In force February 12, 2027
Reflection of deliberation results Reflected in the contract, etc. unless there are special circumstances Adds a duty to secure the funding needed to reflect them (paragraph 2)
Convening the committee Accepted, unless there are special circumstances, when the business operator requests it For contracts prescribed by Presidential Decree, such as projects with a high likelihood of task changes, a duty to convene, unless there are special circumstances, once the work reaches the progress prescribed by Presidential Decree, such as completion of design (paragraph 4, newly inserted)
Simplification or omission The Act has no provision; the public notice specifies which deliberations on finalizing task content may be simplified For projects determined by the Minister of Science and ICT, the deliberation procedure may be simplified or omitted (paragraph 5, newly inserted)

Care is needed over the scope of application. The Addenda provide that the amended paragraphs 2, 4 and 5 apply beginning with contracts concluded after the Act takes effect. A contract concluded before February 12, 2027 is governed by the previous provisions even if it is a continuing project.

The range of contracts subject to mandatory convening and the specific progress meant by "completion of design, etc." are delegated to Presidential Decree. The Enforcement Decree as of the time this article was revised does not yet reflect these matters, so they have to be checked again once the subordinate legislation has been put in place.

This chapter restates the content of the statutes and official guides from a practical standpoint and is not a substitute for legal advice. Statutes and public notices are amended, so for an actual project please check and apply the current provisions at the Korean Law Information Center and the contracting agency's contract conditions.

What is different in private contracts

The Task Deliberation Committee is a system that applies to projects ordered by State agencies, etc. Private contracts have no equivalent procedure, and what the parties wrote in the contract is the standard.

Category Public contract Private contract
Basis of the change procedure Software Promotion Act Article 50, the Enforcement Decree, the public notice The change clause in the contract. If there is none, negotiated case by case
Who decides A Task Deliberation Committee in which external members are the majority A joint board set up by the parties, or the responsible managers of both sides
Response deadline 14 days from the date of the request (may be postponed once) The deadline written in the contract. If none is written, no deadline
Basis for adjusting the amount Software project cost standards applied mutatis mutandis, centered on function points Unit prices written in the contract (person-month rate, per-function rate, etc.)
Baseline documents Statement of work, project execution plan, cost breakdown statement Documents attached to or cited in the contract
Funding Within the appropriated budget. If adjustment is difficult, the tasks are readjusted Agreement between the parties

That a contract is private does not mean the law has no application at all. Article 38 of the Software Promotion Act lays down the principle of fair contracts for software project contracts in general, including subcontracts. It provides that, where the content of a contract is markedly unfair to one party, and the contract, without reasonable grounds, does not recognize a change in the contract amount and contract period following a change in task content after the contract is signed, or shifts that burden onto the other party, the contract is void to that extent only (Article 38, paragraph 3, subparagraph 1). Whether an individual clause falls under this, however, is a question that needs to be judged case by case.

What is worth borrowing for private projects is the structure. The essence is to have a separate consultation channel for judging task changes. Handling everything through discussions between the PMs alone easily damages the relationship. A regular joint board in which senior managers of both sides take part reduces the chance of individual matters turning into emotional ones. The response deadlines, written notice and preparation of a management record in the public system are mechanisms that can be carried over as they are into the change clause of a private contract.

5. What to settle at the contract stage

Change management does not start during the project; it starts with the contract.

Specify the scope in documents

If the contract says only "as per the requirements definition," the ambiguity of that document becomes the ambiguity of the contract as it stands.

  • State what is included in scope as a list
  • State what is not included as well. This item is more important than it seems
  • Define the list of deliverables and the completion criteria for each
  • Define the acceptance criteria and procedure

Some are reluctant to write down "exclusions," but stating them is in fact safer for both sides.

Write down the assumptions

The contractor's schedule estimate rests on a number of assumptions. If those assumptions break, the schedule changes too.

  • The materials the client has agreed to provide, and when
  • Whether the specifications of the systems to be integrated will be provided
  • When the test environment and accounts will be provided
  • The time required for decisions
  • The dates on which front-line staff are available for interviews

If these assumptions are kept in the contract documents, the cause can be checked when a delay occurs. If they are not written down, every delay comes to look like the contractor's responsibility.

Write the acceptance criteria specifically

Scope disputes are at their most intense at the acceptance stage. If the criteria are vague, everything erupts here at once.

  • What is checked to determine pass or fail
  • How long is the acceptance period, and what happens if there is no response within it
  • How are defect grades divided, and up to which grade must defects be resolved to pass
  • Is there a re-acceptance procedure and a limit on the number of times
  • Are defects found after acceptance handled as warranty repairs

The classification of defect grades is especially important. If an error that makes work impossible and an awkward piece of screen text are handled by the same standard, no agreement is reached. Separating the determination criteria by grade puts the discussion in order.

Put the change procedure itself into the contract

  • How change requests are received, and the form
  • The deadline for the impact response
  • Approval authority and procedure
  • The basis for adjusting contract amount and period
  • How matters are handled if consultation breaks down

These clauses are not there to prevent disputes but to make discussion faster. When the procedure is fixed, there is no need to negotiate the method first each time.

Of these, the one most often left blank is the basis for adjusting the amount. If unit prices are negotiated after a change has arisen, the validity of the change and the unit price are disputed at the same time. Choose a method at contract time and write it down.

Method What to write in the contract Where it fits Points to watch
Person-month rate Person-month rate by grade, method of estimating effort Private contracts, projects where the content of changes varies The effort estimate itself becomes the dispute. Attach the work breakdown
Per-function rate Rate per function point or per screen or integration, calculation rules Public contracts, projects with a clear number of functions Work that is not captured by function counts, such as performance improvement and migration, is defined separately
Scope trade A procedure for excluding an existing item of the same size as the added item Projects with a fixed total amount and delivery date Put excluded items on the next-phase backlog so that a record remains
Contingency effort The change-response effort included in the contract amount, and the rules for drawing it down Early-stage projects where requirements are not yet firm Unless the drawdown status is shared periodically, a dispute arises at the point it runs out

In public contracts the method of adjusting the amount is largely determined by statute and contract conditions, so the table above is mainly for reference when designing the clauses of a private contract.

Adjustment of the period is dealt with in the same clause. Write down by what calculation the delivery date changes when a change is approved, and how the days are treated when the client's response passes its deadline. The most common omission is a state in which the amount has been adjusted but the delivery date is unchanged.

6. Frequently asked questions

How detailed should the requirements be

It is hard to fix every field of every screen at the contract stage. A realistic standard is the level at which effort can be estimated.

Estimation is generally possible when the following information exists per function.

  • What data it handles
  • How many screens are needed
  • Whether there is external integration
  • Whether there are distinctions by permission
  • Whether there are special processing rules

Anything more detailed is elaborated in the analysis and design phase after kickoff, provided it has been decided how far that elaboration counts as original scope.

Does every small change have to be documented

Putting every change through a procedure slows the project down. It is better to set a threshold.

  • Things with almost no effect on effort, such as wording corrections and layout adjustments, go through simplified handling
  • Things at or above a certain effort, or affecting the data structure or integration, go through the formal procedure

However, what is handled under the simplified procedure must still be recorded. Individually small, they add up to a volume that cannot be ignored. The record becomes the evidence that later shows "small things kept piling up."

What if the scope has already grown considerably

First, work to sort out the current state is needed.

  1. Set the scope at contract time and the scope currently in progress side by side
  2. Go through the differing items one by one and establish how each came to be added
  3. Distinguish whether each is a difference in interpretation or a real addition
  4. Re-estimate the remaining schedule and effort
  5. Negotiate on the basis of this material

Without this work, simply saying "the schedule is too short" is not persuasive. The discussion begins only when what has grown and by how much is shown item by item.

If starting from a state with no records, trace back the time and the requester of each request from meeting minutes, emails, messenger conversations and the repository's commit history, and fill in the change log. Mark separately the items for which no evidence was found, and do not mix them with the evidenced items in the negotiation materials. Agree on the date of this exercise as the new baseline and apply the procedure from then on.

What if neither the amount nor the period can be adjusted

In a project where the total amount and delivery date are fixed, the only way to accept a change is a trade within the scope.

  • Remove from the baseline an item of similar size to the item to be added, and put the removed item on the next-phase backlog
  • Split into phases by dividing what is essential for going live from what can be added afterward
  • If there is nothing to trade, record that fact in the joint board's minutes

The task deliberation guide for public projects likewise describes a method of readjusting the tasks within the existing contract period and contract amount where adjusting the contract amount is difficult. In either case, the point is to leave a written record of what was taken out and what was put in. A trade that was not recorded comes back at the acceptance stage as an unimplemented item.

What should the client prepare

Demanding management from the contractor alone is not enough. These are the things for the client to prepare.

  • A single decision-making channel — If several departments each make their own demands, the contractor cannot tell which to follow
  • Internal agreement first — Differences between departments are better settled before they are passed to the contractor
  • A schedule for providing materials — If requested materials are late, the schedule slips
  • Acceptance staff — If acceptance is delayed, the next phase is delayed with it

7. Pre-kickoff checklist

Fixing the scope

  • Have catch-all verbs, adverbs of degree and unspecified-scope expressions been screened out of the requirements documents
  • Has each function been made specific to the level at which effort can be estimated
  • Are the items not included in scope stated
  • Are the list of deliverables and the completion criteria defined
  • Are the acceptance criteria and procedure agreed

Advance checks

  • Have the stakeholders and those with approval authority been identified
  • Have the specifications of the systems to be integrated been obtained
  • Have actual samples of the data to be migrated been checked
  • Are the materials to be provided by the client, and when, documented

Change procedure

  • Are the baseline documents and the point of finalization recorded
  • Are the change request form and the channel for receiving requests defined
  • Do the impact estimation items include rework cost
  • Is approval authority divided by size
  • Are rejected and on-hold items also kept on record
  • Is the basis for adjusting contract amount and period stated in the contract
  • Were the criteria separating elaboration from addition agreed at the kickoff meeting and recorded in the minutes
  • Are the deadline for the impact response and the deadline for the approval decision set
  • Is there a cumulative threshold for requests handled under the simplified tier
  • Does every row of the requirements traceability matrix have a source
  • Has it been agreed to include the cumulative figures from the change log in the weekly report

For public-sector projects

  • Has the way the Task Deliberation Committee operates been checked
  • Is the procedure for requesting deliberation on a task change known
  • Has it been checked whether the task change procedure is stated in the bid notice and the RFP
  • Are the project execution plan and statement of work specific enough to serve as the baseline for judging changes
  • Are the function list and function points agreed in the cost breakdown statement
  • Has it been checked whether the contract date is on or after February 12, 2027 and whether the amended provisions apply
  • Has the latest content of the relevant statutes and guidelines been checked

Closing

The purpose of scope management is not to block change. As a project proceeds, circumstances change and better ways sometimes come into view. Change itself is natural.

What causes trouble is change that seeps in without being recorded. If a project ends with nobody knowing when what grew, all that remains is mutual distrust.

Clearing out the ambiguous expressions in the requirements in advance, fixing the baseline, and receiving changes in writing and judging them together with their impact. Each looks like a tiresome procedure, but they are the surest way to reduce the attrition in the later stages of a project.

We have carried out system build projects in both the public and private sectors. If you need help at the stage of defining project scope or organizing requirements, please feel free to contact us.

References