My EPIC Process ASS

Recently a couple of my colleagues have asked me to comment on process that they're setting up. As usual, the problem was less what to suggest and more what to keep back to avoid the well-intentioned but often understandably poorly-received feedback carpet bomb (FCB).

Fortunately, in the blogosphere you can't hear your readers scream, so here's an FCB of heuristics and aides-memoire that I use when setting up processes, guidelines, checklists and the like. They're most appropriate when intended to be used on projects with multiple people, probably across teams, to manage collaboration on something that is considered valuable by a person or people who matter.

There are usually a handful of roles:

• customers - the people who want the process, perhaps with quite specific demands
• owner - the person/s responsible for setting the process up
• manager - the person/s responsible for ensuring it is used as intended
• agents - the people participating in the process

Some of the same people might be in more than one role at various times. For simplicity, I'll assume we're taking the role of the owner/manager here and when I say process read it as communal instructions of some kind. And, yes, this is mostly based on hard-won experience.

• The customers are not the only stakeholders. Anyone working with the process and anyone who interacts with it has a stake in it. 
• Be clear to yourself and the stakeholders what problems you're trying to solve or avoid and what goals you have for the new process.
• Try to make the first implementation something that you think is viable.
• Consider basing it on an existing process if there is one. (Either an iteration or a rejection of it).
• Especially at the start, try to involve sympathetic staff, champions of the project, or those with vested interests in seeing it succeed

• Try to make the process as close to the minimum you're prepared to enforce as possible.
• Try to avoid the temptation to add in reports, requirements, checks and balances that you and/or your customers don't really need. 
• Anything that you know you'd bypass in an emergency is a candidate for cutting.
• You will probably have to enforce every step you define. 
• Be prepared to do that.
• For your process to work for your stakeholders, you need your stakeholders to believe that you will make it work for them.
• Do eat the dog food. Be an agent in your own process for some of the time.
• Don't drink the Kool-Aid. Be prepared to question the process if you feel your customers have it wrong.

• If you design the process it's more credible if you're also the owner and manager (at least initially).
• If you're the owner it's more credible if you're also the manager (at least initially).
• There will be questions. Deal with them in a timely fashion.
• There will be objections. Deal with them in a timely fashion.
• Changes may need to be made. Deal with them in a timely fashion, and ensure all participants are aware of them.
• If documentation is needed keep it up to date. 
• Make sure that the people working in the process can see that you are keeping it up to date.
• Solicit criticism and comments and take them seriously.
• Make it clear that you will make changes if anything is not working (well enough).
• Actually do make changes if it's not working (well enough).
• Be clear about why you're not making changes if you decide not to.
• Don't necessarily stop thinking about improvement when the process is bedded in. For instance, once everyone understands the process are there bits you can safely remove or automate?

• Initially, monitor very closely.
• If you can test it out on a small scale before putting it into production, do so and gather feedback on it from all participants.
• Pay particular attention to interfaces. For example, where does control pass between two parties? What material is required at that point? What format? What other conventions?
• Make templates for stuff that can be usefully templated. Consider this particularly for critical stuff that, if missing, would block a downstream stage.
• Don't demand templates where there's no need or where it would stifle creativity or productivity.
• Look for standard approaches/tools where standards can be useful. For instance, what can you do to make sure that project time is not spent learning how to work in a project?
• Where possible, use tools to report status, provide a framework for moving a process through whatever stages you have.
• Think about how you can tell the process is working? is there a metric you care about?

Too much information? Could I distill all that mess into some kind of compact advice weapon that's more direct than the full FCB? Sure, here's what I like to refer to as an acronym-based surgical strike (ASS):

• Engineer: to make it efficient, smooth, workable.
• Propose: to seed discussion, and then gather and act on the feedback.
• Impose: because sometimes, someone has to have the final say or force the right or required thing to happen.
• Care: about getting it right for all of your stakeholders.

With thanks to the Dev Manager for suggestions and comment (delivered only after I'd formatted the draft in his approved tool's esoteric format, submitted a change request ticket and had it verbally approved by his line manager - written approval to follow by fax).
Image: http://flic.kr/p/6P4iAJ