Illustration on fictional data, prepared in text form by an AI assistant. It shows a review of sources, statuses and dependencies, without a running ECOS mechanism or automated project management.
Task and material
- Project baseline: a read-only order status portal for region R1. For R1, the existing shared SSO login has been confirmed.
- Estimate: 40 person-days for one region with reuse of SSO. Planning target: 8 weeks, dependent on this baseline and on resource availability. These are fictional assumptions, not a HumGu offer.
- Acceptance criteria: read access and permissions for R1. Before launch, approval of the scope and access by the project roles is required.
- New request: include R2 already in the first stage. For R2 there is no connection to the existing SSO yet.
Before you read the result
The client wants to add R2. What do you need to establish before changing the project baseline, and what only after the scope is accepted? Put in order the access check, the update of the estimate and acceptance criteria, and the verification of the deadline. Point out the R1 arrangements that remain valid.
Method and criteria
- Sources and their permissions → the baseline in force → proposed change → acceptance → review of dependent arrangements.
- We check that history is preserved, that a request is distinguished from a decision, and the selective impact on scope, estimate, deadline and acceptance.
State 1 — after the request
R2 is a change proposal. The R1 baseline is not automatically replaced. R2 access and the impact of a possible acceptance on the work need to be identified. We do not promise two regions on the existing terms.
State 2 — after the sponsor's acceptance
The sponsor confirms both regions in the first stage, but does not approve a new estimate, budget or login method. The read-only functional scope and the access approval remain in force.
Result — impact card
- Scope: the baseline changes to R1+R2; the basis is the sponsor's decision.
- Access: the R1 SSO confirmation remains valid. R2 access still needs to be established.
- Work and estimate: 40 person-days remains a record of the earlier baseline, not an estimate of the extended project.
- Deadline: the 8-week target requires re-checking; there are no grounds to name a new deadline or a number of days of delay.
- Acceptance: R1 checks preserved; R2 criteria and checks are needed.
- Independent rules: the read-only nature of the functions and the approval of permissions remain unchanged.
Chain to be checked
- R2 → unresolved access → scope of work and checks → estimate → verification of the deadline target.
- Separately: additional region → supplementing the acceptance criteria.
Why do we review only the dependent arrangements?
The estimate referred to one region and a specific login method. Accepting R2 does not confirm these conditions for the new region, which is why we check access, work, estimate, deadline and acceptance. We preserve the valid R1 confirmations and the read-only functional scope. The lack of data for a new estimate does not justify inventing a delay or a general halt of the project.
What could change the further decision?
Confirmation of access feasibility, the actual scope of work and resources may change the estimate and the deadline. If the R2 change were not accepted, the earlier request alone would not replace the R1 baseline. A general halt of the whole project does not follow from this illustrative review.
In your organisation
Which arrangements change with the new scope, and which should remain valid? Together we can define the sources, roles and review rules for a chosen process.