Ready – Set – GO! with ERM

If you are in the process of reviewing your companies Enterprise Records Management (ERM) strategies and are not sure how to get started, here are some helpful hints to get you going. 

When starting out with ERM it will be useful to first take a look at what kind of an organization you are. Are you a global leader with industry-specific requirements such as Sarbanes Oxley (SOX)? Or are you a small to large size establishment with moderate needs? Do you have an existing ECM system with a RM Module that can be added on, or is this new to your organization? The answer to this question will determine what level of compliance and continuity to start your research and develop a business case and program assessment for a new ERM system.  

An ERM implementation for a global bank will be significantly different than a local county or small law firm. It is important understand the business needs and records management requirements of your organization. Smaller organizations in low-risk (non-litigious) environments may be able to design an ERM system with just a few basic retention categories. However, larger organizations with high risk and in an industry with more litigation and legal requirements will want to look at more robust software with industry regulatory compliance certifications.

The new ERM system will have a big impact on everyone in the organization and it will be worth the time to take a good look at the current Records Management policies and procedures, or lack of them. Additionally, there are many common records and information management polies that are related to ERM, such as email, file naming conventions, version control, file system and network sharing organization just to name a few. Taking the time to read, catalog, and understand how information is used will make it easier to identify gaps and challenges when developing the ERM program.  

Understanding your organization’s internal policies and standards is a good start and the next step is to perform an inventory. An inventory will locate, identify and describe all agency records series, regardless of physical form. The process will describe the general function and overall content of the record types and include physical format, growth rate, location, volumes, frequency of use, and identify duplicate copies. This can be performed with the help of a vendor or consultant to ensure you are getting all the metadata to help build out the ERM system. A data scrubbing project will often be needed after the inventory to eliminate duplication, provide missing metadata, and identify documents that need to be declared as records.

All of these policies, standards, and processes will change from the way you name a word document to where you place the final version. Keep in mind that the ERM system is a function of business process, governance, operational controls, change management and training. We have a saying here –“The technology will always work itself out – it is the people part of ERM systems that is the most difficult.” The ERM program and implementation is a change management project that happens to involve technology. Gathering and reviewing policies and procedures, communicating, locating documents and getting organized before designing the ERM system is critical for success. The first goal is to capture the needs of the organization in a manner which enables a successful program and that can only be accomplished with a good foundation.

Leigh Woody
Program Manager
ImageSource, Inc.

Blogs as Serious Tools for Serious Project Managers?

Blogs are more than a medium for marketing, news, and education. From personal experience I can tell you that they also serve as serious tools for serious project managers.

As a professional project manager I’ve worked with companies from Seattle to Sydney. A key factor in making sure that a project goes well is communications. Blogs are excellent mediums for communicating information in a concise manner that gives all team members the ability to participate in the conversation.

Last year my little company of 70 people was acquired by a Fortune 50 company. As the project manager for the integration I relied heavily on our internal blog to communicate information about project status and schedule. It was also incredibly useful in helping train people on new processes associated with our acquisition.

The number one software used for communications in a project isn’t Microsoft Project or some other fancy tool—it’s email. Blogs have a number of advantages over email. Although our users got email notifications about blog updates they didn’t have to store and manage these notifications in their own email client. They could access the blog from their email notice. And if they wanted to go back to the subject they just had to search the blog. No digging through their inbox, deleted items, folders, or even worse—asking ME to send them yet another copy.

To communicate information about our integration we also put out several newsletters. But this format tended to be a big production in contrast to the blog. For each newsletter we had to pull together a number of articles and format them. By the time we got all the content together some of it was already dated. Plus, people tend to shy away from or skim longer items like newsletters. But with a blog we sent out postings as the information was needed. It was timely and digestible.

Although we kept our blog articles short they often linked to more comprehensive information. Users could look at the posting to get the gist of the update. Then they could use links in the blog to access detailed training, schedules, and other updates. The blog was their portal to key information and remained available well into the future.

Another advantage of a blog is that it’s a very interactive tool. When someone discovered something interesting about our new company they could share that information in a posting. Some users discovered “quick tips” about working with new systems that they shared with everyone else. I also encouraged our executives to share good news about the project in blog postings rather than waiting for company events.

If you’re interested in learning more about how blogs, wikis, and social media are useful tools for managers check out my posting on Enterprise 2.0 and the Hostage Dog. That article also links to a recent presentation I gave to the Seattle area chapter of the Project Management Institute.

Dennis Brooke writes about Almost True Stories of Life at www.dennisbrooke.wordpress.com. He’s a manager for a tiny but important division of a Fortune 50 company. On November 4 he’ll be speaking on Enterprise 2.0 and Project Management in Bellevue, WA at the Nexus ECM conference. See www.nexusecm for information.

This posting originally published on Blogging Bistro and is reprinted courtesy of  that site.

  

Putting Together an ECM Project Team

Part 3 – The Project Team

In previous blogs on this same subject, we have discussed the role of Executive Management in the overall Project Team effort.  And what elements from the  internal organization would likely comprise an effective team.   In summary, vibrant and effective executive leadership is likely to be critical in solidifying the vision for the project.  The target of effort to achieve project acceptance and enthusiasm is cascading in that the focus of executive leadership is middle management.  The components of a project team may be different for each organization or type of organization – whatever best suites the particular organizational structure, and what special considerations there might be in the project (i.e. does it involve web content, collaboration, integration with ERP or SharePoint environments, etc.).

The Role of Line of Business Managers in the Project Team

As your project will likely either be addressing a limited requirement of a single department or two, or will be the start of an enterprise wide implementation of ECM, it is always recommended that it focus on a manageable quantity of work – normally one or two Departmental or workgroup solutions.  Enterprise wide ECM, ERM, and Business Process Management implementations usually start with one or two departments.   The Department(s) chosen for the Project are normally those where enthusiasm for improvements is high, cooperation is supportive, and where the business entity will benefit highly from the application of ECM technologies.

Starting with one or two areas that have been carefully selected based on their high potential for success and strong need for improvement, permits the rapid and clear demonstration of  ECM technology benefits – and that strong example can assist in the acceptance of the larger project to come across the enterprise.

Departmental management and supervisory involvement and strong support is crucial.  The organization’s line-of-business (LOB) managers understand the routine and cyclical “problems and challenges” of business operations.  They are operational experts within their areas of responsbilbity, know the character of the staff resources they have to work with, entity strengths and weaknesses, the potential to accept change, and what “change management” efforts should be implemented.   These LOB Managers and supervisors routinely “concentrate on organizational effectiveness through current processes” they will become the bridges that will carry the success of the ECM project forward into routine of daily work production.

The LOB Managers and other key supervisory or lead personnel need to be considered for the Project Team for either full involvement, or participation in the development of specific new process or workflow designs.

• They are most cognizent of what is done in their departments and why, what documents are received and how they are processed, the various sources of data (paper from internal and mail sources, voice mails, emails, internet provided input, etc.).
• They understand the decision criteria in the flow of work, the point where specific processes are needed, risks to successful processing, exception processing, and all the rest of the challenges that will need to be considered in a process design.
• They also know which other business areas need access to their documents and data.
• They usually have the only available insight into key details regarding operational systems, processes, and policies that support their organization’s mission.

When you apply ECM and BPM technology to an organization’s routine processes, you must have input and significant levels of planning participation from the managers and key personnel who are most familiar with operations so they can ensure that the new system will be successful in meeting objectives at all meaningful levels.  These people are needed to allow the project team to reach all objectives through consistent operational production.

From time to time this blog will continue with the subject of project team challenges, some considerations to remember, use of supporting vendor resources, and some recommended methods for implementation.

Neil W. Lindsey, ECMm, CDIA+

Project Manager / Senior Business Analyst
ImageSource, Inc.

The Role of Leadership vs. Management in Project Management

You’ll often hear people extolling the virtues of leadership, and at other times the virtue or failures of management. The question is what is the difference and how does that play out within the context of Project Management.

In a nutshell (yes, I am simplifying it for this discussion) the difference between leadership and management can be thought of in this way:

Management is about dealing with the complexities, logistics and issues of execution. In short, it brings order, consistency and predictability to the notion of things like Project Deliverables, meeting Quality Assurance goals, and the overall delivery of product, projects or programs, regardless of what those things might be.

Leadership on the other hand is about vision, inspiration and dealing with change.

In order for any effort or organization to function in a healthy and sustainable way, there must a symbiotic relationship between the two. 

Managers and leaders have commonality in some of the tasks and activities that they perform (i.e. deciding what needs to be done, who will do it and making it happen), but they go about achieving the end results in very different, yet interrelated ways that create a synergy that is much more effective than either trait on it’s own.

Managers will plan, create SOW’s, Gantts, Issues Lists, Test Plans, etc… in an effort to solve problems. Leaders will develop a vision first and devise strategies on how to achieve that vision.

Managers will focus on recruiting and hiring to staff the project to completion.  Leaders will often be more focused on aligning strategic resources within the teams, communicating the vision to them knowing that they will support, propogate (and in some cases enhance) the vision to the rest of the teams.

Managers will use all of the planning tools at their disposal to monitor execution and evaluate the end results against the plan. Leaders will inspire and motivate people to continue moving in the right direction, to not be sidetracked by problems, issues, or false objection. And they will often do it in what seems to be very simple ways that speak to the human aspect (e.g. emotions, values, etc…) of their team members.

So as Project and Program Managers, which do we want to be?  Perhaps … both. Any project, program or organization of any substance must have a management component to survive. Structure, procedure and protocol is not a bad thing. But structure, procedure and protocol without vision, and human inspiration becomes static.  Likewise vision and human inspiration without structure, procedure and protocol can lead to chaos.  The key is understanding the difference between them, the proper balance between the two, and when and where to apply them.

Gene Eckhart
Program Manager
ImageSource, Inc.

  

Putting Together an ECM Project Team

Part 1 – Getting Started

From a user organization perspective, constructing an effective ECM Project Team needs to be on of the initial mandatory objectives and activities undertaken when implementing an ECM Project.  Achieving this objective in its totality directly links to the success of the implementation of any major ECM project within an organization – whether it be for a phased enterprise or a departmental initiative. 

Achieving this objective is a management challenge that must be supported at the top.  It requires Executive leadership that should initially lead to developing:

• an organizational vision
• clear and consistent motivation
• full mid-management support
• staff commitment at the user level that supports the executive sponsored vision developed by a qualified Project Team. 

With the above being understood, in an instance where the initiating champion of an ECM Project has a mid-level management role, that person needs to acquire an appropriate and committed executive level sponsor. 

In a typical scenario there initially needs to be a management level person(s) involved as project sponsor(s) who would likely be a department/division manager or line of business (LOB) manager.  As indicated, this person needs to acquire the active support and sponsorship of executive level management.  This could be a VP of Operations or the Chief Information Officer (CIO) of the organization. 

The first sponsor tasks are to:

[1]   Develop and document the initial premise of the ECM initiative.

[2]   Select and organize an effective team of Project Team members who will work together with the sponsors to fully define and refine the project vision, and develop a strategies to plan the details and bring the project to fruition. 

The people selected for the Project Team, their planning and collaboration skills, their ability to understand the underlying concepts of both the change management and technologies necessary to implement ECM, and their ability to communicate effectively are going to be as important to the success of the ECM Project project’s success as the software, supporting expert resources, and project implementation team solution that is ultimately selected.

The successful ECM project will likely have new business processes implemented, improved workflows, integrations with existing systems, and will require changes in the way supervisors and users do their work.  The successful Project Team will be realistically creative, and individuals as Team members need to be open in their communication of ideas and the challenges to be faced.
_________________________________________________________________________________

This blog will likely continue on this subject – with future installments discussing the recommended makeup of the Project Team members, the considerations that need to be covered, utilization of supporting partnership resources, and some recommended methods that should be considered to achieve implementation objectives.
______________________________________________________________________________

Neil W. Lindsey, ECMΜ, CDIA+
Project Manager / Senior Business Analyst
ImageSource, Inc.

 

  

ECM Best Practices: Training – How much is too much, how much is not enough?

How much is too much, how much is not enough?  That is the proverbial question. Often times when project budgets are being developed, training is a secondary consideration. Sometimes it’s not considered at all.  When you’re working with customers helping them to determine what kinds of training and how much should be included, the first thing should be clearly identifying what your objectives are (and qualifying them with the most affected stakeholder – the end users). At times you will find the answer to that question to be very different coming from the project sponsor vs. the End User management team, vs. the End Users themselves. Your ‘objectives’ often transcend the simple task of selecting classes. Hence, the need to clarify with all of your stakeholders…

First, who are your stakeholders in training?  The End Users are obvious.  What about Team Leads?  IT Support (i.e. desktop support, server support, and help desk)? Application Support (administrative and end user)? Change Management teams? What about your Project Sponsor? The list can go on and on.   How much is too much, how much is not enough?

Second, what are your budgetary constraints? Within your project budget, you may have a line item for training, or even a separate line item for training for different phases of the project. This is the money originally allocated by the sponsor. How that money is spent may be rigidly defined, or it may be simply a line item budget number to be used at your discretion. With a little probing, you may be able to determine that ‘other monies’ are available from different budget codes or cost centers (unrelated to the project) that can also be used in a discretionary manner by the department managers. In those cases, with a well thought out justification, you may be able to pool that money in addition to what’s been allocated to the project to increase your available funding for training. In the case where you have line items for training for different phases of the project, close examination and analysis may reveal that there is an imbalance in the amounts allocated for some areas. Understanding that demographic need and the spread can help you level the available funds in other areas or phases of the project where you are deficient in the amount of money needed to support those particular initiatives.  How much is too much, how much is not enough?

Third, what are your logistics and operational contraints?  Training requires time and resources. Staff time, training rooms, systems\application environments, etc…  To train people, the traditional model involves taking them out of their work environment, putting them into a classroom, and running them through a curriculum based program that will orient them to the new systems and sometimes to the specific processes or application used in their jobs.  Point being you are taking people away from their jobs which directly impacts the organizations ability to do business. How do you compensate for that from an operations perspective?  Do you need to compensate for that from an operations perspective? When you’re trying to implement training in large organizations, these challenges become even more daunting.  How much is too much, how much is not enough?

Fourth, what are your timelines?  The best laid plans of mice and men often go awry…  I’m not sure that when Robert Burns penned that famous quote, he wasn’t thinking about project planning, schedules and interdependencies, but he could have been!  You can develop the most comprenhensive training plan possible, taking into consideration every possible need. Then you start to consider the functional dependencies required to pull that off (i.e. availability of systems, availability of facilities, etc…), the personell logistics (availability of staff, availability of trainers, availability of technical support, etc…), and the human factor (how much time will elapse between training, testing and GOLIVE when people will have to use the system) and you start to realize that you have created a monster. How much is too much, how much is not enough?

 Now, how does this all play out in the context of your objectives?

Stakeholders – You have to address all of them.  You don’t necessarily have to deliver to all of them. As quickly as possible assess what their critical functional needs and requirements are in relation to training. Be careful to note the difference between ‘nice-to-haves’ and ‘must-haves’.

Budgetary Constraints – Make a short list of the ideal classes and training Deliverables you would provide in a best case scenario. Ball park cost it and compare to your ‘nice-tohave’ and ‘must-have’ lists from your stakeholders. Identify the gap if one exists. Prioritize the stakeholders in the context of functionally (and successfully) completing the project.

Logistics and Operational Constraints – Now review your operational capability and capacity for delivering the training.  Do you have the required classrooms, computing resources and the application environment to deliver to the volume of people that need to be trained.  Even if all of those people can be spared from their jobs for the time it will take to train them, is it really necessary to pull all of them to accomplish your functional objectives?

Project Timelines – Now that you’ve considered your stakeholders requirements, budgetary constraints, logistics and operational constraints, consider your overall project timelines. Will your systems be online and functional in the appropriate time frame to be used for training.  Will tapping these systems for training impact other scheduled activities (i.e. development, system integration testing, user acceptance testing, etc…)? Can training be combined with other scheduled project activities in ways that create synergy and efficiencies in overall project execution? How much time will elapse between training and when you will count on users to participate in testing and actually take the system live?

Conclusions

1. The blue sky approach is that everyone will want training and as much as they can get. The reality is that you will almost never have the budget, available resources or the time for that, even if you can tap those outside-of-the-project discretionary departmental budgets. It’s up to you to ascertain what is really required to successfully launch. Typically it’s the end users, and some mix of application administration\desktop  support. This is where you engage the Project Sponsor and potentially the clients Project Director to help set expectations with the various stakeholders on what will be delivered. This is also where Change Management comes in. Help the client to understand the need that change management addresses, and suggest  creative ways that change management techniques can help to address the training of future hires and the additional training of people not included in the formal project training.
2. As an alternative to training everyone, consider ‘organic approaches’ that leverage departmental super users for propagating training within their departments. This approach done properly can also yield a secondary benefit of producing ‘product evangelists’ within the department that will culturally promote the use of the system from within. The production of computer based training (CBT’s) for training of the masses can also be a very cost effective alternative when largely repeatable tasks come into play. These can be produced much more cost effectively with current productivity tools than could be done even 3 to 5 years ago.
3. However you deliver your training, it will be more effective if it is delivered just prior to when users will be required to use the system. Typically this should be just before test, and then test should be immediately followed by the launch so that users are using the system while the skills and concepts developed in training are still fresh in their minds.

How much is too much, how much is not enough?

The short answer is that more is not always better. Users need to be able to do their jobs, nothing more, nothing less. We want to deliver the best solution, but we have to remain focused on our core objectives. If informal training with ‘Cheat Sheets’ at the users desktop is sufficient, go there. If it requires multiple language translations of End User Manuals and CBT’s with customized voice overs, go there. It’s about the right solution in the right place for the right people at the right time. It’s your job to understand and articulate what ‘right’ is.

Gene Eckhart
Program Manager
ImageSource, Inc.

Embracing Client Budgets in Meaningful Ways

Setting the “Fixed Bid” model of funding projects completely aside for a moment, let’s talk about the “Time and Materials” model of project funding in relation to project management…

In these difficult economic times, the realities are that budgets for funding projects, particularly new implementations of technology, have become more scarce. When they are available, they are often smaller than what might have typically been allocated for a given organization even 2 or 3 years ago. Many clients that might have historically embraced a fixed bid model for project funding are considering the time and materials model as an alternative for any number of reasons. Again, setting aside the wisdom of those choices, it is a reality that we are seeing more frequently.

Another importat dynamic in this equation as partners and project managers is that even in a T&M engagement, there is often a cap on the funding for the project, which may or may not be sufficient to do the project properly from a consulting vendor or a “best practices” perspective.

The unspoken choice that we have as project managers for these types of projects is whether or not we truly embrace the client’s budget in a meaningful way. The short, easy path is to simply carry on with planning and executing the project the way we would normally in a well funded fixed bid effort, and when problems do occur, to simply blame it on the fact that the client doesn’t have the funding to ‘complete’ the project properly. While this may be an accurate statement, and you may have performed due diligence in planning and execution (up to that point), in the end it serves neither yourself or the client. If your project is not completed, or is completed in haphazard manner, the benefit sought by the project is lost, the relationship with the client is damaged and no one wins.

We have to understand that our clients constraints and limitations are our own by virtue of our current relationship, and our desired long term relationship with them. Once we are truly reconciled to that fact, we should seek ways to meaningfully embrace the budget to accomplish the overall goals and objectives of the project. Consider the following possibilities:

1) Have open and honest dialogues with the project sponsor and key stakeholders about the potential shortfalls in the budget. The message that you want to communicate should be clear. You both need to have a realistic understanding of the limitations of the budget. That being said, they should know that you are conciously and proactively working with them to find creative ways to make it work for both parties within those limitations. By setting these expectations properly, everyone will be more engaged in the process.

2) Fully assess the internal resources that your client can make available for the project. Be creative in how you engage these resources. Be willing to stretch their normal experience boundaries and give them a growth opportunity on the project. Their growth opportunity if properly managed can be an effective way to complete necessary tasks and to take vital project dollars for your teams and use them more strategically in areas of the project (e.g. development) that are more important to the end game.

3) Work with your end users to figure out creative ways to address training. Be open to models other than conventional classroom training which might require significant time (and expense) to develop courseware and curriculum. Consider rapid development of “Cheat Sheets” focused only on the specfic tasks that users will need to complete their jobs. Consider incorporating ‘train-the-trainer’ models into the customers Change Management plan.

4) Be thoughtul when developing your QA\Test plans. Be open and flexible as you work closely with the stakeholders and end users to determine what the true success and acceptance criteria should be. It’s easy, particularly with software development projects, to spend a large amount of time and budget on properly performing Quality Assurance, System Integration Testing and User Acceptance Testing. Seek to find the balance between the overall budget of the project, the anticipated ROI for the customer, and what is reasonable and prudent given the technical complexity of the software that is being developed. This is also an area where the first item comes into play. If you are proactive in engaging client resources early on in the project, you may be able to turn a large part of this effort over to them, and help to reduce the budget.

5) Be diligent in recognizing the difference between genuinely flushing issues out in discovery, and eating up project dollars while your team sits and watches clients sort out their internal decisions and differences. Don’t get caught up in internal politics that can consume large amounts of time and budget with meetings that don’t necessarily require your attendance or participation.

Again, it’s easy to say, “The client didn’t have enough money to do it properly”, particularly if you have done ‘good work’ on the project. The scenario where everybody wins is when you creatively work together and find ways to complete the project successfully, and meet the budgetary constraints of the project by thoughtful planning, management and leveraging the client staff and end users in a manner that gives them opportunities for growth and a deeper sense of ownership of the solution.

Gene Eckhart

Program Manager

ImageSource, Inc.

Change Management and User Adoption

Here is a follow up on my post of June 29, 2009.  This follow up focuses on the section referenced by  “Change Management (People)”  where ECM projects sometimes include significant business process changes that require the user community to change the way they work.  In this case, the success of the project will be dependent upon user acceptance of the new system and their adoption of new processes, challenges to the way they work, and their feeling for their  job security. 

I was reviewing some other blogs sourced from the AIIM site the other day and came across the following blog attributable to AIIM’s “8 Things” guest blog series, and the guest blog author Lynn Fraas, a Director for Crown Partners, and the current Vice Chair and Chair Elect of the AIIM Board of Directors.  Because the following material from Lynn Fraas is related to my previous blog, I am providing this reference to her blog  post as an expansion on the Change Management subject.    See below ↓
          ________________________________________________________________

User Adoption of ECM and ERM systems
8 Ways to Increase User Adoption

A consistent topic in ECM circles is low user adoption.  We think of ECM as “mature” technology, however, most companies still struggle with broad user adoption.  In implementing ECM technology we fundamentally change the way an individual or group does their job.  Consequently, the business process and culture change associated with the technology is much more significant that the implementation of the technology itself.  Below are 8 things you can do to increase user adoption of ECM Applications:

1.  Get top-level support. 

This seems to be a “no brainer” but one that is consistently overlooked.  ECM implementations often require significant changes to the underlying business process.  A strong sponsor at the executive level can work to remove any organizational roadblocks the team may (or should I say will) encounter as you roll-out applications across the organization.

2.  Start small. 

We have all heard the phrase “take one bite of the elephant at a time”.   Trust me; it is harder to do than it sounds.  To start on the ECM journey, take a relatively straightforward business process and work with that first.  Select a group that has at least one or two individuals who are champions for the new system.  Get the first project over the finish line and in the winner’s circle before you embark on project #2.  Measure the results, celebrate the success and make sure the rest of the organization hears about the success.  This will create a level of excitement that will drive other groups to “want” the new technology.

3.  Be fanatical about internal PR and communication. 

User adoption is driven by system acceptance.  Become a PR and communication expert as they form the cornerstone of gaining organizational acceptance of the system.  You must evangelize and spread your messages to executives, managers, information workers and outside vendors and suppliers.  Build a PR/communication plan early in the project and incorporate different mediums to get the word out.  A simple grid with audience (executives, managers, workers etc) on one axis and form of communication on the other axis will suffice.  The key is identifying major stakeholders and messages then planning the communication campaign to ensure all messages are delivered multiple times.

4.  Use “personas” to understand how the new system will impact users.  

Create a persona for your key stakeholder roles and ensure your system addresses their needs.  The typical organization has multiple roles that will interact with any given business process and therefore the system.  Each role has its own unique requirements (at least from their perspective).  Understand who will interact with the system and what they need to be successful.  Make sure you have them covered with the solution – ultimately it is all about making their life easier.  Understand the WIFFIM (What’s In It For ME) for each persona.

5.  Focus on the business process.  

The business process that ECM technology will support should be the focus – not the underlying technology.  The business user wants to get their job done in the most straightforward manner.  To the extent technology provides tangible benefits to the user – adoption will follow.  If you implement technology for technology sake – you will probably struggle to get users to actually use the system.

6.  Get users and business owners involved. 

People love to be heard.  Leverage that core human trait and get the users/business owners involved at the very beginning of the project.  Other than the typical steering committee thy these avenues for involvement:

• Have a representative from each group on the implementation committee and make sure they communicate regularly with the group they represent.
• Organize an occasional brown-bag discussion or whiteboard session to make sure you understand the process and how ECM will improve the process and the lives of the users (well at least their working lives!).
• Drive hands-on involvement by establishing a “model office”.  Use the model office to engage with users, conduct process “what If’s” and to develop and test applications prior to their general release.  The model office is also useful for ongoing training as you add to or change staff.

7.  Leverage collaboration tools. 

In the world of Web 2.0 it is very easy to create a dialogue with the broad user community.  Check into leveraging an existing corporate intranet or wiki to engage the organization in the discussion around the new system.  If you don’t have a corporate standard there are many ways to generate conversation with free web based tools such as Twitter, Yammer, Facebook and MySpace

8.  Training is more than just a class.  

If I had a dime for every time I heard the words “companies did not plan for training” I would be on a sunny beach.  You hear that training is often overlooked and that is a key piece of the user adoption puzzle.   I also believe that in many cases training is conducted but it is ineffective.  To be effective, training must be more than one how- to class.  Here are some additional ways to ensure people make the jump to using the new system:

• Provide online or hardcopy step-by-step user guides with screen shots to help users the first few times they use the new system.
• Conduct a training session prior to use and then one week after implementation.
• Leverage the wiki or whatever collaboration tool you use to enable users to ask questions and get quick answers – that can be review and used by others as you add to staff or bring different groups onto the system
• Review the question and answer site to see if there are any trends indicating issues you need to resolve with the new system.

The broad adoption of technology is difficult but not unattainable.  I leave you with a great clip that my colleague  posted on the Information Zen site – a great clip to show users:  http://www.informationzen.org/video/2043787:Video:160

          ________________________________________________

Atle Skjekkeland, referenced in this blog, is a speaker at the NEXUS 2009 Conference later this year.

Neil Lindsey, Project Manager / Business Analyst
ImageSource, Inc.

The Two Faces of Change Management

Enterprise Content Management implementation projects frequently require the formation of plans for, and execution of “Change Management” as a major part of the project components.  But what is Change Management?  In ECM Projects, participants have been known to describe Change Management using two very different definitions:

[1]  “Change Management (People)”- ECM projects sometimes include significant business process changes that require the user community to change the way they work.  This is especially true of solutions that involve transactional processes.  Process change situations can challenge the success of the project if the users are not involved and informed.  If major business process are major or widespread, the support of executive and middle management is crucial and needs to be effectively communicated to those users involved with the changes.

[2]  “Change Management (ITSM)”- Most ECM Projects, no matter how well planned and documented, will usually have situations arise where plan details should change.  Changes to the plan can be requested by the implementation team, the project sponsor, or a key organizational department.  The Project Manager(s) responsible for the success of the project must have a formal process to receive Change Requests, process, and then respond to them in light of their impact on the design, cost, and schedule of the project.

Neil W. Lindsey
ImageSource, Inc.