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.

But first, a caveat. The roles as well as the org structures I will discuss next time are intended to be a starting point. We don't live in a perfect world (at least I don't, not so sure about you…) and we can't always count on creating the ideal organizational structure. Existing structures, HR policies, sponsorship issues and other organizational dynamics can get in the way.  My goal is to give you a guideline based on my experience with what works.

And one final point. Although many of the roles listed below are called "teams" this can often be one person or multiple roles can be performed by a single person, depending on the scale of your organization, your budget and your ECM program.  Again, this is a guideline to help you develop a structure that works best for you and your organization.

Steering Committee

The role of the steering committee is akin to that of the Board of Directors of a company; they provide high-level direction for the activities of the ECM program and sign off on major program deliverables.   The steering committee should be made up of senior executives (ideally C-level executives or, if that isn't feasible in your organization, their direct reports).

Your project sponsor should be a member of your steering committee and should be your go-to person when you need to escalate issues or if you need business guidance. You should have regular meetings with your steering committee. Ideally once a month but no less than quarterly.

Program Manager

The Program Manager  runs the ECM program and is responsible for the initiatives conducted under the ECM banner. This person is ultimately responsible for all deliverables, budgets, timelines and program objectives. Some specific tasks of the program manager include:

• - Drive the creation and execution of the ECM strategy
• - Liaison to the steering committee
• - Manage vendor relationships
• - Hire and manage the ECM team
• - Contribute to or lead the development of an appropriate information architecture
• - Identify, track and act upon key metrics for the ECM program

Project Team

The project team leads the implementation and design of discrete ECM initiatives. This can include document imaging rollouts, shared drive migrations, team site deployments, the creation of new workflows, system upgrades and many other projects.

The core skills on your project team should be a combination of strong project managers and ECM-savvy business analysts. I have often seen these roles combined and this is my preferred structure. Only in very large projects will you require a standalone project manager

Information Governance Team

The information governance team is responsible for the creation and implementation of your ECM governance framework . This includes aligning ECM activities with the relevant corporate policies by creating guidelines, standards and procedures related to ECM.

The information governance team also works closely with the project team to develop and implement metadata standards, taxonomy standards and the overall information architecture for your ECM solution.  They are the "go-to" team for questions about content disposition or exceptions to your ECM principles (for example, when is it okay to copy content rather than link a single document in multiple locations).

And yes, the information governance group also includes the more traditional records management roles. This includes the creation and application of a corporate retention and disposition schedule and can also include the management of a records centre or corporate library.

Change Management Team

This role is responsible for ensuring that your end user community is ready, willing and able to adopt ECM. While this  activity is often rolled into the accountabilities of the projects team, in my experience it is best to have a person or a team dedicated to ensuring the significant changes that can come from an ECM implementation are accounted for. This is often the single biggest cause of ECM project failure. When we consider that the change required to succeed with many core use-cases for ECM (for example, moving from a "File / Save As…" world to the need to add metadata to a simple MS Office document), there is little wonder end users will often rebel.

The change management team works actively with the project teams and the program office to ensure they incorporate good change management practice as part of each project plan.  The information gathered as part of this process is incorporated an overall change management strategy, which identifies the change impact of each ECM activity and ensures that communication, training and support plans  are in place to ease the end user transition to your ECM solution.

Training Team

The training team's role is relatively straightforward; ensure that your user community knows how to use the ECM toolset.  This is often more of an art than a science. My advice is to focus on providing your end users with "one best way" for performing a particular task. Even though the tool likely supports a variety of methods for achieving the same thing, there's nothing more confusing than giving someone three ways to save a document.

The training team should be ECM experts in their own right. Although it can be tempting to repurpose existing trainers to also provide ECM training, the complexities and subtleties of ECM are often lost on people who are not experts. Where this isn't possible, use the ECM experts from your other teams to implement a "train the trainer" approach.

Support Team

Your support team is often made up of members of your projects team, change team or training team (or all the above).  The role of the support team is to provide second-level support to your end user community. They must be ECM experts and should know the nuances of your ECM toolset very well. They will work closely with your help desk and technical team to identify and trend issues, and will help prioritize system fixes or enhancements.

Technical Team

Your technical team is tasked with keeping your ECM system up and running. Despite the complexities of ECM applications, you know this team is successful when it looks easy.  Technical teams generally have development groups, operational / system administration groups and may also have their own infrastructure groups.

It is critical that your technical team have a close working relationship with your all other teams. Although your projects, change, training, governance and support teams should be ECM experts, the best solutions come from open conversations with the technical team.  This will ensure that the implications of any proposed customizations, new modules or other system changes are well understood and communicated to your user community.

Other Roles

We can't forget end users, of course. They're the reason we are doing all of this in the first place. Ensure that you have a good feedback loop through each of your teams so the end user experience is  understood and incorporated into the continuous improvement of your ECM program.

It is also common to have a close relationship between the ECM team and the communications and / or portal team. There groups are often a separate entity, but there is significant overlap in areas like governance and information architecture.

The Role of Consultants

It is important to recognize that consultants or vendor professional services teams can and should play a role in your ECM program. They have the expertise that comes from having implemented ECM in a variety of different organizations and you should be able to take advantage of their knowledge and experience.

However, when working with consultants it is critical to have an employee assigned to shadow the consultant and ultimately take over their role. Although it can be valuable to engage consultants to establish or revamp your ECM program, it can be risky to become too reliant on them.  If your consultants don't want to mentor your employees to eventually replace them, find different consultants. 

I hope this has been a useful guide. Next time I will share some sample ECM organizational structures. In the meantime, I welcome your comments and feedback.

Cross-posted to my AIIM ECM Expert Blog.

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.

But a funny thing happened on the way to ECM nirvana. Both organizations decided to pursue a “parallel” strategy; one system for collaboration and work-in-progress documents and one for “official records” or final versions (often copies) of documents that have completed the collaboration cycle (and yes, the rise of SharePoint plays a part in this decision, but that’s a discussion for another day).

I will freely admit my first reaction was “are you nuts?” After all, as a red-blooded ECM professional my mission in life is to reduce duplication and promote information lifecycle management. But I’m always willing to listen to both sides of any story (and they’re my clients so they’re always right, right?).

On the positive side, establishing a process to manage only final copies of records mirrors the paper world; if an organization has a well-established physical file management system why not try to replicate that in the electronic world? The other benefits are that final versions of documents are more likely to have a natural structure which leads to more intuitive metadata and greater discoverability (at least in theory), and content disposition is simplified because the retention schedule for “official” copies is often easier to determine.

On the other hand, isn’t the point of ECM to manage information through it’s lifecycle? If we are never going to achieve true ECM why do it at all? You also have the problem of costs; the cost to train people to know when to move a document to its final state and to know where to put it can be high; this is especially true if those people don’t attend training or if they do, still choose not to move final copies to the approved location. The alternative is to assume that any documents that need to be moved to an official repository will be managed by administrative personnel. Again, this increases costs and impacts efficiency, both areas ECM is intended to improve. And there are always the potential risks (and risks always translate into costs one way or the other) from duplicate content in multiple systems. This is gravy for lawyers in an eDiscovery process because it creates the possibility of confusion about which version was used to make a decision.

At the end of the day it is difficult to say definitively which is the best approach. Every organization is unique and has its own history, business drivers, processes and rationale for certain courses of action. General ECM best practice would dictate that information is managed through its lifecycle using a single system or at least seamlessly integrated systems, but this isn’t always possible. What I will say is that minimizing duplication and streamlining business processes through good information management usually means managing the information lifecycle. This should be the approach wherever possible and I suspect in most cases this will be the most cost effective approach in the long term.

Ensuring you have a good understanding of the capabilities of your current platform will also help; in many cases the traditional ECM tool may be perceived to have “failed” but in fact meets all of your functional requirements. The other alternative is to look into the possibility of integrating a collaboration platform with a system of record. Even if the truth is both of these platforms are technically capable of managing the information lifecycle, if users perceive that one is better than the other for a particular task you will have more success managing more content, and that’s really what we are trying to achieve.

The participants were a diverse group but there were many records managers in attendance. The session itself was very interactive and we had a great discussion about Microsoft SharePoint and the future of ECM.

One of the most interesting aspects of the discussion was an attitude shift from many, if not all of the records professionals in attendance. In the past I have observed that many RM-led ECM initiatives have focused on the records management aspects of the content to be managed. Often this meant that end users were trained to file their documents into a structure that mirrored the corporate records retention schedule. While this might make perfect sense to records managers, unfortunately most users in your organization are probably not records managers. As a result, many implementations failed to meet user adoption targets because users didn’t feel the structures they were being asked to use fit the context of their regular business day.

I call this the 20/80 approach; 20% of your content is managed perfectly while 80% is scattered across partially-deployed ECM systems, email inboxes and shared drives.

Amongst the records professionals at the AIIM event, however, there was a clear shift in attitude and approach over what I have experienced with similar groups in the past. They strongly believed that building business-focused structures and small-but-mighty metadata models tailored to core business processes was preferable, even at the expense of “perfect” records management. This is the manifestation of what I have long believed; it is better to have 80% of your content under some form of management even if this isn’t perfectly aligned with the retentions schedule. Yes, you still need tighter management of a small portion of critical or high-risk content, but you should never let the perfect be the enemy of the good.

Here are a few common objections I have heard from IT security teams and my responses to each:

1. You’re telling me that everyone gets access to everything? What about HR information or trade secrets or other sensitive information?

   Open by design most definitely does NOT mean that everyone should have access to everything. It’s easy to get stuck on the “open by design” part and forget “closed by exception”. There are most definitely categories of information that will be tightly controlled. Most organizations will have rules about who can access contractual information and most are governed by privacy and information disclosure rules. The benefit of Enterprise Content Management (ECM) systems is that you have the option of managing access to this information in a more granular way than you can on a shared drive. If the system is used properly, links to content distributed within the organization will only allow privileged users to access information. Your ECM rollout must abide by the rules but these rules are not an excuse to lock down all information.

2. The “need to know” principle means that if someone needs information to do their job, they will have access to it.

   The best thing about an information management system is the power of ad hoc information discovery.

   If you don’t know what you don’t know, how do you know you need access to it? If valuable information doesn’t come up in a search result, how do you avoid re-creating it or making decisions without the benefit of this information?

   It’s a case of risk vs. reward. Your organization needs to decide if you are more worried about the risks that come from people finding information they shouldn’t (a risk which is still mitigated by the “closed by exception” part, as noted above) or if you are more interested in promoting knowledge sharing, collaboration and information discovery. I will always take the side of more information sharing over less; the “weak ties” we develop through finding information created by others help us expand our knowledge exponentially. Sociologist Mark Granovetter first came up with the concept of “the strength of weak ties” and Andrew McAfee and others have applied it to information management. Basically, this principle says that we learn more from those we know peripherally than from our immediate colleagues; we already know what they know and we tend to become insulated and single-minded in our decision making. By expanding your network to people you only know somewhat, or people you don’t yet know at all but have read a document authored by them, you will gain new perspectives and are much more likely to come up with creative solutions.

3. If everyone has access to information they will misuse it.

   I fundamentally trust people. Maybe that’s a shortcoming of mine but in a corporate context, I trust that the vast (vast) majority of people are trying to do the right thing for the organization. If not, you’ve got far bigger problems than information security. The “open by design” principle does not mean that just anyone can edit all information; most information will be read-only and some will be less than that (i.e. see that the content exists but not the content itself). ECM repositories also have versioning and audit capabilities, so it is easy to see who accessed or changed a document and to roll back a version if necessary. This is difficult in an ordinary shared drive scenario and impossible if you can’t find the information in the first place!

   To address the concern that people will share information inappropriately outside of the organization I suggest making sure everyone understands your appropriate use policy. No, I am not so naive that I believe everyone will follow the rules just because they are the rules, but that’s why ECM systems have security policies. If information is truly sensitive it should be secured. If not, is should be open to all users within your organization. Simple as that.

The conclusion I draw is that while SharePoint is clearly having an impact on the ECM market (in addition to the fact that it is the fastest growing server product in Microsoft history, esteemed organizations like AIIM have started to dedicate entire communities to SharePoint), at this point it appears that SharePoint's success has not come at the expense of incumbent vendors.  It will be interesting to see how this evolves but for now, it seems like there is room enough for everyone.

And just to continue the earlier trend of putting SharePoint into the mix of all ECM discussions, there was a great debate on the AIIM ERM Community blog this summer about the merits of SharePoint records management.  James Lappin feels there are significant shortcomings in SharePoint records management, Mike Alsup disagrees.

1. Traditional ECM remains strong even as SharePoint rises. It seems that everyone (myself included) has been talking about the impact of SharePoint on the ECM space, and SharePoint's influence is undeniable. Many analysts, consultants, customers and even casual observers have been predicting that SharePoint will eventually become the de-facto standard ECM application at the cost of market share and license revenue for traditional ECM players.  Then along comes Open Textand the aannouncement of their results for fiscal 2010.  Total revenue is up 16% and profit increased 24%.  That doesn't sound like a company on its way to irrelevance. 
2. Records Management still matters.   Even though most of the hype in our industry seems to be reserved for trends like Enterprise 2.0, open source, and the impact of cloud computing on ECM, enabling proper records management is still a big part of the value proposition for ECM.  Nothing brings this fact into sharper focus than the mountains of electronic and paper records that will be produced as part of the investigationand lawsuits related to the BP spill in the Gulf of Mexico.
3. The future of ECM is cloudy (and Cloudy?). It is natural and healthy for any industry to take stock of where it is in its' evolution, and the ECM industry seems better than most at navel gazing.  Joe Shepley published a good piece on his vision for Second Wave ECMand AIIM's fearless leader John Mancini shares his thoughts in a recent YouTube video.  There are enormous opportunities in ECM (cloud computing, continued data proliferation, Enterprise 2.0) and significant challenges, including significant debate on the definition of Enterprise Content Management itself.  John Mancini says that "ECM as a term is stressed", which tells me that even AIIM is thinking about the future of this acronym.

   Others are also debating the definition of ECM. Laurence Hart, though his Word of Pie blog, has been trying to come up with a new definition for ECM for several years now.  His most recent attempt to define ECM was last week and it has spawned some interesting discussion in his blog comments.  I'm always up for a good debate and this discussion has me thinking.  Should ECM include both structured and unstructured information?  Should it include web content? How about reusable chunks of content that can be used to pull together documents (e.g. standard paragraphs for a contract)?  Tweets? Facebook pages? Just good old fashioned documents?  

   I don't have a good answer (okay, I don't have a short answer) to these questions but I suspect you probably have an opinion, which I  encourage you to share below.

   ]]> http://www.c3associates.com/2010/09/things-i-learned-about-ecm-on-my-summer-vacation/feed/ 1 http://www.c3associates.com/2010/08/8-things-to-think-about-if-you-are-thinking-about-moving-to-sharepoint/ http://www.c3associates.com/2010/08/8-things-to-think-about-if-you-are-thinking-about-moving-to-sharepoint/#comments Thu, 12 Aug 2010 19:11:32 +0000 Greg Clark http://www.c3associates.com/?p=561 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.

   ]]> http://www.c3associates.com/2010/08/8-things-to-think-about-if-you-are-thinking-about-moving-to-sharepoint/feed/ 0 http://www.c3associates.com/2010/07/lessons-from-the-knee-of-the-master-battle-tested-tips-for-ecm-success/ http://www.c3associates.com/2010/07/lessons-from-the-knee-of-the-master-battle-tested-tips-for-ecm-success/#comments Fri, 16 Jul 2010 04:03:39 +0000 Greg Clark http://www.c3associates.com/?p=554 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.
   ]]> http://www.c3associates.com/2010/07/lessons-from-the-knee-of-the-master-battle-tested-tips-for-ecm-success/feed/ 0 http://www.c3associates.com/2010/07/the-lasting-impact-of-canadians-in-records-and-information-management/ http://www.c3associates.com/2010/07/the-lasting-impact-of-canadians-in-records-and-information-management/#comments Thu, 01 Jul 2010 15:38:09 +0000 Greg Clark http://www.c3associates.com/?p=549 In honour of Canada Day today (and yes, "honour" is spelled with a "u"), I thought I would share the significant contribution Canadians have made to the information and records management industry.   I'm not sure why it is that Canada seems to have had a disproportionate impact on our industry; I'm tempted to say that we don't have much to do in the winter except fret about records, but that would further the unfortunate stereotype of Canada as a winter wasteland.  The truth is, Canada is a vibrant, diverse and well-educated country that has given the world a lot of great things; from the first radio broadcast to the BlackBerry, from basketball to birch bark canoes and from the instant replay to insulin, Canadians have done a lot.

   So it shouldn't really come as a surprise that we can add records management systems to that list.  My Twitter pal and content management all-rounder Cheryl McKinnon (more on her later) provided me with some guidance on the short history of records management systems in Canada.

   It is a little-known fact that three of the core records management components in the major ECM suites were originally conceived of in Ottawa.  PS Software Solutions became the core of the Livelink RM module after PS was acquired by Open Text in 1999, Tarian Software was acquired by FileNet (now part of IBM) in 2002 and Provenance Systems became Documentum Records Manager (now part of EMC), also in 2002.

   But Canada's glories in the records and information management space are not all past tense.  The following is a very brief overview of a few prominent Canadians in ECM.  And I say brief because it is impossible to capture the contributions of every Canadian who has had an impact on the records and information management industry. The big risk with listing names is overlooking someone and I am certain I have done so, so my apologies in advance. If you think there is someone who deserves to be recognized as a leader in the Canadian ECM space, please let me know in the comments section below.

   Tom Jenkins is the Executive Chairman and Chief Strategy Officer at Open Text, the company that helped define the ECM industry and make it what it is today. He joined the company as Chief Operating Officer in 1994 and quickly became CEO then Chairman.  He is one of the true champions of ECM and has helped Open Text become the largest independent ECM vendor in the world. Tom literally wrote the book on ECM and continues to actively promote the future of information through Open Text's support of the Canada 3.0 initiative and the University of Waterloo's Stratford Institute, a think-tank devoted to collaboration between digital media, international commerce and culture.

   Cheryl McKinnon has been the Chief Marketing Officer at Nuxeo, an up and coming open source ECM vendor since 2009, but got her start in ECM 16 years ago following a graduate degree in Canadian History.  Cheryl has extensive public sector experience with Hummingbird/PC DOCS and following Open Text's acquisition of Hummingbird she managed the Livelink Collaborative Content Management line of business. It was in this capacity that she launched the Open Text Enterprise 2.0 strategy in 2008. Cheryl is one of my favourite Tweeters (or is that Twitterers?) for her insightful and relevant commentary on all aspects of ECM from records management to social media. She is a true thought leader in our industry and if you don't already follow her Tweets I encourage you to do so. 

   Barclay Blair is an information governance guru who has written extensively on the topic. He is the author (along with Randy Kahn) of the Information Nation books, speaks and consults all around the world to Fortune 500 companies, governments and others.  Just in case you were worried Barclay would coast on past success, he was recently named a "SharePoint Guru" at SharePointGovernance.org, a peer exchange site sponsored by AIIM. Barclay is currently president at ViaLumina.

   Ann Rockley is the founder of the Rockley Group, a globally-recognized content management consultancy.  Ann has written two books on the intricacies of content management, including DITA 101 and Managing Enterprise Content: A Unified Content Strategy,  which is regarded as one of the seminal books in our industry. Ann is also active in the content management  community; she is the OASIS co-chair DITA for Enterprise Business Documents Subcommittee and is a founding member of the CM Pros group.

   Like I said earlier, this list is intended to highlight the contribution Canadians have made to records and information management. If you can think of anyone else who deserves recognition, please list them in the comments section below.

   ]]> http://www.c3associates.com/2010/07/the-lasting-impact-of-canadians-in-records-and-information-management/feed/ 0