Progress % you cannot trust—without a frozen WBS baseline and change intake, percentage is mood
A client casually adds a remark, and two weeks later it turns into 'this should have been done long ago.' Progress charts that appear green are often not due to poor execution, but because the denominator has been quietly rewritten—without a baseline and change control gate, the completion percentage is just a feeling.
What you'll take away
- Freeze the WBS baseline first, then talk about the progress percentage; work outside the baseline should not be included in the formal completion rate
- Changes must assess progress, cost, and risk, and then enter the CCB or fast track according to authority.
- Unapproved changes shall not enter the official plan, reporting, or acceptance; verbal requests must first enter the evaluation pool
- WBS/L1 ~ L3 for waterfalls, backlog for agile - form is variable, baseline and change ideas are unchanged
- The change rate and the proportion of overtime outside the baseline should reflect health; a sudden zero change may indicate underground work, not false health.
The 'Add a Little' in WeChat, how to eat up the entire Gantt chart
The implementation manager's phone lit up at 10 PM: the client’s on-site lead sent a voice message, 'Add one export to the interface, it's very simple.' The presales staff replied 'OK' in the observation group chat. Two weeks later, the export had turned into permissions, templates, audit logs, and training, with man-hours skyrocketing several times. The project weekly report still indicated 75% progress—because the new tasks were quietly added to the denominator, so the completion rate continued to 'steadily rise.' During project closure acceptance, the contract attachments did not match the on-site deliverables, and the blame-shifting began.
Manufacturing and turnkey delivery are particularly vulnerable: contract payments are tied to milestones, and on-site conditions are tracked daily. Project management plans emphasize baselines and entry approvals—once the WBS baseline is frozen, scope changes are assessed for impact before being scheduled; Gantt charts without baselines should not be used for management purposes. Scope creep is rarely caused by someone's malice; it is more commonly due to WeChat messages, verbal agreements, pre-sales on-site promises, and tasks being 'conveniently done' during implementation. The gate is not about attitude, but aboutTurn ideas into the status and permissions of baseline changes。
The completion rate must have a fixed denominator; otherwise, it's just emotion.
For any 'in-progress' task, one should be able to answer within a minute: which version baseline it belongs to, whether it has been change-approved, and which milestone and budget item it affects. If unable to answer, the progress percentage is not trustworthy.
Common sources of fake green:
| statement | actual | Consequence |
|---|---|---|
| The client said to do the upper part first. | Oral request directly dispatched | Costs and delivery times are being eroded |
| Just change a little bit | Small changes leave no trace, but accumulate into a big package | The acceptance scope does not match |
| Agile, can change anytime | Backlog has no version, cards can be inserted outside the sprint at will | Burnout is good-looking, but the delivery list is out of control |
| Changes are too slow, do first and make up later | Skip assessment and approval | The risk is exploding at project closure |
| The progress is already 80% | Denominator contains unapproved range | The management keeps throwing more people into the pit. |
L1 aligns the contract with business milestones, L2/L3 breaks down into work packages that can be assigned, estimated, and accepted; further down, daily reports are sufficient. Once the baseline is frozen, the completion percentage has a fixed denominator; once a change is approved, its spread transforms from a cultural issue into a process issue that can be measured and arbitrated.
The baseline version should include the effective date and a differential comparison: which work packages were added or removed relative to the previous version, and which milestones are affected. A 'full table refresh' without a version number always makes the completion rate look good and makes history incomparable. When freezing v1 of a pilot project, items that were in progress but not included in the contract attachments should be listed separately—this list often represents the real extent of the organization's scope creep and is also the best material for convincing stakeholders to accept the gate.
Pending Evaluation Pool: Ideas and Commitments Must Be Separated
In system design, requirements raised verbally, by email, or on-site should first enterPending Evaluation Pool, isolated from the formal plan, work reporting, and acceptance checklist. Items in the pool can be discussed, estimated, and prioritized, but cannot be assigned without approval, nor can the working hours be counted into the baseline schedule.
Status recommendations should be clear and subject to sampling inspection: To be evaluated → Under evaluation → Approved/Rejected → Included in the baseline. Fast-track processes (for example, below the human threshold and not affecting payment milestones) still need to be documented, otherwise the threshold could become a loophole. After approval, it must be synchronized in three places: scheduled tasks, acceptance deliverables list, and if necessary, the contract/supplementary agreement — if execution changes but acceptance standards remain the old ones, it is equivalent to postponing disputes until a week before payment.
The evaluation pool also needs a cleanup rhythm: items that are neither evaluated nor rejected for a long time will turn into another wish list. During project collection meetings, the pool's age can be spot-checked, and overdue items must have a forced decision—do it, don't do it, or return it to the proposer to provide additional materials. If items only go into the pool and never come out, change control can also appear to be frozen. For items that colleagues implementing the project 'happen to do,' adding them to the pool and supplementing the impact assessment is more honest than tacitly allowing the established fact and pretending the baseline is still valid; if an established fact affects a payment milestone, business confirmation must be escalated, and technical completion cannot replace contract completion.
Impact assessment in four quadrants, so that the CCB won't operate in vain
The Change Control Board is not about 'holding another meeting'; it is about defining who can propose changes, who must review them, and who has the authority to approve them. In manufacturing delivery, the standing members are recommended to include: the project manager (materials), business/sales (customer commitments), technical lead (feasibility and risks), and a cost or finance interface (rough incremental estimates). Customer representatives can attend for key changes, but they do not replace internal approval—otherwise it becomes a case of 'the customer says it, it is approved'.
Do not write the impact assessment as prose. At least four sections:
- Progress Offset(Heaven, is it a threat to milestones)
- Cost increment(Human Resources and Procurement)
- Risk Level(Regarding acceptance, safety, shutdown)
- Whether the payment milestone has been reached
If the grid is not completely filled, there is the right to return it, rather than going on-site to guess. High-impact changes should be able to link to the risk register; if delays and scope changes are silently approved, zombie entries in the register and uncontrolled changes often appear together. Once thresholds are written into the configuration, don’t change them every week: any impact on payment or budget overruns must go through the CCB; minor changes can be co-signed asynchronously.
Waterfall and Agile: Form is variable, discipline is immutable
Waterfalls use phase gates and WBS, while Agile uses epics, stories, and sprints—both are fine. What remains unchanged is: if the committed release scope or contract milestones are affected, first change or formally adjust the release baseline before going to the kanban. 'Agile' describes the delivery rhythm, not the cancellation of commitment management. The same applies to incremental models: each increment still has an acceptable boundary, and ideas outside the boundary go into the backlog, not into the current commitment.
The connection with CRM/contracts is very practical: if the scope casually added by presales during the opportunity stage is not synchronized with the project baseline, the delivery side will use change requests to "catch up." A more stable approach is to use contract attachments or SOW as the source of L1 scope; anything beyond that generates a change request number and a note on whether a supplementary agreement is needed. The organizational version of the problem—where sales makes on-the-spot promises to win a deal and delivery ends up taking the blame—is caused by a disconnect between the opportunity and the baseline.
How to assess health: not afraid of changes, afraid of being unable to see
| Signal | Pronunciation |
|---|---|
| Number and scale of monthly changes | Changes are not scary; suddenly becoming zero may be inevitable. |
| Number of projects started without assessment | Should be zero; greater than zero indicates the gate has been bypassed |
| Proportion of Overtime Outside the Baseline | Persistent high levels need to be managed; the fast-track channel is being abused |
| Change Average Period | If too long, it forces the business to go around; if too short, the evaluation may be just a formality. |
| Proportion of changes in reaching payment milestones | At most, trace back the pre-sales scope and the quality of contract attachments |
Anti-patterns to be called out: Progress meetings verbally 'agree to add' instead of submitting change requests; baselines refreshed monthly for the whole table without keeping versions; Kanban boards with unlimited added cards and no priority versions; change approvals not updating the acceptance checklist. For purely internal research with no external commitments, lightweight tracking is acceptable; once it involves customer acceptance or payment, immediately escalate the discipline. When the charter and success criteria are not clearly written, first add a page of scope and non-goals before discussing the baseline. When estimation basis is missing, first establish task-level estimation references, then enforce three-sided evaluation—otherwise, the CCB will just turn into a head-scratching meeting. When the stakeholder list is incomplete or it's unclear who has the right to propose or approve changes, taking it to the CCB will only result in bickering meetings—first complete the authority matrix, then hold the meeting.
The cost side should also be able to see changes: if the approved scope increase is not synchronized with budget adjustments, the project accounts will penalize those executing the change, and both a 'false spike' in the EAC and scope leakage will occur simultaneously. The risk side is similar: high-impact changes should be able to generate or link to entries in the register to prevent impact assessments from being completed and then filed away. When the three accounts for changes, costs, and risks are invisible to each other, even the most sophisticated project portfolio dashboard is just three colored lights in parallel.
JEDP-PMS covers L1–L3/WBS, pending evaluation and impact assessment access on the planning and change side, and can be linked with business opportunity contracts. What the system needs to capture are statuses and permissions, not an extra change table that can be ignored. Regular project portfolio meetings focus on unevaluated starts and hours beyond the baseline, which reflects actual health better than just looking at the number of green lights. In phase one, the templates, baseline release, and change traceability should be implemented; projects without WBS discipline and only milestone PPTs should first be taskized before discussing alerts and portfolio views.
How the 'do first, make up later' approach on site is blocked by the system
Mechanisms can't stop all favoritism, but they can raise the cost of bypassing them. If reporting work hours checks whether a task belongs to the current baseline or has been approved for change, hours outside the baseline will be exposed; if the acceptance checklist only references baseline deliverables, privately done features won’t make it into the formal acceptance; if procurement requests require attaching task or change order numbers, purchases outside the scope will be blocked. The three checkpoints don't all need to be implemented at once, but at least start with 'no reporting work without approval'—work hours are the most honest trace of spread, and they are also the easiest to get muddled and hidden in month-end allocations.
Communication scripts with clients should be prepared in advance: adding requirements is fine, but please confirm delays, costs, and risks. Summarize the impacts in a four-grid format on a single page and send it to the client; this generates less emotion than arguing over whether something is part of the original scope. When internal sales and delivery have a bet, pre-sales commitments must be tracked to L1 or change orders; for commitments that cannot be met, delivery has the right to refuse to start work and escalate—otherwise, the gate will always be bypassed by business.
You can see how much it has spread in half a day
Choose a pilot under construction: freeze the current WBS as baseline v1; sweep the items from the past two weeks that are "in progress but not in the contract/baseline" into the pending evaluation pool—usually, you can see the extent of hidden scope in half a day. Then release the grading thresholds and the CCB list, with only one rule:Do not report work or enter the acceptance list without approvalTwo weeks later, check again whether the unassessed projects that have started have returned to zero; if they cannot be zero, first investigate who is bypassing the gate, and then discuss the full promotion template. If pre-sales promises are found to have the highest proportion in the channels, trace back the business opportunities and contract attachments; if on-site verbal commitments have the highest proportion, strengthen the entry of the to-be-assessed pool and the project manager's veto power.
Change itself is not a crime; secretly making changes is. Only when each scope change can be made visible, estimable, and recordable for review, does the progress percentage regain the right to enter management review. Wish-list style Gantt charts can still be drawn for fun; what enters management metrics can only be the execution status on a specific baseline version.
- PMS project solution
- Milestones must be accompanied by evidence
- Project costs are recorded in the same ledger
- Risk Register Operation
Want to apply this in your plant?Resources has matching self-assessments and templates—or book a live demo.
FAQ
Quick answers on this topic—still stuck?Contact
Do agile projects still need a WBS?
There should be work breakdown and prioritization, in the form of a backlog and epics. The idea of going into a sprint only after a baseline version, impact assessment, and approval remains unchanged. Don't use "Agile" as a verbal excuse to add requirements.
Do even very small changes need to go through the change process?
Threshold can be set: below the working hours/amount and does not affect the milestone fast track, but still needs record keeping. Zero-record 'minor changes' are often the main channel for scope bleed.
What should be done if the client refuses to make changes?
Explain things in terms of impact: translate 'add an item' into a few more days of delay, an extra cost, an increased risk level, or whether it affects the payment milestone. Most clients will cooperate; those who don’t should confirm in writing that the commitment becomes void under these conditions.
To what level of detail is the WBS?
Detailed enough to assign tasks, estimate time, and conduct acceptance. L1 aligns with contract milestones, L2/L3 translates into deliverable work packages; further down, daily reports can be used to avoid micromanagement.
Does CCB really have to hold a meeting?
Critical or above-threshold change proposals should be discussed in regular meetings or signed off online; minor changes can be approved asynchronously. The key is authority and record-keeping, not the meeting room itself.