Project: plan a handover-reference change
Build a reviewable change pack for the fictional Northstar operations team. Allow 45–60 minutes for the written work. This is a planning project, not a tested IFS implementation.
The brief
Section titled “The brief”Coordinators use a spreadsheet to match internal handovers with references supplied by an external team. Northstar wants to record that reference alongside the handover and report which records still need one.
The initial request leaves several questions unresolved: whether a standard field already serves this purpose, where the authoritative reference originates, who may correct it, and whether it must be unique.
Prerequisites: complete the essentials, configuration, and relevant delivery lessons. Download the change-pack template.
1. Define the outcome
Section titled “1. Define the outcome”Write a brief that explains the current problem, intended users, and measurable acceptance criteria. Keep implementation assumptions separate from the business need.
Deliverable: a one-paragraph problem statement and at least three acceptance criteria.
Example brief
Coordinators should match an internal handover to its external reference without maintaining a separate spreadsheet. Authorized coordinators can record and correct a reference, saved values remain visible on reopening, and existing records without a reference continue to work. Standard-field suitability, validation rules, and uniqueness still require review.
2. Investigate the information
Section titled “2. Investigate the information”Decide whether the value is new information or already available through a related record. Define ownership and example values. Do not invent the entity, projection, or page name: those must be discovered in the chosen environment.
Deliverable: a field definition and a list of environment questions.
Example information definition
External reference: supplied by the partner team, for example DEMO-HO-014. The coordinator records it; corrections are confirmed with the issuing team. Investigate an existing standard field before proposing a custom attribute. Confirm datatype, maximum length, optionality, duplicate handling, and retention with the owner.
3. Define access
Section titled “3. Define access”Create rows for coordinator, supervisor, and read-only reviewer. Create columns for view, update reference, approve exceptions, and manage access.
Deliverable: an approved business-role matrix, followed later by a release-specific technical mapping.
Example access decision
The coordinator views and updates a reference. The supervisor views and approves exceptions. The reviewer reads only. Access administration is a separate responsibility. This matrix describes the scenario; it is not a set of delivered IFS permissions.
4. Build the test evidence plan
Section titled “4. Build the test evidence plan”Use the test-matrix template. Cover a valid reference, an empty value, agreed boundaries, existing records, unauthorized updates, and the unchanged workflow.
Deliverable: six or more cases with expected results, all marked Not run until executed.
Example acceptance test
Given an existing record with no reference, when the authorized coordinator opens it, the current workflow remains available. When they enter an agreed valid reference and save, reopening shows the same value. Repeat using the read-only reviewer and confirm that an update is not permitted.
5. Define the reporting measure
Section titled “5. Define the reporting measure”Northstar wants a count of handovers awaiting a reference. Define which states, sites, dates, and records belong in the population.
Deliverable: a metric definition and a small fictional dataset with a manually calculated expected total.
Example metric
Count each Open handover in the selected site once when its external reference is absent. Exclude Completed and Cancelled handovers. Agree the refresh expectation. A dataset with two qualifying records must show 2, even if a different site has three more.
6. Prepare the release handover
Section titled “6. Prepare the release handover”Identify candidate configuration items and dependencies. Document the exact deliverable, target release, reviewer, smoke test, support owner, and recovery decision. Investigate the supported recovery method before relying on it.
Deliverable: a change pack another person can review without your verbal explanation.
Definition of done
Section titled “Definition of done”Your planning project is complete when the brief, information definition, access matrix, test plan, metric, and release handover agree with one another. Unknowns should be explicit and owned.
A deployed IFS change is not complete at this point. That requires discovery in the actual environment, implementation, executed tests, approval, and verified recovery procedures.
Review rubric
Section titled “Review rubric”| Review question | Evidence |
|---|---|
| Is the business problem clear? | Brief with a concrete example |
| Are assumptions visible? | Named unresolved decisions |
| Is access justified? | Task-based role matrix |
| Can another person repeat the tests? | Inputs, actions, and expected results |
| Can support identify the change? | Artifact identity and responsible owner |
Cleanup: keep or discard your fictional worksheets. No IFS system has been changed.