Change Request Details

The Change Request Details view is the central working space for a change. It presents the full lifecycle of a change request as a series of sequential stages, each unlocked only when the previous one has been approved. Every stage contains the tools needed to plan, execute, and record work for that phase, and each ends with a formal approval gate before the next stage can begin.

Key Principle: PRINCE2 structures project work on a stage-by-stage basis, with the project board authorising one stage at a time. A stage can only commence once the preceding stage has been formally approved and its end stage report created. No stage can be skipped, and no stage can be approved while there are open tasks, unmitigated risks, or unresolved issues.

Stage Overview

The change request progresses through five sequential stages. Each stage is presented as a collapsible accordion panel. Stages that have been completed display a green tick. The active stage displays a filled circle. Stages that have not yet been unlocked display a padlock and cannot be opened.

The header bar displays the CR Number and title at all times so the context is always visible as you work through the stages.

Adding Items Within a Stage

Each active stage includes an Add button that opens a menu of items that can be created directly within the context of that stage:

Items added via this menu are automatically associated with the current Change Request and stage, ensuring they appear in the correct registers and are included in stage validation checks. They are not associated with Tasks if added from the Change Request Details page, Tasks also have an “Add” button.

Stage 1 — Change Request

This stage displays the original submission in read-only form. The fields here are set when the change request is first raised and cannot be edited from this view.

Approved Business Cases

There are two approaches with the Business Case. If you have mature processes and the documentation to support it, a Business Case can be uploaded as a Manamgement Product. smallChange assumes that the uploaded file is Approved and it will be displayed as an Attachment. If a Business Case is created in smallChange and it has been approved, it appears here as a card. Click the card to open and review it. A Business Case at the Change Request stage establishes the outline justification before the board makes its initial decision.

Attachments

Supporting documents uploaded during the Change Request stage are listed here. These may include supporting evidence, impact assessments, or any other material relevant to the initial decision.

Initial Decision

The project board makes the first formal decision at the bottom of this stage. This action is only available to users with the Approver or Admin role.

Note: Only Approvers and Admins can make this decision. If you do not have this role, a notice is displayed instead of the decision buttons. Parking or cancelling a change is not a failure — it is the governance process working correctly. A change that cannot be justified at the point of the initial decision should not consume planning resources.

Stage 2 — Planning

The Planning stage is where the work of assessing and structuring the change takes place before any implementation begins. All decisions and plans made here form the evidence base for the Approval Bar at the end of this stage.

What to do in Planning

Use the Add button to create the items needed for this stage:

• Business Case — A Business Case is mandatory before Planning can be approved. Use the Add button to navigate to the Business Case view and create one for the Planning stage, or upload an existing Business Case document as an attachment tagged to this stage.
• Risk — Identify and log any risks arising from the planned approach. All risks must be mitigated before approval can be sought.
• Issue — Log any problems or concerns that arise during planning.
• Lesson — Capture any lessons identified from the planning process.
• Task — Create tasks to structure the planning work. All tasks must reach Done status before approval is available.

Task Board

The Kanban board displays all tasks in the Planning stage for this change request. Tasks move through their own workflow states (To Do → In Progress → Done). The Approval Bar monitors the status of every task in this board.

Approved Business Cases

Any Business Cases approved for the Planning stage appear as cards here. Click to open and review. An approved Business Case is a prerequisite for stage approval.

Stage 3 — Implementation

The Implementation stage tracks the delivery of the change. The structure mirrors Planning — tasks, risks, issues, lessons, a Business Case, and supporting attachments — but the focus shifts from planning to execution.

The Business Case for the Implementation stage should reconfirm that the change remains justified now that the full scope of work is understood and any planning-stage findings have been incorporated.

All tasks must be complete and all risks mitigated before the Approval Bar will allow this stage to proceed to Completion.

Stage 4 — Completion

The Completion stage provides formal verification that the change has been delivered as planned and that the outputs meet the agreed acceptance criteria. Completion tasks typically include testing, inspection, sign-off activities, and user acceptance.

The Business Case for Completion should confirm that the benefits are on track to be realised, or update the forecast if the implementation revealed new information.

Stage 5 — Closing

The Closing stage is the formal end of the change. It contains three distinct elements:

Closing Summary

A free-text field for the change manager to record a narrative summary of the change — what was delivered, what the final outcomes were, and any significant deviations from the original plan. This summary becomes part of the permanent change record.

Lessons Learned

A table of all lessons recorded across all stages of this change request. Each lesson shows:

Acknowledging a lesson is the formal act of confirming that the lesson has been reviewed and its implications understood. Lessons that are identified but never acknowledged are not lessons learned — they are observations that carry no organisational benefit.

Closing Bar

The Closing Bar archives the change request once all closing activities are complete. The change moves to a closed, read-only state and is removed from active views.

The Approval Bar

The Approval Bar appears at the bottom of each stage from Planning onwards. It is the formal gateway between stages, and it enforces all pre-conditions before stage progression is permitted.

Pre-conditions for Approval

The Approval Bar checks four conditions before the Proceed button becomes active:

The status panel on the Approval Bar shows which conditions are met and which are blocking:

Important: The order of resolution matters. Risks and issues are checked at the task level — a task cannot be marked Done while it carries an open risk or issue. Resolve the risk or issue first, then complete the task.

The Two-Step Approval Process

Clicking Proceed when all conditions are met initiates a two-step process.

Step 1 — Proceed (first click)

Clicking Proceed locks all tasks in this stage so they can no longer be edited. The system then identifies the recipients for approval notifications based on the departments assigned to tasks in this stage. Users in those departments with the Approver or Admin role are automatically detected and pre-populated as approvers in the NotifyApprove panel that appears below the Approval Bar.

Step 2 — Send Approval Requests (second click)

The NotifyApprove panel displays the auto-detected recipients. Before sending, you can:

• Change any recipient from Approve to Notify — recipients set to Notify receive an informational email only and do not need to action anything. They do not block stage progression.
• Add additional recipients manually if there are stakeholders who should be informed or asked to approve who were not auto-detected.
• Remove auto-detected recipients if they are not relevant to this particular stage.

Once the recipient list is confirmed, clicking Send Approval Requests triggers the following:

• Approval request emails are sent to all recipients set to Approve.
• Notification emails are sent to all recipients set to Notify.
• An approval stage record is created for each recipient.
• The change request status is set to Pending, reflecting that it is awaiting external action.

If there are no approvers (only notify recipients, or no recipients at all), the stage advances immediately without waiting for any external response. An audit record is still created.

Awaiting Approvals

Once approval requests have been sent, the Approval Bar enters a waiting state. The status panel shows how many approvers have yet to respond. The Proceed button is disabled — no further action can be taken from this view until all approvers have responded.

Approvers receive an email with a link to approve or reject the stage. Each approver’s response is recorded in the approval stage record. The NotifyApprove panel shows the approval status of each recipient in real time.

Automatic Stage Advancement

When all approvers have approved the stage:

1. An End Stage Report is automatically created as a permanent record of the stage’s completion.
2. The change request stage advances to the next stage.
3. The change request status returns to Open.
4. Notification emails are sent to any recipients who were set to Notify, informing them that the stage has been approved and the change has progressed.

The End Stage Report created at this point is the PRINCE2 Management Product that records the performance of the completed stage. It is used at the next stage boundary as evidence that the previous stage was formally closed.

Admin Direct Approval

If there are no auto-detected recipients and no recipients have been added manually, an Admin user can approve the stage directly without sending emails. An audit record is still created against the Admin’s user account, ensuring the approval trail is maintained even when no external approvals are required.

Change Request Log

A collapsible accordion at the bottom of the page provides access to the full audit history of the change request. Every status change, stage transition, approval event, and system action is recorded here with a timestamp and the user responsible. This log provides the complete audit trail required for governance and post-change review.

Roles and Permissions