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.

Considerations for Architecture and Deployment of Global Capture Systems

 

The considerations for architecture and deployment of global capture systems are several fold. In our experience they include the traditional considerations and methodologies (software deployment models, conventional server models, fault tolerance considerations, human resource considerations, change management, etc.), however, in the global context there is another set of considerations that must be factored into the decision making processes. Regardless of the quality or nature of the software, there are myriad factors (independent of the software application) within any global corporation that can and will affect how that software is implemented and how it performs in any given region of the world. The ability to implement quickly and efficiently is tied directly to the organization’s communication structure, reporting structure, internal politics, policies and procedures, physical infrastructure, and the relationships that exist between the various IT support groups and the business. Any distributed applications performance can be impacted by the network, security configurations, load balancing systems, WAN Acceleration systems, and all of the rest of the traffic traversing those global backbone and regional networks. Many of these factors can and often are completely beyond the control of the customer’s project teams, and those that do control them often have completely different reporting structures within the organization.

Having a clear handle on the state and configuration of the existing environment combined with well managed Command and Change Control structure and a central hierarchy of authority that can be used for escalations is vital to the ability of ground teams to implement, troubleshoot, correct, adjust, optimize and complete rollouts in a predictable, consistent and timely manner.

Most of these factors are never fully known or understood until the teams are well into the planning stage of a given project. There are several ways that any global rollout can be approached from our perspective. Our preference is to work closely with your teams to understand the traditional factors as well as the lesser known and intangible ones so that together, we can arrive at the most effective, efficient and reliable ways to implement for each given region of the world. In our experience we have also found that being flexible as a combined team in our approach can help to ensure successful outcomes at the end of the day. We have to plan based on the information available at the time. As new information becomes available, we work together as necessary to modify the plan to achieve our stated goals and objectives for the implementation and to satisfy the needs of the users. At the end of the day, from a users perspective, it just has to work.

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.

What Type of Search is Right for You?

For many functions in the organization the full text “Google” like search capability found in most document management systems may be useful.  For others, it’s not sufficient in providing the business value.  Here’s some situations that may help determine what is right for you.

A business professor once said “There are three core functions to any process… 1. Procurement of Materials 2. Conversion of Materials and 3. Distribution of those Materials.  All other functions only support these three”.  In translation, these three things can map to any function found in business for any department (Sales, HR, Information Technology etc.)  It seems that when analyzing any business process, this old adage always comes back and discussing search in the enterprise is no exception.

When looking at search it’s helpful to see both sides of these functions for document management.  Documents either “drive the process” as a core function, or documents are ”driven by the process” as in a supporting role.  The differences are not all that hard to see.  Document that drive the process are directly related to the three functions above 1. Procurement 2. Conversion and 3. Distribution.  Documents that are driven by the process may be everything else.

Vouchers, Invoices and Checks are all documents that drive Purchasing.  Service Orders and Proof of Delivery are documents that drive Operations.  Purchase Orders and Service Contracts drive sales. 

On the other side, Marketing Literature  is driven by Marketing.  Brochures are driven by Sales.  The company Calendar is driven by HR and Inventory Reports are driven by Operations.  These documents support the functions of their departments.

A less technical way to look at this dichotomy is ”gotta have that document now” and “gee, this looks like what I’m looking for”.  When designing a search architecture, this is one of the basic questions you can ask yourself.

Documents that drive the business process tend to require a discrete index field search.  This is because the user is typically looking for the one document they need, and they need it quick.  A Sales Order for a customer service representative or an Invoice for a purchasing manager.  These documents also typically already have a structured meta-data component already designed for them before the document management system is in place.  A Sales Order Number field is always generated for Sales Orders and an Invoice Number Field always has an Invoice number.  This is true before or after a document management system exists.

Documents that are driven by the process are less structured in nature.  Marketing Literature, Progress Reports and the Employee Vacation schedule to name a few.  The user is typically looking for some information that could be in one, or many of these documents.  Could an employee figure out if Memorial Day is a company holiday by finding the wrong documents to their search?  Like last years vacation schedule?  Probably so.  If this is the case, a full text content search may prove successful.

Documents that “drive the process” answer questions to a search that only that one document can satisfy.  What items were billed for Invoice # 123456?  What date was Employee #78910 hired?  Who signed for Proof of Delivery #34567?  In these cases, a discrete index field search is required.

 

John Moffitt

Systems Engineer

ImageSource, Inc.

http://www.nexusecm.com/index.htm

www.imagesourceinc.com

www.ilinxcapture.com 

  

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.