SCP expertise / Tools and techniques
Understand the process, test the causes and prove the change. Explore how we would select analytical and improvement methods around your needs.
Our six-stage approach links Define, Understand, Diagnose, Design, Test, prove and embed, and Sustain and improve. Techniques can support more than one stage; the groupings below show a useful starting point.
Total Quality Management provides an organisation-wide view of quality. Lean examines value and flow; Six Sigma brings structured analysis of process performance and variation; Kaizen supports continuing improvement. Just in Time is a flow principle, while Kanban provides replenishment signals within a pull system.
These are established methods, combined here into a proposed SCP approach. The depth of analysis, specialist inputs and delivery scope are agreed around each client engagement.
Requirements through to acceptance
We would describe user needs through requirements, user stories and use cases, then agree acceptance criteria. A test plan links those requirements to scenarios, expected results and evidence. Testing may cover functionality, system handovers, data, performance and failure paths according to the change.
User acceptance testing (UAT) allows appropriate business users to assess the solution against agreed needs. A pilot examines performance in a bounded operating setting. The two activities complement each other. Test results, defects, pilot outcomes and any remaining risks inform the authorised rollout decision.
Example: a planner can identify an order at risk, understand its cause and carry out only the actions their role permits. The acceptance criteria and tests should cover the normal case, missing information and restricted actions.
Testing, requirements and change control
When a test or UAT session produces an unexpected result, record the observation and investigate it against the agreed requirement, acceptance criteria and tested version. Check the test, data and environment too. An unexpected result is not automatically a software bug.
Record a defect with the expected and actual results, reproduction steps, impact and evidence. Link it to the requirement, criterion and test; assess priority and confirm the correction through retesting.
Raise a change request to clarify or amend the requirement and assess the proposed solution change. The need may have been missed, captured incorrectly or changed since approval. A requirements defect and a change request can be linked; the labels are not always mutually exclusive.
Investigate the test case, data, configuration and environment before changing the solution. Retain the original result, record the reason for any correction and rerun the relevant tests.
A controlled document or tracked system record should include a unique ID, requester, date, owner, business reason, current behaviour and proposed change. Link the originating test, UAT observation or defect, the affected requirements and acceptance criteria, and the version assessed.
Record options and impacts on scope, benefits, cost, schedule, resources, dependencies, data, security, operations and testing as relevant. Include the decision, approving authority, conditions, delivery priority and closure evidence. A separate downloadable document is not necessary when the agreed delivery system holds this record.
Keep the original criteria and test results. A request being approved does not turn an earlier failed test into a pass. Revised criteria define what the changed solution must meet; new test and UAT evidence support the later acceptance decision.
Illustrative example: the agreed rule sends an alert when an order is less than 24 hours from its promised date. During UAT, a planner identifies that a customer group needs 48 hours to arrange recovery. If the solution correctly applies the agreed 24-hour rule, record the unmet business need and raise a change request. Assess the effect on alert volumes, workload and service, then approve and version the customer-specific rule and its Gherkin criteria before implementation and retesting. This does not alter the rules in our separate synthetic worked example.
In Waterfall, Agile and hybrid delivery: use the agreed level of change control. An Agile team may capture and assess the request through its backlog, but changes affecting authorised scope, funding, contractual commitments or release criteria still need the appropriate decision.
Jira and Confluence, or Microsoft Azure DevOps and Test Plans, can hold linked requests, requirements, decisions, delivery items and test evidence using the client’s agreed configuration. Keep change control distinct from the wider work of preparing people for organisational change.
Reference: APM: change control ↗. Reviewed 17 October 2026. The triage guidance and example above describe SCP’s proposed application.
Business analysis / Requirements structure
Grouping requirements helps a team see why a change matters, manage its scope and retain the links from a business need through to acceptance. We would agree a proportionate structure with the client, using stable IDs and clear ownership.
Business Requirements Document / BRD
Where a consolidated requirements baseline is useful, SCP can help prepare or review a BRD with the client. It records the business problem, intended outcomes and success measures, scope and exclusions, stakeholders, business requirements, constraints, assumptions, dependencies and approval responsibilities.
Give requirements stable IDs, a source, rationale, priority and owner. Include or link the relevant process descriptions, business rules, detailed requirements and acceptance criteria. Record the approved version, open points and decisions so providers and internal teams work from the same agreed need.
The BRD establishes the business context and requirements; a functional specification develops the required solution behaviour, while HLD and LLD describe the technical design. Keep those links explicit. In iterative delivery, equivalent controlled backlog and repository records may fulfil this purpose without duplicating everything into a separate document.
A BRD is a document container, not another level in the epic–feature–requirement hierarchy. Its approval does not replace design review, testing or UAT. Assess later changes through change control.
Further reading: IIBA: Business Requirements Document resource ↗. The content and review approach described here are SCP proposals.
Acceptance criteria → linked test cases → recorded results and defects → authorised acceptance decision. Retain the criterion version, test environment, tester and evidence so the team can see what was proved and what remains unresolved. The criteria define what must be met; testing and UAT evidence record whether it was met.
User stories and use cases are complementary ways to describe requirements. A use case may support several stories; it does not have to be a child work item. Security, accessibility, data freshness and performance requirements may apply across several features and should be linked wherever they need verification. Tasks describe the work to deliver the change.
Synthetic example — proposed SCP grouping, not a client implementation.
AC-06 → UAT-06 → actual result, supporting evidence and any defect → authorised acceptance decision. UAT-06 remains Not run. The separate Python reference check passes; it does not constitute client UAT or acceptance.
The other proposed features group controlled recovery (US-04, US-05), event handling and audit (US-06, US-07), and benefits measurement (US-08). Keep the tested version of each criterion and the evidence together when a requirement changes.
Tool mapping: Azure Boards provides Epic and Feature levels above requirement-level items; the item name depends on the chosen process. Jira commonly groups stories under epics, so a separate Feature level needs an agreed mapping or suitable configuration. Confluence can hold linked use cases, process descriptions and decision records. Agree the structure around the client's tools rather than assuming the same hierarchy everywhere.
References: Microsoft: organise features and epics; Microsoft: work item types; Atlassian: epics and stories. Source guidance reviewed 17 October 2026; the grouping and example above are SCP proposals.
Requirements into a buildable solution
Building on the BRD or equivalent agreed requirements, SCP can help write a functional specification for an internal development team, or review a provider’s proposed specification with the client. We connect the business requirements to a design that the delivery team can implement and the business can assess.
We would agree the required documents, authors, reviewers and approval authority at the outset. The descriptions below are a proposed SCP structure; document names and boundaries vary between organisations. They may be separate specifications or controlled sections of one design record.
Functional specification
Describe roles, workflows, business rules, inputs, outputs, data validation, permissions, exceptions and user interactions. Link each function to the approved requirement, story or use case and its acceptance criteria.
Review focus: completeness, business meaning, consistency, testability and unresolved assumptions. Include or reference performance, security, accessibility and other quality requirements.
High-level design / HLD
Describe the system boundary, main components, external systems, integrations, information flows, deployment approach and architectural decisions.
Review focus: fit with the client’s systems, security boundaries, capacity, resilience, supportability, dependencies and material trade-offs. Allocate requirements to the components that will satisfy them.
Low-level design / LLD
Define component behaviour, interface contracts, field mappings, data structures, calculations, validation, error handling, retries, access controls and configuration as relevant.
Review focus: enough unambiguous detail for implementation and testing, consistent with the functional specification and HLD. The development provider or internal technical team normally owns this detail.
Design approval authorises a defined development baseline. It does not establish that the built solution works, and it does not replace integration testing, UAT or the later acceptance and release decisions.
Keep the requirements hierarchy ending in acceptance criteria. Link functional-specification sections, HLD components and LLD details to the requirements they implement. Link test cases and execution evidence separately to the relevant criteria and design version.
Illustrative link: a planner’s requirement to identify missing supply dates → functional rule for an explicit missing-input state → HLD order/supply interface → LLD date-validation and exception handling. Agreed Gherkin criteria define the expected outcome; integration and UAT results show whether that version meets it.
Use process or swimlane maps for workflows, decision tables for business rules, wireframes and prototypes for user interaction, and context, data-flow, sequence and data-model diagrams where they clarify interfaces and behaviour. Maintain a requirement-to-design traceability record, review-comment log and design-decision record in the client’s agreed repository, linked to Jira or Azure DevOps work items and tests.
References: IIBA: requirements and designs ↗; SEBoK: detailed design ↗; NASA: requirements traceability and change control ↗. Reviewed 17 October 2026. These inform the principles; the document structure, roles and example are SCP proposals.
Keep the evidence connected
Jira and Confluence, or Azure DevOps, can support a linked record of the problem, user stories, Gherkin acceptance criteria, tests, defects, change requests and approvals. We would agree the workflow, owners, permissions and version controls around your existing systems.
These are alternative ways to organise delivery. The tools preserve links; business users still need to perform UAT and an authorised owner must decide acceptance.
Atlassian: using Jira and Confluence together · Microsoft: Azure DevOps and Test Plans
Explore project and programme delivery methods and controls →
Search by name or problem, or choose a stage. Open an entry for its output, an example and service links.
46 techniques available
What matters to the customer?
Agreed service/quality definitions.
Agree what an on-time, complete order means before measuring delivery performance.
Where does the process start and end?
Scope and interfaces.
Set the boundary from supplier confirmation to customer receipt and name the owners.
Where do handovers, decisions or rework occur?
Validated current-state map.
Map how a shortage or delayed shipment passes between teams.
Where does elapsed time accumulate across material and information flows?
Current/future-state maps.
Separate working time from waiting across replenishment and fulfilment.
Does the documented process match actual work?
Observation record.
Observe picking, replenishment or exception handling with the people doing the work.
Can teams record incidents consistently?
Defined event log.
Record comparable delivery failures or stock discrepancies before ranking causes.
Which lanes, products or failure types account for the problem?
Prioritised analysis.
Split failures by lane, product, site or reason to choose where to investigate first.
How variable are lead times or losses?
Distribution and tail view.
Examine long-tail transit times rather than relying on the average alone.
Is performance changing, stable or showing unusual variation?
Time-based signals.
Monitor delivery or exception-resolution time and investigate unusual signals.
What possible causes should we investigate?
Hypothesis map.
Organise possible causes of late orders, then test the important branches.
What evidence-supported chain explains an incident?
Cause/action record.
Follow the evidence behind a recurring shortage rather than stopping at a symptom.
Which factors merit further investigation?
Relationship model.
Explore associations between delays, workload and shipment characteristics.
Can a stable process meet a defined specification?
Capability assessment.
Assess whether a stable operation can meet an agreed timing or quality requirement.
How could the process fail, and where should prevention focus?
Risk/action register.
Examine potential supplier, process or automation failures and prevention actions.
Can a team explain the problem, reasoning, action and follow-up coherently?
Shared improvement record.
Keep the problem, evidence, countermeasure and follow-up together in one record.
How should a recurring supplier or customer issue be contained and resolved?
Structured corrective-action record.
Coordinate containment and corrective action after a recurring supplier or delivery incident.
Do layout, organisation or unclear locations cause errors?
Workplace standards and review.
Improve locations, labels and workplace organisation to reduce picking confusion.
Where is avoidable travel or handling?
Movement map.
Map avoidable movement between storage, workstations, docks and dispatch.
How does workload compare with the required pace?
Capacity and workload view.
Compare demand pace with picking, packing or replenishment workload.
What should trigger replenishment, and in what quantity?
Explicit signal and replenishment rules.
Trial a clear replenishment signal with agreed quantities and service safeguards.
Can sequencing reduce uneven workload?
Feasible levelled schedule.
Assess whether a more even production mix can reduce workload peaks.
Which setup tasks can be shortened or performed outside the stoppage?
Changeover plan.
Separate setup tasks that require a stoppage from those that can be prepared beforehand.
How should teams execute and improve the agreed method?
Work standard and training.
Document and train an agreed picking or exception-response method.
Can an error be prevented or immediately detected?
Tested prevention control.
Test controls that prevent wrong-item selection or make it immediately visible.
When should a process stop or seek an authorised decision?
Escalation and response rules.
Define when an abnormal event should stop a process or trigger authorised action.
Are equipment losses disrupting flow?
Loss analysis and maintenance priorities.
Analyse equipment losses that disrupt warehouse flow or dispatch.
Which feasible option best meets agreed criteria?
Transparent option appraisal.
Compare feasible network, equipment or packaging options against agreed criteria.
Which controllable changes affect the outcome?
Designed trial and analysis.
Plan a controlled trial when several factors may influence the result.
Which policies balance availability and stock across locations?
Policy/scenario comparison.
Compare stock policies across locations against customer-service requirements.
Which locations, flows or routes meet constraints?
Modelled options.
Compare locations, routes or flows within capacity and service constraints.
How might queues, variability or disruption change the result?
Scenario results with assumptions.
Explore queues, variability or disruption before committing to a change.
Did the change behave as expected?
Documented learning and next decision.
Record a prediction, run a bounded trial and review what actually happened.
Who checks performance and reacts to deterioration?
Measures, owners and response plan.
Assign owners, measures and response rules so improvements persist.
Are functions using compatible process and performance definitions?
Shared scorecard.
Align process and performance definitions across functions before comparing results.
When a change needs a clear user, goal and business reason.
Agreed user needs, discussed with the people affected.
Describe what a planner needs to recognise and respond to an order at risk.
When roles, steps, business rules or alternative paths need explaining.
A scenario covering normal flow, exceptions and expected behaviour.
Describe a shortage response, including missing data and an unauthorised user.
When the team must agree what a satisfactory outcome looks like.
Specific, testable conditions agreed before acceptance.
Agree that an at-risk order shows its reason, affected promise, owner and permitted actions.
When evidence must show that a change meets its requirements.
Traceable test cases, expected results, responsibilities and defect records.
Link each requirement to tests, covering integration, data quality and performance where relevant.
When business users need to judge whether a solution meets their needs.
Recorded user test outcomes and an authorised acceptance decision.
Ask planners to execute agreed order-exception scenarios and record issues before release.
When a missing, incorrect or changed business requirement needs an assessed and authorised solution change.
A linked change record, impact assessment, decision, revised requirements and acceptance criteria, and verification evidence.
During UAT, assess a request to change an agreed order-alert rule before updating the rule, Gherkin criteria and linked tests.
Apply change control throughout delivery, including when testing reveals a gap in the agreed requirements.
Explore the change-request process →
When an internal team or solution provider needs agreed functional behaviour before developing a change.
A versioned specification linked to requirements, acceptance criteria, review comments and approval.
Specify the planner workflow, missing-input handling and permitted actions, then resolve review comments before development.
Explore the approach and review responsibilities →
When architecture, system boundaries, components and integrations need to be agreed.
A reviewed architecture and interface design, requirement allocation and recorded design decisions.
Agree how orders and supply information connect to the exception workflow and its security boundaries.
Explore the approach and review responsibilities →
When developers need implementation detail consistent with the approved solution design.
Detailed component, data-mapping, interface and error-handling definitions linked to the design baseline.
Define date validation, interface field mappings, duplicate-event handling and audit records before coding that scope.
Explore the approach and review responsibilities →
When delivery risks, assumptions, issues and dependencies need owners and action.
A maintained log linked to milestones, actions, decisions, review dates and escalation triggers.
Track a provider interface specification needed before the integration design can be approved.
Explore the approach and review responsibilities →
When the project needs clarity about who delivers, approves, contributes to and receives each output.
Agreed responsible, accountable, consulted and informed roles for deliverables and decisions.
Assign the provider to author a specification, the client owner to approve it, and SCP and users to review it.
Explore the approach and review responsibilities →
When the business need, scope and requirements need a consolidated, reviewed baseline.
A versioned business requirements record with owners, priorities, decisions and links to design and acceptance criteria.
Agree the delivery problem, business outcomes, scope and planner requirements before preparing the functional specification.
Explore the BRD and its links to solution design →
No techniques match this search. Try a broader term or clear the filters.
Method references are linked in each entry. The application examples, groupings and service connections are SCP proposals, rather than endorsements by the source organisations.
Sources reviewed 17 October 2026. This page introduces methods; it does not claim SCP accreditation or replace a client's specialist quality or assurance requirements.