A team prepares a plan for a new approval service. It identifies the main users, estimates the work, and agrees an initial release. During implementation, the engineers discover that requests can be amended after approval, while the current specification assumes an approval is final.
The team now needs to establish what the business requires and how that choice affects permissions, records, notifications, and recovery. It is doing more planning while building the service. The discovery does not make the original planning pointless, but it changes the next decision.
Planning and execution describe different work. Planning examines an outcome, available options, constraints, and a proposed course of action. Execution carries decisions into implementation and operation, producing both results and further evidence. The distinction helps an organisation understand what remains unresolved and what a commitment means.
It does not require dividing people into incompatible categories. Engineers, product specialists, operators, and business owners can contribute to both activities. The practical question is how to preserve the connection between the reasoning behind a plan and the conditions encountered while carrying it out.
Distinguishing a Proposed Course of Action From an Operating Result
The approval-service plan should explain who needs the service and what work it will improve. Reducing the effort spent chasing managers is a different objective from strengthening spending controls, even if both lead to an approval screen.
The plan also needs enough detail to support a commitment. It can identify roles, relevant workflows, dependencies, estimated effort, and the conditions for an initial release. Known requirements should be distinguished from assumptions or questions that still need an owner.
Those artefacts have practical value before the software exists. A clear permission model can prevent incompatible implementations, while a dependency agreement can help two teams coordinate their work. Planning creates value when it improves a consequential decision or reduces avoidable uncertainty.
It remains evidence of preparation rather than proof of an operating outcome. A documented recovery procedure has not yet demonstrated that the team can restore the service. An integration diagram does not establish that the supplier’s interface behaves as expected under the required load.
Implementation and testing provide further evidence. The team can verify access, inspect record changes, exercise failure cases, and observe how users complete the process. A successful demonstration answers some questions without necessarily establishing production readiness or the eventual business benefit.
The distinction therefore belongs in progress reporting. The team can state that a design is agreed, a workflow is implemented, or recovery has been exercised. Each statement describes a different result. Treating them as interchangeable can make a project appear further advanced than the evidence supports.
Bringing Practical Knowledge Into the Plan
The people familiar with existing work should contribute before major commitments are fixed. An operations specialist may know how approved requests are corrected today. A business owner may identify restrictions on delegation. An engineer may see that the proposed audit history requires a change to the data model.
This input can improve the initial plan without requiring every contributor to attend every planning meeting. The team should involve relevant expertise around the decisions that need it and retain the resulting context where later work can find it.
For the approval service, representative examples can expose hidden choices. What happens when a manager is absent? Can two people act on the same request? Does an amended request need another approval? How should the service handle a failed notification after the decision has already been recorded?
These questions connect business intent to implementation. They also show why execution decisions are not necessarily minor. A choice about how records are updated may determine whether the organisation can reconstruct who approved a request. Technical expertise and business judgment both matter.
The Scrum Guide offers one example of a framework in which a cross-functional, self-managing team plans and performs its work. It does not establish a universal organisational design, but it illustrates that planning and delivery can be connected within the same team rather than allocated permanently to different kinds of people.
Specialist roles can still be useful. A programme planner may coordinate dependencies across several services, while a technical lead examines a difficult integration. The relevant arrangement depends on scale, expertise, and the decisions involved. Neither a separate planning function nor a combined role guarantees good performance.
The organisation should also provide time for the work. A person responsible for implementation may need focused time to investigate options, just as a coordinator needs time to maintain the plan. Repeated interruption can undermine both without demonstrating that the person lacks one of the required capabilities.
Keeping Assumptions and Authority Available During Delivery
Once work begins, the plan needs enough maintenance to remain a dependable source of context. If the business decides that amended requests require reapproval, that choice should reach the relevant requirements, tests, interfaces, and support procedure.
Availability alone is insufficient. A repository can contain several documents describing different versions of the rule. The team needs a clear indication of the current decision and enough history to understand why it changed. Otherwise later work may reintroduce behaviour that was deliberately removed.
The team should know which decisions it can make within the agreed scope. An internal implementation choice may need peer review, while changing approval authority may require a business owner. A material effect on cost or the release commitment may need a sponsor’s decision.
Decision rights provide that route. They allow implementation to proceed without sending every question upward, while ensuring that choices beyond the team’s remit reach someone authorised to resolve them.
Coordination needs similar clarity. If another team supplies identity data, the agreement should specify the relevant information, expected behaviour, and how readiness will be confirmed. The dependency belongs in the plan because its condition affects what the approval service can deliver.
When a dependency changes, the project owner needs to communicate its effect on the commitment. A private workaround may keep one task moving while altering security, operating costs, or future support obligations. Those effects should be reviewed at the appropriate level rather than hidden inside an implementation detail.
A useful handover therefore includes more than a document transfer. The receiving team needs the reasons, open questions, and a way to obtain decisions. Where planning and delivery happen within the same group, those needs still exist; familiarity should not become the only place important context survives.
Revising the Plan While Protecting Progress
The amended-request discovery should lead to a specific assessment. The team needs to determine whether the behaviour is required for the first release, what it changes, and which options remain available. A read-only amendment history, a restricted correction process, or a later capability might each have different costs and consequences.
The response should preserve the intended outcome while examining the route. The organisation may accept a smaller first release, revise the date, or fund additional work. The choice should account for capacity and dependencies rather than assume that a newly recognised requirement adds no effort.
Pre-kickoff planning can make these decisions easier by identifying uncertainties early. It cannot remove every question from complex work. What matters during delivery is whether the organisation recognises new evidence and changes commitments responsibly.
Iteration does not require restarting whenever another possibility appears. The team should compare the value of changing direction with the cost of interrupting current work. Some findings require an immediate response, while others can inform the next stage or remain outside scope.
Small, coherent increments can provide evidence before a larger commitment. The team might implement one approval path and test its permissions, records, and recovery. The boundary needs to include a useful workflow rather than merely produce an isolated component that cannot be assessed in context.
DORA’s small-batch guidance describes the role of smaller changes and feedback in software delivery. The practical application depends on the service: dividing work should help the team understand and verify it, rather than multiply handovers or leave essential failure behaviour until the end.
The plan should record what the current stage is expected to establish and when the next commitment will be reviewed. This gives staff enough stability to complete work while keeping the larger approach open to evidence.
Reviewing Both the Work and the Reasoning
When the approval service launches, the organisation should examine delivery and business outcomes separately but together. The service may meet its access and reliability requirements while failing to reduce the time spent chasing approvals. That finding suggests investigating the workflow or original diagnosis rather than simply declaring the implementation successful or unsuccessful.
The team should also review how its decisions developed. Were significant requirements reasonably discoverable earlier? Did relevant specialists participate? Were dependencies confirmed? When new evidence appeared, did the authorised owners respond in time and adjust the commitment clearly?
Implementation deserves scrutiny too. A supported plan can still be undermined by a defect, an unreviewed configuration change, or a recovery procedure that was never exercised. Distinguishing activities does not mean insulating either planning or delivery from its contribution to the result.
Outcomes include uncertainty. A sound decision can encounter an unexpected event, and a weakly supported shortcut can produce a favourable result. Preserving the reasoning makes it easier to assess the work on evidence available at the time rather than on hindsight alone.
The findings should improve the next cycle. The team may need better discovery examples, more reliable test environments, clearer delegated authority, or a different allocation of specialist time. Each addresses a specific gap instead of assuming that the solution is to replace planners with implementers or the reverse.
Execution tests the strategy by adding evidence about what the organisation and its users can actually do. Planning remains useful when it absorbs that evidence and provides a clear basis for the next action. For the approval team, the connection is working when it can explain the current decision, deliver and verify a useful change, and revise the approach without losing the purpose of the service.
