AllenWeb Site - since 1995
ERP Project Management Basics - Jun 1998 - Part 2
| Automation |
ERP Project Management Basics - Part 2
ERP Project Management Basics - Part 2
Management and Implementation - The Importance of a Positive Corporate Culture The Vendor Relationship -
Balancing Benefits with Risk
Corporate Culture - the Seeds of Failure - The
Right Attitude Can Make or Break a Project Risk Goes With the Project - Prepare to face the Danger
Committing Management - Gradually
Encourage Corporate Ownership Implementation Will Hurt - But Preparation Will Help Ease the Pain
Ownership Starts on Day One - Finding and
Keeping Project Enthusiasm Are You Ready for a New System? - Determine Company Intentions and Commitment
Increase Success by Avoiding Failure -
12 Steps to Risk Reduction How Important is Cost? - Be True to the Budget
Angels in the Executive Suite - Working
Miracles with the Right Manager's Support
The Importance of Technology - Preparing for Your Company's Future Needs
It's Your Project and Your Project Manager - Owning Implementation Keeps Credit and Blame In-House The
Necessity of Functionality - What Do You Want Your System to Do?
Project Justification - Honesty is the Best Policy The Right Time for Reengineering - The Truth Behind a Growing
Concept
Using Consultants - When and Why Managers Seek Help From the Outside Implementing What You Need - A Quick
List for Corporate Success
Who Are the Decision Makers? - Seeking a
Supportive Steering Committee Overcoming Resistance to Change and Managing Expectations - The Key
The Vendor Relationship
Balancing Benefits with Risk
Choosing the right software vendor goes beyond evaluating software functionality. There has been a gradual
movement among a handful of the largest software vendors to take a one-size-fits-all posture. Some vendors
believe functionality ratings no longer are important since all software systems are beginning to look alike. While
appearances may tend to support this theory, reality paints a different picture. Merely having a particular function
does not guarantee users will be able to capably work with it. If two vendors offer a function required in a specific
industry segment, and one specializes in deploying it in that segment while the other does not, the difference can be
dramatic. The one-size-fits-all garment may fit everybody, but does it look good on everyone?
Vendor selection is not a popularity contest, and bigger does not always mean better. While the financial stability,
ensured longevity, and broad spectrum of offerings provided by behemoth vendors are good reasons for selecting
them, size is not without its downside. Size breeds bureaucracy, and bureaucracy hampers personal attention and
agility. While smaller vendors that are not quite household names may carry increased risks in the area of
long-term longevity, they may actually provide a better solution if they specialize in your industry segment rather
that covering a broad spectrum of industries.
You have the greatest leverage with your vendor once you've made the decision to buy their software but have not
yet issued the purchase order. Waiting for the end of their quarter can help you get the best price. Also view the
financial stability of your future relationship as important - you will receive positive support from your vendor as long
as it is profitable for them to do so. The relationship is a balancing act. Interest your vendor to get the job done
right, on-time, and within budget, but watch out for penalties that may increase project pressure and sour the
relationship.
As 2000 approaches, the workload for many vendors already is exceeding their wildest forecasted goals. There are
not adequate implementation resources available, so you must be more wary than usual of the quality of personnel
that will be offered. Obtaining the necessary resources will be time-consuming and risky. If you feel you have
adequate resources and personnel, make sure you've locked them in for the duration of the project.
It is important to remember that the vendor, as long as they provide working software and capable personnel, really
has very little responsibility for your overall success. Responsibility for success of failure lies within the four walls of
your business, and if you import failure in the form of a third party, it's still your responsibility.
--------------------------------------------------------------------------------
Risk Goes With the Project
Prepare to face the Danger
All application software projects involve risk. Even the most simple effort probably has only a 90 percent chance of
success - i.e., the project is on-time, within budget, and attains all the planned benefits. As projects increase in
scope, the odds of achieving success diminish rapidly. Implementation projects require companies to strike a
balance between the desire to satisfy everyone's functionality needs, and the need to keep things simple enough to
ensure success. If you implement a package with no software modifications, you are more likely to succeed than if
you make major software and structural operating adjustments. But at what cost? Without customization, you may
end u wit a system that executes flawlessly, but doesn't support your business adequately. Balance risk and results
at a level comfortable for your company. Remember that technology is fragile, and heavy software modifications can
lead to constructing a howse of cards that will topple easily.
Many managers understand the risks involved with new software and put all their efforts into minimizing them. What
many fail to realize is the high risk associated with existing applications that will be retained - the most onerous of
these being bad data in the current system. It's common that many problems with a company's existing system are
more related to inaccurate data than to faulty systems. Yet, the system usually takes the blame. Converting to a
shiny, new system replete with the latest features and functions, and then populating it with rusty, broken-down data
does little more than continue yesterday's problems.
How do you minimize risk? Obviously, you could do less in less time, but this is generally not a viable solution. One
of the best hedges against risk is the use of a proven methodology. The simpler the better. Going into battle without
a firm plan of attack introduces the risk that your soldiers will end up shooting each other on the battlefield. One
blanket methodology isn/t necessary - software selection, acceptance testing, and implementation can each have
tailored methodologies. Neither the methodology nor the project plan need be overly exciting in their own right - in
fact, its perfectly OK if they're downright boring. The realities of the implementation hurdles are likely to give the
team all the excitement it can handle.
A methodology will help ward off risk, but a contingency plan still is absolutely necessary. Virtually all planning for
such projects has a positive spin to it - the assumption is made that the project will unfold as planned. Ugly
surprises that surface during the course of the project can devastate the project, and even the entire company.
Having a working contingency plan, agreed upon in advance, can come to the project team's rescue.
A methodology will help ward off risk, but a contingency plan still is absolutely necessary.
--------------------------------------------------------------------------------
Implementation Will Hurt
But Preparation Will Help Ease the Pain
There are at lest two truisms that fit most ERP projects: implementation will be painful, and financial benefits realized
in the first year will be minimal.
Preparing your company for the vicissitudes of implementation is almost as important as the project itself. Too
often, in justifying a project, we downplay the risks and pain of implementation, afraid the truth will mean
disapproval. However, brutal honesty at the onset always is better than giving team members false expectations. If
employees believe the project will progress painlessly, they'll only get discouraged when a problem occurs. If you
tell them the truth, they can anticipate pitfalls and prepare for them.
It's important to let everyone know that after nine months of implementation preparation, system operations may
not go smoothly, and the pain can last as long as three to four months more, even if everything has been done
correctly. If the implementation goes well, all the better, but if things go wrong as they sometimes will, everyone
will be much more understanding. You can get to the same point with all the same problems and be viewed with
either approval or disdain, dependent on how well you prepared your company.
Too often, project promoters claim new systems will impact the bottom line immediately. However, experience
shows that many systems benefits don't occur until the second year.
Brutal honesty at the onset is better than giving false hope.
--------------------------------------------------------------------------------
Are You Ready for New System?
Determine Company Intentions and Commitment
To be successful, you must do the right things for the right reasons. Make sure, before you begin the
implementation process, that your company is up to the challenge. Examine why you wish to undertake such a
major project. Is it to improve your already efficient and streamlined procedures? Is it to speed workflow
bottlenecks? Are you replacing inadequate systems? Is everything in disarray or do you just need to remove one or
two bad apples? Are you trying to get everything fixed at once? Would you rather replace your company and keep
your systems? There are many possible reasons for dissatisfaction.
Before blaming company inefficiency on bad practices, determine if current systems are able to provide much
needed flexibility. Sometimes it is the system that's at fault. With the right systems, you may be able to define a
working environment that encompasses current practices and also allows the company to move forward. In many
cases you may find that the new system resolves many issues that lingered due to inflexible functionality.
Training is a necessity, but management may be unwilling to devote considerable time or money to it. The prime
advantage of training prior to implementation is familiarity - users who are not confused by the software will
recognize and deal with inevitable problems better. This familiarity comes only with hands-on experience. Keep in
mind that learning is more than simply going through the motions of training. It's easy to throw a few three-ring
binders at people and have them sit through lectures, but trainees need to truly understand the new system.
Teaching is easy - it's learning that's hard.
Even the brightest, most self-motivated employees need to be trained on new systems, especially if you want a
smooth implementation. Employees need training to instill confidence that they can cope with unexpected situations
during implementation and operation. Lack of confidence undermines the operation, discouraging and frustrating
employees and management alike.
Educated and trained users will support the systems, because when the going gets tough, as it invariably will, you
want as many knowledgeable eyes as possible looking out for, and smoothing over, problems. There are only two
things that can happen: your people are with you, or they are against you - and all steps should be taken to ensure
they're on your side.
--------------------------------------------------------------------------------
How Important is Cost?
Be True to the Budget
Cost becomes an important factor at least twice during implementation: when you ar developing and approving the
budget, and when you start overrunning the budget. Budget overruns, in both time and dollars, are commonplace.
Many projects begin without a realistic budget, and when overruns start to occur, it's usually education and training
that are cut. However, all aspects of the implemtnation are important, and the failure to stay within budget at one
point should not justify robbing from other project components. The project should have a contingency budget - to
be applied where needed - but there should be a penalty for consuming the contingency. Keep constant pressure to
control costs on all project tasks. It's important to remember that tasks completed within projected costs are almost
always on-time. This is a good a reason as any to maintain control.
How much contingency will be needed? Most projects should have a contingency of 10 percent on time - if all tasks
go well, you'll finish 10 percent early. Correspondingly, you should have a likewise contingency cost for planned
activities, but you must also account for unplanned tasks (e.g., staffing changes, added hardware and software
components).
Your project also should be correctly sized and your on-going system-related expenses should be in line with your
competitors'. Find the appropriate cost structure averages for your industry, and if you are going to exceed them,
make sure you have good reasons. Sometimes spending more on information technology yields a strong
competitive edge, but investing in technology for technology's sake increases cost with little or no offsetting benefits.
There are many cost elements to control, and there are a number of free models available to show you where the
costs are, both internally and externally - there's no need to re-invent the wheel.
Maintain pressure to control costs on all project tasks.
--------------------------------------------------------------------------------
The Importance of Technology
Preparing for Your Company's Future Needs
Most companies buy software to improve business functions, not to implement data processing technology. Often,
leading-edge technology is too expensive, and even unnecessary, for these companies. But technology quality is a
factor when choosing a system. Be aware of the functions you'll need, and seek the appropriate technology. A
decision to use a certain platform - AS/400, Unix, or NT - will have a wide-range of functionality-acceptable software
solutions. Make sure that the solution selected has a proven track record of success in companies of equal size and
comparable operating environment to yours. This is especially important when considering client/server options.
The tradeoff between stable, proven technology and newer, state-of-the-art systems is one of the most critical
decision points for the project. While stable technology - one that has been around for several years - runs the risk
of being obsolete in the near future, newer technology may involve near-term instability, which can lead to its own
problems. Keep inmind that new technology may not become a sustainable industry standard, and could vanish
altogether.
Your project is work, not sport. Can you afford to select the wrong technology? One that will be out-of-date, maybe
obsolete in the future? Big companies can knowingly take this risk, but for smaller companies, it is usually
unintentional and the results often dramatically impact cost and performance. Most companies want to play it safe -
that is, ensure that the technology they choose cannot hurt them. The best of all possible worlds is full functionality
in a mature technology with a large user base, hardware independence, and a bright future. You may have to
sacrifice some of these, but first and foremost for small companies, the platform should be secure and have a large
user base.
Another telling indicator of your odds of success is your company's view of technology itself. Is it seen as a tool or a
toy? If your team sees it as a tool to help the business get where it wants to go, your chances of deploying it
properly and preventing it from overshadowing the business benefits are excellent. If, on the other hand, your team
becomes enamored with the technology gadgets so that more time is spent tinkering with the new toys than using
them to do actual work, the process will take precedence over the results, and the project could spin out of control.
There is an inverse relationship between the number of computer technicians on the project and its odds of success.
An ERP system implementation is NOT an MIS project.
First and foremost, MIS employees are not users and have no vested interest in the project's success.
An ERP system implementation is not an MIS project. First and foremost, MIS employees are not users and have no
vested interest in the project's success. Though they work out detail design and provide manual labor for the
project, it is the functional managers who make th decisions. MIS people are computer experts, not business
experts. It is their job to manage the technical aspects of the project - including technical cost and risk analysis -
not to override the operating decisions of functional managers.
Keeping MIS in its place decreases the inclination to use them as scapegoats.
Keeping the MIS department in its place also decreases the inclination to use it as a scapegoat if anything goes
wrong. In fact, MIS people are so easy to scapegoat in many companies, it is necessary to actively and publicly
reduce the likelihood of their being responsible for failure. There are several ways to "protect" MIS from taking the
fall. Make as few program changes in the main body logic programs as possible. Even the best programmers will
make errors that will not be found until it's too late. Compounded with a few expected errors made by the software
vendor, programming mishaps can greatly impact implementation. MIC's prime activities during initial programming
should be to convert data, prepare and write system reports, ensure technical processes work, and provide working
hardware and software. All this is daunting enough without creating extra risk through program change.
MIS certainly has a place in your company, but it's not deciding how the business should be run.
MIS certainly has a place in your company, but it's not deciding how the business should be run.
--------------------------------------------------------------------------------
The Necessity of Functionality
What Do You Want Your System to Do?
Functionality is the key to successful implementation.
Functionality is the key to a successful implementation. When functionality is overlooked in a software
implementation effort, users become disenchanted and companies lose money. A glaring example of this is a
corporate decision to implement a system that does not have the support of company dividisons. Why would a
division work hard to implement a system it didn't select? This scenario unfolds, for instance, when a corporation
with 15 divisions running on the same package has only one division that's happy and successful. Of the remaining
14, one is slightly successful and unhappy, and the rest are unsuccessful and dissatisfied. It is the successful and
satisfied division that selects the software, the others just implement it. The reason for the failure often is clear and
predictable: most people will lend lukewarm support at best when they haven't been involved in the decision. If they
are forced to implement a system that doesn't serve their needs, then they aren't going to invest the time and effort
into making the system work.
Companies that don't take the time to decide what their software must do will not be successful. A company must
decide what its functions are, and then implement a system that will work toward supporting these functions.
A dilemma faced by companies searching for integrated software packages today is the choice between off-the-shelf
packages and custom-fit providers. There is a fear among many that shortly after the Year 2000 problem
diminishes, there will be a massive shakeout in the software industry that will cause many of the smaller niche
packages to disappear. While there is sure to be a softening in the industry that will cause some weaker vendors to
disappear, logic tells us not to panic. The law of diminshing returns will stabilze the situation. As the big packages
become larger, containing all the functionality any large company could want, the dynamics of size could favor
smaller niche packages for mid-sized companies.
While large, all-inclusive software packages are a good fit for conglomerates with multiple divisions, they probably
will not have the agility of smaller packages designed for a specific industry or operating environment. There is a
downside to too much functionality in a software package. Dealing with the added complexity brought on by the
abundance of features and functions that are needed in a given environment means increased operating hassles and
costs. All those extra, built-in feastures also mean a higher price for the system.
All the technology in the world is worthless if a system can't perform the functions needed to run your business.
All the technology in the world is worthless if a system can't perform the functions needed to run your business.
Functionality without flexibilty is ultimately unproductive. Decide what you need, then implement within the bounds of
the solution.
Functionality without flexibility is ultimately unproductive.
Decide what you need, then implement within the bounds of the solution.
--------------------------------------------------------------------------------
The Right Time for Reengineering
The Truth Behind a Growing Concept
If a single word has dominated the world of business in the 1990's it is "reengineering" - a process that reforms
business practices for optimum performance, customer service, and financial return. Teams are organized, studies
are made, money is spent, and dreams are hatched, but for most companies, not that much changes.
"Can-identify-the-problem" people far outnumber "can-solve-the-problem" people, so that problems are found but
left unresolved, adding to workforce cynicism. In all this team problem-solving and supposed reforming, too many
forget that changing business procedures is a complex activity. Some companies have implemented reengineering
in a continually impoving environment, but most have abandoned reengineering as just another fad.
Companies should separate reengineering modifications from ERP implementations.
The theory behind reengineering is a good one - modifying procedures and behavior to the needs of the business.
Most companies were implementing these type changes long before the term "reengineering" came into existence.
Yet, a complete company overhaul is often beyond what companies are willing to tackle - the effort is too much and
the impact too large. For this reason, companies should separate reengineering modifications from ERP
implementations. Installing a broad-based ERP system is a complicated job involving a high level of risk, especially
as it relates to cost and timing. Adding other factors that are complex in their own right, such as reengineering, can
often doom a project.
IF the work processes to be used in an ERP system have not been established prior to trying to install one,
"reengineering" should take place to establish the work processes to be used in such systems (i.e., SAP R/3, Baan,
etc.). It should take place "prior to and in preparation for" an ERP implementation - not in conjunction with, and
should be in a state of continually updating as the dynamic enterprise must continually change to meet changing
market demands.
--------------------------------------------------------------------------------
Implementing What You Need
A Quick List for Corporate Success
Use the following as a quick list to move your company toward success.
Successful implementation of the wrong system is a disaster.
Successful implementation of the wrong system is a disaster. This happens all the time, especially when technology
is given greater weight than function. Decide what you want the software to do, then implement software to do it.
Successful implementation of the right systems in the wrong environment.
Successful implementation of the right system in the wrong environment. Those of us who have been in the
implementation game a long time have installed systems that met all the goals, yet the implementers were despised
by the users. This occurs when no one is prepared for the pain of implementation. Only in the rarest situations is
implementation painless. Implementations carry risks, and if you want system users to approve afterwards, let
them know what to expect ahead of time.
Don't change the goals.
Don't change the goals. Commit to the end date and the end result. The final product is one that users will either
like or will have to put up with. Make sure users know when they're specifiying their needs at the beginning of the
project that once it's done, it's done! Management needs to commit to this as well. No successful implementation
meets everyone's needs and a committed management will resist the urge to try.
Uncommited management is downright dangerous.
Uncommited management is downright dangerous. When complex projects are undertaken, uninvolved managers
will lead to abject failure. Even though there is only one project leader, responsibility for an all-encompassing ERP
implementation must be shared by all, and thus failure can be avoided by all.
Take time for risk assessment.
Take time for risk assessment. Study your plan in an open forum and talk about what could go wrong. Then rate
these various risks and develop plans, policies, and procedures to recognize them early and deal with them.
Implement what you need to run your business.
Implement what you need to run your business. Some view large projects as a platform to completely reengineer
the business. But it is difficult to combine system replacement with extensive reengineering. ERP systems exist to
help businesses perform. Business performance is the bottom-line measure of success.
--------------------------------------------------------------------------------
Overcoming Resistance to Change and Managing Expectations
The Key to Successful Implementation of Projects
Resistance to Change
The bulldozer and construction worker are symbols of change. Yes, you have heard about change management for
how long? Too long, right? But now we are entering a new century. Change is happening faster that most people
care to think about. What is more important, change is happening faster that most people care to accept. In fact,
most people do not want change! The premise is that change is not always good...that somehow it will have a
negative impact. And in many cases, this is correct depending on where a person stands in the arena.
In the automation business we are, by the very nature of our discipline, in a state of constant change. Technology
is exponentially advancing. Even for those of us who have been using and advocating automation for many years,
changes in available technology is difficult to stay abreast with, if at all. We are in a constant state of change.
Whether its upgrading a new plant, a new materials handling system, a new robotics installation, or just plain
business systems integration, we are making continuous improvements in the abilities of companies to do things
better, faster and cheaper. That is what automation is all about. If it doesn't serve that purpose, it doesn't belong in
the market place.
The problem in automation is not the technology in 95% (a reasonable percentage) of the cases. The problems come
from either mis-applications of hardware or software and from people. The problems with hardware and software
can usually be fixed by re-design , integration, or changing up. The problems with people are not so easily
dispatched. They can be constant threats to the success of any project and to the very survival of a company. I will
not address the technical - hardware and software in detail on this page. That is another story. The purpose of this
page is to discuss the human factor.
--------------------------------------------------------------------------------
The Human Problem in Automation
Do you remember your first bicycle (two-wheeler)? Do you remember your fears and concerns as a child at that
moment of decision. The decision whether you should try it. The concerns about your abilities. Could you be
successful? Would you be able to do it? Would you instead crash, injure yourself, or even more disastrous....
embarrass yourself in front of parents or maybe friends standing by? The damage to the bike during your learning
may never have entered your mind and probably didn't. The concern was for your safety, your self-esteem, your
pride, your abilities, your success of failure.
Maybe you were one of the lucky ones. Yes, maybe your parents put training wheels on your bike to give you
stability. Those wheels helped you develop the skills without the embarrassment and potential injuries that you
might have suffered without them. Or maybe you were one of the unlucky ones. Your parents put you on the seat,
after a little instruction, and gave you a shove. Maybe you survived with little damage or maybe you had several
mishaps before you gained the experience and confidence.
The big difference in all of this is that whether your parents put the training wheels on your bike or didn't, you
wanted to learn and you wanted to be successful. Why? Because it was an important part of growing up and taking
your place with your peers. And certainly it was because you really wanted the fun, freedom, and adventure of
riding a bicycle to distant places even if it was only a few blocks away.
Not all people share this same enthusiasm in dealing with automation. In fact, many have the very same concerns
that they had during their first bicycle experience. The big difference is, they really do not want nor do they share
the desire to "ride" automation. There are many more factors involved, but the concerns are still uncertainty, fear
of failure, fear of the unknown, and now fear of being "put out of a job."
Yes, most people see automation as a threat....a threat to their very existence. Whether they are senior
management, middle management, a shop floor technician, or janitorial labor - unless they are comfortable with
automation and embrace it as they did their bicycle, they will resist and fight the change automation brings with
every tool at their disposal. And why do they do it? Why do they fight it and sabotage its implementation?
The answers are easy, but putting the solutions into action and implementing them is difficult.
--------------------------------------------------------------------------------
#1 - Fear of Being Redundant
The biggest fear shared by people faced with automation is the loss of their job. When a company talks about
automation, the immediate reaction is that machines will replace people. Take the insurance industry as an example.
Remember when the use of the computer was first introduced. Remember the large redundant clerk force that was
eventually reduced. That is what enters the minds of folks faced with an automation effort by their company. They
don't see the other side of it. Higher profitability and higher wages for those who adapted and grew the company.
And they certainly don't think about the failed companies that didn't adopt automation because they were not able to
compete against those who had. Those companies no longer exist in some industries.
An answer: Automating a facility should give the company a much larger capacity, allow them to go after a bigger
market share by adding more flexibility in responding to the market, etc. But care should be taken early to identify
exactly how this automation will impact the current work force and if there will really be a redundant situation or will
the current workforce be a necessary part of the new plant? What training needs are there? Every effort must be
made to identify any redundant elements in the planning phase and action taken with those effected.
Remove the uncertainty by all in the company by openly displaying the new interim organization structure BY NAME
"prior" to automation implementation. (And take good care of the redundant elements.) This MUST be done to
maintain a level of confidence by those who remain behind to adapt to automation usage. More problems have
arisen during implementation from all levels of a company because people were uncertain of their future upon
completion of a successful implementation.
--------------------------------------------------------------------------------
# 2 - Fear of Failure
Another fear that must be addressed in the planning phase is how to handle people's fear of failure. The fear of not
understanding or being able to work within an automated environment. Many companies make the serious mistake
of not insisting on a very thorough training program that will insure the employees a knowledge and a confidence
level in adapting and using the new systems to the maximum benefit of the company.
Many view training as an expense to be cut. Beware of those that claim they can reduce this expense for a pat on
the back. The resulting proven increases in hidden cost to the firm can exceed the perceived savings of cost cutting
by multiples! This is an item that should receive the most serious attention by professional implementors. Once it is
determined in scope and budgeted, it should become a sacred cow, and be adjusted only by the implementor due to
project scope changes.
An Answer: This is one of the most dangerous and expensive "things" to short on. The lack of preparatory and
reinforcement training or inadequate training in these areas contains some very direct damaging expense to the firm
and even more dangerous indirect expense. DO NOT short on this important part of automation, unless you
significantly adjust your expectations downward in return on investment in automation. Remember the training
wheels analogy?
--------------------------------------------------------------------------------
# 3 - Fear of the Future
The fear of the future must be addressed by openly discussing and announcing the purpose of automation and what
it means to the employees of the firm. Normally automation investment is made so the firm can compete and grow
the business. It may be latent automation for survival.
An Answer: Whatever, the future expected from the implementation must be made openly clear to all that are
expected to participate in making it successful. A feeling of excitement must be built from the ground up in order for
people to enthusiastically embrace automation as the key to their futures. Without a feeling of confidence that "riding
the bike" is going to be good, they may never ride it at all! If they decide not to ride, you will not be successful in
your implementaton.
--------------------------------------------------------------------------------
Address Issues of Fear, Uncertainty, and Self-esteem
The levels within an organization that must be addressed in overcoming resistance to change is each and every one
of them. The first thought in anyone's mind when automation is discussed is, "What's in it for me?" If the answer
must be self-generated, then it will probably be on the pessimistic side yielding a negative outcome perception. This
critical issue should be addressed early in any project and at every level.
Factual representations of what will happen to people within the organization, how the automation will take place
over what period, milestones during the project, and managing expectations of all (from janitor to board director)
are absolutely necessary if a successful on-time and on-budget project is the goal.
--------------------------------------------------------------------------------
Manage Expectations
Managing expectations of problems to be expected during the start-up and ramp-up periods is the biggest challenge.
Due to "sometimes selective memory loss" by some parties, some "CYA" moves by others, and "nay sayers
kibitzing" on the sidelines, your implementation efforts can be derailed. Never let this type of activity impact a
project. It will - if allowed to go unchallenged.
In the planning stage, these elements must be addressed and well documented for later fire fighting, if necessary.
If planning is thoroughly completed prior to implementation, most of these elements will be insignificant to
non-existent because they have been dealt with early on. And if expectations are openly adjusted and well
documented during changes in project scope or circumstances, you can avoid blind-siding parties with resulting
perceived surprises. If they are not, it usually can result in the loss of confidence in the project or you or both.
--------------------------------------------------------------------------------
The Real Challenge
The real challenge in automation is meeting the above fears head-on, addressing them in a very satisfactory
manner, and eliminating them through planning, training, understanding, and obtaining "buy-in" to the automation
effort in everyone's agendas. You can do it! It can be done, if you pay real attention to these fears and take care
of them in your design, planning and implementation. If you don't, they may undo everything else you have done
well. People's resistance to change can and will burn you, regardless of the level you are at in the process!
--------------------------------------------------------------------------------
- END Part 2 -
| Disclaimer: This is Paul Allen's personal business library. Articles and papers contained therein are for his use and reference. While this information is being made public by being published on the internet, any use of any material or guidance contained herein is at one's own risk. Neither the author Paul Allen nor Project Executive Group have any responsibility if anything is taken from this website and utilized. While we believe these articles and papers make a significant contribution to learning, beware that anyone who uses this information does so at their own risk. We make no representations to accuracy or completeness. |
| Return |
