PUTTING TOGETHER AN ECM PROJECT TEAM

Part 2 – The Project Team

I discussed in the last blog on this general topic that the strong support of the intended Project by executive management is a critical factor for success – they need to support the projects sponsor, and smooth the path of challenges that sometimes occur when change is contemplated.  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, and then it effort fans out to focus on users and supervisors. 

What Will be the Right Team
The right team of players, working together to hone the vision, is required to construct the concepts to be considered, refine the concepts, and to develop strategies to support the selected conceptual structure to fruition.  The people on the team are as integral to your project’s success as the solution, the project plan, the software tools, and infrastructure that is chosen.

Forming the right team is not easy – as not all leaders and users welcome new ideas and changes to the routine process.  But the executive support and the right team members are just as important for for standard ECM projects success as these factors are vital for business process management (BPM) and integrated implementations.

The primary key role types that are required on any ECM project team are listed below.  The exact position titles and numbers of team members recommended for participation will differ depending on an organization’s size and individuals’ skill levels. It is important that the eight classifications of people resources below are part of the Project team.

1. Executives: provide the supporting vision and enthusiasm for the solution objective

2. Line-of-Business (LOB) Managers: provide important project support and key higher level objectives

3. Business Analyst: provide discovery and analytical resources, reporting, perspective and ideas

4. Records/Compliance Manager: assure objectives and solutions match mandates and requirements

5. IT/IS Manager: supporting infrastructure, including business & IT challenges into the plan

6. WorkGroup Manager/Supervisor staff:  provide working knowledge of operations being addressed and realistic possibilities on what will work and where the challenges will be

7. End users: discovering what will and won’t work and where the challenges for acceptance are

8. Project Manager:  This person is the organization’s operational leader of the project and the coordinator with outside resources – ECM industry experts, software vendors, conversion resources, Training, etc. 

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

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

Basics of Consulting for the ECM Project

Many organizations look for expert assistance in a quest to justify, plan, and develop the concepts for an Enterprise Content Management system (ECM) or smaller departmental system using this technology.  A provider of these services needs to have demonstrated expertise regarding consulting services focused on the application of the entire breadth of the disciplines associated with Enterprise Content Management.  General business process or management consultants seldom have the experience necessary to provide the requisite resources.  The solutions addressed by the consultation project need to focus each client’s objectives and how they may have to be addressed by the professional application of a combination of:

• Document Management
• Document Imaging / Image Management
• Digital and Physical Records Management
• Digital Asset Management
• Business Process Management and Workflow
• Reports Management (ERM / COLD)
• Content Addressable Storage
• eForms Design, Library management & business processes
• Legacy system and database integration for data sharing (i.e. SAP, Oracle, PeopleSoft)
• Legacy system integration for image enablement of third party applications
• Digital signatures and data encryption
• Large Document Viewing Enhancements
• Data capture technologies & custom document and data capture management
• OCR/ICR/OMR & bar code reading
• Data capture from Digital forms and Web forms
• Web Publishing & Content Management
• Web based information delivery systems
• Network Fax Systems and capture
• Collaborative Portals and resources
• File conversion, document migration, and scanning services
• Application Development and Programming Services for Custom Requirements

Consultants need to be able to actively provide expert participation and guidance in analysis to determine requirements/objectives, develop and validate goals and expectations, and apply capabilities of technology for application concepts, business processes, and design at the workgroup, departmental, and enterprise requirement levels per objectives. 

Consultants need to provide resources to advise and direct on project aspects such as technical design specification for hardware, ECM software platforms and components, the network infrastructure, conversion and migration of document information, the training program and facilities to be utilized. 

A consultant’s roll can consider numerous other ECM specific factors such as performance standards, operational and functional objectives, ROI analysis, Change Management considerations, and others which frequently need to be addressed, researched, analyzed, documented, and presented to the client when . 

ECM Consulting Services should also be able to address and provide guidance on the following when generating documentation to the client in the form of a Consultant Report, a Project Charter, and/or a subsequent full Project Plan with design detail:

• Current process documents and flows of work
• Project Scope Planning, Definition, and Management
• Definitions – Process Re-engineering to Technical Opportunities
• Project Deliverables Definition
• Work Breakdown Structure (WBS) at the Project Plan level
• Conversion and Migration Services Requirements – Deliverables
• Standard and Advanced Training Curriculum Planning and Management
• Quality Control Strategies and Planning
• Project Cost Estimating Costing

Application Design for Project Standard Deliverables as well as Architecture Engineering Analysis and recommendations.  These can include conceptual to detailed Design for standard and custom system components and design details for:

• system configuration, and all standard software modules
• document/image capture including information capture considerations for workflows and business processes
• planning, design, and development for web-based resources
• interfaces and integrations with legacy systems as required by objectives
• Activity Definition, Sequencing, and Predication Planning
• Risk Identification and Management Planning
• Duration Estimation with Project Schedule Development and Control (Microsoft Project) when developing Project Plan level strategies plans.
• Project Team Development and Management with Resource Planning
• Communications, Information Distribution, and Performance Report Planning

The consulting organization may bring multiple experts to guide and participate with the client in the discovery and analysis process. Consultants, no matter what their expertise in a particular vertical application, should remain open to a client’s specific goals and interests and not automatically apply past experiences to the specifics of what solution a new client will need.  There should be an initial concentration on specifically defining business challenges, phased implementation priorities, and evaluations of the best opportunities for initial success. This process leads to business solutions that integrate with a client’s standing technology investment and unique business culture, and result in real returns if managed professionally.

Find out more about ECM Strategies and Project Planning at NEXUS 2009

Neil W. Lindsey, Project Manager
ImageSource, Inc.
www.imagesourceinc.com

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.