[{"data":1,"prerenderedAt":71},["ShallowReactive",2],{"legacy:insights\u002Fpms-wbs-change-control:en":3},{"id":4,"title":5,"description":6,"keywords":7,"author":8,"robots":9,"bodyClass":10,"image":11,"jsonld":12,"html":70},"insights\u002Fpms-wbs-change-control","Progress % you cannot trust—without a frozen WBS baseline and change intake, percentage is mood - JEDP Digital Platform","Scope creep rarely occurs due to malice, but rather because verbal requests directly enter the plan. Starting from adding requirements on WeChat onsite, it explains how baseline freezing, the pending evaluation pool, progress\u002Fcost\u002Frisk impact assessment, and CCB-level approval can allow the completion rate to have a fixed denominator again, while being compatible with both waterfall and agile formats.","WBS decomposition, project scope change, PMS project management, change control board","Shenzhen Langbowan Information Technology Co., Ltd.","index, follow","page-insights","https:\u002F\u002Fwww.jedp.cn\u002Fres\u002Fimages\u002Fproduct\u002Fpms-slide6.webp",[13,30,44],{"@context":14,"@type":15,"@id":16,"headline":17,"description":6,"inLanguage":18,"datePublished":19,"dateModified":20,"articleSection":21,"keywords":7,"image":11,"author":22,"publisher":24,"isPartOf":25,"mainEntityOfPage":27},"https:\u002F\u002Fschema.org","Article","https:\u002F\u002Fwww.jedp.cn\u002Finsights\u002Fpms-wbs-change-control#article","Progress % you cannot trust—without a frozen WBS baseline and change intake, percentage is mood","zh-CN","2026-07-23","2026-10-17","PMS · Projects",{"@id":23},"https:\u002F\u002Fwww.jedp.cn\u002F#organization",{"@id":23},{"@id":26},"https:\u002F\u002Fwww.jedp.cn\u002Finsights#collection",{"@type":28,"@id":29},"WebPage","https:\u002F\u002Fwww.jedp.cn\u002Finsights\u002Fpms-wbs-change-control",{"@context":14,"@type":31,"itemListElement":32},"BreadcrumbList",[33,38,42],{"@type":34,"position":35,"name":36,"item":37},"ListItem",1,"Home","https:\u002F\u002Fwww.jedp.cn\u002F",{"@type":34,"position":39,"name":40,"item":41},2,"Insights","https:\u002F\u002Fwww.jedp.cn\u002Finsights",{"@type":34,"position":43,"name":17,"item":29},3,{"@context":14,"@type":45,"@id":46,"mainEntity":47},"FAQPage","https:\u002F\u002Fwww.jedp.cn\u002Finsights\u002Fpms-wbs-change-control#faq",[48,54,58,62,66],{"@type":49,"name":50,"acceptedAnswer":51},"Question","Do agile projects still need a WBS?",{"@type":52,"text":53},"Answer","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.",{"@type":49,"name":55,"acceptedAnswer":56},"Do even very small changes need to go through the change process?",{"@type":52,"text":57},"Threshold can be set: below the working hours\u002Famount 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.",{"@type":49,"name":59,"acceptedAnswer":60},"What should be done if the client refuses to make changes?",{"@type":52,"text":61},"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.",{"@type":49,"name":63,"acceptedAnswer":64},"To what level of detail is the WBS?",{"@type":52,"text":65},"Detailed enough to assign tasks, estimate time, and conduct acceptance. L1 aligns with contract milestones, L2\u002FL3 translates into deliverable work packages; further down, daily reports can be used to avoid micromanagement.",{"@type":49,"name":67,"acceptedAnswer":68},"Does CCB really have to hold a meeting?",{"@type":52,"text":69},"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.","\u003Carticle class=\"insight-article\">\n    \u003Cdiv class=\"insight-container\">\n      \u003Cnav class=\"breadcrumb\" aria-label=\"Breadcrumb\">\n        \u003Ca href=\"\u002F\">Home\u003C\u002Fa>\n        \u003Cspan class=\"breadcrumb-sep\">\u002F\u003C\u002Fspan>\n        \u003Ca href=\"\u002Finsights\">Insights\u003C\u002Fa>\n        \u003Cspan class=\"breadcrumb-sep\">\u002F\u003C\u002Fspan>\n        \u003Cspan>PMS · Projects\u003C\u002Fspan>\n      \u003C\u002Fnav>\n\n      \u003Cheader class=\"insight-hero\">\n        \u003Cdiv class=\"insight-tags\">\u003Cspan class=\"r-tag\">WBS\u003C\u002Fspan>\u003Cspan class=\"r-tag\">Scope Change\u003C\u002Fspan>\u003Cspan class=\"r-tag\">Progress\u003C\u002Fspan>\u003C\u002Fdiv>\n        \u003Ch1>Progress % you cannot trust—without a frozen WBS baseline and change intake, percentage is mood\u003C\u002Fh1>\n        \u003Cp class=\"insight-lede\">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.\u003C\u002Fp>\n        \u003Cdiv class=\"insight-meta\">\n          \u003Cspan>Updated 2026-07-23\u003C\u002Fspan>\n          \u003Cspan class=\"dot\" aria-hidden=\"true\">\u003C\u002Fspan>\n          \u003Cspan>~10 min read\u003C\u002Fspan>\n          \u003Cspan class=\"dot\" aria-hidden=\"true\">\u003C\u002Fspan>\n          \u003Cspan>Manufacturing digitalization · PMS · Projects\u003C\u002Fspan>\n        \u003C\u002Fdiv>\n      \u003C\u002Fheader>\n      \u003Csection class=\"insight-takeaways\">\n        \u003Ch2>What you'll take away\u003C\u002Fh2>\n        \u003Cul>\u003Cli>Freeze the WBS baseline first, then talk about the progress percentage; work outside the baseline should not be included in the formal completion rate\u003C\u002Fli>\u003Cli>Changes must assess progress, cost, and risk, and then enter the CCB or fast track according to authority.\u003C\u002Fli>\u003Cli>Unapproved changes shall not enter the official plan, reporting, or acceptance; verbal requests must first enter the evaluation pool\u003C\u002Fli>\u003Cli>WBS\u002FL1 ~ L3 for waterfalls, backlog for agile - form is variable, baseline and change ideas are unchanged\u003C\u002Fli>\u003Cli>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.\u003C\u002Fli>\u003C\u002Ful>\n      \u003C\u002Fsection>\n\n      \u003Cdiv class=\"insight-layout\">\n        \u003Cdiv class=\"insight-body\">\n\u003Ch2 id=\"微信里的-加一点点-如何吃掉整张甘特图\">The 'Add a Little' in WeChat, how to eat up the entire Gantt chart\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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 about\u003Cstrong>Turn ideas into the status and permissions of baseline changes\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Ch2 id=\"完成率要有固定分母-否则只是情绪\">The completion rate must have a fixed denominator; otherwise, it's just emotion.\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>Common sources of fake green:\u003C\u002Fp>\n\u003Cdiv class=\"table-scroll\">\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>statement\u003C\u002Fth>\u003Cth>actual\u003C\u002Fth>\u003Cth>Consequence\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd>The client said to do the upper part first.\u003C\u002Ftd>\u003Ctd>Oral request directly dispatched\u003C\u002Ftd>\u003Ctd>Costs and delivery times are being eroded\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Just change a little bit\u003C\u002Ftd>\u003Ctd>Small changes leave no trace, but accumulate into a big package\u003C\u002Ftd>\u003Ctd>The acceptance scope does not match\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Agile, can change anytime\u003C\u002Ftd>\u003Ctd>Backlog has no version, cards can be inserted outside the sprint at will\u003C\u002Ftd>\u003Ctd>Burnout is good-looking, but the delivery list is out of control\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Changes are too slow, do first and make up later\u003C\u002Ftd>\u003Ctd>Skip assessment and approval\u003C\u002Ftd>\u003Ctd>The risk is exploding at project closure\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>The progress is already 80%\u003C\u002Ftd>\u003Ctd>Denominator contains unapproved range\u003C\u002Ftd>\u003Ctd>The management keeps throwing more people into the pit.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>L1 aligns the contract with business milestones, L2\u002FL3 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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"待评估池-想法与承诺必须分居\">Pending Evaluation Pool: Ideas and Commitments Must Be Separated\u003C\u002Fh2>\n\u003Cp>In system design, requirements raised verbally, by email, or on-site should first enter\u003Cstrong>Pending Evaluation Pool\u003C\u002Fstrong>, 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.\u003C\u002Fp>\n\u003Cp>Status recommendations should be clear and subject to sampling inspection: To be evaluated → Under evaluation → Approved\u002FRejected → 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\u002Fsupplementary agreement — if execution changes but acceptance standards remain the old ones, it is equivalent to postponing disputes until a week before payment.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"影响评估四格-CCB-才不会空转\">Impact assessment in four quadrants, so that the CCB won't operate in vain\u003C\u002Fh2>\n\u003Cp>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\u002Fsales (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'.\u003C\u002Fp>\n\u003Cp>Do not write the impact assessment as prose. At least four sections:\u003C\u002Fp>\n\u003Col>\u003Cli>\u003Cstrong>Progress Offset\u003C\u002Fstrong>(Heaven, is it a threat to milestones)\u003C\u002Fli>\u003Cli>\u003Cstrong>Cost increment\u003C\u002Fstrong>(Human Resources and Procurement)\u003C\u002Fli>\u003Cli>\u003Cstrong>Risk Level\u003C\u002Fstrong>(Regarding acceptance, safety, shutdown)\u003C\u002Fli>\u003Cli>Whether the payment milestone has been reached\u003C\u002Fli>\u003C\u002Fol>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"瀑布与敏捷-形式可变-纪律不可变\">Waterfall and Agile: Form is variable, discipline is immutable\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>The connection with CRM\u002Fcontracts 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.\u003C\u002Fp>\n\u003Ch2 id=\"健康度怎么看-不怕变更-怕看不见\">How to assess health: not afraid of changes, afraid of being unable to see\u003C\u002Fh2>\n\u003Cdiv class=\"table-scroll\">\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Signal\u003C\u002Fth>\u003Cth>Pronunciation\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd>Number and scale of monthly changes\u003C\u002Ftd>\u003Ctd>Changes are not scary; suddenly becoming zero may be inevitable.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Number of projects started without assessment\u003C\u002Ftd>\u003Ctd>Should be zero; greater than zero indicates the gate has been bypassed\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Proportion of Overtime Outside the Baseline\u003C\u002Ftd>\u003Ctd>Persistent high levels need to be managed; the fast-track channel is being abused\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Change Average Period\u003C\u002Ftd>\u003Ctd>If too long, it forces the business to go around; if too short, the evaluation may be just a formality.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Proportion of changes in reaching payment milestones\u003C\u002Ftd>\u003Ctd>At most, trace back the pre-sales scope and the quality of contract attachments\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>JEDP-PMS covers L1–L3\u002FWBS, 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.\u003C\u002Fp>\n\u003Ch2 id=\"现场-先做后补-如何被机制挡住\">How the 'do first, make up later' approach on site is blocked by the system\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"半天能看见蔓延有多大\">You can see how much it has spread in half a day\u003C\u002Fh2>\n\u003Cp>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\u002Fbaseline\" 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:\u003Cstrong>Do not report work or enter the acceptance list without approval\u003C\u002Fstrong>Two 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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cul>\u003Cli>PMS project solution\u003C\u002Fli>\u003Cli>Milestones must be accompanied by evidence\u003C\u002Fli>\u003Cli>Project costs are recorded in the same ledger\u003C\u002Fli>\u003Cli>Risk Register Operation\u003C\u002Fli>\u003C\u002Ful>\n        \u003C\u002Fdiv>\n        \u003Caside class=\"insight-toc\" aria-label=\"On this page\">\n          \u003Ch2>Contents\u003C\u002Fh2>\n          \u003Ca class=\"h2\" href=\"#微信里的-加一点点-如何吃掉整张甘特图\">The 'Add a Little' in WeChat, how to eat up the entire Gantt chart\u003C\u002Fa>\n          \u003Ca class=\"h2\" href=\"#完成率要有固定分母-否则只是情绪\">The completion rate must have a fixed denominator; otherwise, it's just emotion.\u003C\u002Fa>\n          \u003Ca class=\"h2\" href=\"#待评估池-想法与承诺必须分居\">Pending Evaluation Pool: Ideas and Commitments Must Be Separated\u003C\u002Fa>\n          \u003Ca class=\"h2\" href=\"#影响评估四格-CCB-才不会空转\">Impact assessment in four quadrants, so that the CCB won't operate in vain\u003C\u002Fa>\n          \u003Ca class=\"h2\" href=\"#瀑布与敏捷-形式可变-纪律不可变\">Waterfall and Agile: Form is variable, discipline is immutable\u003C\u002Fa>\n          \u003Ca class=\"h2\" href=\"#健康度怎么看-不怕变更-怕看不见\">How to assess health: not afraid of changes, afraid of being unable to see\u003C\u002Fa>\n          \u003Ca class=\"h2\" href=\"#现场-先做后补-如何被机制挡住\">How the 'do first, make up later' approach on site is blocked by the system\u003C\u002Fa>\n          \u003Ca class=\"h2\" href=\"#半天能看见蔓延有多大\">You can see how much it has spread in half a day\u003C\u002Fa>\n        \u003C\u002Faside>\n      \u003C\u002Fdiv>\n\n      \u003Cdiv class=\"insight-cta\">\n        \u003Cp>\u003Cstrong>Want to apply this in your plant?\u003C\u002Fstrong>Resources has matching self-assessments and templates—or book a live demo.\u003C\u002Fp>\n        \u003Cdiv class=\"insight-cta-actions\">\n          \u003Ca href=\"\u002Fresources?from=pms#selftest\" class=\"btn btn-outline\">Self-assessment in Resources\u003C\u002Fa>\n          \u003Ca href=\"\u002Fcases#case-pms\" class=\"btn btn-outline\">PMS acceptance case\u003C\u002Fa>\n          \u003Ca href=\"\u002Fcontact?from=pms\" class=\"btn\">Get a demo\u003C\u002Fa>\n        \u003C!-- next-step:BEGIN -->\u003Ca class=\"btn\" href=\"\u002Fproduct\u002Fpms\">Product solution: \u003Cspan>JEDP-PMS Project Delivery\u003C\u002Fspan>\u003C\u002Fa>\u003Ca class=\"btn btn-outline\" href=\"\u002Fres\u002Fresources\u002Fkits\u002F27-pms-ccb-acceptance.html\">Matching resource kit: \u003Cspan>Change CCB + acceptance three-state checklist\u003C\u002Fspan>\u003C\u002Fa>\u003C!-- next-step:END -->\n        \u003C\u002Fdiv>\n      \u003C\u002Fdiv>\n      \u003Csection class=\"insight-faq\" id=\"faq\">\n        \u003Ch2>FAQ\u003C\u002Fh2>\n        \u003Cp class=\"insight-faq-sub\">Quick answers on this topic—still stuck?\u003Ca href=\"\u002Fcontact?from=pms\">Contact\u003C\u002Fa>\u003C\u002Fp>\n        \u003Cdiv class=\"faq-list\">\n        \u003Cdetails class=\"faq-item\" open>\n          \u003Csummary>Do agile projects still need a WBS?\u003C\u002Fsummary>\n          \u003Cp>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.\u003C\u002Fp>\n        \u003C\u002Fdetails>\n        \u003Cdetails class=\"faq-item\">\n          \u003Csummary>Do even very small changes need to go through the change process?\u003C\u002Fsummary>\n          \u003Cp>Threshold can be set: below the working hours\u002Famount 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.\u003C\u002Fp>\n        \u003C\u002Fdetails>\n        \u003Cdetails class=\"faq-item\">\n          \u003Csummary>What should be done if the client refuses to make changes?\u003C\u002Fsummary>\n          \u003Cp>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.\u003C\u002Fp>\n        \u003C\u002Fdetails>\n        \u003Cdetails class=\"faq-item\">\n          \u003Csummary>To what level of detail is the WBS?\u003C\u002Fsummary>\n          \u003Cp>Detailed enough to assign tasks, estimate time, and conduct acceptance. L1 aligns with contract milestones, L2\u002FL3 translates into deliverable work packages; further down, daily reports can be used to avoid micromanagement.\u003C\u002Fp>\n        \u003C\u002Fdetails>\n        \u003Cdetails class=\"faq-item\">\n          \u003Csummary>Does CCB really have to hold a meeting?\u003C\u002Fsummary>\n          \u003Cp>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.\u003C\u002Fp>\n        \u003C\u002Fdetails>\n        \u003C\u002Fdiv>\n      \u003C\u002Fsection>\n      \u003Csection class=\"insight-related\">\n        \u003Ch2>Related reading\u003C\u002Fh2>\n        \u003Cdiv class=\"insight-related-grid\">\n          \u003Carticle class=\"r-card\">\n            \u003Cdiv class=\"r-tags\">PMS · Projects\u003C\u002Fdiv>\n            \u003Ch3>Acceptance scramble one week before payment? A milestone without an evidence pack is just a dunning calendar\u003C\u002Fh3>\n            \u003Cp>Acceptance disputes often erupt before payment; the root cause is that milestones have only dates but no evidence. Make a package of evidence including the deliverable list, checklists, three-state conclusions, and conditionally pending items, then align it with payment triggers and scope changes, so that disputes can be addressed beforehand...\u003C\u002Fp>\n            \u003Cdiv class=\"r-meta\">2026-09-10 · ~8 min\u003C\u002Fdiv>\n          \u003C\u002Farticle>\n          \u003Carticle class=\"r-card\">\n            \u003Cdiv class=\"r-tags\">PMS · Projects\u003C\u002Fdiv>\n            \u003Ch3>Overrun discovered only at close—hours, purchases, and expenses must be visible same-day under one project ID\u003C\u002Fh3>\n            \u003Cp>Cost explosions after the fact occur because labor hours, procurement, and expenses each proceed independently. Starting from the false surplus of 'budget still sufficient,' it explains how estimates to final accounts are aggregated according to WBS\u002Faccounts, how provisional estimates and work in progress eliminate false safety, and...\u003C\u002Fp>\n            \u003Cdiv class=\"r-meta\">2026-08-06 · ~10 min\u003C\u002Fdiv>\n          \u003C\u002Farticle>\n          \u003Carticle class=\"r-card\">\n            \u003Cdiv class=\"r-tags\">PMS · Projects\u003C\u002Fdiv>\n            \u003Ch3>Four projects all “fully staffed”? If the load board cannot show conflicts, overtime becomes the default fix\u003C\u002Fh3>\n            \u003Cp>Key personnel overload is often overlooked because scheduling only assigns names without considering available work hours. Using a calendar, available percentage, and task time estimates to calculate load rate exposes conflicts during the planning period; hierarchical roles and named assignments, with priority arbitration results returning...\u003C\u002Fp>\n            \u003Cdiv class=\"r-meta\">2026-08-27 · ~8 min\u003C\u002Fdiv>\n          \u003C\u002Farticle>\n        \u003C\u002Fdiv>\n      \u003C\u002Fsection>\n    \u003C\u002Fdiv>\n  \u003C\u002Farticle>",1793937990581]