Putting Together an ECM Project Team

April 29, 2010

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.

PUTTING TOGETHER AN ECM PROJECT TEAM

February 18, 2010

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, ECMM, CDIA+
Project Manager / Senior Business Analyst
ImageSource, Inc.


Putting Together an ECM Project Team

November 24, 2009

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?

September 25, 2009

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.

Share on Twitter


Quality Management Within the ECM Project Plan

September 10, 2009

For every major ECM project being defined and planned, a Quality Management Plan should be included within the Project Plan and consider that:

  • Quality planning can be, and is usually closely related with aspects of the Risk Management Plan.
  • Quality planning does define the aspects of the project to which quality standards apply and how to measure and report on compliance.  Benchmarking will be accomplished in accordance with realistic expectations and the customer/stakeholder’s requirement that benefit analysis or ongoing metric comparisons be provided outside of or within the purview of the Project.
  • Quality assurance is included as an application of the Project Plan to assure that an analysis of where standards apply is actually accomplished according to the processes for Quality Assurance that are identified in the Project Plan. 
  • Quality control is reflected in the process used in the monitoring of project results at key points within the project and/or at relevant points within each Deliverable as appropriate. 
  • Some monitoring is constant and in compliance with professionally established practices.   The actual monitoring activity, along with reporting and meetings, is planned and critical activity junctions are considered for specified attention.   Monitoring processes are closely tied with the “Communications” Plan so that a the internal customer or external organization’s Project Manager and team is apprised of project status as pre-planned or as is prudent.

Neil W. Lindsey
Project Manager / Business Analyst
ImageSource, Inc.
See me at Nexus 2009

Share on LinkedIn   Share on Twitter


Embracing Client Budgets in Meaningful Ways

August 21, 2009

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.

Share on LinkedIn Share on Twitter


Change Management and User Adoption

August 8, 2009

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 Thingsguest 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.

Share on Twitter


ECM Upgrade – Do it Yourself or Turn to the Experts?

July 31, 2009

Content/Document Management (“ECM”) systems are built upon software platforms that are continuously innovating and improving features and performance.  The vast majority of organizations using ECM systems subscribe to Annual Software Assurance so they can continuously receive updated or upgraded software as it is released by the software publisher. 

For example, Oracle® and Kofax® are software publishers of two of the frequently implemented ECM solutions among the many that are supported by ImageSource to provide solutions for clients.  These two major software vendors  have traditionally been expected to publish major upgrades approximately every 18 to 24 months. 

Users of ECM software understand that it is critical to maintain currency with regard to the versions of mission critical software applications they are running.  By upgrading to new releases, you enhance your ECM system with new features and functionality and maintain your investment.  You also stay on the most current version so that you always acquire the benefits of having the fully up to date software throughout the life of your system.

The question frequently asked by user organizations is whether or not to implement major upgrades using internal resources, or turn to an expert and trained vendor to work with them to get the tasks completed.  With each new release, the new software version solves additional business challenges and offers new functionality. 

Some vendor and integrators (ImageSource included) offer an Upgrade Consultation Program.   Using this approach is ideal for customers who are currently using an older version of the software applications, have received or are about to receive their update/upgrade, and are interested staying current and moving their system to the latest product release.  This professional services program is normally designed to accurately identify all of the technical and functional considerations that need to be taken into account prior to and during an upgrade. 

Major reasons to consider the involvement of your ECM vendor or integrator as a business partner when you are faced with a major upgrade can include factors where the experienced vendor or integrator:

  • provides technical resources that may not be available internally, or only available at the sacrifice of other planned internal projects
  • has specific training with regard to the version upgrade being implemented – they know the most efficient way to complete the required tasks
  • has deep software product knowledge and prior experience implementing the upgrade at other clients
  • has dedicated staff whose primary job description and every day experience is working with the software and all aspects of installation, planning, and other important factors.  User organizations do not usually have staff that spends significant time and an intense level of focus on the intracies of the ECM system software.
  • frequently, as a part of the upgrade project, organizations take advantage of new features to implement improved processes and applications – or just make the effort to enhance the system with new productive solutions when additional ECM training within the organization is going to be scheduled anyway

The recommended program should follow a formal Project Methodology developed through specific knowledge and experience.  It should provide the user organization with the analysis, process, a defined Project Plan and a firm cost to move forward with the assistance resources needed for a major upgrade project.  This analysis and planning is critical in order to minimize potential complications and allow a smooth and successful upgrade with minimal if any reflection on the productive use of your system.

User Organization Benefits of an Upgrade Consultation

  • Increase return on the initial investment in the ECM system by implementing additional functionality
  • Benefit from the expertise of a knowledgeable and trained Project Team who utilize best practices
  • Gain a detailed understanding of the project requirements and cost justification of an upgrade
  • Understand system requirements to ensure success
  • Understand the opportunity for organizational benefits leading to improved operations
  • Identify major considerations upfront and proactively determine ways to avoid risks
  • Define the Training Program that will optimize the new upgrade features and benefits

Primary Tasks in an Upgrade Consultation

  • Current system audit and assessment
  • On-site analysis and interviews
  • Current system snapshot and baseline metrics
  • Create upgrade execution plan
  • Review upgrade execution plan with customer

Project Plan Developed For an Upgrade Project

  • Report on the opportunities, benefits, and functionality that will result from the upgrade
  • Architecture analysis — a detailed analysis to review the current hardware and network architectures and then identify any recommendations for improved performance with the upgrade
  • Upgrade Project Schedule and execution plan (procedures, activities, roles, prerequisites)
  • Firm – Fixed Cost based on disclosed considerations and staying with the Project Plan
  • A Project Plan developed in conjunction with, and presented to, key stakeholders (IT, application owners, executive management, etc.)

On average, an Upgrade Consultation Program should be able to be completed in seven to fifteen days – depending upon the complexity of the installation and the amount of customization that has been included with system design.   If you are attending NEXUS 2009, make sure to discuss your approach to your next major upgrade project.

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

Share on LinkedIn   Share on Twitter


Basics of Consulting for the ECM Project

July 31, 2009

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

Share on Twitter

Follow

Get every new post delivered to your Inbox.