In any standards project, you have at least one key deliverable, and that is the specification. How is that any different from other tasks where you can put 1,2,3 .. 5 whatever number of experts together to produce something that will work (or fail)? It isn't really. The experts work out the details, focusing on their areas of expertise, and form and storm and norm and eventually product a work product.
What is different in standards work is the almost forgotten delivery that goes along with a successful standard. Consensus. Sometimes in our haste to get things done, we forget that this is also a deliverable. That we, in the course of obtaining our insights into the problems we have solved, must also share those with others in a way that they see what we see, and hopefully agree that we have solved it in the right way.
And the best measures of consensus aren't yes votes. No, those measures are better indicated by two things, one short term, and one in the longer term. In the shorter term, you can measure consensus by how the workgroup feels after the shouting is over and the job is done. Did we feel good about what we delivered? Do we think it was worth doing? Or are we so glad that is behind us so we can get onto some real work?
And in the longer term, did it get used? Implemented by someone? Incorporated into a program? Or at the very least, did it feed into and inform something else of use.
In the end, it isn't about delivering a specification. Anyone can sit in a room by themselves and write (I do that on a daily basis). The real measure is whether what you delivered is consensus.
0 comments:
Post a Comment