11 minutes

Revise one process

Take one step that feels punitive, confusing or impersonal; find what it is actually protecting; and change the design without giving up the protection.

What you’ll be able to do

Complete a process revision for one step in your own work, keeping what the step protects and ending with a named owner, a date and a signal you can already see.
Compare the responses to this question and explain your choice: What does a sound revision look like?
Draft a process revision for one punitive step for your work, including the step and the moment a person meets it, what the step currently does to the person, what the step is protecting.

Keep the protection, change the delivery

The fastest way to lose an argument about a punitive step is to ask for it to be removed. Almost every harsh rule in a public system is protecting something a colleague can name in one sentence: a federal timeline, a finding from a review, a budget that only stretches so far, a duty to verify before paying, a queue that once grew until nobody could see the bottom of it. The person defending the rule is usually right about the risk and wrong about the only way to manage it.

So the revision separates two questions that normally arrive fused together. What is this step protecting? And is the current delivery the only way to protect it? In most cases the protection needs a boundary — files do have to close, money does have to be accounted for, decisions do have to be made by a date — and the punishment is an accident of how that boundary was implemented. You can keep a closing rule and stop closing on somebody's worst week. You can keep a verification duty and stop writing it like an accusation.

Three things separate a revision from a conversation. It changes what happens by default rather than what is available on request. It has a name attached to it and a date by which the change is in the mail. And it carries a way to tell whether it worked that uses something already being recorded, so nobody has to be interviewed about how frightening the old version was.

A process revision for one punitive step

One page that turns “this step feels harsh” into a change somebody owns by a date.

The step and the moment a person meets it Automatic closure of an open request after one missed appointment. The person meets it as a letter saying the request is closed and they may reapply, arriving days after an appointment they could not attend.

What the step currently does to the person Threat with no path, then silence. The appointment letter states the closure consequence with no way to reschedule or explain; the closure letter arrives with no route back other than starting over. People who miss appointments for the most serious reasons — a hospital stay, a caregiving crisis, a shift they could not leave — are the ones most likely to be closed.

What the step is protecting A real backlog finding: requests sitting open for months with no activity, no way to tell live work from dormant work, and a queue nobody could see the bottom of. Files do have to close, and the review will be repeated.

The revision: default, wording, timing and route Keep a closing rule. Before it: a reminder in the person's own channel two days ahead; one automatic reschedule on a first missed appointment rather than a closure; a named unit and direct number to say what happened; a rewritten appointment letter that carries the consequence and the route in the same paragraph. Closure only after the reschedule and the route have both been offered, with that recorded in the file.

Owner, review point, and how you will know it worked Owner: the request-processing lead, with the correspondence lead named for the letter. Reviewed at the agreed point using counts already collected — reschedules used, closures, reapplications after closure, and time from request to decision. No one is asked to describe their distress, and the paid advisors who reviewed the letter are asked what they think of the new version.

Copy the five fields, fill them in for one step you administer, and keep the completed page with the project file rather than in your own notes.

Browse and download only. Staff notes are not typed or saved on this page.

Real change, explanation, or work moved onto the person?

The renewal window goes from ten days to thirty for everyone.

A paragraph is added to the notice explaining why the deadline exists and what it protects.

The notice now says that extensions are available on request.

A first missed appointment now produces one automatic reschedule instead of a closure.

A sentence is added saying the unit understands this process can be stressful.

People who need the notice in another format may submit a written request to the unit.

The packet is sent in the language already recorded for the household, by default.

Revisions that rarely need anyone's permission

Move the route out of the consequence and into the same paragraph as the consequence.
Name a unit and a direct number instead of a general line.
Say what happens next and by when, including when the honest answer is “we do not know yet, and we will write again by the date below.”
Replace “failure to” with what is needed and why it is needed.
Send a reminder before a deadline rather than a notice after it.
Make the first reschedule automatic before anything closes.
Reply to every comment a participant sends with what happened to it.
Confirm what is already known at the start of a step instead of asking for it again.

Finish it with a name and a date

What you can change

You control whether a revision leaves the meeting as a decision with an owner and a review point, or as a shared agreement that the current design is unfortunate.

What to watch for

Do not send the whole process upward and wait for permission you already have. Do not measure the change by asking people to describe how distressing the old version was.

Your next step

Assign the first change to a named owner with a date, and pick a signal already in the records — returns, calls, reschedules, time to a decision — to tell you whether it worked.

Which entry describes a finished process revision?

“The automatic closure is harsh and we should look at alternatives in the next planning cycle.”

“A first missed appointment now produces one automatic reschedule and a reminder in the person's own channel; closure only after that route has been offered and recorded. Owner: the request-processing lead. Reviewed at the agreed point using reschedule and closure counts already collected.”

“We will explain the closure rule better in the appointment letter and remind staff to be sympathetic on the phone.”

“Automatic closure is removed; staff will follow up on open requests as time allows.”

Try a situation

A quality unit reviews a DSD process in which a missed appointment automatically closes a request, and the person must start over from the beginning. The automatic closure exists because a backlog review found requests sitting open for months with no activity. Staff agree the closure is harsh. The backlog finding is real, and nobody wants it back.

What does a sound revision look like?

Keep the automatic closure and add a paragraph to the appointment letter explaining why the rule exists and what it protects.

Remove the automatic closure entirely and manage the backlog by asking staff to follow up more often on open requests.

Keep a closing rule and change what happens before it: a reminder in the person's own channel, one automatic reschedule instead of a closure, a clear route to say what happened, and closure only after that route has been offered and the file records it.

Carry this forward

Most punitive steps are protecting something real: a legal deadline, an audit finding, a limited budget, a duty to verify, a queue that once ran out of control. The revision keeps the protection and changes the delivery.
A real design change alters what the process does by default. An explanation added to the top of an unchanged process is not a change, and “available on request” moves the work onto the person least able to carry it.
The revision is finished when it names an owner, carries a date, and has a way to tell whether it worked that uses signals already in the records — returns, calls, reschedules, time to a decision — rather than asking anyone to describe their distress.
You almost certainly already hold the authority for the first change. Wording, sequence, timing, who is named and what the default is usually sit inside the unit that sends the thing.

A completed process revision for one step, a sorting exercise separating genuine design changes from explanations and from burden moved onto the person, and a knowledge check on what makes a revision finished.

Run the revision on one step this month with the colleague who takes the phone calls about it, then send it to the person who owns the step with a date attached.

Your next step

What is the one step you will revise, and who owns it?

Name the step and the protection it is carrying.

Write the single default you will change.

Name the owner and the date you will ask them.

Decide how you will know it worked, using a signal already in the records.

Browse and download only. Course notes are not typed or saved on this page.

Mark this lesson complete

Participation and course completion in this program do not count toward DHS-required training credits unless management, a director, or DHS leadership expressly approves an exception.