ESX Maintenance Standard Operating Procedures (SOPs)

Question

Do you use SOPs for ESX maintenance?  I'm currently compiling some for VIOPS taken from my own experience - I think I've spotted a pattern, you see...
Also, I love the work of the IT Process Institute, Gene Kim (CTO Tripwire) and Kevin Behr (Assemblage Pointe) and others on bringing science to IT... ever heard of the Toyota Production System?  Ever heard of an IT version?  But I digress (if your interest is piqued - private message me!).
Back to the SOP - do you have one for ESX maintenance?  My work so far has found five different triggers:
Swap - e.g. replace failed drive
Patch - e.g. security patch
Upgrade - e.g. minor release like 3.5 U2
Configure - e.g. lock down SSH so you can only access via bastion/jump box
Observation - e.g. to run a vmsupport script
So now I'm thinking that ESX Maintenance isn't an SOP, but a collection of SOPs - and the real SOPs are those five above.
But what does an SOP look like?  The most basic example is a list of steps, but that's not enough for me.  I want something that brings science to IT and allows for continuous improvement.  I want the procedure to be followed rigorously, consistently - and where there is deviation it is because either (a) the process can be improved (improve the process), or (b) the person needs to be improved (improve the person - training).
So for my gold standard of SOP I've thought of the following attributes - and each SOP should fit on one piece of A4 paper
Trigger / Driver - what starts this whole thing, possibly a connection to a preceding SOP?
Input - what information is required to do this job?
RACI - for this procedure, who is Responsible (who does it), Accountable (who supervises?), Consulted (who helps), Informed (who is notified)
Resources - what tools and suchlike are needed for the actions (e.g. the list of changes to make to /etc/ssh/sshd_config
Actions - the unambiguous action to do, down to the most intricate detail - do not summarize, do not leave open to interpretation.
Timing - for each action, like the marks on the Toyota production line that shows in 32s you should be at step 3.
Output - A measurable outcome
So I'm desperately seeking SOPs and people who are interested in this stuff - I believe it's the key to increasing throughput and reliability of change, as do many others... do you?

Answer 1

I'm planning on separating a SOP from an STP - Standard Technical Procedure.
So the SOP will have a list of actions / STPs with how long they should take... example:
1.  On the SOP, one action is "logon to host" and it should take 2 minutes
2.  The STP is "Use SSH + RSA keyfob to connect to bastion.vmware.com, then SSH from bastion to host with username"
So on the A4 piece of paper, it does not go into n'th degree of the technical procedure, which may, as you say, require screen shots and stuff.
And the A4 suggestion is figurative, because all of this should be online anyway, but keeping it short is my point.
An SOP is equivalent to a project manager's Work Package (Prince2 term?).
Like you say, I'll write up a sample and try and get that looking good with your help (and others?) - then tackle the rest.
I am particularly keen on the time it takes to do an SOP... not just the steps required.  How does one limit unplanned yak shaving (to quote John Troyer!).
Your list looks great, and I've seen a similar one in PSO with HTML interactive screens...