Killing a Bad Standards Project

This term I'm studying project management, and as we are finishing up the term, the current discussion is around killing projects.

I've previously noted how hard it is to kill a standards project in the past.

The easiest way to kill a bad standards project is before it starts.  But how do you know that a standards project is a bad one?  There are a few signs that you can look for that mean you need to do more investigation:

1. Does the project leadership come from within the consensus body or share the same values as it, or does it come from outside expecting the consensus body to adopt its values?  If the latter, ensure that the values of the leadership are aligned with the values of the consensus body.  If they aren't, investigate further.  It may be that you are experiencing Not-Invented-Here syndrome, but it could also be a sign of a misfit project.
2. Is the project one-sided or designed principally to benefit a single organization or type of organization? Do benefits of the standard accrue to only one of the consensus bodies stakeholder groups and not others?  There's almost never a complete balance, but if both parties don't get something, it needs further investigation.  I wrote about this idea briefly with regard to how HQMF can help take those costs out of the system 5 years ago.  I find it interesting that we are still expecting EHRs to do the heavy lifting with regard to computation, but I also see many organizations centralizing that capability to make life easier.
3. Is the project within the main area of expertise of the consensus group, or is it stretching the edges and would fit better elsewhere.  This can be a sign of the proposer cherry-picking the consensus body that would approve the project.  This happens all over.  Sometimes it happens within an SDO, and other times it happens across SDOs.

One sign that I always look for is who is getting paid to do the work and by whom and how much influence they have and how well does the schedule fit with my own.  This is part and parcel of how much standards work gets done, but it can also be a significant clue.

Once a project has started, it becomes harder to kill.  Both IHE and HL7 have some processes in place to make sure that ongoing work receives necessary approvals before it continues on to the next step, and that causes projects that aren't really making progress to die.  I've seen several projects die in both organizations even though they may have started with very good reasons.  For example, the original CDA Release 3.0 project died due to lack of participation. It has now been replaced by a new project (previously named CDA Release 2.1, but changed to 3.0 because of HL7 rules about major and minor versions).

Even after they have died, dead projects still have something to contribute, if only as a teaching experience. The "CCR wars" eventually prevented the ASTM XML (defined in an adjunct) from being the dominant format, but a CCD is, by definition, still conformant to the ASTM CCR standard (which functionally described the data being exchanged), even in the 1.1 version now present in the C-CDA.

A last note about failure.  If you never have failed projects, you aren't trying hard enough!  Some projects are destined to fail, and others to succeed.  You cannot predict which ones will do which.  If we could, the world might be a better place, but it would also be more boring.