Microsoft has done a great job of driving this conversation through the functional improvements in SharePoint 2010 and also through some aggressive and effective marketing, but is SharePoint the answer for all of your content management needs? 

Here are eight things to think about if you are thinking about migrating your records and information management platform to SharePoint.

1. Customizations, system integrations and modules.  Most implementations involve at least some customization, and most include a variety of vendor or third party modules.  Because of this, considering a move to SharePoint is not a simply a matter of copying over your content.  You will need to think about whether SharePoint has equivalent or "good enough" functionality to replace these customizations, integrations or modules without breaking your business processes.  If not, you will need to think about the costs to rebuild an integration, re-buy a particular module (if it is even available for SharePoint) or change your business process. None of these things should be taken lightly and there can be a significant effort associated with each. 
2. How important is records management and compliance?  Yes, SharePoint 2010 has records management capabilities but this is relatively new within the application and there is a great deal of debate about whether SharePoint RM will truly meet your needs (James Lappin feels there are significant shortcomings in SharePoint records management, Mike Alsup disagrees).   This is a decision you will need to make in consultation with your content owners, legal team and regulatory compliance group.
3. Business drivers. It is important to consider why  you want to move to SharePoint. Cost savings? Usability? Spite? Okay, scratch that last one. As with any decision you need to think through your business case ahead of time. What is the value proposition for moving so SharePoint vs.  the cost of continuing to use your other system?  Is it feasible to integrate the two systems?  It is important to consider all of the potential benefits and pitfalls, efficiencies and costs for swapping out your system.  Try to be as realistic as possible and quantify both the costs and benefits; I find a good place to start is a simple SWOT analysis.  Once you have an understanding of what you hope to achieve, build measurable objectives and create key performance indicators (KPIs) to track your progress.  This is a standard process for the analysis and execution of any business decision but it never ceases to amaze me how often emotion comes into the picture when considering SharePoint.
4. Does your platform speak the same language as SharePoint?  SharePoint works in a certain way; sites are contained within site collections and everything can be tied together with custom metadata columns and content types. There is a large and growing list of add-on modules available.  SharePoint is considered by many to be a development platform and SharePoint also has some intriguing social, portal and business intelligence capabilities.   You need to consider the use cases and information architecture of your current system and determine how closely you want to replicate that system. More importantly, you need to decide whether SharePoint will let you or whether you will be under-utilizing the functionality of the tool if you try to copy your existing system too closely.
5. Content migration is no fun.  Once you've figured out how you will map your existing system to SharePoint you will need to plan the migration itself.  You will need to make decisions about which groups go first (it is unlikely that you will be able to do a "big-bang" migration) and about whether you bring across all document versions or just the latest ones (this will likely vary by group). How will you handle content from departed users?  What about URLs linked between documents and to other places? How about your security model? Who will update your information governance policies and practices? (You dohave information governance policies and practices in place, right?  If not, see here for a primer on the importance and challenges of implementing information governance).
6. Pick the right project team.  This is not, Irepeat notan IT project.  Managing user impact and business process change will be the biggest job for your project team.  Finding a team with strong information management skills is critical as they will understand the specifics of how information needs to be mapped between the two systems. At the same time, you will nee strong business sponsorship to provide guidance, set priorities and give you an escalation point when the going gets tough.
7. Are you ready to get social?   If information wants to be free (and it does), information really wants to be free in SharePoint.  SharePoint started life as a collaboration tool and although it now has a powerful security model, the system works best when most information is available to most people. You need to consider what capabilities the average end user will have; what will people be able to do with their My Sites? Can everyone blog? Who can create a new list, library or team site?  These are fundamental questions of SharePoint governance but be careful not to lock the system down too much. And these considerations are much more than just technical; there are cultural questions that need to be considered as well. This is true of any information management system but is especially important when working with SharePoint.  
8. Infrastructure. Are you a Microsoft shop? How up to date is your SQL Server environment? Do you have some 64 bit servers kicking around? What about Active Directory? Which version of MS Office are you running? The specific requirements for SharePoint 2010 can be found here: http://technet.microsoft.com/en-us/library/cc262485.aspx.  Although these are fairly high-end specs it really isn't out of the ordinary by today's standards. At the same time most organizations will likely need to upgrade at least some components. You will also need to consider how you will do the content migrations themselves. You will need a test environment to bring across the data and may need a tool to extract, transform and load the documents and metadata from your legacy system as well. 

The bottom line is that the benefits of moving to SharePoint are not automatic and may not be there at all.  Many of my clients are taking a hybrid approach; adding SharePoint on top of their existing information management platform.  Management of this hybrid solution begs many more questions, but may be a part-way solution if your organization is considering a move away from your current platform to SharePoint.  If you do decide to migrate, it is important to recognize that it will very likely be a long and complicated process.  Before you commit, it is critical to understand why, when and how you will complete the migration.

Duncan recently retired after 20+ years of service at Shell Canada  (which is now wholly owned by Royal Dutch Shell) and I recently had the privilege of joining him and several of our peers in the Calgary knowledge and information management community at a retirement luncheon in Duncan's honour.  In the true spirit of knowledge management, Duncan shared some of the lessons he learned from the successes and challenges he faced over the years. The summary below was shared in the context of implementing a knowledge management program but it applies equally to any RM, ECM or information management program as well. 

1. Go where the energy is. Duncan suggests that while there may be many opportunities to make a big impact with your initial implementation efforts, don't try to boil the ocean. When choosing where to focus, find the group with the most enthusiasm for your project, pick a problem and solve it. This not only builds goodwill with the folks whose problem you've solved, it also builds momentum and a positive reputation for your program team. 
    
2. If you can't find energy, create it.  This is easier said than done but by focusing on the value your program will bring their area of the business and to them as individuals you will gain their trust and enthusiasm.  Again, find a problem and solve it.
    
3. When talking to customers, don't talk about KM (or RM, IM or ECM), talk about their business.  This helps build trust and shows that you are there to help them solve business problems. It also has the handy side effect of helping your learn more about their slice of the organizational pie, which helps you apply your expertise in ways that are specific to their business context.
    
4. If you can't create a hard-dollar ROI, focus on real risks. There is seldom a conversation about information management that doesn't at some point come back to the question of value for money (and nor should there be).  But hard-dollar saving s from de-duplicating the shared drive and improving information access do not always offset the initial costs of your program. However, a risk-based approach that uses hard cost measures based on things that have actually happened will help make your case. Sell your program on the same basis that you sell a safety initiative; the benefits of working more safely are irrefutable , and once they understand the similarities between the two they will be supportive.
    
5. "You're already doing knowledge management. You're just doing it badly".  Duncan's point is that most groups within your organization are already doing knowledge management (or records, information or content management) but because they are using ineffective processes they are not managing their knowledge or information well.  Your job as an expert is to help guide them through the process to managing that knowledge or information better. Duncan suggests that you find cases where you have successful practices and repeat these until you succeed.
    
6. Tools won't sell the thing.  At best, tools and technology can facilitate adoption and at worst they can constrain it, but the best tool in the world will not help if you are not helping real-world business users solve real-world business problems.

The first question to ask is whether it really matters. Shouldn’t a first class Records and Information Management (IM) program succeed by virtue of its own momentum and the value it creates irrespective of what the boxes on the org chart say? In a perfect world that would be true, but unfortunately we don’t live in a perfect world (if you need proof see my earlier post about the Calgary Flames missing the playoffs).

So where should the Records and Information Management function live? Not in IT, at least not in most cases.

Notwithstanding the fact that the “I” in “IT” stands for “Information”, the mandate of most IT organizations is to keep servers running and to manage vendor relationships. I know that many, if not most IT professionals are truly dedicated to helping their customers manage their business more efficiently, but at the end of the day the great majority of IT organizations are not set up to accommodate the challenges of managing information well.

And these challenges are many. Perhaps the most important comes from the fact that Information Management implementations do not have a natural beginning, middle and end. Information Management is an ongoing process that evolves and changes over time to support changing business requirements and the needs of their user community. Information Management is not a project and it certainly is not a technology deployment.

IT groups on the other hand generally operate a project management office tasked with standing up servers, upgrading software and rolling out new technologies. Each of these tasks fit well with a traditional “waterfall” project management methodology that expects right and wrong answers along the way. Information Management on the other hand is more art than science. Yes, it is critical that IM projects are managed properly and that appropriate controls are in place to ensure the implementation stays on track, but the key aspects of IM projects are people and process rather than technology. Change management is critically important and, let’s face it, most IT organizations are not adept at the people side of change.

That leaves the question of where the Records and IM function should live within your organization. In my experience there are three good answers depending on the makeup and business challenges of your organization.

1) If you are in a heavily regulated industry or are likely to face more than your fair share of lawsuits you likely want to align your IM program closely with your corporate legal group, reporting in to chief legal counsel.

2) If your objectives are to enhance operational efficiency or improve the bottom line of your business by managing your information better, align your IM program with an operational support area or even a strategic marketing or R&D group.

3) Finally, if you are in a situation where the only logical spot is within IT, try to ensure that you carve out the IM function from the other core teams in the IT group. One of my clients appointed a Director of Information Management a s a direct report of the CIO, which made her a peer of the more traditional IT roles of Infrastructure and Application support and gave her a seat at the table to advocate for IM.

In the end, when push comes to shove the core mandate of each part of your organization will ultimately prevail. In the case of IT, generally speaking their mandate is to keep the servers running and as a result the processes and political power tends to support this objective. Many IT groups can walk and chew gum at the same time but if they start to stumble they’ll spit out the gum before they fall over. Placing IM in a part of your organization where it can fulfil its mandate is one of the first steps on the road to success.

Cross-posted to the AIIM ERM Community blog.

Much of this has to do with organizational culture and the fit of a particular ECM strategy to the business problems faced by a given organization. Readiness is key as are executive buy-in and a well-chosen and well-implemented tool. But these things can be said for pretty much any software application; if the bosses aren’t onside and a good change management strategy isn’t in place, the implementation will fail.

Jeetu Patel of Doculabs recently summarized his perspective on why ECM implementations have high falure rates and what you can do about it on John Mancini’s Digital Landfill blog. I highly recommend you read the post and watch the associated slide show. I’m hopeful that my post is complementary to Jeetu’s perspectives.

So what is it that makes information and records management implementations so special? What challenges do these implementations present that other systems do not? In my mind, there are two big differences;

1.Information Management hits people where they live, for better or worse. At best, records and information management are tied in with business processes and improves them to the point where users can’t believe they ever lived without proper RM / IM and ECM tools. For example, scanning invoices and initiating an automated Accounts Payable workflow process will make any approving manager wonder why they ever thought hand-coding invoices and routing them in multicoloured folders was a good idea. Same for users of Business Process Management applications like insurance claims processing or engineers using a GIS map integrated with a document repository. On the flip side, ECM asks users to change deeply ingrained work habits. Most of us have been using “File / Save as…” then navigating 10 folders deep on a shared drive for as long as we can remember. While most users don’t like storing documents on their shared drives (often lovingly called the “S: mess”), most will take this over a different structure imposed by an ECM system any day (even when you can prove that it’s actually less work to store documents in the ECM system!). Add to this the complexity that many organizations add by expecting their user community to remember a complex records classifications scheme or other detailed metadata and you have a recipe for failure.

2.The other big difference with ECM tools is that they are largely optional. An accountant may not like the way the new ERP system works, but she doesn’t have much of a choice when creating quarterly financial statements. ECM systems, while core to many business processes, can often be worked around by users who insist on storing documents on local drives or USB keys. This isn’t always the case, but it crops up most often when phasing out shared drives with ECM systems and is related to the work habits noted above.

In my next post I’ll talk about what you, the budding ECM deployment guru, can do to overcome these challenges and give your implementation the best chance for success.

Cross posted to the AIIM ERM Communities blog.

1. If you want to start a debate in the enterprise content management (ECM) community mention SharePoint, and;
2. I’m really bad at predictions.

Evidence for point #1 is all over ECM blogs, countless conversations at conferences like AIIM and ARMA, and countless sleepless nights for traditional ECM vendors as they try to think of ways to fend off Microsoft. As for the second point, let’s just say that after I picked my Calgary Flames to win the Stanley Cup they missed the playoffs entirely. Nice call on that one.

The purpose of this post is to list some of the reasons why traditional ECM tools might survive (or even thrive) in the face of Microsoft’s full-court-press into the ECM space. I will leave it up to you, my colleagues in the Electronic Records Management (ERM) community, to expand on this list, tell me where you disagree and have a good discussion about the future of Enterprise Content Management. Next week I will make the case why SharePoint might be the future of ECM.

So, here goes.

1. Records Management is not optional. Many organizations wish it was, but it isn’t. Although SharePoint 2007 introduced some records management capabilities and SharePoint 2010 seems to take this to the next level, the critical role records management plays within an organization means it is not something that can or should be done half way. Traditional ECM tools like EMC Documentum, Open Text Content Server (formerly Livelink), Open Text eDocs (formerly Hummingbird), IBM FileNet and open source tools like Alfresco have a several-year head start on Microsoft. This means there is a significant body of best practice built up within the vendor and partner channels associated with each tool. There is a very good chance the issue your organization is dealing with has been seen somewhere else and that you can call on these resources to help get you where you need to go. Can you say that about SharePoint RM? The tool and best practices may eventually develop, but do you want to go first?
2. The vertical is steeper than you think. Whenever a client or colleague would ask whether I thought SharePoint 2007 was a viable replacement for their existing ECM system, it was relatively straightforward to explain why most organizations needed to continue leveraging their existing investments in traditional ECM suites. I summarized some the shortcomings of SharePoint 2007 last year, and have found these points to be a very useful “elevator pitch” when discussing the differences between SharePoint 2007 and traditional ECM suites. Admittedly, this discussion gets as lot more muddled with SharePoint 2010. Many if not all of these points have been addressed in one form or another, except for one very important area; solid, mature solutions in industry verticals. ECM vendors have spent the better part of the past two decades developing, deploying, supporting and improving their solutions for specific industries. Will the life sciences industry trust their complex regulatory approval process to SharePoint any time soon? Will the architecture, engineering and construction industry be able to manage multi-billion dollar projects that generate millions of AutoCAD files and tens of millions of facility tags in SharePoint? Speaking in strictly technical terms it is possible that SharePoint can handle the volumes, but for these use cases and others like them, ECM suites offer mature tools that support complex business processes and as above, the vendor professional services and partner networks have extensive experience in implementing these tools in a variety of industry verticals. Although there is a perception that ECM should primarily focus on replacing shared drives, my suspicion is that most ECM is targeted at solving business problems in core operating areas, and it is in these areas that traditional ECM players hold a significant advantage.
3. A suite of tools from one vendor increases accountability. Whenever someone questions the ability of SharePoint to meet a particular business need using the product as-is out of the box (as is often the case when discussing the vertical business requirements noted above), the response is usually that a Microsoft partner either has or will provide a module that meets this need. While that may be true in many cases, most organizations end up with many different modules from many different vendors. There are a couple of downsides to this; the testing required each time you need to upgrade goes up exponentially and, if and when things do go wrong you will not be able to hold a single vendor to account. This is often referred to as the “one throat to choke” argument (although my friends in the vendor community prefer to call it the “one back to pat” argument). Although the “suite” approach taken by traditional ECM vendors usually means that some of the individual components are not best of breed, the ability to hold a single vendor to account for their product is a significant benefit, and one that SharePoint cannot offer.
4. If Microsoft CRM didn’t kill SAP, why would SharePoint kill traditional ECM? Although there has been a lot of talk about SharePoint overtaking traditional ECM players, why has Microsoft not overtaken SAP in the CRM space? Is there is a case to be made that SharePoint is akin to Microsoft’s CRM offering; a tool targeted at the mid-market, mass-market space but not really suitable for true enterprise deployment?

I hope these questions provide a good starting point for a good discussion about the future of ECM. Next Thursday I will make the case for SharePoint to live up to the hype and change the ECM landscape as we know it.

Until then look forward to your comments.

Cross-posted from my blog on the AIIM ERM Expert User Community.

My big “aha” moment at AIIM came in the speakers ready room. I got to talking with fellow Canadian Lewis Eisen about how to truly measure success when implementing information management. We discussed whether traditional measures of success like the number of documents loaded to the system, number of users, number of searches, etc. are really all that valuable. The short answer for both of us was a resounding no. These measures are peripheral at best, sort of like saying “It always rains when I go to Philadelphia for the AIIM conference, therefore I make it rain in Philadelphia”.

So what metrics and measures are valuable? The answer to that question is another question; what is the mission for your organization? The main point of my AIIM presentation this year (”What Success Looks Like – The Anatomy of a Successful ECM Implementation“) was that there is nothing inherently valuable about an ECM implementation (at this point you’re wondering why I’m blogging about ECM…bear with me, there’s a point here).

There is little doubt most organizations are dealing serious information overload problems and these problems are impacting their ability to succeed, but setting out simply to fix an information management problem without considering the broader objectives of your organization is a recipe for failure. Many (or perhaps most) ECM projects started out as IT-driven initiatives. Measuring the success of a project by the amount of content loaded to the system in the first year, or counting the number of users who have been trained, or even counting the number of new versions added by users will not tell you whether the system is a success or not.

To truly measure success you first must establish key performance indicators (KPIs) for ECM. While that hardly ranks as the most earth-shattering bit of news you are likely to hear this week, it is amazing how often this basic principle is missed when implementing ECM. KPIs must measure outcomes that are important to the bottom line of your entire organization, not just your IT department.

For example, if you are a sales-focused organization develop metrics within your ECM program that measure the impact on sales. The impact on the sales cycle from implementing good information management practices within the sales group is a good KPI (note: the amount of time it takes to find current sales collateral is not a valid measure; the amount of time it takes to convert prospects into clients is). This is obviously not a simple task and requires very close alignment with leadership in this part of the organization, and that’s really the point. If your ECM team is close enough to identify and measure KPIs within a business unit, your ability to design information architectures and work practices that support business objectives will increase exponentially.

The last, and possibly most critical point is that you need to be committed to continually monitoring, reporting and evolving your KPIs. This continual improvement review should be formalized to be at least an annual process or perhaps even more often if you have met your objectives and need to set new targets (or equally important if you have not met your objectives).

I am certainly interested in hearing about your experiences creating and measuring KPIs for ECM so please feel free to share your comments below.

Cross-posted from my blog on the AIIM ERM Expert User Community.

Scratch that. I want to make the world safe for records managers. Why? Because they don’t seem to get the respect they deserve and in most cases, neither does the information they help manage.

Based on the fact that you’re reading this blog I’m sure you agree organizations should work hard to manage information well. Certainly most have taken a crack at it with varying degrees of success but regardless of their efforts we can usually predict which parts of our organizations will succeed or fail based on their organizational mission in life. For example:

• If I’m in accounting I can usually dig up an invoice from a few years back if I really need to
• If I’m in legal I can usually find a contract (or at least sheepishly call the company we contracted with to get a copy)
• If I’m in marketing I usually wonder where the he*l that file went

I’m generalizing to make the point that many organizations have failed to realize the full benefits of their enterprise information management programs because their efforts to date haven’t been truly enterprise. Information management within many (if not most) organizations has emerged from a series of point solutions deployed to individual departments, often on different platforms.

So what are successful organizations doing right? How do they manage the ever-present tug of war between efficiency and process? How do they get buy-in from senior executives and how do they sustain the momentum of ECM initiatives to ensure they stay relevant?

The answer is deceptively simple; they evolve. They move beyond managing records as valuable in their own right to governing information as a true asset of their organization. Easy to say, hard to do. Organizations that successfully navigate this transition usually do so because they establish strong information governance practices.

What’s the difference between records management and information governance? In my opinion:

• Records management is static where information governance is dynamic
• Records management is reactive where information governance is proactive
• Records management is focused on the retention schedule where information governance is focused on enabling the business to get their work done

I am most definitely not saying that records management is not important (some of my best friends are records managers…). Organizations that successfully manage information across the enterprise (and this information includes records) realize that information is only valuable if it helps advance the cause of your organization. In the case of highly regulated industries or those with a high litigation risk there will be a strong focus on creating hard-and-fast rules for information retention and disposition. The challenge that most organizations face is that this is where enterprise information management begins and ends.

Organizations with a focus on information governance realize the importance of creating a living model that puts appropriate structures in place to enable users to manage information appropriately. This means a risk-based approach to records retention, but frankly there’s nothing especially new or unique about that. What is unique are those organizations that establish mechanisms to efficiently support the changing information management needs of their users. According to IDC individuals (rather than transactional systems) create 70% of the information in organizations; this means organizations that provide simple, intuitive and, most importantly, flexible information management structures will be the ones that succeed.

Information management structures (a folder hierarchy, metadata model, line-of-business integration, or custom interface) must make sense to the end users and fit easily into the flow of their work. This is no easy task and is only made more difficult when there is an overemphasis on command-and-control governance structures.

My advice to records managers and information management practitioners everywhere is to focus on a thin layer of standardization, then provide “guidelines” and “principles” for managing information rather than hard and fast “must do” policies. Users are much more likely to follow good practices for managing information if they feel they have some flexibility to do it on their own terms. Yes, there is still a need for certain information to be managed with more rigour, but my challenge to the records managers of the world is to find ways to empower your users to manage information rather than taking a one-size-fits-all approach. A little freedom might just be what your information, and your users, need.

You can download both slide decks in the Presentations section of our site.

You can find a copy of the presentation here.

Day 2 Summary

The day started with a series of keynote speeches. The most interesting was from Andrew Lippman, founding director of the MIT Media Laboratory. He talked about the “cracks” forming in institutions (he used banks as an example, but says the example can apply to many / most organizations) as a result of four things:

1) Inability to scale – Things that work well when an organization is small don’t usually work well when they get too big. Ethics comes to mind here.

2) Monocultures – Tribes of political beasts roam through most large organizations limiting its ability to thrive.

3) Opacity – Because of the first two points, it becomes difficult to understand exactly what’s going and innovation tends to be stifled.

4) Blurred mission – Organizations forget why they existed in the first place and start to exist only to sustain themselves.

His solution to these issues is “living content” generated by networks of people working from a common platform to build what they need. He suggested that building applications that constrain users to work a certain way is outdated and will be eclipsed by (social) networks and common platforms.

Extending this to an ECM example, I see this broadly as the approach Microsoft has taken with MOSS; although it is a proprietary server-based application its extensibility has attracted a large developer community who are busily building custom Web Parts that integrate nicely into the SharePoint platform. Although traditional ECM vendors have a similar model, theirs is closed and limited only to official partners whereas anyone with some .NET skills can spin up a web part and get to work.

The open source folks may disagree with me that SharePoint is a true platform but it is certainly more so than the traditional ECM applications on offer. This is not the death knell for traditional ECM but more of a shot across the bow that they too will likely need to open up to survive in the brave new networked world.

Enough thinking and more drinking! I’m off to the pub to talk ECM (or not) with my conference colleagues. As always, comments are welcome.

My presentation stimulated a lot of interesting discussion (well, interesting if you’re a PM or ECM enthusiast). Here’s a link to the presentation. Questions or comments are welcome.