A Matter Of Degree

The importance of trust to adoption and governance

1. Trust Is Critical to Adoption

I heard a story on the radio a few months ago that has stayed with me.

From a news perspective, this story is about changing healthcare practices to reduce costs, and the important role of data in this change.  From my perspective, there is a scene-stealer in the story that eclipses those topics.

Brief synopsis:  A group of health care providers in Camden, NJ analyzed data about emergency room use with the goal of reducing ER visits by those who didn't actually need emergency care (but rather the regular care of a primary care physician).  They mapped hospital billing info and found hotspots within the city of "super users" of the ER.  With this information they placed physician's offices directly in those hotspots - sometimes in the same apartment building with the super users.  Result:  over time, use of these local physician's offices has increased, and ER and inpatient visits have decreased.

Here's the part of the story that struck me:

"Dr. Jon Regis is a longtime member of the Camden coalition. ...Regis says it took longer than he had hoped to win over residents — almost two years.  "We thought that since they were having such a difficult time, we could just open up the door and they would come down," he says. "That wasn't the case ... We had to do a number of different things, like health fairs and meet-and-greets. We had to engender a sense of trust in the residents before they would come down to see us," he says. "I think that was somewhat surprising. But we're starting to get past that now." "

Think about this - you have the chance to switch from trekking across town to the ER, where you experience long wait times and where the nurses are sometimes point-blank telling you you shouldn't be, to visiting a doctor just a few floors down in your own building.  But you don't do it.  There could be any number of reasons behind this - the main point is, even a change that's seemingly a no-brainer requires time and outreach in order to take hold.  You need to trust that new system before you will start using it.

This story is a metaphor for practically every SharePoint implementation I've worked on, and I'm guessing it's the case for most IT projects, SharePoint or otherwise.  It's not enough to introduce something life-improving and cost-saving to your end users; they need to trust that new system before they will use it, and in order for that to happen, it requires change management, which usually means you need to walk the halls, tell the story, meet the users on their own terms. 

Unlike a hospital ER, a company might be able to shut down an old system or restrict access to it, but in my experience companies can't or won't do this, especially with entrenched systems like file shares and email.  And if the doors remain open to the old system, without a serious outreach effort (marketing and communications), that convenient new time-saving application may take years to be fully adopted (if ever).

2. Trust Affects Governance, Too!

On a similar theme, last week Atul Gawande published "Slow Ideas" in the New Yorker.  In this article he tells the story of how several life-saving innovations progressed through history.  Some spread relatively quickly, like the use of anesthesia.  Some have taking much more time to spread and be adopted, even though they are generally understood and accepted, like antiseptic behaviors. Gawande looks at the motivations behind the spread of ideas, and different approaches to changing behaviors - one being punishment or disincentives, and the other being incentives and rewards. 

This is where the article started to sound like a governance story to me: you have a list of behaviors that you want your workforce to follow, for the good of all.  In Gawande's example of reducing infant mortality in developing countries, this list includes handwashing, disinfecting delivery rooms, and keeping the newborn warm.  Now, although I'm in no way trying to equate the impact or criticality of a hospital delivery room with an information technology system, in the organizations where I've seen new IT systems implented, there is also typically a list of desired behaviors, which may include the use of naming conventions, granting of permissions and rights based on role or training, and the following of a code of conduct, to name a few. 

In both cases, if you ask the practitioners in the system whether they think the list of rules is a good idea, intellectually they would say yes - yet they don't follow them or carry out the steps on a daily basis.  Why?  To quote Gawande -

"...technology and incentive programs are not enough. “Diffusion is  essentially a social process through which people talking to people spread an  innovation,” wrote Everett Rogers, the great scholar of how new ideas are  communicated and spread. Mass media can introduce a new idea to people. But, Rogers showed, people follow the lead of other people they know and trust when  they decide whether to take it up. Every change requires effort, and the  decision to make that effort is a social process.

This is something that salespeople understand well. I once asked a  pharmaceutical rep how he persuaded doctors—who are notoriously stubborn—to  adopt a new medicine. Evidence is not remotely enough, he said, however strong a  case you may have. You must also apply “the rule of seven touches.” Personally “touch” the doctors seven times, and they will come to know you; if they know  you, they might trust you; and, if they trust you, they will change. That’s why  he stocked doctors’ closets with free drug samples in person. Then he could poke  his head around the corner and ask, “So how did your daughter Debbie’s soccer  game go?” Eventually, this can become “Have you seen this study on our new drug?  How about giving it a try?” As the rep had recognized, human interaction is the  key force in overcoming resistance and speeding change."

In the article, Gawande gives several examples of how the placing of experienced trainers among the group of people whose behaviors they wanted to change, and bringing them into regular social contact, eventually brought about changes in those behaviors.  His article is lengthy but in my opinion well worth the read to get a sense of the scale of the effort that is required to make even small changes that can have tremendous impact. 

This is as true for your technology governance and adoption as it is for people in the medical field - your checklist won't be followed, and your system won't be adopted, if you launch it and only provide self-service training.  To achieve the successful spread of the change, you need to go out among your user base, not just once but multiple times, subtly reinforcing the message and building trust.

Read More

Slow Ideas by Atul Gawande in the New Yorker's Annals of Medicine

In South Jersey, New Options For Primary Care Are Slow To Take Hold by Taunya English for NPR

 

Why Intranet Adoption Is Like The Color White (or, Adoption Doesn't Exist)

Last week a client asked me, “How do we get better adoption?  It’s such a challenge.”  At this point I can’t count the number of times I’ve been asked how to improve adoption of SharePoint intranets or applications.  I have plenty of recommendations.  And I know that the number of presentations, training courses, articles and opinions out there on the subject are also beyond counting.  Clearly there’s a problem and the community is doing the best it can to address it.

When I was asked this last week for the nth time it came to me very clearly:

"Adoption" doesn’t exist.

At least, not the way most people think about it.  It’s not an entity or a competency on its own.   It’s not a feature or an endpoint with a well-defined set of characteristics.  It’s not an improvement or an upgrade that you can run like a project and dedicate attention and resources to as its own workstream.  

Think of the way the color white is made, which many of us learned in grade school or at a science museum:   the result of many colors of light added together.  

This is adoption.  The “white” at the center that can’t exist without all the other colors.

 

Original photo source:  Jared

These are the critical colors that need to be in place:

• Executive support – Has using the new system or tool been made a priority at the highest levels?
• Business alignment – Does the new system reflect how people actually get their work done every day, and does it improve that for them?
• Marketing / Communication / WIIFM – do the users know about changes in advance, and has it been sold to them why the change is good for them?
• Staffing, training, and support – Do the users know how to do what they need to do, and whom to contact when they hit a snag?
• Trusted infrastructure – What would make the users leave their desktops, email, file shares, etc. for something unknown?  Has it been proven to them that the new system is even more trustworthy than the old one?
• Dynamic, fresh content – Who is in charge of making sure that content is up to date, and do they have enough time to perform this function?
• Users have a voice – Increasingly, users want intranets to work the way the internet does. This could mean anything from voting and commenting on content, to uploading their own content, to sending feedback about a problem and/or making a suggestion.  Does your solution span the range?
• Usability – Is the system usable, more efficient than the way users worked before, and even appealing and beautiful?
• Accessibility / mobility – this isn’t only about mobile devices; it’s about whether people can connect quickly from home, and/or do their work on a plane or commuter train.  It’s about whether the folks in the warehouse or out in the field have a way to access the system. 

And there are likely many more than this (for example, Carrots and sticks – has the organization considered what to turn off (e.g. file shares) and what to light up (e.g. performance incentives) in order to drive behavior?). 

Put them all together, and you’ll have user adoption.  I grant you, this is much harder work than shining a collection of colored lights in the same spot.  But everyone, from the CIO to the content owner, needs to stop thinking about adoption as if it's something that can be affected in a vacuum.  It is the result of all the other efforts you make. 

And your efforts within your organization will be different from others - the mix of colors will almost never be the same from one to another (but that's an article for another time - Why Intranets Are Like Snowflakes):

Photo:  Geoffrey Drake-Brockman, Optobot, Detail

So if you're struggling with the adoption of your intranet sites or applications, remember that it can only exist as the result of a mix.

And for those of you who prefer a more retro look and feel, I reversed the time-honored prism poster and envisioned the mix as follows (click to see full size). 

Quick strategy briefing for project managers - tell the CIO that you're the prism.  ;)

Original photo source: Brittanica.com

Six (additional) Worst Practices for SharePoint

This is broken, originally uploaded by Lodigs.

I recently saw that Ben Curry (of Mindsharp and the SharePoint Best Practices Conference) has a list of the Top 10 Administrative Bad Practices for SharePoint. I definitely agree with his choices.

The SharePoint Practice team at my company has been keeping our own list of Worst Practices for SharePoint, and I'd like to take this opportunity to expand on Ben's list and add a few that we have seen over the years.

Please note - this appears to be a list of recommendations; IT IS NOT.

1. Give all your power users and content owners Full Control.
When you can't decide which level of rights to give to your content owners (for example, those individuals who will need to create new metadata categories and build new lists and libraries as well as contribute content to a site), you can be confident that Full Control will give them all the rights they need, but there is a better way. Manage Hierarchy is often an acceptable level of security, which will let those power users do more than contribute, but not do irreversible damage to the site.

2. Don't use metadata to categorize documents or databases; just create a new folder, list or library every time you need a category.
While there are often reasons to create new lists and libraries to segregate content, and there can even be good reasons to use folders within a list or library, this shouldn't be your default content management model. This Worst Practice is related to Number Three:

3. Don't use metadata to categorize documents; just put all the information in the filename field.
Companies with document naming conventions are often used to long filenames that give a lot of information about the document. By using metadata instead, SharePoint (and similar content management systems) can free you from the need to keep all the information in the filename, and provide greater power for filtering and finding documents.

4. Use your old legacy servers for your new SharePoint implementation.
You're not sure if SharePoint is the right product for you, so you'd like to give it a test-drive without making a big investment in hardware.  Unfortunately, what we've seen many times is that running SharePoint on underpowered servers and forcing it to share space with other legacy applications may not give you an accurate test-drive of the product, and in fact could cost a significant amount in terms of time spent troubleshooting.

5. Don't set up any test user accounts.
When you're building out SharePoint, you're most likely logged in with the powerful permissions of a farm administrator, site collection administrator, or site collection owner with Full Control.  As you prepare for launch, moving around the site and testing functionality, you can see and do everything you need to.  Your end-users with Read and/or Contribute rights may have a very different experience - and you don't want to hear this from them on the day of launch.  Create, at the very least, one end-user test account, so that you can log in and out as needed to test your site.  Ideally you would create one for every location, department, or high-level user role, especially if you're using features like Audience Targeting, so you can really see what your different user groups see.

6. Use a folder or document library called “Old.”
Like a lighter held aloft at a concert, this practice keeps the spirit of the file share alive in your new SharePoint implementation.  Folders with names like "Old," "DO NOT USE," "Don't Need," and "Blurry Photos" can be a comforting structure for the end-user who's missing that big old P drive on the network.  In a system where content can easily be surfaced by Search rather than by browsing, however, it may not be apparent to the searcher that the likely-looking filename they've turned up is sitting in the "_delete" folder. 

For your long-weekend enjoyment, check out some more Worst Practices in the physical world at the "There I Fixed It" site.

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?

Issues with Manage Content and Structure Move / Copy functions in MOSS 2007

I like the convenience of using Manage Content and Structure to move batches of files from one document library to another, while maintaining their metadata (custom fields as well as metadata like "modified by" are brought over from the source library to the target library).

However, I have been seeing some strange and concerning results, mostly having to do with content types.  In a recent example, I had a library of documents with a yes/no checkbox to allow for displaying certain of the documents in a view on the home page.  Another library needed to be merged in with this one, which had the same yes/no checkbox (same column name).  I recommended that my client move the files from one library to another using Manage Content and Structure.  After she did this, she reported that the documents from the merged library were not apperaing on the home page view even though she had checked "Yes."

When I looked more closely at the document library, I saw that there were now two identical fields for the yes/no choice in the same document library.  SharePoint had copied one over and kept the original - and the values were different in each field.  (In the field properties, I saw that the system had appended "0" to one of the column names on the back-end.)

In this case, it was a simple matter of making sure all the data matched from one column to another, and then deleting the duplicate column.  But in some cases (e.g., when the Move function added the "Publishing Start Date" and "Publishing End Date" fields to a document library) I've had to switch on "Allow management of content types" and hide the extra fields that were added during the move process so that my end-users wouldn't be confused by the newly-added fields.

Consider this a word of warning - Manage Content and Structure may beat Explorer View in terms of convenience and speed when moving batches of files, but it can cause unintended outcomes that could take you more time to troubleshoot and fix in the long run.

MOSS 2007 folks - If you're using the Site Directory web, put an alert on your Sites list!

I'm at a client site today, finishing up a MOSS 2007 intranet for launch this week.  I just viewed the Categories tab on the client's Site Directory when logged in as an end-user.  We customized the categories to reflect the organization, and filled them out with links for each division.  As an admin I can see five links under a particular division, however the end user could not see any of them. 

The Sites list (which can be found under the Site Directory tab, by choosing View All Site Content) can be manually built to include links either inside or outside your intranet, but also receives automatic entries anytime someone creates a site and checks "List this new site in the site directory." 

 

These entries go into a "Pending" state even if they're created by an admin (which could be defined as in the "Owners" group, and/or having Full Control rights over the site, and/or a Site Collection Adminstrator). The result is that only admins can see the Pending links. If there are content owners with Manage Hierarchy rights who are out there creating sites, the admins have no way of knowing when new links have been added to the Sites list.  The Site Directory is being populated but none of the end users will be able to see the additions. 

To ensure that your Site Directory is up-to-date and useful, set an alert on the Sites list to notify at least one of your site administrators when a new link is added.  This seems like simple common sense, but my thought in posting this is that if it hasn't occurred to me in 2+ years of working with MOSS 2007, there's a chance that others have missed it as well.

Site Column Best Practices - whether to use a list lookup or choice field

The question came up this week of whether it's preferable to use a lookup or choice field for storing data within a site column.

I don't have a definitive recommendation, but I can offer some pros and cons, gleaned from various sources:

• A list lookup will let you delegate management of the master list to an end user simply by giving them elevated rights to the list; to manage a site column you must be a site collection administrator.

• A list lookup will allow approvals for selection choice changes, and will allow audit trails (great point by Nadeem as a comment to this post).  There is no tracking or approval workflow for changing the choices in a choice column.

• A list lookup can't be used as part of a formula in a calculated field. (from the Stump the Panel forum on End User SharePoint)

• A list lookup can't be accessed in "edit in datasheet" mode, which means that a look up value should probably not be a required field or there’s no possibility of a “bulk edit.”  (from Sue Hanley)

• A choice field won't maintain referential integrity if changed, and a lookup will (?)  (from Real World SharePoint Experiences by John Powell - I haven't tested this.)

• A list lookup will render the data in the field as a hyperlink, which users could click through to see the master list record (this may be good, bad, or neutral depending on your data) (from this thread on SharePoint University)

• A list lookup lets you add additional metadata fields about the list item (from Mark Miller on this thread on End User SharePoint)

• If looking up to a document library, the document name field is not available for lookup (from a comment on this thread on End User SharePoint)

• You can't filter or sort a lookup field so that the column displays the data in your desired order.  It orders by ID, so your choices can't display alphabetically.  One user on this thread on End User SharePoint (comment #57) says it is possible to install a custom field type "view filtered lookup" which will do this, but I have not tested this.  With a choice field in a site column, you can alphabetize the data or sort it whichever way you like.

To Note:

I checked the SharePoint Server 2007 Best Practices book by Ben Curry and Bill English, and it did not contain any additional information on the subject.

This question was posted to the Experts Exchange, but the approved answer bascially describes how to implement either of the two options, not much about potential gotchas.  Lame.

If you have any additional pros or cons on this subject, please leave a comment!

File downloaded from sharepoint document library replaces spaces in file name with underscores

I have been noticing for some time now, in several MOSS implementations, that spaces in filenames are replaced with underscores on file download/upload from SharePoint.  I was blaming this on SharePoint SP1, since I started to notice it around the time of that release, however this discussion on MSDN indicates Internet Explorer 7 is the reason.

To see the behavior, find any document in a SharePoint document library with spaces in the filename, or upload one.  Then download the document to your desktop - you can see that the underscores are added in the "Save As" window.

If you are working quickly and not expecting this filename change to happen, you would save the document to your desktop, make edits, and then re-upload it later.  Since you didn't actively change the filename, you would expect the document to save over the original in the document library.  This is the way SharePoint has traditionally worked.  But what you end up with is two copies of the document in the document library. 

 

Disclaimer - I'm sure we can all agree that the best practice in general is to check out / check in your document rather than downloading it to your desktop.  (The underscores are not added during checkin/checkout.)  But what if someone else has the document checked out, and you can't reach them to ask them to check it back in, and you're under pressure to make edits right away?  Or what if you thought you were just taking a copy, but the edits you make on your desktop turn out to be the preferred version?    Or what if you haven't fully tested the offline sync capabilities of MOSS 2007, and you want to be absolutely sure the document is accessible when you're offline?  These and many other real-world situations could lead to this downloaded-file scenario, which could lead to multiple copies of the same or similar documents in your SharePoint environment, which is exactly what most of us are trying to avoid. 

The MSDN thread proposes a workaround, although I will argue that the adding of underscores is not necessarily a bad thing, expecially since SharePoint can cause problems when working with filenames that include spaces.  I think it's important to be aware of this download behavior and to work toward minimizing the multiple-copies effect - emphasize checkin/checkout vs. download in end-user training sessions, for example.

Best Practice - do not use dash or hyphen in SharePoint system account / server farm account name

We recently saw an issue at a client site where the client chose to use a dash, or hyphen, in the name for the server farm account (a.k.a. the database access account, a.k.a. the System Account) - e.g. "moss-admin."  The account worked until our infrastructure expert tried to create the Shared Service Provider - it hung for over 10 minutes, and when he checked the event log he found it flooded with errors to the effect that the user could not be found in the domain.  Once they went back and changed the account name to remove the dash, they were able to create the SSP without any issues.  Going forward we are recommending that as a best practice, you should not use any special characters (e.g. \ / : * ? " < > | # { } % ~ & - _ . , ) in the server farm account name.