Your team has a wiki full of work steps. Many, many pages. Someone made them for a review two years in the past. That person left. The tools in the pages have been changed out. The call list is wrong. The names go to a desk that is not there any more.

At three in the night, a worker gets an alert. It looks like ransomware on a file server. They open the wiki. They look for "ransomware." They find a big document. It was last changed a long time in the past by someone who is not with the team now. The first three pages are full of words that do not help. The fourth page talks about a tool the team does not use any more.

The worker gives up on the wiki. They do what all workers do when the steps are no good: they make it up as they go. It may go well. It may not. But the work steps did not help. They were there to show that a document was made -- not to show that a way of working was real.

This is how it is at many places. Work steps are made to make a review look good, not to help the person who does the work. The space between those two needs is where things fall down and break.

To fix this, you need more than good writing. You need to change who writes the steps, how they get a test, and what you do when they break.

Why Most Work Steps Fail

The Wiki Where Steps Go to Die

Every team I have worked with in the last twenty years has a place where old documents go to die. The tool is different from team to team -- wiki, shared folder, or a code home that no one reads. But the story is the same.

Someone made a space for documents. Pages were made in a big push after a bad day or a review. The first rush of work made many documents. Then the work stopped. The documents stayed.

New pages were made but old ones were not changed. No one took out old pages -- it felt like losing work. If you look for "alert" you find five documents. You have to read all five to find which one is right. Three of them say different things about who to call. The newest one is a year old.

This is not a writing problem. It is an owner problem. No one person is in charge of any set of steps being right -- right now, as of this day. When there is no clear owner, no one keeps things up to date. And old work steps that no one keeps up are not just no good. They are bad. They give the look of being set for what comes -- but it is a lie.

Made by the Wrong People

The second way work steps fail is who writes them. Most steps are made by managers or people who write for a living -- not by the people who will use the steps. The person who writes has different needs than the person who will follow the steps.

A manager needs a document that looks full and complete. A person who writes for reviews needs a document that maps to a list of rules. But the worker who will use the steps at three in the night needs a short, clear list: what to do right now, what to check, when to call for help, and who to call.

When the person who writes and the person who uses have different needs, the document helps the one who writes. This is how you get a big document for ransomware that no one reads.

Fig. 01 -- The gap between who writes and who uses
THE WRITER WANTS - Looks full on paper - Maps to rule list - Has many pages - Makes the review go well What you get: big document, put away and not used THE WORKER NEEDS - What do I do first? - What tool do I use? - When do I call for help? - Who do I call right now? What they need: the right thing done in the first ten minutes GAP THE DOCUMENT HELPS THE WRITER, NOT THE WORKER
The gap between what writers make and what workers need is the big thing that makes work steps go to waste. To close the gap, let the workers write their own steps.

The Good-Looking Document That Does Not Help

Some teams see the problem and try to fix it by making the documents look great. They bring in a writer. They build forms. They take many months to build a full set of steps with pictures and long lists.

Six months go by. The tool in the pictures has been changed. The list of names is wrong. The team has been moved. And no one wants to change the document -- it took so long to make that changing it feels wrong.

A short, right set of steps that was checked last month is more of use than a good-looking set of steps that was checked last year. How it looks does matter, but being right for this day matters more.

Made for Reviews, Not for Work

A review wants to see that a document is there, that it was said to be good, and that someone looks at it now and then. A worker wants to know what to do when things are on fire.

These are not the same document. If you try to make them the same, the review wins and the worker gets nothing of use. The review gets a check. The worker does not read the document.

The fix: keep two parts. One part is for the review -- the rule list, the name that said it was good, and when it was last looked at. The other part is for the worker -- the one-page list of steps they use for real. Let the review part point to the work part. But do not let the review part tell you how to write the work part.

What is a step list? What is a rule? A rule says what must be done. A step list says how to do it. Rules are from the people in charge and do not change much. Step lists are from the people who do the work and change all the time. When a review asks for "work steps," they will often take a rule -- a few big words that sound good but tell the worker nothing of use. Know the difference. Push for real step lists, not just rules.

Steps Go Bad Over Time

All work steps go bad. Every set of steps needs things to be true: the tools are set up this way, the network looks like this, this team owns this system, this person takes this call. Those things change all the time.

A set of steps not used in 90 days should not be fully trusted. Steps not used in six months are not to be used at all. Steps not used in a year are not real -- they are a story.

Most places do not know when steps were last run for real. They know when someone last looked at the page and said "looks good." That is not the same thing. A real test means someone tried to follow the steps -- in a walk-through or in a real problem -- and showed that the steps work.

If your work steps have not been run -- not just looked at, not just said to be good, but run step by step -- in the last 90 days, do not trust them. Put a date on them. Keep a list. If no one can say when the steps were last used for real, those steps are for show and nothing more.

The Form That Works

The One-Page Rule

If a set of steps does not fit on one page, it is not one set of steps. It is many sets put in one place. Cut it up.

This is not a made-up rule. It comes from how people use steps when things are hard. When a worker is in the middle of a problem, they do not have time to read ten pages. They need to look at one page, find where they are, and see the next step. If they have to look through many pages to find their place, the steps have not done their job.

One page means about 15 to 25 steps. If you have more than that, you are not writing one set of steps -- you are writing many. Cut it into parts and point from one to the next: "When you get to step 12, if the answer is yes, go to SOP-IR-007: Network Cut-Off."

What Goes at the Top

Every set of steps needs six things at the top, where you can see them right away:

What starts it. What do you see or hear that tells you to run these steps? Be clear. Not "bad software found" but "alert from EDR tool with High or big mark on any system, or a person says their files are not right."

What it is for. What does this set of steps take care of -- and what does it not take care of? This keeps workers from using the wrong steps for a problem that looks the same but is not.

The steps. The list of things to do, in order, with a number for each. One step is one thing to do. Not "look into the alert and find out how big it is" -- that is five steps in one.

When to call for help. Clear rules for when the worker should stop and ask for help from a lead. Not "when it looks bad" but "when more than five systems show the same problem" or "when any high-level account is part of it."

Owner. One person. A name, not a team. This person is in charge of the steps being right. If they leave, a new owner is set on their last day -- not six months from then when someone sees the problem.

Last test date. Not when someone last looked at it. When someone last ran the steps for real, in a test or in a live problem, and showed that the steps work.

One set of steps, one book, one big book People use these three words as if they were the same, but they are not. A set of steps is one list for one kind of problem -- one start, one path (with some turns). A book is a set of step lists, all for one kind of problem -- the ransomware book holds the find-it steps, the cut-it-off steps, the get-it-back steps, and the tell-people steps. A big book is a set of step lists for one system -- the server big book holds all the things you may need to do to that system. Step lists are small. Books hold many step lists.

Two Kinds of Step Lists

Not every step list is a straight line. Some need a turn: if you see this, do A; if you see that, do B. The question is when to use a straight list and when to use a list with turns.

Use a straight list when the steps are the same no matter what you find. The first look at a problem is often a straight line: get this, check that, write it down. The steps do not change with what you see.

Use a list with turns when what you do next needs to be set by what the last step showed. Is the system a server? Do this. Is it a work system? Do that. Is the account a high-level one? Call for help. If not, go on as set out.

The problem with lists that turn is that they can get too hard to follow. If your list turns more than three times, it is too hard for one set of steps. Cut it up. The top part takes care of the first turn, then hands off to a new set of steps for each path.

Fig. 02 -- Straight list or list with turns
STRAIGHT LIST 1. Get alert facts 2. Check log tool 3. Check alert tool for host 4. Write down what you find 5. Call for help or close Same steps every time. LIST WITH TURNS Is it a server? YES Call the server lead NO Cut it off Has files or data? DATA SOP-IR-012 FILE SOP-IR-013 Next step set by what you find.
Straight lists work when the steps are the same every time. Lists with turns work when the path set by what you find. Keep turns to no more than three in one set of steps. More than that means you need to cut it up.

The Full Example: Ransomware Found

Here is a full, real set of work steps -- not a short form or a list of ideas. It is in the form your team would use, with clear turn points and rules for when to call for help. Put in your own tool names, call list, and numbers where you see [words in these marks].

SOP-IR-003: Ransomware Found -- First Steps

Owner: [Name], Lead Worker
Last Test: [Date -- must be in the last 90 days]
Form: 4.2
Said Good By: [Manager Name]
What Starts It

Run these steps when ANY of these things come up:

  • Alert tool says: "Ransomware found" (High or big mark)
  • Alert tool says: "Many files changed" or "Many files with new names" on any system
  • A person says: files will not open, file names look wrong, or a note on screen asks for money
  • Log tool shows: more than 3 systems with file change signs in 60 minutes
What This is For

This set of steps is for the first look and the first moves. It does NOT take care of the full cut-off (see SOP-IR-004), the get-it-back work (see SOP-IR-009), or the talk-to-them-about-money part (see Book PB-RANSOM-001 -- the law team must say yes first).

Steps
  1. Write down the alert time (in UTC), system name, IP number, and the name of the person on that system. Put it in the ticket. If there is no ticket, make one now. Do not go on with no ticket number.
  2. Open the alert tool. Look up the system. Check if this is a known false alert by looking at the false alert list at [wiki link / shared place]. If it is on the list, write that down and close. Stop here.
  3. In the alert tool, pull the list of what the bad thing did on the system. Take a picture of it or get a copy. Put it in the ticket.
  4. Check the file changes on that system. Look for: many files with new names, new file types (.encrypted, .locked, .crypt, or any one new type on all files), note files asking for money (README.txt, DECRYPT_INSTRUCTIONS.html, or the same kind of file in many folders).
    5. TURN POINT: Do you see real file changes on the system?
    -- YES: Go on to step 5.
    -- NOT SURE: Set a 30-minute timer. Check the alert tool for new facts. If you still see nothing after 30 minutes, write what you found and close. Stop here.
  5. Check the log tool for all times the person on that system got in to other systems in the last 24 hours. Write down every system that person used. These are the ones you may need to check next.
  6. In the alert tool, look for the same signs (name of the bad thing, its number, the file type) on ALL systems. Write down how many other systems show the same thing.
    7. CALL FOR HELP: If more than 1 other system shows the same signs:
    -- Call the lead on duty: [call number]
    -- Mark the ticket as a P1 problem
    -- Do NOT stop to finish these steps. Call for help now.
    -- Keep going with the steps here as you wait for the lead.
  7. Cut off the bad system with the alert tool. Make sure it can not talk to the network any more. Check by trying to reach it from a work system. Write down the time you cut it off in the ticket.
  8. Turn off the person's account. If you can not do that, call the system lead on duty at [call number] and ask them to do it right now. Write down the time it was done in the ticket.
  9. Get a copy of what is in the system's memory and what it is doing right now, if you can:
    -- What is in memory (if the tool lets you get it from far away)
    -- What is running on it right now
    -- What network lines are open
    -- Who is on it
    Put all of this in the safe place for things you find, at [file path / place name], under the ticket number.
  10. Check the network logs (firewall, web filter, DNS) for the bad system. Look for: calls out to bad places (odd lines out, same call over and over), big sends of data out in the last two days, lines to known-bad places on the internet (check with the list of known-bad things).
    11. TURN POINT: Is there a sign that data was taken out?
    -- YES: Change the ticket to "Ransomware + Data Taken." Tell the law team right now at [call number/email]. This changes what you must tell people.
    -- NO / NOT SURE: Go on. The full look into this will keep going.
  11. Write a short note in the team channel with this form:
    [TIME UTC] [TICKET#] Ransomware -- First Look
    Known bad: [number] system(s) with file changes
    Cut off: [Yes/No] | Account off: [Yes/No]
    Data taken signs: [Yes/No/Looking into it]
    Next: [what you will do next and when]
  12. Hand off to the lead for full cut-off work as in SOP-IR-004. Stay for questions. Your notes are now the start of the full look into it.
Who to Call
  • Manager: [Name] -- [call number] -- [email]
  • Lead on duty: [list of who is on when] -- [call number]
  • System lead on duty: [call number]
  • Law team: [Name] -- [call number] -- [email]
  • Head of all things (for P1 only): [Name] -- [call number]

That set of steps does not tell you what ransomware is. It does not talk about how to stop it from coming in. Those things go in other places. It gives the answer to one question: what does the worker do right now, step by step, when this alert goes off?

It also has what most work steps leave out: clear turn points with real numbers, rules for when to call for help with a real count (not "when it seems bad"), a call list with real numbers (not "call the right person"), and a set form for the note you write to the team.

Writing in the Fire

The Write-As-You-Go Way

The best work steps come from real problems, not from a room with a white board. What the team does in a real problem, the things they check, the calls they make -- that is the set of steps. The problem is that no one writes it down as it is going on.

The write-as-you-go way changes this. In a real problem, one person -- the note-taker -- has one job: write down every step, every call, and every thing that comes of it, as it takes place. Not after. Not from what they can call to mind. Right then and there.

The note-taker does not do the work. They do not look into the problem. They watch, they hear, and they write. On a small team, giving one person to just writing things down feels like too much. But it is worth it in two days, because those notes turn into work steps you can use for the next time.

What the Note-Taker Does

The note-taker needs three things: a way to hear what the team is saying (the call, the chat, the room), a document that the team can see in real time, and the will to write down what is going on with no changes.

The note-taker writes down:

The note-taker does not clean up, set in order, or make things look good in the heat of the problem. Notes that are not clean are fine. Times and the right facts are what matter. How it looks does not.

Fig. 03 -- The note-taker in the team
LEAD Makes the calls WORKERS Do the work, find things TELLS PEOPLE NOTE-TAKER Hears all the team Writes it all down Times on every line Does NOT do the work RAW NOTES With times, not clean Ready in hours WORK STEPS YOU CAN USE Set in order, clean Ready in two days
The note-taker hears what all the team does but does no work on the problem. What they write down -- raw notes with times -- turns into work steps you can use in two days. One person writing in real time keeps the team from losing many hours of trying to call things to mind after the fact.

How to Turn Notes into Work Steps

In the two days after the problem is over, someone -- the note-taker or the lead worker -- takes the raw notes and turns them into a clean set of steps. Not a week from then. Not at the next big review. In two days, when you can still call it all to mind and the hard parts are still clear in your head.

How to do it in four parts: take out the things that are only about this one time (system names, person names, times), find the steps that would be the same every time, mark the turn points where a different problem would go a different way, and add the top part (what starts it, what it is for, owner, when to call for help).

The left side here is raw notes from a real problem. The right side is the clean set of steps that came from those notes.

Raw Notes -- 2026-02-14 03:12 UTC

03:12 -- Alert on WS-FIN-044. "Bad thing found -- may be ransomware." Person: jsmith. Called Dave, he said check if it is that same false alert from last week with the backup tool.

03:15 -- Checked false alert list. Not on it. This is different -- bad thing is running a hidden command.

03:18 -- Got the list of what it did. Looks like it came from an email. Took a picture of it.

03:22 -- Checked log tool for jsmith. Got in by VPN at 01:45 and was on file server FS-02 at 02:30. Not good.

03:25 -- Checked FS-02 in alert tool. No alert yet but same kind of thing is there. Not good at all.

03:27 -- Cut off WS-FIN-044. Trying to cut off FS-02 but need the server lead to say yes. Called Marcus (on duty). No answer.

03:31 -- Marcus called back. Said yes. Cut off FS-02.

03:33 -- Turned off jsmith account.

03:35 -- Called Sarah (lead). Set as P1. Five more systems now show the same thing.

Clean Steps -- From the Notes

1. Write down alert facts: time, system name, person, alert name. Make a ticket.

2. Check alert on the false alert list. If it is there: write it down and close.

3. Get the list of what the bad thing did from the alert tool. Take a picture. Put in the ticket.

4. TURN: Is this a real bad thing? If NO, watch for 30 minutes. If YES, go on.

5. Check log tool for all the places that person got in to, last 24 hours. Write them all down.

6. For each system that person used: check the alert tool for the same signs. Write what you find.

7. CALL FOR HELP: If any other system shows the same signs, call the lead now. Do not wait.

8. Cut off the bad system with the alert tool. For servers: call the server lead first for a yes.

9. Turn off the person's account.

10. Write a note to the team channel with: how many, cut off or not, and what you will do next.

The raw notes hold the real order that the team used, with the waits (Marcus not picking up), the good calls (knowing it was not a false alert), and the feelings ("Not good at all"). The clean steps take out all of that and keep only the things you would do the same way next time, and the turn points.

Look at step 8 in the clean version: "For servers: call the server lead first for a yes." That step is there because in the real problem, the worker could not cut off the server with no one saying yes. They had to wait four minutes for the call back. That wait is now part of the steps, so the next worker knows to start that call early.

This is how good work steps get made. Not in a planning room. In the hard times of a real problem, by the people who lived through it.

The 80 Out of 100 Rule

A set of steps that is 80 out of 100 right, ready now, is better than one that is 100 out of 100 right but does not yet live.

People who have done this work for a long time hold back. They know the hard parts. They know that step 7 only works if the system is running the new form of the tool, and many systems still run the old one. So they wait to write the steps until they can take care of every case.

But the new worker on the night turn has nothing.

Write the 80 out of 100 steps. Put them out. Add a note at the top: "These steps are for [systems on the new tool]. For old systems, call [name]." That note takes a short time to write and it turns work that is not done into work that can be used. The worker knows what to do for most cases and knows what to do when they hit a case the steps do not take care of: call for help.

Get the steps to the people who need them. Make them better next month.

Give someone the note-taker job. Get raw notes. Turn them into clean steps in two days. A set of steps that is 80 out of 100 right, made from a real problem, is worth more than a set that is 100 out of 100 right, made from an idea of what might go on. Put the 80 out of 100 version out and make it better over time.

How to Test and Keep Steps Good

Walk-Through Test

A walk-through is the best test you can give your work steps for the least time and money. Get the team that would use the steps. Tell them a story that matches the start of the steps. Go through the steps, one by one, out loud, with the document on the screen.

You will find gaps in the first five minutes. The gaps are the same kind every time:

Run walk-throughs four times a year at a small number. Run them every month if the team is growing or things are changing fast. Each walk-through should give you a list of things to fix in the steps, with the owner's name and a date by which to do it.

Real Use is the Real Test

The true test is when someone uses the steps in a real problem. When a worker follows the steps to get through a live problem, that is the one test that shows if the steps work.

The important thing here is to write down every time someone goes off the steps. Every time a worker does not follow what the steps say, write that down. Not as a bad thing -- as a fact. Going off the steps tells you one of two things: the steps are wrong and need a fix, or the worker needs to learn why the step is there.

You need the note to know which one it is.

The "Went Off the Steps" List

Keep a list -- a simple page will do -- that holds every time someone went off the steps in a real problem. Four things to write down:

Look at this list every month. If the same step gets left out over and over, the step is wrong. Change it. If different steps get left out for the same kind of thing ("I could not get into that tool"), you do not have a step problem. You have a tool-access problem.

Four-Times-a-Year Review

Every set of steps gets a look by its owner, four times a year. Not by a group. Not by a manager. By the owner -- the one person whose name is at the top. The review has three questions:

Has anyone run or tested these steps since the last look? If yes, use what you learned from the "went off the steps" list. If no, set up a walk-through for next month.

Are all tools, call numbers, and ways to get in still right? Check for real, do not just think about it. Call the numbers. Get in to the tools. Make sure the call-for-help path still goes to real people.

Has anything changed that would change these steps? New tools, team moves, systems taken down, network changes.

The owner puts their name on the review with a date. That date is the new "last look" time. But keep in mind -- looking is not the same as testing. Keep both dates.

Old Steps and What to Do with Them

If no one has used, tested, or looked at a set of steps in six months, take it out of the live set. Move it to an old-steps folder with a note: "Moved out [date] -- not tested or used in 6 or more months. Do not use with no review first."

A set of steps that is old but still in the live set makes two problems: a worker may follow it and the steps may be wrong, or a reviewer may see it and think the team is set for something it is not set for at all.

Moving old steps out is not the same as getting rid of them. They are still there if you need them. But they have a clear mark that says they are not to be trusted. That is the right and true thing to do -- and being true about the state of your documents is worth more than a long list of steps that look good on paper.

Keep your steps like you keep your tools If your team uses a code home for its tools, put your work steps there too. Every change gets a note with a date. Every big change goes through a review by someone who uses the steps. The list of changes is your log of what was different and when. When something goes wrong and someone asks "what did the steps say when Worker X used them on that day?" you can give a real answer, with a date. You can see what changed between then and now. You can take back a bad change.

How to Get the Team to Use Them

One Owner, One Set of Steps

If more than one team owns a set of steps, no one owns it. Team A thinks Team B is keeping the call list up to date. Team B thinks Team A is testing the steps. No one does it.

Every set of steps has one owner. That owner is on one team. If a set of steps goes from one team to the next -- and many do -- give it to the team that does the most important part. The other team helps when it is time for a review, but does not own the document.

When steps go from one team to the next, cut them at the line between teams. Team A owns the find-it-and-look-at-it steps. Team B owns the cut-it-off steps. Each team is in full charge of their part. The hand-off between them is clear: "When step 8 is done, tell Team B and hand off as in SOP-CONTAIN-002."

How to Make Steps Easy to Find

A set of steps that can not be found in 30 seconds is the same as one that does not live at all.

Three things make steps easy to find:

Same kind of name every time. Use a name form that has the kind, a number, and a short word about it. SOP-IR-003: Ransomware Found. SOP-NET-011: Firewall Rule Fast Change. Not "Ransomware Plan v2.1 DRAFT (2).docx."

Mark by what you see. Workers do not look for steps by name. They look by what they see. "I see files that are not right" should find the ransomware steps. "A person says they got a bad email" should find the bad-email steps. Mark every set of steps with the things a person would see that would make them need it.

One place for all of them. Steps live in one place. Not in a wiki and also in a shared folder. Not in a page and also sent by email. One place. All other copies point to it. If someone finds a copy that is not in the one true place, that copy is not to be trusted.

New Workers and Work Steps

Most teams bring a new worker in by putting them with a lead worker for two to four weeks. The lead shows them the tools, walks them through what can go on, and step by step gives them more of their own work. It works, but it needs the lead to be there, to be good at showing others, and to think of everything.

Work steps make this less about one person. The new worker gets the full list of steps on day one. Their learning plan maps to the steps: "In week one, you will run SOP-IR-001 through SOP-IR-005 in a test place with a lead near by. In week two, you will take real alerts with those steps, with the lead there but not right next to you."

Work steps do not take the place of learning from a lead. They give it form. The lead's job changes from "show the new person everything" to "help when the steps do not take care of their case." That works even when you bring in many new people at the same time.

New workers are also the best people to test your steps. They follow the steps as they are written because they do not yet know another way. If a step is not clear, they will ask about it. If a tool needs access they do not have, they will find out. Every question a new worker asks about a step is a gap in that step.

How to Know if Your Steps Work

Two numbers tell you if your work steps are doing their job:

Time to fix with steps and time to fix with no steps. How long does the same kind of problem take when the worker uses the steps, and how long when they do not? If the steps do not make it faster, the steps are not good or the workers are not using them. Both can be fixed, but you need the number to know which.

How often people go off the steps. If workers go off the steps a lot, the steps do not match what is real. If no one ever goes off the steps, that may mean the steps are right -- but more likely, no one is keeping a list of when they go off. Try to see a low number but not no number. Some going-off is good. It means the steps are being used and the world is changing.

"How many sets of steps we have" is not a good number to watch. A team with 20 tested, up to date step lists is in better form than a team with 200 old ones. Look at how up to date they are, how many have been tested, and if they make a real difference in the work.

The Hard Part is Not the Writing

The hard part of getting people to use work steps is not making the documents. It is getting people to follow them.

Most teams see work steps as a thing the manager makes them do -- a sign that the manager does not trust the team, or a rule that gets in the way of real work. Lead workers push back because it feels too set. "I have been doing this for many years. I do not need a list."

But people who cut open the body for a living use lists. People who fly for a living use lists. Not because they are not good at what they do -- because the cost of not doing a step is too high to trust to what you can hold in your head. Good workers have bad days. They get pulled away. They do not think of things when they are under a heavy load.

Work steps are not for people who do not know what they are doing. They are a safety net for people who do know what they are doing but are tired, under a heavy load, short on time, and do not have all the facts. The steps are there so that on your worst night, you still do the least that is needed and do it right.

That changes who writes the steps. If steps are for new people, managers write them. If steps are a safety net for people who know the work, the people who know the work write them. And when those people write the steps, the steps are good -- because the one who writes and the one who uses are the same person.

Get your lead workers to write the steps for their own part of the work. Not as a job they are told to do. As something they own. "These are your steps. They say how you take care of this kind of problem. When you are not here and the new worker has to do it, this is what they will follow. Make it good so you can trust it."

When it is about trust and not about rules, the talk changes. Good teams take care of their own tools -- and that means their documents too.

Work steps fail when they are made by the wrong people, kept where no one looks, tested by no one, and owned by all. They work when the people who do the work write them, one place holds them, tests four times a year show they are good, and one person owns each one. The change from "thing we do for a review" to "tool we use for real" is the hard part. Get that right and keeping them up to date takes care of its own self.

Twenty years of this work has shown me one thing about work steps: the ones that last are the ones that were born in hard times, tested in fire, and kept up by the people who use them. All the rest is just paper.