Question: "We have been told by several people that we do not need a dedicated Conference Room Pilot facility, that it can all be done from our regular workstations via Internet meeting technology and conference calls. Why are you so insistent on having a physical place, a meeting room for the team? Isn’t this a bit "old school?"
Answer: "Good question; goes to the heart of how we do, or don’t work together. We are great fans of Internet meetings and conference calls, and have done significant portions of projects using these tools. However, there ARE limitations. As a guideline, the more closely a team needs to work together, to trust each other and communicate not only hard data information, but to perceive more subtle forms of communication, the more physical presence will prove valuable and, in the end, will save major amounts of time.
The lack of trust is the greatest cause of additional work on team-based projects, because it leads to CYA work, which does not add value to the actual project itself. When people are physically in the same room, learning, growing, arguing, debating, collaborating, disagreeing and resolving issues, there is an opportunity for trust to really grow and strengthen. If you label in-person communication as "100% of the information" that passes between people, as you move further away from this, major portions of this "100%" are lost. Video conferencing would be the closest, followed by Internet meetings, with phone conference calls in last place. Each increment allows the participant to pay less and less attention to what is going on. Everyone is under intense time pressure, it seems, to "multi-task" which is techno-speak for "I’m not really paying attention to you."
Advanced web meeting technology allows the presentation organizer to discern who is really paying attention to the presentation, as the viewer client software can detect and communicate real-time to the organizer who has moved the window into the background, to work on their email or something else. This doesn’t happen when you are in the same room together. Your CRP is way too important to allow it to be "moved into the background."
-
Friday, July 13, 2007
Friday, July 6, 2007
Implementation: Conference Room Pilot Preparations
Article Summary: In previous newsletter articles, we focused on the “front-end” of an implementation project, including setting up clear top management support, involvement and communication, and selecting a Best Practice implementation project team. When these are accomplished with Best Practice methods and principles, the team is, at this point, operating in a low-risk field – so far, so good.
In this article, we discuss preparation for a Best Practice Conference Room Pilot. This includes making sure the team itself is sufficiently educated and trained, and that the CRP itself is sufficiently organized. In our next issue, we will discuss the detailed implementation preparation activities, the “dress rehearsal” aspect of the CRP – where the rubber hits the road before the rubber really hits the road – and the Go-Live preparations critical to success.
Topics include:
- Education and Training for a CRP
- CRP – the Dress Rehearsal
- CRP facility – organizing for success
Education and Training for a CRP
The first step in this area is to clearly separate education from training. Briefly, in the context of implementation, the purpose of education includes:
- New concepts – these are underlying thought processes, and assumed understanding that is embedded in the Best Practices integral to the new software. The implementation team must clearly understand these if it is to be effective in the CRP process and implementation preparation that is at the core of the CRP. Often these are different ways of looking at things, different perceptions. If one doesn’t understand these, there can be a real crippling effect, as people (unintentionally) try and force-fit the new software to work the “old” way.
- Example – many problems associated with implementations of material planning (MRP) functions stem from the fact that those using it have not been adequately educated in MRP concepts. Effectively using software delivering MRP capabilities has a poor chance of succeeding if the users are blindly clicking on buttons and following rote procedures. A person who truly understands the concepts involved with a particular software function can almost figure out how the software works on their own.
- Precedes and informs detailed planning – if those who are planning the project truly understand the concepts behind the business processes, and the revised, more effective work flows that will come with the software, the steps from “here” to “there” will be considerably shorter and more direct.
- Speeds up detailed, hands-on training – As was just mentioned, the actual amount of detailed, hands-on training needed to become proficient with the software is a small fraction of that required to “teach” rote-style, how a person is to do their job with the new system. We have observed people like this taking notes that say “hit the down arrow 3 times, then press Enter…” and the like. Frightening, from a management point of view! As MRP legend, George Plossl said many years ago “If you think education is expensive, try ignorance!”
For the complete article, please visit the PROACTION website "Conference Room Pilot Preparations".
-
Tuesday, July 3, 2007
Best Practices Q & A - Part 14
Question: “Several of the people that appear to be the best choices for our implementation project have worked at this company their whole career. How do we bridge the gap for these otherwise good folks between the ‘way we’ve always done things’ and the new Best Practices that we hope to bring into operation with the new system?”
Answer: “While the first impulse answer is ‘education,’ in reality it is ‘support.’ These folks must feel secure in their place in the company, in their jobs and roles, to be able to embrace changing how they look at things, how the work is done. No amount of education, to an unwilling, threatened or frightened person will stick. The more it is pushed on them, the more they will tend to fight back, to resist, defending the status quo. Naturally, this is the opposite of what you want to accomplish. If your leadership pays quality attention to these seemingly non-business, yet essential needs, these people may become the champions you need to lead the change because they are often very loyal to the company and really want to see it succeed now and in the future.”
Monday, June 25, 2007
Implementation: Best Practice Teams
Article Summary: In the previous newsletter’s feature article, we focused our attention on the “front-end” of the implementation project. This included how to establish meaningful ownership of the project, how critical real, effective leadership is, and the pivotal issue of setting up clear, unambiguous top management support, involvement and communication. When these are consistent with Best Practices, the implementation team is operating in a zero or low-risk field – they can stick out there necks, own their work, be fact based (not “politically” oriented), with little or no CYA activity. The focus is instead on getting everything in place solidly, getting it “right” and effectively identifying and resolving all potential problem areas.
In this issue, we’ll focus on the formation of the implementation team, who should be on the team, who not, what areas they’ll come from, and how to organize the team so the company isn’t driven off the proverbial cliff with no one at the wheel. Topics include:
How NOT to create an implementation team
To continue a recurring theme in this topic we touch once again on the CYA factor, and the importance of confronting it head-on. This same thought process should be carried over into selecting the team leadership and members. This kind of activity is overhead, extra baggage and waste of the first magnitude, and can in itself cause a project to fall short.
Remember – once the project is done, no one will care in the least who said what at a meeting, or what the basis for a minor decision as – only that it was successful, and if/where it is not, what is underway now to correct it. When serious CYA activity is going on, it is prima facie evidence that there is a lack of trust. When you find this going on, drag it and whatever “sacred cows” are involved out into the open, shine light on it with candid, honest discussion, then provide leadership and support to re-establish trust.
We mention this in the context of team formation because of far too many examples we’ve seen where teams were selected with the desire to absolve one’s self of blame of any sort for possible failure, not only of the implementation project, but of possible operational short-falls that could result from the implementation.
By identifying implementation team mistakes, we will concurrently illuminate their logical opposites, Best Practice team formation methods. Here are some of the bigger, yet surprisingly common mistakes companies make when assembling an implementation team.
This depressing “checklist” is included here, in an otherwise positive-oriented set of guidelines specifically because we, and others, have so frequently seen them in actual practice. Although it is widely known that implementation projects are risky, what is NOT so widely discussed are the causes of the risks. We’ve just covered some of the major ones – where problems or failure were almost built-in from the start.
To take an example – sky-diving – the act of jumping out of a perfectly good airplane couple of miles above the earth’s surface, would appear to be highly risky, and it is, if you aren’t prepared. Just “going for it,” in this situation can and has resulted in a greatly shortened life span. Similarly, in a complex business change, i.e., software implementation, rigorous planning, preparation, education and training virtually eliminate risks, just as it does in sky-diving. And high blood levels of testosterone won’t bridge the gap.
This depressing “checklist” is included here, in an otherwise positive-oriented set of guidelines specifically because we, and others, have so frequently seen them in actual practice. Although it is widely known that implementation projects are risky, what is NOT so widely discussed are the causes of the risks. We’ve just covered some of the major ones – where problems or failure were almost built-in from the start.
To take an example – sky-diving – the act of jumping out of a perfectly good airplane couple of miles above the earth’s surface, would appear to be highly risky, and it is, if you aren’t prepared. Just “going for it,” in this situation can and has resulted in a greatly shortened life span. Similarly, in a complex business change, i.e., software implementation, rigorous planning, preparation, education and training virtually eliminate risks, just as it does in sky-diving. And high blood levels of testosterone won’t bridge the gap.
Project Leadership – selection and administration
Strong, internal project leader – Select a key leader, not “manager”. A key hands-on executive or relatively senior manager (not the IT manager) should take this role – he/she will be a powerful force for ownership. Here’s how to keep from overwhelming this person:
We have found there is frequently a lot of confusion over the roles of project leadership, management and administration. Leadership is clearly the most powerful and critical, yet most of the time for getting a project to move forward is devoted to administrative work.
Keeping the project leadership securely in his/her power base of a key line management role insures that reality is an integral part of the change/implementation process and keeps ownership solidly in place as well. The Best Practice here is to select a real, effective leader, keep that person in their primary job, while providing supplementary support to back-fill the person in their primary leadership role, while off-loading as much of the project administrative work as possible.
This strategy allows the project leader to truly be physically and emotionally able to continue to provide leadership in the primary business role, yet also effectively lead the change process for the company, including his/her own work area as well at the same time.
Selecting team members
In the NOT to do it discussion, we eliminated many of the most common, yet failure-driving ways to create an implementation team. Similarly, the theme of hands-on, leadership based individuals who are capable of the degree of ownership of the results in their own work areas, plus the implementation team we can concisely summarize how the team should be assembled and who should be on the team:
Note the common thread of ownership – the before and after work, having people remain in their line roles, and keeping communication and responsibility lines within the team short and effective, with a minimum of overhead. And, of course always selecting people who exhibit real leadership qualities. This “follow-me,” lead by example method has proven very, very effective in countless situations of change within work groups. A solid leader helps people feel relatively safe and secure in the midst of change, potential confusion and what they feel will be the chance of mistakes.
Success Example
One company we are familiar with, a $ 50 million/year high tech manufacturing company, was unable to utilize much of its implementation consulting budget that it had planned. The company is highly customer focused, with many short-notice on-site visits by key customers. Consulting resources from the software company had to be scheduled in advance, and frequently were cancelled at the last minute, or went under-utilized while they were on-site.
This forced the management to “do it themselves” – using Webinar and conference calls to tap into outside expertise just for educational purposes, so they could learn what was needed. Since they were working nights and weekends, they really wanted to get it done soon, yet since the team was entirely composed of key line managers, making sure it went well was critical.
As a result, all of the planned functions in the new system went into live use only a few months after starting, with only a small portion of the external consulting support that had been planned being utilized.
This simple example illustrates the key points involved in Best Practice implementations – all centered around maintaining effective ownership of the before and To-Be processes, and all steps between the two. In this instance, the company’s leadership was able to simultaneously keep things moving well in their work groups while moving the implementation forward, without the off-loading and back-filling steps recommended above. However, in a larger company, this may not have been possible – the additional work would be more than could be handled by some evenings and weekend work.
In our next issues, we’ll continue the implementation discussion, moving onto the topics of education and training, and the all-important conference room pilot.
If you like this article and think it's helpful, please spread the word and digg it.
-
In this issue, we’ll focus on the formation of the implementation team, who should be on the team, who not, what areas they’ll come from, and how to organize the team so the company isn’t driven off the proverbial cliff with no one at the wheel. Topics include:
- How NOT to create an implementation team
- Project leadership – selection and administration
- Selecting team members
- Success example story
How NOT to create an implementation team
To continue a recurring theme in this topic we touch once again on the CYA factor, and the importance of confronting it head-on. This same thought process should be carried over into selecting the team leadership and members. This kind of activity is overhead, extra baggage and waste of the first magnitude, and can in itself cause a project to fall short.
Remember – once the project is done, no one will care in the least who said what at a meeting, or what the basis for a minor decision as – only that it was successful, and if/where it is not, what is underway now to correct it. When serious CYA activity is going on, it is prima facie evidence that there is a lack of trust. When you find this going on, drag it and whatever “sacred cows” are involved out into the open, shine light on it with candid, honest discussion, then provide leadership and support to re-establish trust.
We mention this in the context of team formation because of far too many examples we’ve seen where teams were selected with the desire to absolve one’s self of blame of any sort for possible failure, not only of the implementation project, but of possible operational short-falls that could result from the implementation.
By identifying implementation team mistakes, we will concurrently illuminate their logical opposites, Best Practice team formation methods. Here are some of the bigger, yet surprisingly common mistakes companies make when assembling an implementation team.
- Have an external project manager – assign project management to a person who is an outsider, not in any way a part of the company’s success, failures, or culture. He/she will be an “expert” in a mysterious, dangerous process, but if/when it crashes, will be long gone.
- Depend heavily on external skills and resources - hire temps, consultants, people hired only for the project. This will make the internal people feel completely incapable of performing on their own, and thus remove ownership from it. Almost all huge implementation failures have this element in common.
- Reassign key internal people full time to the team – remove them from their daily jobs and responsibilities. This way, they cannot fully own the resulting success or evaluate risks. They will now be in “their own little world.” Meanwhile, life moves on in their former departments, new political alliances are formed, new in/out groups, and new “secret handshakes” created. They must “sell” everything they do to those still in their old departments and work groups. Challenges, high potential for difficulties and failure are virtually assured.
- Assign expendable people to the team – when department managers are asked to select people for implementation teams, it is VERY hard for them to select their best people – or even harder, to take the responsibility on themselves; they just feel way too overwhelmed. Further, they depend on their best people to keep things together, working well – vital for their own performance reviews, raises, etc. So, the “weakest link” is often selected. Once again, challenges, high probability for difficulties or failure are virtually assured.
- Create a large team - with many people on the team, they’ll have to spend a lot of time in meetings, communicating with each other, resolving disagreements, etc. This dramatically increases project overhead, adds confusion, decreases individual ownership. Once again... You can see where this leads – once again.
- Make a long schedule – allowing a long time for the team to prepare, convert and Go-Live greatly adds to the number of meetings, CYA projects, and changes in team members, none of which actually moves the implementation forward. When new people join the team, they have to “get up to speed” – all extra work, with no added value on the actual project itself. With a long project, the percentage of time devoted to status reporting, meetings, communications, reporting to top management, collaborative sessions with work groups, changes in business processes and strategy – all dramatically increase, thus once again – increasing the probability of difficulties or failure. A short, tight schedule may appear counter-intuitive, but it is a fact. A multi-year implementation project is almost assured of never succeeding fully, simply because of leadership changes, both within the company, and on the team alone.
This depressing “checklist” is included here, in an otherwise positive-oriented set of guidelines specifically because we, and others, have so frequently seen them in actual practice. Although it is widely known that implementation projects are risky, what is NOT so widely discussed are the causes of the risks. We’ve just covered some of the major ones – where problems or failure were almost built-in from the start.
To take an example – sky-diving – the act of jumping out of a perfectly good airplane couple of miles above the earth’s surface, would appear to be highly risky, and it is, if you aren’t prepared. Just “going for it,” in this situation can and has resulted in a greatly shortened life span. Similarly, in a complex business change, i.e., software implementation, rigorous planning, preparation, education and training virtually eliminate risks, just as it does in sky-diving. And high blood levels of testosterone won’t bridge the gap.
This depressing “checklist” is included here, in an otherwise positive-oriented set of guidelines specifically because we, and others, have so frequently seen them in actual practice. Although it is widely known that implementation projects are risky, what is NOT so widely discussed are the causes of the risks. We’ve just covered some of the major ones – where problems or failure were almost built-in from the start.
To take an example – sky-diving – the act of jumping out of a perfectly good airplane couple of miles above the earth’s surface, would appear to be highly risky, and it is, if you aren’t prepared. Just “going for it,” in this situation can and has resulted in a greatly shortened life span. Similarly, in a complex business change, i.e., software implementation, rigorous planning, preparation, education and training virtually eliminate risks, just as it does in sky-diving. And high blood levels of testosterone won’t bridge the gap.
Project Leadership – selection and administration
Strong, internal project leader – Select a key leader, not “manager”. A key hands-on executive or relatively senior manager (not the IT manager) should take this role – he/she will be a powerful force for ownership. Here’s how to keep from overwhelming this person:
- Add project administration – provide a full-time project administrative assistant to the leader – most of the project management work can be handled by a capable assistant. The most time intensive part is gathering status information, preparing reports, presentations. o ·
- Add key role deputy – assign a capable deputy, a fully-capable “stand-in” who can, if/when needed for the functional manager serving in the project leader role. This can and will off-load the leader, so he can have enough time to effectively lead the implementation project, while remaining effective in his / her primary functional role – essential for full ownership.
We have found there is frequently a lot of confusion over the roles of project leadership, management and administration. Leadership is clearly the most powerful and critical, yet most of the time for getting a project to move forward is devoted to administrative work.
Keeping the project leadership securely in his/her power base of a key line management role insures that reality is an integral part of the change/implementation process and keeps ownership solidly in place as well. The Best Practice here is to select a real, effective leader, keep that person in their primary job, while providing supplementary support to back-fill the person in their primary leadership role, while off-loading as much of the project administrative work as possible.
This strategy allows the project leader to truly be physically and emotionally able to continue to provide leadership in the primary business role, yet also effectively lead the change process for the company, including his/her own work area as well at the same time.
Selecting team members
In the NOT to do it discussion, we eliminated many of the most common, yet failure-driving ways to create an implementation team. Similarly, the theme of hands-on, leadership based individuals who are capable of the degree of ownership of the results in their own work areas, plus the implementation team we can concisely summarize how the team should be assembled and who should be on the team:
- Strong, functional managers as team members – everywhere possible, assign a strong manager for team membership, one who exhibits real leadership characteristics, more than just someone who really knows the functional area. Follow the same guidelines described above for insuring that these people have enough time to effectively carry the dual responsibilities of their functional management role plus the implementation project role. Off-load and support them in their regular job role to allow quality, effective time for the implementation project.
- Keep the team small – a highly focused, tight, small team of intensely motivated people who really know what they want to accomplish, will move mountains, quickly to get it done. Communication lines will, on a small, tight team, be short, concise, and trust-filled.
- Continuity – ideally, the implementation is the same team that performed the “as-is” and “to-be” business process analysis, and which thoroughly understands the business strategy and its critical success factors.
Note the common thread of ownership – the before and after work, having people remain in their line roles, and keeping communication and responsibility lines within the team short and effective, with a minimum of overhead. And, of course always selecting people who exhibit real leadership qualities. This “follow-me,” lead by example method has proven very, very effective in countless situations of change within work groups. A solid leader helps people feel relatively safe and secure in the midst of change, potential confusion and what they feel will be the chance of mistakes.
Success Example
One company we are familiar with, a $ 50 million/year high tech manufacturing company, was unable to utilize much of its implementation consulting budget that it had planned. The company is highly customer focused, with many short-notice on-site visits by key customers. Consulting resources from the software company had to be scheduled in advance, and frequently were cancelled at the last minute, or went under-utilized while they were on-site.
This forced the management to “do it themselves” – using Webinar and conference calls to tap into outside expertise just for educational purposes, so they could learn what was needed. Since they were working nights and weekends, they really wanted to get it done soon, yet since the team was entirely composed of key line managers, making sure it went well was critical.
As a result, all of the planned functions in the new system went into live use only a few months after starting, with only a small portion of the external consulting support that had been planned being utilized.
This simple example illustrates the key points involved in Best Practice implementations – all centered around maintaining effective ownership of the before and To-Be processes, and all steps between the two. In this instance, the company’s leadership was able to simultaneously keep things moving well in their work groups while moving the implementation forward, without the off-loading and back-filling steps recommended above. However, in a larger company, this may not have been possible – the additional work would be more than could be handled by some evenings and weekend work.
In our next issues, we’ll continue the implementation discussion, moving onto the topics of education and training, and the all-important conference room pilot.
If you like this article and think it's helpful, please spread the word and digg it.
-
Best Practices Q &A - Part 13
Question: “Our company does not have anyone in any of the leadership management positions with any prior experience in a major implementation project. What is the best way we can bridge this gap to insure a successful implementation?”
Answer: “There is nothing wrong, per se, with bringing in outside expertise to support your project. The issue is one of how is this person to be used – what role will he/she be assigned. In-house people on the team will be the experts on the company. The external person’s role is to help the team grow themselves to the point where they can meaningfully, effectively own the “to-be” business processes – after the implementation is successful. The best practice role of a person outside the organization is one of coaching, facilitation, and education – NOT being responsible for deliverables, milestones, go/no-go decisions that the like. There is no quick, easy way to escape the reality of experience the team has – the remedy is always education, coaching and extra trials to gain the needed experience.
Likewise, there is no escape from the fact that handing a project over to an external person WILL definitely shift responsibility and thus ownership away from internal leaders. Finally, remember that when any well motivated leader is leading a project where certain expertise may be lacking – that person WILL be paying attention during education sessions.”
-
Answer: “There is nothing wrong, per se, with bringing in outside expertise to support your project. The issue is one of how is this person to be used – what role will he/she be assigned. In-house people on the team will be the experts on the company. The external person’s role is to help the team grow themselves to the point where they can meaningfully, effectively own the “to-be” business processes – after the implementation is successful. The best practice role of a person outside the organization is one of coaching, facilitation, and education – NOT being responsible for deliverables, milestones, go/no-go decisions that the like. There is no quick, easy way to escape the reality of experience the team has – the remedy is always education, coaching and extra trials to gain the needed experience.
Likewise, there is no escape from the fact that handing a project over to an external person WILL definitely shift responsibility and thus ownership away from internal leaders. Finally, remember that when any well motivated leader is leading a project where certain expertise may be lacking – that person WILL be paying attention during education sessions.”
-
Monday, June 18, 2007
Implementation Preparation Best Practices
Article Summary: The preparation process – i.e., the “front-end” of a Best Practice enterprise software implementation project sets the basis for what follows. This article explains the common thread of ownership and effective leadership upon which a successful, low-risk implementation project is based. In a subsequent article, we will discuss the Best Practice way of organizing and preparing the implementation team, and then in a third article, the activities of the implementation team – conference room pilot, go-live preparations and support. Topics:
Background and context factors Few business areas seem to be so risk-filled as implementation of new Enterprise software systems. Research has shown consistently that more than 70% of all ERP system implementation result in one form of short-fall or another, ranging from acceptable performance with no real measurable benefit but at a higher operating cost, down through several gradations of difficulty to outright failure. Collapse or bankruptcy does occasionally result, although rare.
A sane business leader reads these research findings and thinks “Yikes! Do we have to do this? There must be a way to reduce or eliminate this terrible risk, isn’t there?”
Fortunately, there most definitely is. Understanding and following proven Best Practices can and will lead to an almost zero-risk implementation project. These are NOT a mystery, although if one doesn’t know about them, they are. Absent proper preparation, implementations become the business equivalent of just jumping out of a perfectly good airplane and hoping that your parachute will open OK. “Banzai!” is not a Best Practice.
In this first of three articles, we discuss the Best Practice way to prepare for an implementation project. This involves understanding the common thread of ownership and leadership that runs through all facets of successful implementation projects.
Ownership – The Overriding Principle
At every level in a Best Practice implementation project there is the principle of ownership. The project that comprises the implementation is, itself a process – one that results in a slew of other processes. This means that the project manager, the team members, and adjunct participants such as those in functional work groups whose role is to interface with the implementation team – all of these individuals must feel the ownership of their tasks, that it is their job to see it through to successful completion, and to work as a team to bring this about.
The principle of ownership and its importance can hardly be overemphasized. Here is why:
When a team of change agents, which is what an implementation team is, is organized, it is vital that, at the very start, that top management display real leadership – backing the team’s efforts, making sure everyone in the company understands their role, its importance, and that management is “in the boat” with the team – and will succeed or fail with the team. The oldest project joke is that the most important task at the start is to “figure out who to blame when it fails.” Unfortunately, this is what happens all too often. Make sure there isn’t even a suggestion that this could happen and your project will go well.
Experience – remember that most people on a project team have, at most, participated in one, perhaps two implementation projects in their career. This is OK, normal, but needs to be factored in. They are learning both how to do this one, and how to do them in an overall sense.
The Machiavelli principle – implementation projects “establish a new order” which has long been identified as carrying high risk to its leader – one where there are few friends, and many enemies. In many of the unfortunate situations the project management ends up consistently in a defensive posture, working in a conflicted state where each step forward exposes the manager to more criticism, opposition, and various fears.
Bearing this principle in mind, senior management can, in effect, “shield” the project manager by providing solid, consistent backing. This must go beyond just budget to clear, explicit leadership via words and deeds that clearly show support and an intention to share all risks associated with the changes being made.
If there is even a hint by top management that, in the event of a short-fall in the project that “heads will roll,” everyone will take cover, and the project will soon make no steps forward without solid CYA material in place, greatly hampering its effectiveness.
Top Management Interface
Every major project in a mid to large sized company needs a process to connect it with the CEO, ideally the Board of Directors, key investors, and C-level executives. There are several ways to accomplish this, such as:
Summary of Factors – in the area of project leadership interfacing with the top management of the company, as we’ve seen, the mechanism or process used is not the major factor – it is how it is run or used that determines success. Some guidelines for a Best Practice executive interface:
In the next installment we will discuss how to form and prepare a successful implementation project team – how to select the team members, and the education and training component both for the team members, and others in the organization.
If you like this article and think it's helpful, please spread the word and digg it.
-
- Background and context factors
- Ownership – the overriding principle
- Leadership – key best practice
- Top management interface
Background and context factors Few business areas seem to be so risk-filled as implementation of new Enterprise software systems. Research has shown consistently that more than 70% of all ERP system implementation result in one form of short-fall or another, ranging from acceptable performance with no real measurable benefit but at a higher operating cost, down through several gradations of difficulty to outright failure. Collapse or bankruptcy does occasionally result, although rare.
A sane business leader reads these research findings and thinks “Yikes! Do we have to do this? There must be a way to reduce or eliminate this terrible risk, isn’t there?”
Fortunately, there most definitely is. Understanding and following proven Best Practices can and will lead to an almost zero-risk implementation project. These are NOT a mystery, although if one doesn’t know about them, they are. Absent proper preparation, implementations become the business equivalent of just jumping out of a perfectly good airplane and hoping that your parachute will open OK. “Banzai!” is not a Best Practice.
In this first of three articles, we discuss the Best Practice way to prepare for an implementation project. This involves understanding the common thread of ownership and leadership that runs through all facets of successful implementation projects.
Ownership – The Overriding Principle
At every level in a Best Practice implementation project there is the principle of ownership. The project that comprises the implementation is, itself a process – one that results in a slew of other processes. This means that the project manager, the team members, and adjunct participants such as those in functional work groups whose role is to interface with the implementation team – all of these individuals must feel the ownership of their tasks, that it is their job to see it through to successful completion, and to work as a team to bring this about.
The principle of ownership and its importance can hardly be overemphasized. Here is why:
- Risk mitigation - The team will not just “jump off the cliff” blindly. They’ll move when they are ready – because it is their project, their success.
- Details – ownership helps insure that participants are truly paying attention to relevant details – and ignoring irrelevant ones.
- Education and training – when non-owners attend classes, one is lucky if they a) show up, b) stay awake, c) retain much. In contrast, if it is my project, my success at stake, I will pay attention and make sure I retain everything I need.
- Preparation for Go-Live – a goal driven team that owns the outcome, the success, will not agree to a go-live until they know they are truly ready. At this point, the risk of failure or serious problems is virtually zero.
- Painless transition – if the team owns its success, and is prepared, the Go-Live is almost just another work day. There is little or no additional re-training of everyone, because they are prepared, looking forward to working with a new, better system and work flows.
When a team of change agents, which is what an implementation team is, is organized, it is vital that, at the very start, that top management display real leadership – backing the team’s efforts, making sure everyone in the company understands their role, its importance, and that management is “in the boat” with the team – and will succeed or fail with the team. The oldest project joke is that the most important task at the start is to “figure out who to blame when it fails.” Unfortunately, this is what happens all too often. Make sure there isn’t even a suggestion that this could happen and your project will go well.
Experience – remember that most people on a project team have, at most, participated in one, perhaps two implementation projects in their career. This is OK, normal, but needs to be factored in. They are learning both how to do this one, and how to do them in an overall sense.
The Machiavelli principle – implementation projects “establish a new order” which has long been identified as carrying high risk to its leader – one where there are few friends, and many enemies. In many of the unfortunate situations the project management ends up consistently in a defensive posture, working in a conflicted state where each step forward exposes the manager to more criticism, opposition, and various fears.
Bearing this principle in mind, senior management can, in effect, “shield” the project manager by providing solid, consistent backing. This must go beyond just budget to clear, explicit leadership via words and deeds that clearly show support and an intention to share all risks associated with the changes being made.
If there is even a hint by top management that, in the event of a short-fall in the project that “heads will roll,” everyone will take cover, and the project will soon make no steps forward without solid CYA material in place, greatly hampering its effectiveness.
Top Management Interface
Every major project in a mid to large sized company needs a process to connect it with the CEO, ideally the Board of Directors, key investors, and C-level executives. There are several ways to accomplish this, such as:
- Executive Management Team (EMT) – in mid-sized or smaller companies, the project leader can just interface directly with the executive top management team. This provides an immediacy and a reality to the endeavor, as the EMT is fairly closely involved, and must understand and concur with all major issues, resolutions and decisions.
- Steering Committee – these can be very effective, or not, depending on how they are constituted, their charter, and how they are led and operated. We define a Steering Committee as an appointed group of senior level executives, either a mix of “C” level and below, or managers who are most affected by the project. Typically these are not the EMT, but are appointed by the EMT to function in their behalf. Hazards with Steering Committees:
- Disconnected from top management – since the project SHOULD be tightly tied to the company’s business strategy, having an additional reporting layer (read: “insulation layer”) allows the EMT the costly luxury of imagining that they don’t need to be concerned with it, never a good idea.
- Second-guessing / excessive approvals – a poorly led steering committee will require the project manager and his / her team to review each detail with the committee at its (monthly) meetings, until they fully understand it, then approve it. This severely hobbles forward progress, needless to say. It occurs when there is weak or no trust of the judgment of the project manager and the team. The trust issue should be addressed head-on, here as in all other circumstances where it occurs and changes made so trust can function – this is the only way true, effective delegation can occur.
- “No-shows” – key managers may miss meetings delaying key decisions, or producing “I’m not involved” attitudes in the missing manager’s mind. It can also foster an attitude of “abdication” instead of delegation.
- Single Senior Executive Responsibility – if the single executive is the CEO or President, this can work, unless his/her availability and access is very limited, typically the case. More likely, if the CEO says “I’ll manage this myself” it is a case of inability to delegate, which of course severely hampers the project. Alternatively, if another senior executive assumes this role, it CAN be very effective. While there are some great exceptions, generally this should not be the CFO, unless the person in this role is unusually operationally oriented. Otherwise it’s like having the CFO have reporting responsibility for all of IT. The financial function, in too many of these cases, ends up with everything it needs, while the operational functions wait, or worse, are starved of budget and leadership. When in doubt, remember the objective of the project – to improve (operational) performance of the business.
Summary of Factors – in the area of project leadership interfacing with the top management of the company, as we’ve seen, the mechanism or process used is not the major factor – it is how it is run or used that determines success. Some guidelines for a Best Practice executive interface:
- Keep the goal in mind – The goal here is a fast-moving, low-cost process that transitions the company from operating with its current systems and processes, to a new one. Everything that aids this process adds value to it, and activities and actions that do not subtract or are just waste – expensive waste. A Best Practice, of course, is to constantly strive to improve this, as with other processes by eliminating waste and improving quality.
- Summary level reporting only – one big time/cost waster is elaborate PowerPoint presentations and reports, which don’t add value. One of our favorite report Best Practices is that of a major global corporation. You are limited to one 11 x 17 piece of paper, both sides, but can do anything you want with it. This is the paper equivalent of the “stand-up” meeting – key issues only.
- Frequent is better – more frequent, short, informal, summary level meetings which focus on unresolved issues that need top management involvement, budget, time-line, schedule, or resource issues. This allows the project to move fast, change plans and directions quickly, without having get bogged down in the “why did the plan change?” kind of discussion, a waste of time.
- Confront CYA head-on – inherent in this kind of reporting structure and project is the desire to look good, look like you knew what was going on from the start, etc. The evidence that CYA forces are operating is when one sees an expansion of presentation materials, reports, minutes of meetings, emails and memos to “document” discussions and decisions, multi-media presentations, and other time-consuming items that do not move the project ahead. Once the project is done, none of this will matter and the extra baggage can, itself, cause the project to not meet its objectives.
In the next installment we will discuss how to form and prepare a successful implementation project team – how to select the team members, and the education and training component both for the team members, and others in the organization.
If you like this article and think it's helpful, please spread the word and digg it.
-
Subscribe to:
Posts (Atom)
