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:
- 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.
- 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.
- 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.