Tactics for Standards Setting: Lead, follow, or get out of the way.

“	Lead, follow, or get out of the way. -- Thomas Paine

I have to make up my travel budget annually every December/January.  In order to do so, I have to look at the overall strategic picture for standardization, and then pick the tactics that I think I will use.  Having chosen the tactics, I can plan my movement orders to match.

One of the things that I learned about 5-6 years ago from a colleague in the Healthcare standards space is what the tactics are.  They fall into 5 categories, each with different degrees of effort required:

1. Ignore
2. Monitor
3. Contribute
4. Lead
5. Kill

These tactics are applicable to any industry, not just healthcare.  Let's look at them in more detail.

Ignore
Tactics in this category include: 
If I pretend it doesn't exist, maybe it will go away. 
This is the Ostritch method, or the stick my finger in my ears tactic (nyah, nyah, nyah, I can't HEAR YOU....).  It only works if I can successfully ignore the standard and convince others that I don't need to pay attention to it (but see kill below).
I can simply ignore that at it is not relevant to me. 
This is easier.  If I never build a product that will use that standard, and it will never impact me, I can also ignore it.  I might want to pay attention from time to time to see if they've done anything I can learn from, but realistically, this is simply not my problem, or anyone else's that I deal with.
This is John's problem, not mine.
Or Harry's, or Charles', or whomever.  This is a delegation tactic.  DICOM is not an area in which I have expertise, so I let others deal with it.  As a friend of mine says, 'I put a "not-my-problem field" around it and it simply goes away.'  But, first I have to trigger the field, and thats where the delegation part comes in.

Anything in this category gets no travel time allocated, and little if any effort.  It does require a VERY small amount of monitoring, to see if tactics need to change.

Monitor
The principal tactic in this category is listening.  That may be monitoring e-mail or RSS feeds, or paying attention to what others are saying.  That's why I want an RSS feed for new projects from all the SDOs, so I can better monitor what is going on.  For now, I stay on several e-mail lists to keep up with what's going on.  I can also expect to get a heads up call from my network if something comes up that I might be interested in.   In the same vein, I also make sure to contact those I know when I see something coming up that might interest them.  Developing your network is one of the very best ways to increase your bandwidth in managing standards.

Monitoring implies that you have a process for review and escalation if your tactics need to change, so I try to keep enough in the kitty for one unplanned trip.  Monitoring can take from 2-5% of your time

Contribute
Contribution can include comments on listserves, participation in discussions and t-cons, engagement in meetings, or providing feedback during voting / balloting, or providing text.  The level of engagement depends on A) your level of trust in the process to move forward without you, and B) the amount of influence you want to have in the end result.
Contribution can take 5-15% of your time depending on the level of engagement.  I often have to allocate travel to activities that I'm going to contribute to.

Lead
Lead can also be at various levels.  You can lead a project as editor, cochair a workgroup, or become a member of the organization's board.  One of the nice things about editing a standard is that about 80% of what you write goes uncontested.  The remaining 20% is stuff that you wind up having to fight for, and probably half that is not worth the effort if you can have a good consensus group.  Leadership can be a valuable position to be in, but is also very effort intensive, requiring about 10-25% of your time.  It almost always involves travel for me, usually a week or more.  My leadership position in HL7 requires me to travel about 4 times a year now, and in IHE, 6 times.

Kill
Not all standards efforts are good ones.  Some deserve to die.  Failure to recognize that or acknowledge it is not an option.  Since most standards are good, the general perception is that all standards are good (the fallacy of hasty generalization).  As a result, killing a standards effort is often the hardest to accomplish, and should be undertaken rarely.  You can spend time, effort and most importantly, credibility on this sort of effort, and they don't always die easily.  Sometimes you'll think you put the last nail in the coffin, and it simply crops up another way.  Been there, done that, and there are people who still won't talk to me as a result.

I'll note that it is far easier to divert a punch or kick than it is to stop it.  I much rather use diversion tactics than head on ones when I can.  Another point is that it is far easier to generate change from within rather than without.  I tried making CCR better before I tried to oppose it, and it was only when the former was unsuccessful that I did the latter.

You cannot go this route alone.  You usually need partners outside your organization to help you.  Effort is always high, but travel varies.  Sometimes you need as much travel as leading, and other times, as strong as monitor.

There are a few different ways to kill a standard:

1. Ignoring it (this works if only everyone in the industry does it).  Microsoft tried this with XSTL but eventually had to put support in Internet Explorer.
2. Pre-empting it with something better.  HL7 tried this with the Care Record Summary and put a big dent in the ASTM Continuity of Care Record.
3. Replacing it with something better.  ASTM and HL7 produced CCD which effectively did in the Care Record Summary.
4. Confusing the space with multiple versions.  So now there is a Care Record Summary Release 2, which works somewhat differently than the IHE XDS-MS and the HITSP C48 specification.
5. Introducing unimplementable features and/or scope.  This is hidden as a contribution and fails the test of transparency.
6. Delaying a standard.  Negative ballots can take quite some time to reconcile.  ANSI and ISO rules require that all negatives be addressed, so you can stretch out the process, or retain your negative vote requiring an administrative process to resolve the issue.  I'll continue to work with a committee on a negative ballot as long as they want.  But I will rarely try to stretch the process out on my own, as the test of transparency fails there.  I recall one HL7 ballot that went a year.  The committee didn't contact me for 6 months, and then we spent another 3 months before they eventually "voted my comment non-substantive."  As is my right, I retained by negative and they had to go through another ballot process to pass.
7. Reducing the level of impact.  An informative document in HL7 usually has less "credence" in the industry than a normative standard.  Similarly, a white paper in IHE is not a profile that gets tested at connectathon.  Sometimes you can scale back the effort to be less intrusive.  This needs to be done sooner rather than later.

One of the principles that I use when engaging in the "Kill" effort is to be open and transparent.  Efforts at standardization need to be creditable.  If you engage in nasty tactics and aren't open about what you are doing, it can come back to haunt you.  One of the "old sayings" where I work is "Never do anything you wouldn't want to see reported on the front page of the New York Times".  That's what I call the test of transparency.  The report might not even be the NYT, it could just be the committee list serve.

The best time to kill a standard is in the early stages, during processes to evaluate the project.  Some organizations are better than others at not starting projects that aren't valuable, and others will adopt anything that is staffed.  Even then, it is difficult because standards organizations don't want to alienate those who are willing to contribute.

So, there you have it.  Lead, follow, or get out of the way.