A forum to discuss ideas, approaches, standards, and architecture to establish and support open interoperability among healthcare IT systems.

Thursday, January 18, 2007

Creating a Culture of Success

The Healthcare Services Specification Project (HSSP -- http://hssp.wikispaces.com ) celebrated its unofficial one-year anniversary last week. One year ago, the HL7-side of the HSSP standards collaboration was formally chartered. We have learned a bunch of things during the course of the year, and made our fair share of mistakes.

Ultimately, if HSSP is to achieve its goal of creating viable healthcare SOA standards that are to realize marketplace acceptance, the group creating them must be successful. The energy around this activity has been growing throughout the course of the year, and more activities are presently in the "channel" than we ever imagined would be -- presently six active HL7 functional model specifications under development, and two OMG-issued RFPs to industry soliciting technical specifications based upon already balloted HL7 work.

The following are some of the cultural lessons-learned that I have observed within the group during the past year. I do not believe that we're doing everything right by any stretch of the imagination. That said, I think we are doing a lot of things right.

1) Don't be afraid to fail. The adage "fail early and often" couldn't be truer. We've made a bunch of mistakes along the way. That said, HSSP as a group has been pretty fearless. Ultimately, people are very forgiving folks. We screwed up getting our communications channels right (mixing two mail lists was a horrific failure). We started a little to ambitiously. We didn't have sufficient materials out there for folks to learn and understand what we were up to. The practical guidance to developers trying to solve business problems was lacking.

But we learned. We learned and improved. Problems were corrected. We persevered, and we listened. That listening has made us a better group, and we've done a good job of documenting what we do, improving as we go, and not making the same mistakes twice.

2) Keep the pressure on. Deadlines themselves are good things, not bad things. When we started, we tried to keep "Uncomfortably aggressive" timelines. Nothing so ridiculous that it wasn't plausible, but nothing that would be "comfortable" either. The result is that HSSP continued to push and get things done. Every deadline slipped. That said, I don't believe any have slipped more that one calendar-quarter. Not bad for a project with zero budget and zero dedicated resources.

3) Document your process, and seek continuous improvement. HSSP follows a formally documented process. That process started out with a lot of holes, and still has plenty. Many have been filled in. Inherent in the process, the group, and the culture has been engrained the attitude to do things better, capture those lessons, document them, and then follow our process.

Without a documented process, activities cannot be repeated. Perhaps most importantly, having the process documented means that newcomers can understand what we are doing. A colleague and HL7 attendee whom I very much appreciate and respect said of HSSP "This is [one of] the only groups where you can come into the room and understand what they are doing." The byproduct of having process rigor and operating in the daylight.

4) Let subgroups work autonomously. HSSP created a model where each subgroup must conform to the overall methodology and processes of the project, but they work autonomously. This autonomy allows each effort to establish their own dates, develop their work, meet and discuss, and ultimately custom-tailor to their needs. That said, the overall process ensures sufficient public vetting, quality assurance, and confidence that the work is consistent with the scope of HSSP activities and aligned with parallel work streams.

The upshot is that an increasing number of new work threads are emerging with new communities taking on the responsibilities. HSSP has been able to scale-out and actively collaborate with many HL7 committees, and is even entertaining discussions with newly-interested external standards bodies.

Perhaps most important, this autonomy has created diverse leadership opportunities, where anyone willing to do heavy-lifting can participate and realize business value and recognition for doing so.

5) Keep a relentless focus on business value. Many standards activities are about creating standards, and lose sight of the fact that standards must solve some problem to be useful. HSSP welcomes any point of view, but ultimately makes decisions based upon business value and resource contribution and interest. By aligning standards-development with people's day-jobs, the notion of "volunteers" largely goes away: working on the standard is working on the "day-job."

HSSP since its inception has been constantly striving to connect these two worlds, and has been enjoying slow but steady growth as a result. The business world and the standards world do not need to be in conflict. Recognizing that business needs and interests are strong motivators, there are many work threads that are synergistic to both. Striving to remain in that space is hard, but rewarding.

6) Maintain a high-trust environment. I met Jim Demetriades (Biomedical Engineer and Healthcare Architect, Veterans Health Administration) many years ago and learned a lot from him. One of the most important lessons was the impact of a low-trust vs. a high-trust environment.

In a low-trust environment, we must take on activities ourselves because if you don't, the original intent of your work, how it fits, its success, and progress can be stymied by the world at large. Collaborating is largely risk-mitigation. Ultimately, ownership is of paramount importance, for it provides the enabler to achieve your objectives.

A high-trust environment is very different. It is predicated on the fact that others are focused on their areas of interest, which may-or-may-not intersect with yours. In a high trust environment, you work in the sunlight and expect criticism and feedback that is constructive. Some is, and some isn't, but you learn from each data point on the way.

HSSP has created a culture and in my opinion a high-trust environment. There can be (and are) many very heated, juicy arguments in a high trust environment. That said, the arguments are always technically focused and about improving the work product, and almost always end with the opponents heading off together to lunch or to a watering hole. Built on mutual respect, when each of us expects and demands this from each other we can all be successful together and not at each others' expense.

7) Have fun. I think it was particularly fitting when HSSP concluded its business activities last week in passing a guiding principle that stated, very basically...

...No group would have more fun doing meaningful work than HSSP...

Hard work can be fun, and fun does not have to be irrelevant.

Until next time....

- Ken


Anonymous Anonymous said...

This comment has been removed by a blog administrator.

13 November, 2009 09:00


Post a Comment

<< Home