C3 Associates Inc.

In Part 1 of this post I talked about the roles and responsibilities that make up an ECM program team. In this edition I will share some sample organization structures and discuss some considerations when creating an ECM team within your organization.

As before, you will need to take the elements of these structures and weigh what will work within your organizational context. My hope is that you will be able to use some of the elements of these structures when creating an ECM organization for yourself.

The following three structures are scaled for small, mid-sized and large organizations. Again, these are not the only possible options but I have found that our clients have had success implementing ECM using structures similar to these.

Click here for a larger image

The most important aspect of this particular structure is that the ECM group is not part of the IT department, Legal group or even an administrative or business services group. This organization has chosen to align ECM with overall business operations in a group called Technical Operations and Competence. This division is responsible for helping the organization achieve operational excellence across their core business, and includes such functions as Engineering Standards, Maintenance and Reliability, Environment, Health and Safety (EHS), Training and Development, and, finally, the ECM function.

The concept of moving ECM out from under IT applies equally to smaller organizations although there does need to be a certain level of scale to justify moving ECM into it’s own area. One key benefit of this model is that the ECM team is able to focus exclusively on the business benefits of content management and not get caught up in the minutiae of IT systems operation. This is not to say that the technology aspects or ECM are not important; as I said last time the best ECM solutions come from open conversations with your technical team. However, the root cause of many failed ECM implementations is an over-emphasis on the technology and not enough focus on the business problems ECM will address.

You have likely noticed that this structure doesn’t reference an executive steering committee. That is indeed a shortcoming of this particular structure, although this is offset somewhat by the fact that the team reports into a Vice President. Also, there was an executive steering committee in the initial project phase of this particular ECM program but as the ECM team transitioned to an operational mode it was decided that reporting to a single VP was sufficient to ensure business alignment.

Click here for a larger image

This organization shares many of the structures used by the larger organization but the key difference is that this group reports into IT (although the overall program is guided by an executive steering committee to ensure proper business alignment).

The other important aspect of this structure is that the core ECM roles report into a Director of Information Management, who has a dotted line relationship with the technical personnel responsible for ECM development and day to day operations. Again, I believe this separation of business alignment and technical execution is important to ensure that the ECM solutions continually focus on providing business value.

Click here for a larger image

This organization has a small but mighty ECM team and again reports into the IT function. The fundamental ECM roles have been collapsed down into a smaller group but note that there is a specific role focused on Change Management. This was the topic of the comments posted in response to Part 1 of this blog, with one person going to far as to suggest that the acronym ECM should stand for Enterprise Change Management.

I won’t go that far but I do agree that one of the keys to any successful ECM program is to ensure that your user community is ready, willing and able to adopt ECM-based business processes.

Finally, there is a shared accountability for managing the tasks of the ECM Operations (and development) team between the IT Manager and the ECM Program Manager. They report directly to the IT Manager but have a dotted line relationship to the ECM Program Manager to ensure they are engaged in meeting the business objectives and strategies set out by the ECM team.

I hope you have found these posts to be useful. I welcome your comments and would be happy to share further observations and experiences in the comments section or directly. You can drop me a note on Twitter @GregClarkC3 or send me an email at greg.clark@c3associates.com.

The last post on my AIIM blog generated a lot of very good feedback about whether it is ever okay to maintain two separate repositories, one for collaborative content and one for records. This proved very helpful as I put together some recommendations about this topic for a client. One very nice thing about the blogosphere is that I have the choice as to whether or not I take a stand on an issue; in this case I decided to walk a fine line and look at both sides of the issue. Unfortunately, one doesn’t have that luxury in client work. I needed to make a recommendation and that meant taking a stand.

And my stand is this: I believe we shouldn’t give up on the information lifecycle.

Although it is tempting to think that by using separate systems, one for “collaboration” and one for “records” we can remove the burden on end users from worrying about how to classify a document, I believe this is false economy.

The risks of separating collaborative and records content can be high. Having a formal records platform for only final records leaves the very good question of what becomes of all the drafts and versions that led to the document becoming final. I’m no lawyer, but I can tell you that in any discovery process you will be asked for the draft and work in progress documents even if you have legitimately disposed of your “record” copy.

I agree with those who commented that we can’t always achieve perfection. My post from last month speaks to this and I definitely stand by the fact that we can’t let the perfect be the enemy of the good.

I believe we can have “good” even while not losing sight of the information lifecycle. Although those words may scare some people, information lifecycle management doesn’t necessarily equate to a lot of overhead. In fact, proper information lifecycle management should mean LESS overhead.

The term I’ve used in the past is “subversive” RM. By this I mean end users don’t know (and probably don’t care) about when something is declared a record or what the classification is. This can be achieved relatively easily by using simple metadata inheritance at the container level.

I advocate a big bucket approach instead of a big budget approach. Wherever possible consider creating a retention schedule based on retention period instead of content type. This means that users likely won’t be able to use retention as a search item but let’s face it, most users don’t use records classifications as search terms anyway.

At the end of the day it comes down to business value and risk. Every ECM project should focus on maximizing business value while minimizing risk. Clearly it can be a challenge to rationalize these two things but in my next post I will address strategies for creating an ECM organization structure that can help resolve these questions and help you achieve your content management goals.

Most conversations about enterprise information or records management  these days seem to involve SharePoint in one way or another.  Many organizations are finding that information management is not meeting their expectations and some are wondering if SharePoint 2010 as the answer to all of their problems.  Whether this push is coming from IT hoping to reduce costs, your portal team hoping for a new intranet or your user community hoping that that SharePoint will be easier to  use (or all of the above), there can be no doubt that many organizations are considering a move to SharePoint.

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.

Not many people have heard of Duncan Stanners. Forget Twitter, LinkedIn and Facebook, Duncan was quietly plying his craft when the internet was but a twinkle in the DoD's eye. But make no mistake, Duncan Stanners has had the kind of success implementing knowledge management programs that most of us can only dream about. 

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.

I am often asked where I think the Records and Information Management function should exist within a company’s org chart. This question usually comes up in the context of a frustrated practitioner who is having a difficult time getting traction for their ECM program or from business users how are frustrated at being told by IT, RM or someone else that they need to manage their information in a certain way that may not be immediately intuitive to them, or does not support their business processes.

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.