Skip to content
ImproveDesk

Everyday use · 6 min read

Moving work through the lifecycle

Transitions, putting work on hold, rejecting with a reason, reopening, and the gates that stand in the way.

The shape of it

Nine statuses, mapped onto the Deming cycle. The route through them is enforced by the server, so the buttons you are offered on a record are the only moves that exist.

The ImproveDesk improvement lifecycle Seven statuses run left to right: Proposed, Triaged, Approved, In progress, Implemented, Verified and Closed. Proposed, Triaged and Approved sit in the Plan stage of the Deming cycle; In progress is Do; Implemented and Verified are Check; Closed is Act. Two further statuses sit outside the happy path: On hold, which Proposed, Triaged, Approved and In progress can enter and leave; and Rejected, which open work can enter up to and including In progress but never once it has been implemented, and which can be reopened to Proposed. PLAN DO CHECK ACT DEMING CYCLE STAGE Proposed Triaged Approved In progress Implemented Verified Closed Reopen — clears the downstream completion stamps On hold Proposed, Triaged, Approved and In progress may pause, and resume. Rejected Open work may be rejected up to In progress — never once implemented. A reason is required, and is kept.

Moving a record on

Open an improvement from the register. The buttons under the status badges are the transitions available from where it currently sits.

An improvement that is In progress
A row of buttons reading Move to Implemented, Move to On hold, Move to Rejected, Edit, Archive and a red Delete.
From In progress, the only forward move is to Implemented. Rejecting and holding are also available; Verified is not offered, because it cannot be reached from here.

Compare that with a record that has already been verified — the choices are different, and narrower.

An improvement that is Verified
A row of buttons reading Move to Closed, Move to In progress, Edit, Archive and Delete.
From Verified you can close it, or send it back to In progress if the verification did not hold.

Selecting a transition applies it immediately and writes an audit event. There is no confirmation step, because the move is reversible in almost every case and the trail records who did it.

Every permitted move

FromMay move to
ProposedTriaged, Rejected, On hold
TriagedApproved, Rejected, On hold, back to Proposed
ApprovedIn progress, On hold, Rejected
In progressImplemented, On hold, Rejected
ImplementedVerified, back to In progress
VerifiedClosed, back to In progress
ClosedNothing. Closed is the end.
RejectedProposed, if you want to reopen it
On hold Proposed, Triaged, Approved, In progress or Rejected

Note what is missing. There is no route from Implemented or Verified to Rejected. Once work has been done, the honest options are to close it or to send it back — not to pretend it never happened.

Putting work on hold

Any of Proposed, Triaged, Approved and In progress can move to On hold, and from On hold you can resume at whichever of those four is right — you do not have to go back to the beginning.

On hold counts as open work. It still appears in your open count and it can still go stale, which is intentional: an improvement parked and forgotten is exactly what the attention digest exists to surface.

Rejecting

Choosing Move to Rejected opens a panel rather than applying immediately, because a rejection needs a reason.

Rejecting an improvement
A panel headed 'Reject this improvement' asking 'Why is it being rejected? A reason is required and is kept in the audit trail', with a text area and Reject and Cancel buttons.

The Reject button stays disabled until you have typed something. The reason is stored on the record and written into the audit trail, so six months later the register still answers "why did we not do this?".

If the improvement is later reopened, the rejection reason is cleared — a live improvement never carries a stale explanation of why it was turned down.

Reopening, and what it clears

Moving back from Implemented or Verified to In progress clears the completion timestamps downstream of where you land. If a record was implemented on 30 March and verified on 13 April, sending it back to In progress removes both stamps.

This is what stops a record ever showing a verification date earlier than its implementation date, which is the first inconsistency an auditor spots. It also means the dates you see are always the dates of the current pass through the lifecycle. The full history is in the audit trail.

The gates

Three things can stop a transition. The first two are project policy; the third is always on.

GateApplies fromWhat it wants
Owner required
Optional		 Approved onwards An owner account id on the record.
Benefit case required
Optional		 Approved onwards Either a forecast benefit figure or a written narrative.
Evidence before verification
Always		 Verified Either a realised benefit figure or at least one measure.

Because the first two apply from Approved rather than at Approved, you cannot satisfy a gate, move past it and then strip the field out. Any later transition checks it again.

What gets recorded

Every transition writes an audit event carrying:

  • a sequence number, unique and increasing within that improvement;
  • the date and time;
  • who made the move;
  • the fields that changed — status, and any timestamps stamped or cleared;
  • the rejection reason, where there is one.

See Comments and the audit trail for how to read it.