Most ERP projects promise to transfer software knowledge from the consultants to the client. Once a project is over however, the client is often clueless about how to make software configuration changes, and may even struggle with performing basic transactions in the system. So what gives?
Even though many aspire for successful knowledge transfer, most businesses lack a real strategy to make it more than just a dream. Secondly, when push comes to shove, we often set learning to the side and think we can worry about it later (which, of course, never happens). Think of what would happen if consultants built a spaceship to get you to Mars but decided to not plan the return trip until after you got there. In other words, consultants who assume software knowledge will somehow automatically cross-pollinate face business consequences. Some consequences include the following:
1. Paying consultants to do project task that the client could (and should) be doing. Without a certain level of software knowledge, the client will struggle to fulfill even the most basic project responsibilities. Beyond that, what incentives do consultants have to transfer knowledge? As I have said before, the less you know the more money they make!
2. Fostering resistance to change. When it comes to change management, we are often our own worst enemy. It is not hard to imagine why employees refuse to buy into something they do not understand (no matter how great it sounds). When consultants are running the project because the team is unable to learn, many employees understandably view the project as a ticking time bomb.
3. Software quality will suffer. If the client team lacks software knowledge, it cannot be proactive in the design of new business processes and software. In this case, unless the consultant is Superman (and they never are), something very important will slip through the cracks. On the other hand, a client that has a decent understanding of the system can at least ask the right questions or spot things that may be wrong with the software.
4. You pay consultants to camp out for years after the initial go-live. After all, someone must hold the hands of untrained users and make simple software configuration changes. Clients face a similar issue when attempting to implement new releases without an army of consultants.
5. The software remains static while the business needs change. The reasons: a) no one internally is aware of what the software is capable of doing; b) no one internally understands how to make the changes; c) the alternative of hiring consultants costs too much. These issues boil down to a failure to leverage your software investment. In the meantime, users are told to live with the software and “work around” the functionality issues.
6. As employees change jobs, leave the organization, and are onboarded, consistency in user procedures and knowledge of the system slowly erodes. This is inevitable considering no one can explain the big picture or the original software design intent. Therefore, new users are not trained correctly and simply do the best they can (we are now back to sub-optimization).
7. The organization makes modifications to the software to support needs that the software already addresses (right out of the box or with a few configuration changes).
8. After several years of struggling with the software, the organization finally hires an employee from the outside with the expertise to provide needed support. If they had done so prior to implementation, they could have saved themselves a lot of money and grief.
9. The organization outsources the application support with the hope that the problem goes away. Don’t kid yourself; if no one internally can make sense of user requests (from a software design and set-up standpoint) or actually make configuration changes, outsourcing may cost more than you think (service or change orders).
Knowledge transfer is not a one-time event, but a project management “thread” that runs throughout the project cycle. It requires a strategy and attention to execution. In other words, you must manage the consultants and the internal team with the objective of knowledge transfer in mind. The following is a list of items to consider in any knowledge transfer strategy:
1. Select application consultants who have implemented their assigned modules on at least three other projects (with at least one in a similar industry, scope, and degree of complexity). Otherwise, there may not be much knowledge to transfer. Also, they will spend most of their time trying to figure out the software (at your expense).
2. Select application consultants with good oral and written communication skills. Understanding software is one thing, but if the consultant does not communicate very well, they may undermine the goal of knowledge transfer. In addition, a consultant twho simply does not say much may also be a consultant who does not know much.
3. Understand that rapid deployment or fixed price consulting engagements can work against you. These type of projects may (or may not) result in a faster or cheaper implementation; but they are definitely more consultant and date driven. This means the client may not have the chance, and the consultant may not have the time for knowledge transfer.
4. Put together an internal project team that has the desire and ability to learn the software. The core skillset includes understanding your business processes, demonstrating business systems analysis skills (process oriented, logical thinker, problem solver), and being willing to roll up their shelves and dig into the software. If you do not have employees with the right skills, get them. You will need them longer than you think.
5. Establish clear expectations with the team and consultants that knowledge transfer is a key priority and shared responsibility, and that progress will be measured. For example, add a “knowledge transfer status” segment to the agenda of project team meetings and executive steering team meetings. Schedule one-on-one discussions with each team member and consultant to discuss specific issues.
6. Do the formal project team training (but do not reinvent the training wheel). This training is normally conducted after the software is acquired but before the design phase. When done correctly, classroom style training for the project team is of considerable value since it lays a solid foundation for continued learning. However, when poorly planned or executed, it is a waste of time.
As general rule, I prefer courses offered by the software vendor (not those delivered by the consultants you might have working on your project). First, vendor training programs are developed by those with expertise in both formal teaching methods and the software. These courses are also time tested. In other words, your team will probably not be the first to take them. A professional trainer typically conducts the course with a pre-defined training agenda, lesson plan, data and supporting materials. As a result, you generally receive a more comprehensive coverage of the software capabilities, consistency, smoother delivery, a software perspective other than that of your consultants, and access to up-to-date training materials.
On the other hand, when consultants deliver the lesson plan and training, you risk the opposite (narrow scope, poor quality, etc.). This is not necessarily due to bad consultants. Generally, the need to reinvent the training wheel causes problems with this approach. Secondly, do not underestimate the time that the consultant requires just to prepare for a class. This is one reason why training delivered by consultants may end up costing much more than vendor training. Finally, many consultants are willing to customize the training beyond what is reasonable or advisable. Classes may be customized to the extent that they are no longer actually training, but instead a premature design or testing session. Remember, the goal at this stage is to learn the software capabilities and basic transaction processing, not test or determine how they will be used. The truth is no one at this point has enough information to design or test anything.
7. Plan courses to maximize learning for the dollars spent. When scheduling classes, first take only the basic courses required for each module. After the team has worked with the software for a while (with the assistance of your consultants), take the advanced functionality if you need to. With this approach, the team has a chance to absorb and reinforce what they learned during initial training and, as a result, should be better prepared for advanced topics and likely will have more specific questions.
Finally, do not send a cast of thousands to project team training (the idea is the project team will train others). The key people to attend the courses for a given module include the module team lead, the power user (functional analyst), the internal consultant (if you have one), and the IT developer (supporting the module). Recognize it may be appropriate for a few others to attend, such as the department manager (not formally on the team), power users from other highly integrated modules, etc. However, as a general rule, training only those on the project team is the best use of time and the training budget. That is why they call it “project team training”!
8. Take the software configuration classes. When offered, these courses get into the software’s parameters, switches, and settings. The point is, most classes focus on end-user transaction processing, but the software configuration classes get into what is behind the curtain (but are not about writing programs). These classes are very important because if you aim to wean yourself from consultants, you need the team to understand how to maintain the software setup. The list of attendees for these type of classes is shorter and includes the module team lead, power user, and IT support.
9. Set up a playground software environment. When the team returns from training, they need an immediately available environment to reinforce learning and do some self-help follow-up testing. This playground needs to be mandatory.
10. Develop a realistic (yet aggressive) schedule to transition consultants into support roles. When developing internal software expertise, the consultant generally has primary responsibility for initial software setup and other application activities (based on client input). However, as the internal team gets up to speed and confidence grows, you need a plan to transition primary application responsibilities from the consultants to the client module team. At this point and thereafter, the consultants play coaching and support roles. This transition should occur as soon as it is realistic to do so and should be targeted for specific project milestones/dates. Some client teams start this transition after the design phase or after the software is configured (construction phase). At the very latest, the internal team should take primary responsibility once formal testing begins.
11. Make sure the internal team (client team) is available for knowledge transfer. A consultant cannot educate a client that fails to show up for meetings.
12. Insist that consultants give homework assignments to the project team. The assignments should require the team to work with the software on their own with some meaningful expected outcomes (reviewed by the consultant). Most people learn by doing, struggling a bit, and making a few mistakes. In fact, a client should work on assignments when the consultants are not around. If the team does not have these experiences on their own, the consultant will become their crutch.
13. Require the internal team (not consultants) to perform software demonstrations, design reviews, and management presentations. This is not about throwing your team to the wolves. However, if you expect nothing from the team, that is exactly what you will get. These activities should be part of any implementation methodology and must start early and occur often. When the internal team knows they will eventually take the lead for these activities, they feel more driven to learn and move out of their comfort zones, expediting the process and providing a gauge of learning progress. These types of activities also build team confidence in their own abilities.
14. Take advantage of all learning resources available for your specific ERP system. This involves some self help (a very necessary part of learning) through web communities, memberships, and white papers (obtained from the consultants or software vendors). These type of white papers (not to be confused with marketing “white papers”) explain the step-by-step details of setting up the software to perform certain functions.
15. The client team should create most of the project documentation related to software usage and set up. Examples include work procedures, end user training materials, and system documentation with screenshots and explanations. The premise is if the client is required to do documentation (with a consultant-provided quality review), the client will learn many things in the process.
16. The client team is expected to train all end users prior to go live. Again, if you are training many people, you will probably feel the need to learn the software. Keep in mind, consultants play training support roles. (What is required to transfer knowledge to the end-user is a different topic.)
17. Put the client team on the frontline of post go-live support. There is no better incentive to learn the software then knowing you will field the real-world questions and issues once the rubber meets the road.
~~~~~~~~~~~~~~~~~~~
Reposted with permission from my friend and author Steve Phillips who runs a blog entitled Street Smart ERP – Visit his site for great insight and commentary.
The original post can be seen here:
