IT takes a Community to build best practices. Really.

I treasure the chances I get to interact with our customers and partners.  I have  made a lot of my living side by side with  customers, field engineers, architects, and executives, solving problems, sharing knowledge, capturing and documenting how best to design and implement IT solutions.  So I know something about how customers feel when they're faced with hard decisions in the high-risk high-stakes world of Enterprise IT Service Management.  To reduce the risk and increase the value of  solutions, we need "best practices".  But what does that really mean? 


I believe best practices, product champions, and product leadership are a natural result of the formation and power of community, a subject I'll be blogging about in the near future.   A large community is not required to produce a set of best practices.  But you do need some essentials to build a community.  And while I'm not gonna give away our secret recipe, I can give you a few of the ingredients.  Most still depends on the chef.


Membership -  The membership is the field in which best practices grow.  The user base is not a membership until it is brought together somehow for the purpose of interaction with each other.

Persistenance - a community must have a memory, such as forums, blogs, archives, etc.  This is not just a document repository, but a continuance of the knowledge sharing that occurs during interaction.  It is a reflection of the actual state of the practitioner community.  It is a major source of the ideas and proofs for best practices.

Sponsorship - A community of practitioners must have someone to "stir the pot", someone to orchestrate the interaction and see to the capture and distribution of the results of the interaction.   Either free time donated by one or more of the actual practitioners, or under a community or social program of a vendor.   For HP communities, each community has an HP employee who is the orchestrator.

Interaction - a way for practitioners to share and discuss content and ideas.  Call them user group meetings, or whatever.  We hold regular practitioner's forum conference calls.    With focused interaction, best practices that once languished in hidden isolation are shared and brought to light, "pulled" as it were into the community by other, perhaps newer, practitioners experiencing the same challenges.  All that has to happen is the author of the practice shows up to be asked, and BANG! - a support call was just saved, five others wrote it down, including the scribe, who captures it for the next best practices update, and forwards it to product support's knowledge base and to product management for discussion.

We just started new practitioner's forums for the APM, OM, and NMC communities.  Reply to this blog post  if you'd like more information on these or other communities.

Product and Architectural Thought Leadership - The community of experts must actually contribute some good ideas and direction to the product.  It is up to the community to leverage these good ideas into a voice back to the vendor.  The CMS best practices program had thought leaders from within and outside of HP.

Hands-on Thought Leadership -   Not only in the design and applied theory parts, but in the implementation parts.  Without a doubt, hands-on practitioners produce the best product-level best practices.   These best practices are often laced with workarounds and implied enhancement requests.  When leveraged properly, these become a clear voic back to the vendor for product improvement.  The wise vendor pays close attention to these "bees".  A community amplifies a single bee into a hum loud enough to get the vendor's attention, which is always a healthy thing - but only the unwise vendor will fail to react before being stung.  And it's more painful to be stung by a community than by an individual.

Orchestration - the processes of sharing community knowledge:
     -  with the vendor (to improve the product)
     - with the community (for the next generation of new practitioners)
     - with each other (establishing and growing technical thought leadership)


Bake, regularly check for tenderness, serve fresh.  It might look similar to this:

 The Power of Community


This is only a a taste of what it takes to create a best practices library - not a project.  You have to go build a community, make it grow, harvest and share.  And have the help of about a hundred of your friends.  Thanks to all who contributed, reviewed, discussed tirelessly, argued, corrected, cleaned up, and did many other tasks it took to get a library published.  The process of creating the library out of the harvested expertise is indeed a project.  But having the content can only come from an existing community.


So a lot of best practices aren't.  Why?  Now you know the answer.  Why do ours work?  They were built by the community, for the community.  By the way, our CMS best practices library is located here.  Strategy.  Design.  Planning.  Implementation.  How to make a squeaky-clean, actionable CMS.  How to build those really cool application maps everyone is talking about.  Killer discovery and dependency mapping techniques.  Data Center Transformations.  It's all in there.  Access is granted to all UCMDB or DDM entitled customers.


Please feel free to reply here and let us know what you think about the community or best practices concepts in general, or if you'd like more information about specific HP software communities.  Most HP communities are at including the ITSM blog.


Thanks for listening!


Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Showing results for 
Search instead for 
Do you mean 
About the Author
Jody Roberts is a researcher, author, and customer advocate in the Product Foundation Services (PFS) group in HP Software. Jody has worked ...

Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.