Thursday, May 8, 2008

Trying to sell Web2.0 to C-level execs

The company I work for started planning a document management system about four years ago, two years before I started there. At about that time people started talking about Web 2.0. Unfortunately since the project was started before wide spread adoption of the term and concepts of Web 2.0, those ideas were not incorporated into the scope of the project.

There were a lot of obstacles that came up which delayed the actual implementation, personnel changes, internal politics, and the biggest obstacle changing platforms for the project. The company first started working with Documentum, spent tons of money, then settled on SharePoint. The SharePoint platform was rolled out about a year ago.

For the last year all we have been using SharePoint for has been as a fancy file server. Some of the criticism I have seen about SharePoint calling it FileServer 2.0 would fit how limited our use has been. Managers and some users believed that emailing a document back and forth with track changes turned on was collaborating.

Finally we have started to look at some of the collaboration features of SharePoint and setting up sites with many collaboration features enabled for users to share data and work together in more efficient manner. The developers got together with some stake holders and some of our early adopters and came up with the features they wanted and that would have the biggest impact on their work. A large number of the features requested and added were ways to eliminate data that was kept in multiple spreadsheets. Email enabled lists, group calendars and RSS feeds were also popular. The fact that each individual could customize the way the page looked to fit their work style was a HUGE selling point.

Well, that point was immediately attacked by the executive team. When we first started to show them the sites the website team had developed, the first thing they said was that we had to lock each site down so that they all looked exactly the same. Huh?!

Now, I am a former security guy and am usually all about taking permissions from users. But this is going to be counter productive. People are now used to working on Web2.0-y sites where they can customize the pages they are working on. We aren't talking giving users administrative rights on pages. They arent going to have access to the backend database. We just want to give them the ability to close features they don't like, move them around on the page, change the display options of lists.

After the first meeting where were told we had to deny users the ability to make any changes, most users in the pilot program said that this was going to be something that kept them from using the sites as their main project management tool. They would go back to emailing documents back and forth, saving their own versions of spreadsheets, and even worse saving files locally on their hard drives.

I still hold out hope that we can convince management to get with the 2.0 times and let us enable the level of cutomization that is available to most people on the WWW today.

Anyone else deal with a similar issue? Or enabling Web2.0 type features in corporate web aps?

2 comments:

Jon said...

Ouch. I've run into that problem; but only in much smaller organizations where it's possible to (usually) do an end-run around management to create a working, popular tool and worry about "top-down" adoption after the bottom-up side's taken care of. Best of luck!

Kevin Shea said...

I would be interested to know the size of the company and whether the management was corporate or divisional.

Was the staff already using a collaborative app before using SP? do you consider SP to be web2.0?

The following is based on a Documentum deployment in a rather large industrial firm.

The issue seems to originate from the approach used to sell the idea, and may stem from a misunderstanding of the culture of the organization. The bottom up sell may have been viewed as an attack by some management and as such, a more refined up sell approach based on defining benefits and ROI may be in line.

The idea of everything the same, may reflect a desire to maintain some form of structure and using the structure to manage quality and process repeatability. My experience is that if left up to the staff then the result could be multiple different approaches seeking to solve the same issue. Bottoms-up often reflects the current modus operandi and may be indicative of "why things are going wrong now".

In my experience you can set up and lock in the structure, focus on the top level only, and still offer flexibility to the users.

Getting management buy-in is often identified as a key to long term success in collaboration deployments. It sounds you your case that the customer may be management and not necessarily staff.

Lastly, it sounds like your management does not subscribe to an open emergence model and may wish to see deployment under a contolled emergence model.

Kevin