A Matter Of Degree

Avoid Future Crisis - Ideas for keeping business and system documentation up-to-date

Sketching, originally uploaded by NathanaelB.

 

Yesterday I presented a case at a“KM Challenges” workshop, jointly hosted by the Boston Knowledge Management Forum and the Boston chapter of the Special Libraries Association.

My session concerned the documentation that is created to support the implementation of technology solutions. As the system is designed, launched, and then evolves, how do you keep the documentation (whether it be requirements, technical design, site maps, relationship diagrams, physical / logical architecture models, details about customizations, etc.) in sync with the current state of the environment or the current policies in place? There are many compelling reasons to do this, however most of the organizations I work with don’t have a system for handling it. As a consultant who delivers SharePoint projects and the documentation to support them, the ongoing maintenance of that documentation is typically out of my hands, but I want to help my clients avoid the issues that out-of-date documentation can cause.

The cases I outlined were variations on the same theme, as follows:

1. In the design of a new technology system, requirements documentation and a technical design spec is written, approved, and signed. When the design phase ends and the construction phase proceeds, the scope often changes during the build; however nobody goes back to update the written requirements. The risks inherent in this situation: if there is a dispute over what was built, there is no way to reference the most recent approved version of the requirements or spec.

2. To provide policy and oversight for the new system, governance documentation is written. As time passes, the system evolves and policies change. (Examples: a new version of the system is launched which includes the ability to rate and freely tag documents; a collaboration area is created where all users have the permission to create new sites) Nobody goes back and updates the governance. The risks inherent in this situation: if policies are not put in place, uncontrolled growth or sprawl could occur. Staff members could use the system in unapproved ways, which is more difficult to stop/enforce without a policy.

3. After the technology system is launched, updates are made over time. (Examples: the system administrator installs a third-party web part; a power user creates a custom workflow) These changes are not documented. The risks inherent in this situation: In a disaster recovery scenario, the system cannot be fully restored. If the system was built by an individual who leaves the company or a vendor who goes out of business, there may be nobody at the company who knows how to make changes to the system without breaking it. The changes that are made may have downstream consequences to other users, who may spend hours trying to figure out what affected their piece of the system.

4. In an organization without a robust Help Desk / ticketing system, the IT staff may be too busy to document the issues they resolve or the changes they make. Knowledge is kept in the heads of the staff, and to some extent in email. As time passes and the staff turns over, the same issues might be encountered again and again without any way to connect them. The risks inherent in this situation: Different staff develop their own ways of handling issues; the lack of standards creates confusion. Time to resolution isn’t shortened by having a common knowledge base, which can lead to frustrated users.

I had the benefit of fourteen intelligent, experienced minds to help me brainstorm solutions to these problems. Three hour-long sessions, each one with a different team workshopping the same four cases, produced a long list of suggestions. These boiled down to about 20 unique suggestions which sorted into five major categories:

Make the case

Make a compelling argument to the organization that emphasizes the reasons why they should protect their investment by keeping documentation up to date.

Share the negative - relate anecdotes of disasters and consequences, discuss downstream consequences of each system change to the other users in the system, provide hard numbers around costs. What is the cost for a vendor to come in and document all the undocumented? What is the cost of the application if it has to be rebuilt?

Share the positive - show the ROI of documenting, tell success stories – i.e. businesses or individuals who saved money, averted disaster, reduced the occurrence of issues or time to resolve them.

Improve processes

Schedule it – build in time to review changes and document them. Hold monthly or quarterly meetings with the team to discuss and document any changes that have been made to the system. If working with an outside consultant, make this recurring review/documentation part of the maintenance agreement with that vendor.

Leverage the training/orientation process; let training documentation serve as system or governance documentation. (Typically there is a strong focus on keeping Training documentation up to date, because it is highly visible and training occurs on a regular basis.)
Add a loop-back step at the end of each phase to check whether requirements, design spec, diagrams, etc. need to be updated. What are the gaps and how will we handle them?

Leverage Resources

Give a role to new hires to document changes, create knowledge base articles. As one of my session attendees said, “The newest person there is like your customer.”

Find the right resource – acknowledge that not everyone has an aptitude/affinity for documentation, and find / hire / outsource to someone who does.

If the system administrator is too busy to document as he/she goes, assign a scribe who can shadow, take notes, document.

Write or expand a job description, e.g. “This person needs to document this this and this. It needs to be done with this frequency. These tools will be used.”

Change the Culture

Screen new hires around code quality or documentation ability. If a candidate is going to be expected to create documentation as part of their role, make this part of the interview process.

Change the management style – instead of implementing requests as soon as they are made, institute a policy that for a certain period of time, the system is frozen, and frozen means FROZEN. Limit firefighting by asking, "Can it wait?" Roll requests into packages of changes rather than making them ad hoc.

Institute change review / code review, and require that more than 1 person is required to make a change or close a ticket. (This can also be a training tool for junior staff / new hires.)

Document at the front end rather than the back end – any time a change is requested, get signoff on the current state & requested changes, and document the request first before the change is made.

Make the change process more collaborative – have code review, hold meetings to work out large requests, let requestors negotiate priority among themselves; in essence, have more conversation around change rather than top-down “just do it, and it must be done immediately.”

Use / Improve tools

Make it easier for documenters to take screen shots, do voice recordings or video capture of steps taken.

Provide a template for updates and changes rather than an open-ended “comments” field where users might not be sure what they should write.

Provide a system to track requests, prioritize them, and add details about what was done.

Find out whether an automatic audit log can be implemented.
Leverage analytics and data mining to determine where efforts should be focused. What are the recurring issues that are most important to document? How many times was this KB article viewed (by customer, by IT staff)? How well is it rated?

Summary

We’re overcoming human nature here so there’s no easy solution. The situation can’t be solved unless organizations recognize the value of investing in up-to-date documentation – and in many cases, it’s human nature not to recognize the value until it’s too late and the disaster actually happens.  But there are many ways that organizations can improve what they do today.  I hope that one or more of the ideas above will be helpful to your organization.

 

More Information

Literate Programming - Software Documentation - a collection of brief quotes and ideas about the importance of software documentation from a variety of sources

Neglecting Systems Documentation Courts Disaster - discusses scenarios, consequences, and types of documentation.

89 benefits of documentation - some high-level ideas that could be used to develop R.O.I. estimates

 

 

How Reliable is Your SharePoint Implementation? Eight ideas to make a SharePoint-based intranet or KM system more reliable.

Reliable, originally uploaded by Phill Price.

Last night I attended a presentation by Simon Trussler and Anna Gilpatric from Health Dialog on the subject "Getting the most KM bang-for-your-(Information Technology) Bucks. They discussed and demo-ed their use of out-of-box SharePoint as a knowledge management system ("Health Dialog University"), and true to their presentation's title they have really leveraged MOSS 2007 for their needs without investment in third-party tools or custom code.

From their talk and screenshots, I saw quite a few reasons for their KM system's success, mostly based on human time and effort:

• a great-looking interface with graphical elements and usability emphasis
• a dedicated knowledge broker resource to populate the system and review metadata
• active promotion and training
• use of metrics, tracking, and KPIs
• development of workflows and content types to automate processes and make file types more consistent

Trussler summed up the presentation with his three keys to success: promotion, reliability, and usability. I wanted to focus on the "reliability" factor because I feel it's not typically emphasized for the end-user experience of SharePoint implementations as often as the other two concepts.

Some of these points will overlap with usability, but I think it's useful to look at them in the light of reliability - can your end-users depend on the system, and know they will get the same result each time they use it?

1. Are your files and metadata consistent and standardized?  Health Dialog University's dedicated knowledge broker reviews the metadata of every document subitted to the knowledge library.  Pick lists help standardize the choices, and content types are used, in Trussler's words,"to simplify data entry and hide complexity from the user."  There is continuous quality control and quality review of the material.

2. Is your material up-to-date?  When files are uploaded to the HDU system, they are automatically assigned an expiration date which lets the knowledge broker know when they need to be reviewed.  Different kinds of material have different expiration dates - e.g. quarterly vs. yearly.

3. Can users find what they need?   Although SharePoint's out-of-box search capability can be used to find material in the system, HDU also offers a browse-based navigation based on document metadata, in addition to featuring different views of the knowledge library.  Some of these topics and views are a direct response to user requests.

4. Do users receive timely feedback?  When end-users submit a document to the HDU system's pending area, they receive an immediate feedback email (generated by a SharePoint Designer workflow), and are also notified when their document has been approved and moved to the knowledge library, with a path to the new location.

5. How is the response time for approvals?  For HDU, the knowledge manager relies on a system of workflows and alerts, and can act quickly to review and approve pending documents.

6. Do links take the user where they expect to go?  Beyond the issue of broken links, do links behave in a consistent manner (e.g. either all links open in a new window, or none do), and do users know what they're going to get when they click on a file (i.e. will they know they're opening a Word document, a PDF, or a web page)?  (This one's firmly in the "usability" realm but a bad experience could cause the user to feel the system is less reliable.)

7. Where can the end-user turn for help?  On many of the HDU pages, Gilpatric has included a graphical link to a brief training screencast on how to use the features on that page.  This seems to be a really effective way to provide more specific on-the-spot training than the generic "help" link that SharePoint provides out-of-box.

8. How is the overall performance of the system?  Entire books have been written on this subject, and there are many factors to consider which are out of the scope of this post, but Trussler and Gilpatric mentioned that their KM system has experienced no crashes and very little, if any, downtime, and this certainly contributes to a feeling of trust for the end-user.

Some additional reading on SharePoint reliability (There are thousands of pages of material out there on this subject - please drop me a comment if you know a particularly good resource!):

10 suggestions for a reliable, low-latency Search deployment

Microsoft Best Practices Analyzer for Windows SharePoint Services 3.0 and the 2007 Microsoft Office System

 

How the Apollo 11 moonwalk became a tagging and records retention tale of woe

Stepping Onto the Moon's Surface, originally uploaded by NASAImageoftheday.

Today is the 40th anniversary of the Apollo 11 moonwalk, and this morning's NPR story "Houston, We Erased The Apollo 11 Tapes" is a classic tale of tagging, search, and records retention policies (or lack thereof). The article and broadcast are really worth a read/listen, but to sum up:

The original recording of the moonwalk was not in a format that was compatible with television, so the recording was converted for the TV broadcast in 1969 - and degraded in the process. Engineers knew there was a better-quality recording from the camera on the moon, but for years they couldn't find it. They had to search a vast repository of content using much-used terms like "Apollo" and "tape." It turns out that the recording was most likely recorded-over due to NASA's increased need for magnetic tapes in the 1980s.

This scenario makes me think of my clients - many of whom have expressed to me, in the process of converting to a SharePoint implementation, the notion that "any content over five (or three, or six, etc.) years old is worthless." I understand the concept - policy and regulation changes, business and market trends, and fresh research and information all change the relevance of older content. But as the NASA story shows, you may not realize now what's going to be gold in 40 years.

If you're managing content (and who isn't, whether on an organizational or individual level?), do you have record retention policies in place to expire content after a certain time, and if so, are you notified to check the content first, or is it automatically deleted? Are you at risk of having files erased due to exigencies like lack of storage space? Are files backed up on a regular basis, and if they are, could you restore those backups successfully? Have "delete" permissions been given to those who may not fully understand the importance of the content? In your search results, are the "gold" files getting buried under layers of more recent sediment?

NASA invested time and resources to restore and improve the quality of the recordings they did have, since they couldn't access the original. While you're pondering these questions, you can see the video here. (Personally, I'm a fan of the grainier original look; by removing noise they've flattened out some of the detail, a metaphor to explore another time...)

And a nod to you conspiracy theorists out there - pretty convenient that they "lost" those tapes, eh?

Knowledge Management at Partners HealthCare

Tonight I attended a Boston KM Forum presentation by Dan Bogaty from Partners Healthcare.

Dan emphasized a three-part formula for KM at Partners:

knowledge + technology + process

Partners is a complex organization, with 1500 people in IS alone, but Dan’s formula looks the same in many of the organizations with whom I work, no matter their size:

 

Bogaty went on to refine the KM process at Partners as follows:

His presentation underscored the relationship between knowledge management and patient care.  This got me thinking about how such a relationship could be said to exist at any business.  They may not all involve life-or-death concerns the way doctor-patient transactions do, but knowledge management is a critical component to what any business can deliver.

Most businesses have do-ers and technology systems to support them.  The processes that link the two are where it gets interesting.  Bogaty’s presentation made me realize that KM processes can influence:

• the speed of response to change (Bogaty gave the example of Merck pulling Vioxx in 2004 – how quickly can an organization comprising eleven hospitals respond to a shift like that?)
• the rate of innovation
• the setting (and amending) of best practices and standards
• the level of service provided to the customers
• the degree of compliance with internal and external rules and regulations

All of which influence an organization’s competitive edge and company culture.  Which means that knowledge sharing processes and practices can directly influence (and here I’m paraphrasing the core principles from Michael Gerber’s “E-Myth” series) a business’s ability to:

• Attract customers
• Attract employees
• Deliver uniformly predictable service
• Act distinctively differently from other businesses.
• Be so predictably responsive to customer’s needs that the customers return.

I think my clients would see a clearer path to implementing a knowledge management system if they asked themselves these questions:  Do our organization’s knowledge management processes and practices align with the way our organization envisions itself?  Do our employees adopt standards and deliver the product to the customer in a consistent, predictable way?  Is knowledge and methodology shared across the organization?  Can the organization absorb changes and react quickly?  What restrictions are placed on content creation and visibility – and are these restrictions seen as appropriate governance, or as frustrating roadblocks?

An audience member asked:  how can the customer’s feedback be brought in to these processes and systems?  This was not germane to Bogaty's presentation, but it was a good point – knowledge management doesn’t have to be a closed internal system.  The questions here could be:  Do our customers have a means to submit feedback?  Do they receive follow-up surveys?  If they do, does our organization review the data and use that information in a purposeful way?

Finally, I was left with this question for myself:  how can I help my clients see that knowledge management is not just a cost center or low-priority administrative function, but a critical input to the business?

Wall-E and Knowledge Management

Wall-E Rubik's, originally uploaded by The Wall-E Builders.

Inspired by the Clutter Diet Blog's post about Wall-E as a great organizer, I wanted to post my take on Wall-E's knowledge management practices. If we look at Wall-E's on-the-job skills, as well as his collection of objects, as his "knowledge," he:

- Readily shares his methodology for doing his job
- Shares his filing system and what is filed there
- Lets his taxonomy grow organically (the spork!) rather than constraining it to a predefined set of categories
- Takes time to learn about new things rather than opting for the safety of his work routine.

For me, the movie raised these questions:
If you're the only one who knows how to do what you do, whether at home or at work, is your filing system intuitive enough for someone to find what they need if something should happen to you? Could they find it by browsing, keyword searching, or by both means? Could what you keep (versus what you discard), and how you keep it, actually save your life or your career?

Tag as you search?

Today I attended a seminar hosted by the Boston KM Forum on categorization and tagging.  One of the speakers, David Hobbie, brought up a great point - that tagging / categorizing in the enterprise happens when a document is saved into the content management system, when a better way would be to have people tagging documents as they find them in search results.  The first scenario – tag on upload – involves questions such as Which version do you tag?  How can other users tag and rate?  The second scenario – tag on search – accounts for these issues and will lead to richer search results in the future.  I’m not advocating doing away with tag-on-upload, but I’d like to see Hobbie’s idea implemented in the enterprise applications used by my clients.

 

Last night I attended a talk on Enterprise Search from Microsoft by Tara Seppa at the New England SharePoint User Group.   Microsoft emphasizes the value of SharePoint’s “actionable search results” (by which they mean “preview helpful summary information and clear graphical representations of files; move, delete, copy, and drag & drop files; send, forward and reply to messages directly from search results, and open and run applications from the results”). The tag-as-you-search concept would be great functionality to add to future releases of SharePoint Search.

David’s blog:

http://caselines.blogspot.com/

New England SharePoint User Group:

http://www.clearwaypartners.com/SUGHome.htm

KM forum topic:

http://kmforum.org/blog/?p=70

Actionable search results definition from the whitepaper Microsoft’s Approach to Enterprise Search:  Bridging the Gap between Information Management and Enterprise Search

Social Networks and Smoking Cessation - what it might mean for your organization

I heard a great article on NPR this morning about a study which shows that when an individual quits smoking, this has a ripple effect on family members and friends, with the result that those in the social network are more likely to quit as well. 

"There's no doubt that people are influenced by the behaviors of individuals that are not just one degree of separation from them, but two and three degrees of separation. There's a kind of cascading influence," says Nicholas Christakis, a professor at Harvard Medical School and a co-author of the study, which appears in Thursday's edition of The New England Journal of Medicine.

This story was an inspiration, as I see so many companies struggling with behavioral and cultural issues that affect productivity and delivery.  If the clustering / hive intelligence effect that the article describes can work the same way within the social network of an organization, then there's hope for cultural change if a few key individuals will adopt the desired behavior, and spread this to their colleagues.

What issues is your company struggling with, that technology alone can't solve?  Here are a few that I see all the time:

• adopting a new tool, application, or platform
• using a naming or filing convention
• allotting time to non-billable activities that are critical to improving the practice or organization

In most cases there are at least a few people in any company who are doing the "right thing" already.  What will encourage them to spread their behavior to their network, and beyond?  How can the social network be strengthened so that desired behaviors might spread more rapidly?  And how can you start tracking this spread, to be able to show that positive change is happening?

Update - my colleague Marcel pointed me to a similar NPR article about social networks and weight gain / weight loss.

For Knowledge Management, Add a Human

This blog was inspired by tonight's discussion at the Boston KM Forum.

In my work with clients who are implementing a knowledge management platform, I see the same scenario again and again:

The client has a lot of disorganized:

They say:

"I can't find anything!"

So the client does this:

Then they say:

"I get too many results! It's a big pile of junk!"

So they do one or more of the following:

• Faithfully slog through the pile of junk ("Maybe it's on the next page of results")
• Go back to the old way ("I'll squirrel away the content I know and trust")
• Evaluate other search tools

When what might really help is this:

i.e., add a person.

A human to bridge the gap between the content and the people who need it.

Gian Jagai, who spoke tonight about his role as a Knowledge Manager, mentioned the need for a Community Coordinator, to facilitate the knowledge shared in a Community of Practice.

Dan Galant, the instructor of the Mindsharp course I recently took, said "Sharepoint is going to bring back Library Sciences," and that the best implementations he's seen are the ones where the organization hired a librarian to come in and organize the content.

They're both talking about the same thing – the need for a human to vet the content, to link information and technology and the user community. I'm not saying anything new here, but most of the organizations I work with don't have this role, and aren't planning to hire for it. Yet here are just a few of the ways this person could improve knowledge management at a company:

• Analyze search results and requests, then create links between what people are searching for and the best content or expert for the job (in SharePoint, these are your Keyword Best Bets)
• Identify premium content and tag it as such
• Update old content (or make sure someone's updating it)
• Interview experts, and document knowledge and information (this could be as simple as adding wiki entries)
• Distribute content to those who could benefit from it (RSS feeds are one way of making this easier)
• Document the requests for research help, and interview users about the ways an improved knowledge management system has benefitted the organization, to generate metrics justifying further investment.

One of the main things I've learned from working with SharePoint is that no matter how well you set up this tool, and no matter how many features it has for facilitating knowledge management, the customer probably won't be satisfied if they are relying on the technology alone to do what they need it to do.

Unfortunately, the folks with whom I work most closely and feel this lack of user satisfaction most acutely are influencers rather than decision-makers, with no authority to hire this community / content coordinator.

I don't know the answer, but I want to start recommending this role as part of the SharePoint team my clients will need as they roll out their collaborative portals.

Thanks, KM Forum, for a great discussion!

Execution vs. Innovation (and how Microsoft SharePoint is positioning itself these days)

I attended the AIIM expo today to hear the keynote speech by Microsoft's Jeff Teper, with demo by Arpan Shah.  Teper's talk, "From Business Intelligence to Blogs and Workflow to Wikis: Accelerating Both Empowerment and Governance in a Rapidly Expanding World of Information," discussed the difference between companies that are execution-oriented and those that are innovation-oriented.

The execution-oriented companies are concerned with governance, control, and regulating their internal content.  The innovation-oriented companies are concerned with collaboration and empowerment of their users.  The two types appear to have different strategic and infrastructure needs, but in reality, all companies need to combine the right amount of both.  Execution-oriented companies need to innovate in order to survive in the marketplace, and innovation-oriented companies need some standardization of their work process and product so that they don't end up with duplicative effort and chaos. 

Teper showed how Microsoft designed SharePoint (MOSS 2007) with both sides in mind.  It has what Teper called the Governance Accelerators:

• Consistent site & information architecture
• Information management policy
• Rights management
• Auditing

And it has the Empowerment Accelerators:

• Employee self-service
• Role delegation
• Intuitive User Interface
• Pervasive Collaboration

Which way does your company tend - toward execution or innovation?  Is one of these words part of your mission statement?  Have you experienced situations where you needed to enable your organization to work in a different direction than you usually do?  I'd love to hear stories or examples from the real world, now that I'm looking at things through execution-vs.-innovation-tinted glasses...

Blogs are from Mars, Wikis are from Venus?

At a seminar I recently attended about how blogs are used in the corporate environment, one of the speakers, Susan Dobscha, Ph.D. (Associate Professor of Marketing at Bentley College) mentioned that she believes blogs are a masculine form of communication, and wikis are a feminine form of communication.  (In this context, blogs represent an individual making a statement to maintain independence and status in a hierarchical world (see Deborah Tannen's Difference Theory), and blogging involves a strong sense of identity and ownership, whereas wikis are a collaborative and iterative effort without a single identity or owner, to create a network of links based on consensus.)

At first I bought in, because the association was appealing, but it doesn't hold up.  It's easy to say that it's masculine to hold forth on your opinions (whether anyone responds or not), and it's feminine to organize and edit without being in the spotlight.  Blogging is hurling arrows around and wiki-ing is nest-building, right?

I kept thinking about rocks covered with petroglyphs, paintings on cave walls, and hieroglyphics - I can't prove that no women were involved, but my sense is that the men were doing this collaborative, uncredited work.

I thought, too, about women and fashion - how women use clothing to make a statement and show status (think of an actress at the Academy Awards, or a bride on her wedding day) whereas men in those situations generally wear variations on the black tux.

I'm sure there are other examples that show how men have a history of collaboration & consensus in their communications (e.g. The U.S. Constitution & Bill of Rights) and how women have eschewed compromise in favor of victory (the Suffragettes?).  What are your thoughts?