Nexus is Coming!

The ImageSource NEXUS ECM conference is fast approaching.  NEXUS is a unique opportunity for you to discover:

• How companies lever ECM beyond traditional Account Payable Invoice processes
• Lean about Enterprise Content Management industry trends (Cloud, Mobile Technologies, Social Media, to name a few)
• Invaluable opportunities to meeting and collaborate with industry peers
• Attend certified educational seminars
• View current ECM related technologies
• Participate in one on one sessions with industry technical and business experts
• Hear about using ECM as a tactical advantage is solving today’s business issues

All this as well as the ability to earn industry accreditations:

1. Project Management Professionals (up to 20 PDU’s)
2. Certified Records Managers (10 ICRM CMP Credits)
3. Healthcare Professionals (16 AHIMA Credits)
4. Accounts Payable Processionals (IAPP Credits)
5. Business Analysts (IIBA Credits)
6. American Payroll Association (3.5 RCHs)

NEXUS is a conference you can’t afford to miss!

Hope to see you there.

 

NEXUS 2011
November 3 – 4, 2011
Meydenbauer Convention Center, Bellevue Washington
To learn more: www.nexusecm.com

 

David MacWatters
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.

  

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.

  

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.

  

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.

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.