During an overseas project, a request can sound like a small favor: just add this. Misunderstandings surface when hours, budget, or delivery dates change. Compare each request with the agreed scope, record its impact, and schedule it only after an authorized person approves it. The example is hypothetical.
When should you open a change request?
Open a request when a new requirement changes an agreed delivery baseline, not simply when someone uses a particular phrase. Adding or removing pages, languages, features, data fields, formats, acceptance criteria, required materials, or work order should be recorded. If the impact is not yet known, log it as pending assessment; an unfinished estimate is not a reason to promise the work verbally.
Distinguish clarification, defect correction, and scope change. A clarification explains an unclear part of the existing specification without expanding the deliverable. A defect fails to meet a written, agreed condition. A change adds an outcome, alters an agreed condition, or reworks something already correct. Whether free corrections or revision rounds are included depends on the original agreement and approved records, not the team's usual practice.
Ask whether the request could change the estimate, cost, dates, quality checks, or another person's work. If so, assess it through a change request. If it is only a no-impact wording clarification, record the answer in the existing task thread to keep everyone on the same version.
For example, suppose the baseline is an eight-page bilingual Chinese and English website. Someone asks for four more pages and a registration form for overseas distributors. Those additions affect content, interface, testing, and handover, so list them separately instead of calling them a minor adjustment. If the team misspelled an approved product name, correct and record the defect under the agreed process.
Acknowledge a new request with its ID and expected response time. This is not approval or a date commitment. If the requester says only that the site should suit the local market, ask what screen, wording, or workflow should change and who will accept it.
How should you describe the original scope and new request?
A change record should show someone who missed the meeting exactly what differs. Cite the valid scope version or delivery list, including deliverables and acceptance, then describe each new request. Avoid vague phrases such as optimize or make it more international. Flag ambiguous wording for confirmation instead of choosing an interpretation.
For each item, note the requester, purpose, affected deliverable, required inputs, acceptance method, desired date, dependencies, and open assumptions. Purpose helps identify alternatives; acceptance criteria define completion. Separate requirements from preferences and state what is outside the assessment, so one request does not silently expand into market research or ongoing support.
Suppose the baseline has a general contact page and the request is to add a distributor form. Before scheduling it, confirm the fields, required entries, post-submission message, data recipient, approved copy owner, and screens to test. If information is missing, mark the item as awaiting input, name the provider, and set a due date. Do not treat an assumption as approved scope.
A simple difference table keeps the discussion focused:
| Field | Original baseline | New request |
|---|---|---|
| Pages | Eight bilingual Chinese and English pages | Add four pages |
| Form | None | Distributor registration; fields to be confirmed |
| Acceptance | Check each page against the original list | Add checks for the new pages and form |
Ask the requester to confirm the difference before assessment, not the price. List missing copy, assets, language versions, or data sources as assumptions; if one changes, the estimate may need revision.
Who should assess the hours and cost?
The project lead gathers the request and breaks it into work but should not guess every specialist's effort. Ask the people doing design, content, engineering, localization, and quality checks to estimate their parts. The owner of an external dependency should explain waiting conditions and schedule impact. The commercial contact can then organize cost and options under the existing pricing arrangement, showing how each figure was derived.
Estimate checkable tasks such as clarification, layout, writing, production, integration, testing, and handover. For each, record effort, responsible person or role, required inputs, estimate basis, and uncertainty. Do not give only a total or mix calendar waiting time with labor hours. If information is missing, give a conditional estimate and state what would trigger recalculation.
These figures are hypothetical, assuming the distributor form can be estimated from the current description:
| Work item | Assumed effort |
|---|---|
| Clarify requirements and fields | 2 hours |
| Design the form interface | 2 hours |
| Build and integrate | 4 hours |
| Test and prepare handover notes | 2 hours |
| Total | 10 hours |
If the assumed rate is NT$2,000 per hour, the example is 10 hours × NT$2,000 = NT$20,000. This is arithmetic for illustration, not a Chan & Chung quote, rate, or tax statement. An actual quote should follow the applicable agreement and state currency, billing unit, potentially separate work, and assumptions. Engineering and content estimates should identify their own inputs where they differ.
Present options to add the full request, reduce scope, defer it, or supply missing information first. Explain each option's deliverable, effort, cost, and date impacts. Estimators confirm workload; the budget authority approves the commercial commitment.
What work should pause before approval?
While approval is pending, pause affected work that could be discarded, reworked, or create extra cost. Continue independent work under the last approved version. Record what is paused, why, when, its dependencies, and what must happen before it resumes; notify the people doing it.
Check dependencies. If new copy determines the page layout, the copy and related design may need to wait. If a feature's direction is undecided, do not take implementation or testing into an irreversible stage. The team may analyze the request or organize existing materials, but that preparation is not approved scope. Check whether scheduled external resources or purchases can be canceled, held, or adjusted before promising new spending.
Suppose testing the existing pages has begun when the distributor form is requested. Continue testing the agreed content for the original eight pages, but mark the form fields, submission result, and interface as undecided. Do not build it and ask for approval afterward. If it uses a component shared by existing pages, the engineering lead should identify affected work; pause that component if needed while unrelated testing continues.
Keep the pause narrow enough to limit rework and clear enough to prevent outdated assumptions. Set a resume condition for each item, such as approved fields, confirmed copy, or a designated budget. If the approval deadline could affect the baseline schedule, include the waiting time. If there is no response, follow the existing agreement for original scope and state that the proposed addition has not started.
If someone asks the team to start before approval, check for written authority for a capped discovery task. Without it, do not begin production. Update status so no one must infer from chat which work may resume.
How should you update dates and owners?
After approval, place the work in dependency order, check people's availability against other commitments, and publish updated milestones. Do not simply add estimated days to the original completion date. New work may depend on client materials, cross-time-zone confirmation, translation, or prior acceptance; independent tasks may run in parallel. Label dates as estimated or confirmed and state assumptions that could change them. For a range, record the earliest feasible date and outstanding conditions.
Assign each added deliverable a responsible role, collaborators, input provider, acceptance owner, and action dates. Do not name the whole team as owner or write only client confirmation as acceptance. Identify the authorized person and criteria. If new work replaces an old task, update assignments and tell the original owner so both task lists are not treated as current.
For example, assume the form needs one workday to confirm fields, two to design, three to produce, and one to test. If these steps are sequential, that is seven additional workdays. This excludes calendar time waiting for inputs and assumes no parallel work. Reinsert the estimate in the current schedule, check for milestone conflicts, and revise only affected dates rather than adding seven days to every deliverable.
Keep before-and-after milestones, affected deliverables, owners, and dates in the update. Identify what moved and what stays on plan. If the approver chooses a smaller request or later implementation, re-estimate and issue a new version. Ask affected people to confirm the dependencies are workable; silence is not acceptance of a date or responsibility.
How do you preserve earlier decisions for traceability?
Use a stable change ID to link the original scope, request, assessment, approval, schedule version, and final delivery. Keep the date, author, and decision status for every update. Do not overwrite the original document or leave the only record as a chat screenshot. An index should let the team find the basis for a decision without guessing which attachment was current.
For each version, retain the original scope and requested difference, requester, estimate and assumptions, budget and date impacts, approver or rejecting party, decision time, conditions, and follow-up owner. Keep rejected, withdrawn, and overdue requests with their status and reason, since the context may matter if they return. For sensitive data, retain only the summary needed for the work decision and use the team's existing access controls.
Suppose version one includes a full estimate for a new form, but the approver authorizes only a reduced set of fields. Version two should link to version one, identify approved and unapproved fields, and show recalculated effort and dates. If another language is requested weeks later, create a new change record that refers to the earlier one. Do not rewrite history to make separate decisions look like one approval.
When work is complete, link the approved version, acceptance result, and unfinished items to the same record. Share the current version externally and tell the team to stop using old task lists as instructions. Keep old records for traceability. A practical next step is to use a one-page template for a pending request, recording its baseline, difference, assessors, approver, and schedule impacts. For Chan & Chung's background and contact options, visit the English homepage.