A company commits to launching a new customer portal in twelve weeks. The application team has estimated the main screens and workflows, and leadership has approved the budget. At kickoff, the team learns that the portal needs a database change from another department, a security review, and customer records that have not yet been assessed for migration.
The deadline was agreed before those requirements were understood. That does not make failure inevitable, but it changes what the commitment means. The company needs to investigate the missing work, confirm the capacity available, and decide whether scope or timing should change.
Some execution problems begin in this gap between an initial proposal and an executable commitment. Others arise later through events that could not reasonably have been anticipated. A useful review distinguishes the two and examines how the organisation responds when its assumptions change.
Defining the Outcome Before Fixing the Scope
The portal proposal needs a reason beyond replacing an old interface. The intended benefit might be fewer calls about account status, faster onboarding, or a dependable route for customers to change their details. Those outcomes imply different capabilities and measures.
For an account-status portal, the company should establish which customers are included, what information they need, and how current that information must be. It should also consider users who cannot complete the online process and the support route available to them.
A broad objective such as improving customer experience can guide discovery without being a sufficiently specific acceptance condition. The team needs examples of the work customers should be able to complete and the constraints that must be respected, including access, correctness, and operational support.
Early specificity should not imply that every future requirement is known. The plan can distinguish settled scope from open questions and identify what depends on each answer. This allows useful work to proceed while preserving uncertainty where it matters.
The sponsor should also agree what is outside the initial release. A narrower portal that reliably answers one important customer need may be preferable to several incomplete workflows. That choice needs to be made explicitly rather than emerge through late cuts under pressure.
Showing What the Estimate Includes
A duration estimate should come with an account of its scope and assumptions. Time spent building screens may exclude integration testing, migration, specialist review, deployment, training, and recovery preparation. The omission matters if leadership interprets the estimate as time to an operational service.
The team should examine relevant previous work, including where earlier forecasts proved optimistic. Historical experience will not predict the new project exactly, but it can reveal recurring omissions and the range of outcomes encountered under similar conditions.
The Green Book’s appraisal guidance discusses optimism bias in assumptions about costs, benefits, and duration, and the use of evidence to address it. The principle applies here without importing a generic contingency percentage into every project.
For the portal, the forecast could identify a range conditioned on the database change and migration findings. A fixed external date may still be necessary, but the organisation should then examine what scope and resources can credibly fit within it. A deadline is a constraint on the decision, rather than evidence that the original scope is achievable.
The estimate also needs a route for revision. If discovery reveals an additional workflow or a data problem, the team should show its effect and obtain a decision. Treating every revised estimate as a broken promise can encourage people to conceal information the plan needs.
Confirming Capacity Across the Dependencies
Headcount alone does not establish availability. The portal engineers may support production, review other teams’ work, and deliver earlier commitments. A specialist listed as part-time may be available only after another project reaches a safe point.
Planning should examine the work each required team can actually accept. The database group needs to confirm the proposed change, its prerequisites, and the evidence that will demonstrate readiness. Security needs enough context to estimate the review and identify design requirements early.
Dependencies also have dependencies. A database change may require infrastructure work, a supplier upgrade, or a maintenance window. The team need not map every theoretical connection, but it should investigate the relationships capable of materially affecting the plan.
Prioritisation then becomes an allocation decision. If the portal has precedence, some existing work may need to move. If it does not, the forecast should reflect the capacity left after those obligations are met.
The commitment should reach the people who control those resources. Listing another department in a plan is not the same as obtaining an agreement from it. The programme owner needs a way to track readiness, resolve changes, and communicate the effect of a missed dependency.
Investigating the Starting Environment
The portal will inherit the behaviour and limitations of the services beneath it. An apparently simple account lookup may rely on inconsistent identifiers, a slow batch update, or an interface that was never designed for customer-facing traffic.
A focused technical investigation can reduce these uncertainties before the main build is approved. The team might test the required query, inspect representative records, and check how permissions apply to the proposed access path. The investigation should be chosen to address consequential unknowns rather than become an indefinite architecture exercise.
Legacy systems may also contain useful rules or operational practices missing from current documentation. Business specialists and operators should help distinguish required behaviour from defects or workarounds that can be removed.
The findings can alter scope. If account state is updated only overnight, a portal promising live status needs further work or a different customer promise. That is a business choice supported by technical evidence, rather than a problem the developer can solve by interpreting the requirement more generously.
This investigation does not eliminate surprises. It gives leadership a better understanding of what is known, what remains uncertain, and which early tasks will improve the next estimate.
Establishing How Decisions Will Be Made
The project owner needs an agreed remit. They might sequence work and resolve minor requirements while the sponsor approves budget or significant changes to the customer offer. Specialist controls may remain with the functions responsible for them.
The arrangement should explain what happens when those boundaries meet. If Sales requests an additional workflow that changes the data model, someone must decide whether to alter the release, remove other work, or defer the request. Without a route to that decision, the project can accumulate scope through informal promises.
Accountability does not require a project manager to control every participant. It requires clarity about the decisions they can make, the commitments others hold, and how unresolved trade-offs reach someone with authority.
Communication should support these responsibilities. Distributed teams may work effectively through maintained decisions, clear interfaces, and asynchronous review, with meetings reserved for questions that need joint resolution. Requiring constant synchronous coordination across time zones can add cost without addressing missing context.
The plan should identify where current decisions live, how changes reach dependent teams, and who can confirm an agreement. Tool choice matters less than whether the necessary information remains available and dependable.
Agreeing What Readiness Will Mean
The kickoff should establish how the company will decide that the portal is ready for its intended audience. Functional tests belong alongside access checks, relevant performance evidence, monitoring, customer support, and recovery arrangements.
For an initial release, the team might select a bounded customer group and a defined account-status task. The boundary needs to limit the relevant exposure; a small audience does not automatically make a serious access defect acceptable.
The roadmap should connect stages to evidence. Before the limited release, the team needs agreed data mappings and validated permissions. Before expansion, it may need evidence that customers complete the task and that staff can manage exceptions.
Rollback also needs an account of state. Returning to the previous application may be straightforward for a read-only view, but a workflow accepting updates can require reconciliation. The relevant procedure should be understood and exercised before it becomes the fallback for a difficult launch.
These conditions allow leadership to assess readiness without pretending a planned date proves it. If the conditions are missing, the decision can consider a narrower scope, further work, or a revised commitment.
Revising the Commitment Without Losing Its Purpose
A credible plan includes review points and triggers for escalation. The team should not need to wait for a missed milestone to report that a critical dependency has moved or a technical assumption has failed.
The report should identify what changed, the effect on the outcome, and the options available. A request for more time is easier to assess when it explains the remaining work and what a smaller release could achieve. The sponsor then needs to make or obtain a decision rather than simply repeat the target.
A revised date or scope can be a responsible response to evidence. It should still be examined: was the new information reasonably discoverable earlier, and is the forecast improving as uncertainty falls? Neither automatic blame nor unlimited tolerance helps the organisation learn.
The same questions apply after delivery. A successful portal might meet the agreed requirements without reducing support calls because the original diagnosis was incomplete. That finding belongs in the assessment alongside delivery performance.
For this company, a good kickoff establishes a supported commitment and a way to change it deliberately. Planning cannot guarantee the result. It can make assumptions visible, bring the right people into consequential choices, and give the team room to act on what it learns before a manageable issue becomes an avoidable crisis.
