AllenWeb Site - since 1995
ERP Project Management Basics - Jun 1998 - Part I
Automation

ERP Project Management Basics

--------------------------------------------------------------------------------

ERP Project Management Basics - Part 1  

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




--------------------------------------------------------------------------------


Management and Implementation
The Importance of a Positive Corporate Culture
No project is executed in a vacuum.  Projects are realized within the confines - both physical and psychological - of a
given company.  Perhaps today's most complex project is implementing an enterprise resources planning (ERP)
system.  By its very nature, the unfolding of such a large project is influenced by the company environment, and it is
that environment that can breed success or failure.  Oftentimes, corporate culture is an extension of its
management, but even with the most optimistic manager, it is unlikely that an entire company will change its attitude
just to increase an ERP project's chances of success.  Management must recognize th subtleties inherent in the
company culture and develop an implementation plan that works around, or avoids,. pitfalls.

Although corporate cultures are very complex, there are some key indicators that can greatly impact your ERP
project:

Does your corporate culture discourage micro-management?
Does your business environment value team participation over individual heroics?
Does your company encourage quick conflict resolution as opposed to hoping disagreements will go away by
themselves?
Can the project manager handle the necessary responsibility and authority?
Will all mangers commit to personal as well as corporate goals?
Will responsibility for failure as well as success be shared?
Can resources be committed?
Can a committee be established to resolve management differences in a timely manner/
Will the project manager be an experienced, respected, powerful user?
Will top management support remain steadfast despite project and/or market problems?
There are few companies that can answer yes to all of these questions, but knowing how your company deals with
each is important to your project's success.

Most companies are not fertile fields eagerly awaiting your ERP plow, but instead are potential minefields ready to
blow up the unsuspecting.  This coverage will go to some lengths to make you more cognizant of how to identify,
avoid, and/or defuse these bombs.  





--------------------------------------------------------------------------------


Corporate Culture - the Seeds of Failure
The Right Attitude Can Make or Break a Project
Before you turn your implementation dream into a reality, you first must set boundaries that will define the
corporate culture.  No project can succeed without a shared spirit of cooperation.  However, even though most
companies are unwilling to admit it, there is often much in the corporate ethos and culture that negatively impacts
the likelihood of success.  there are many defining characteristics to every corporate culture. Making the following
decisions will help you ensure success for the implementation:


Consultants cannot override managers.
Managers give pre-defined responsibilities to the project manager.
Managers commit to company-approved project goals.
Within budget, committees have complete authority.
Responsibility for failure is shared by the whole team.
The project manager has final approval on program changes.
Committees have override authority vis-a-vis individual managers.
Management disagreements are resolved quickly.
The project manager is an operating user.
The project manager can make difficult decisions.
The training budget will not be reduced.
Management aligns its expectations with reality.
The company will not attempt to off-load blame to a third party.
IF you can make all of this happen, your corporate culture will help you attain success.

You probably cannot respond positively to all of these statements, but your project still must be played out within the
corporate culture, whether you like it or not.  You probably will have no real opportunity to change it, so you must
learn to first recognize it, then evaluate its impact, and finally work around it.

No project can succeed without a shared spirit of cooperation.





--------------------------------------------------------------------------------


Committing Management
Gradually Encourage Corporate Ownership
Corporate culture is a key facet of company management, and the most effective way to work within the corporate
culture is to get management to believe in the project.  They must commit to the project so that its success or failure
also is their success or failure.  By doing this, even the corporate culture may bend to your will.

The best projects slowly draw management into deeper commitment.  In this way, managers have time to adjust to
escalating responsibilities instead of falling into them all at once.  Such escalating steps may be:


obtaining support for the justification costs/benefits analysis;
developing a detailed needs analysis wherein the managers select and weigh their own functional requirements;
assigning discrete, closed activities to responsible managers;
having multiple sigh-off steps; and
as start of the project, distributing shirts, cups, and other promotional material to all levels of management and
employees that prominently display the implementation date.
With any luck, your management may be committed before they realize what's happened to them.  And, by the time
they realize their commitment level, they'll have assumed partial project ownership.  Joint ownership means joint
risk - greatly reducing the likelihood of a designated scapegoat.  This is the essence of committed management -
shared responsibility and shared risk.




--------------------------------------------------------------------------------


Ownership Starts on Day One
Finding and Keeping Project Enthusiasm
One of the greatest challenges of major system implementation projects is sustaining the enthusiasm and
commitment throughout the course of the entire project.  Involvement engenders ownership, and employee
involvement secured early and maintained consistently can spell the difference between success and failure.  This
involvement starts with requirements definition (the SCOPE) and software selection.  The more people feel they
have had a say in setting priorities and selecting a system, the more they will feel compelled to stay involved, even
during rough times.  If the software selection is perceived to have been done by a chosen few, the masses can feel
justified in remaining aloof.  Full-scale mutiny is unlikely, but if most of the crew feels they are just along for the
ride, the odds of weathering the inevitable storm are greatly reduced.

While ownership can be secured with involvement, it cannot be sustained without constant forward movement.  Long
lapses between action steps are certain to lessen workers' focus and dedication.  From the moment of the project
kickoff, time becomes the project's worst enemy  While care must be taken not to rush into premature decisions,
getting bogged down in weeks or even months of analysis work will sap the energy of those waiting to get to work.  
The longer you spend analysing the problem, the fewer people you'll have ready to roll up their sleeves to solve it.

The process of defining system requirements and narrowing down the list of acceptable software vendors is most
often the biggest culprit in the time versus enthusiasm scenario.  IF it takes months for the selection team to emerge
from the conference room with its list of software packages for people to start viewing, they will have a tough time
recapturing that enthusiasms that has dissipated in the interim.

Encouraging Ownership
No matter how anxious you may be to make your project a success, not everyone will jump at the chance to
participate.  Sometimes incentives need to be offered to elicit a higher degree of ownership.  For so-called bad
apples - those who refuse to go along, becoming a detriment to the project - the incentive of keeping their jobs may
be enough.  Let them know they must be either part of the team or not involved at all - the only alternative is
removal.  Big-ticket projects are tough enough without naysayers.  Another more accepted practice that encourages
a willing team spirit is awarding financial incentives.  If all responsible managers' end-of-year bonuses are
dependent on specific project and financial goals, their buy-in, especially as the implementation approaches,
becomes even more committed.  The company must recognize that some project goals must be rewarded when
met, regardless of whatever overall profit and sales goals for the the business are.

Successful projects comes only from management with a strong sense of responsibiilty.





--------------------------------------------------------------------------------


Increase Success by Avoiding Failure
12 Steps to Risk Reduction
It's human nature to begin a project with dreams of success.  With an implementation, project teams plan that each
step taken will be successful, each attained goal building on preceding successful steps.  But this is only part of the
total equation for a working system.  Equally important is the plan to avoid failure.

Avoiding failure, that is, risk reduction, is separate from planning for success.  In a world where only good things
happen, you need only plan how to move forward.  In real life, however, most of our large errors blindside us
because we had our sights set on looking forward to success and weren't aware of potential downfalls.  Any large
project is as much an exercise in risk aversion as it is in task accomplishment.

Successful project managers anticipate what can go wrong.  While they cannot identify every possible misstep,
spotting just a few reduces the risk of complete failure. (Uncertainty management here is a must).  Avoid potential
risks by incorporating the following into the company culture.

Don't do things for the wrong reason.  Identify the benefits that will result from your project, then make sure every
project-related action is directed toward achieving those benefits.  remember, benefits supersede company politics.

Own the project.  All managers own the project.  They will be credited for its success, or blamed for its failure.

Failure is not an option.  No one should believe that the project will be terminated.  Doubt is not tolerated.

Warn off the disbelievers.  IF successful results are truly important to your company, naysayers must be silenced.  
Remove those who won't support the project, or it that's not possible, make their future success with the company
dependent on the system's success.

Cast implementation details in concrete.  Set believable dates and do not change them.  Promote the implementation
loudly and often, leaving no room for anyone to believe that the company will tolerate missing the deadline.

Keep the project under control.  The longer and larger a project, the greater the likelihood of failure.  Nine months is
usually the extent of management's attention for any implementation effort.

Designate a single leader.  Shared leadership is divided leadership.

Don't demonize your vendor.  Never use your software vendor as a scapegoat.  You will need his goodwill as well as
his technical support for the long-range success.

Keep functional managers accountable.  An ERP implementation is not merely a "computer project,"  it is a strategic
business project and must be approached as such.  

Make business objectives the primary drivers of the project.  Investing in technology for the sake of technology does
little more than drain company assets.  Business objectives must be the primary drivers.

Don't let technology jargon intimidate system users.  When system users do not understand what is being explained
about the system, they will lose their enthusiasm for making the system work.

Do not over-modify.  Perfectionists try to customize the system down to the smallest detail, they will only succeed in
building a fragile house of cards that is certain to crumble at the inopportune time.

To keep the project in-hand, periodically reassess where it stands, especially in regards, to potential problems.  Also
verify that the project team's attention is focused on the right goals. Remember the two important and mutually
dependent goals: success and not failing.

All managers own the project.  They will be credited for its success, or blamed for its failure.   





--------------------------------------------------------------------------------


Angels in the Executive Suite
Working Miracles with the Right Manager's Support
Every project needs a guardian angel, an overseer who can make things happen.  The angel who champions the
project must come from the upper reaches of the organization for the following reasons:


the angel must have the clout to obtain needed resources at critical points without scaling many approval layers,
the angel must show that upper management has a stake in the project just as much as those operating the
day-to-day chores, and
the angel must be able to bring warring parties to the table and force necessary compromises in a timely fashion.   
It's best when this angel is the "top guy" in the organization, but for many companies the angel is a mid-level vice
president.  The angel's job is easier when the project is contributing directly to the overall success of the company -
when corporate goals cannot be adequately met without the new systems (e.g., sales volumes exceed current
system capability or the Year 2000 problem will cause bookkeeping chaos).

But many projects have far less immediate underpinning.  These are systems that are being implemented to
increase control, replace obsolete functions, establish more flexible systems, embrace a new technology, or replace
a recalcitrant vendor.  It's not easy to develop a sense of urgency for this type project, so urgency is usually
generated by management.  Projects like this should be as short as possible so as not to lose what is probably
minimal support at best.  Market conditions, management changes, and unexpected bumps in the project road all
can have a disastrous effect.

Given this environment, the angel's motivations should be parochial.  With a bonus performance dependent on
implementation success, the angel should be responsible for departments that expect the most from the
new/improved functionalities.  When possible, the angel's focus should be financial.  Financially justified projects
demand management support, and when things get tough, the pressure to complete such projects usually goes up
rather than down. Projects with questionable bottom line impact are th first ones to be jettisoned.





--------------------------------------------------------------------------------


It's Your Project and Your Project Manager
Owning Implementation Keeps Credit and Blame In-House
There is no concept more important to implementation success than project ownership.  And if you fail, it's your
fault. If you can even imagine a scenario where an outside firm could be the fall guy, you might as well forget the
project - the necessities of implementation leave no room for a scapegoat.

Outsiders may be brought on to help, but they aren't responsible for your project's success.  Some negative
consequences of outsourcing project management include:


it will seem you don't trust your staff's ability or experience,
the outsider can walk away if things get tough, and
the outsider won't be there to help run things on a day-to-day basis.
Even the best consultants consider your company's needs as third in line, right after themselves and their firm.

Now that you've decided to keep project management in-house, the choice of a project manager is next.  The
project manager must be committed (the project strongly impacts his area of responsibility), respected (he has
experience and capability that others in the company trust), and powerful (he will make things happen, sometimes
even with intimidation if necessary).

The background of the project manager is crucial - after all, there is a difference between operations staff - the
"how" people - and systems staff - the "why" people.  It's best to have a background spanning both, but if that's not
possible, someone from the operations side of the business is preferable - the "why" can be accommodated by the
steering committee, but "how" knowledge must be on the front line.

The project manager's demeanor is equally important.  The attitude spectrum runs from taskmaster to
crowd-pleaser - the ideal candidate being somewhere in the middle.  While the project should not resemble a forced
march, a successful project manager understands that the job isn't a popularity contest.  Salesmanship is a trait
often overlooked when selecting this position, yet it is one of the most powerful tools a project manager can carry.

A Different Type Project
Even the best user-sourced project managers have to start from scratch - project implementation is different than
most managerial projects.  While an effective manager may be able to organize a department to do the same
routines on a day-in, day-out basis, implementation requires identifying and implementing thousands of steps that
each occur only once.  The project manager will need training and guidance for this kind of project, or will need to
look to an experienced project administrator to help.

Even a strong project manager cannot succeed when others believe the project can be stopped or delayed.  
Everyone involved must believe from the beginning that an on-time implementation is the only acceptable solution,.  
The project manager also must have the authority to get things done without having to ask permission each step of
the way.

The best project managers use the buy-n, fearlessly command the support, and ruthlessly pursue the end date.  But
remember, if the end date is conservatively developed in the first place, ruthless may mean no more than light - but
steady - pressure.

A successful project manager understands that the job isn't a popularity contest.   





--------------------------------------------------------------------------------


Project Justification
Honesty is the Best Policy
The justified project has received its stamp of approval, and top-level support is guaranteed.  If the system's
advocates can't rally support for the project, they are better off forgetting the more difficult task of implementation.  
Proper management attention is gained only through realistic assessment of what is required.  System advocates
must receive support after identifying bot benefits and risks facing the company.

The best justifications match project goals to company business objectives.  For example, if the business's goal is to
grow through acquisition, then concentrate on how the new system can be sued to squeeze inventory and
receivables assets to finance the acquisitions internally.  Identify the company's goals and focus the system's
benefits on those.

Not only do project deliverables need to support overall business objectives, but the cost/benefit analysis also must
be  constructed with numbers that have credibility.  If the numbers cannot pass muster, your troops will view the
project as a scam, or even worse, as a persona agenda.

Employees must believe the project is worthwhile, or they will not be willing to put forth the effort required to
succeed.

On a cautionary note, projects justified by projected downsizing start out with a negative atmosphere that almost
guarantees a low level of ownership and participation.  When employees see that success is defined by the loss of
jobs - either their own or those of their friends - the odds of anyone rolling up his sleeves to dig into the project is
virtually nil.  While downsizing may be one of the easiest benefits to visualize and quantify, it is the most dangerous
to use.  Get creative and dig deeper to find other options.

Even projects without financial justification need to be costed realistically.  Since cost overruns are likely to reduce
management support, you must make sure all cost items are included and adequate money is provided, despite
pressure from management to reduce costs.  If you attempt to downplay or under-plan costs to gain approval, you
are courting failure once the cat's out of the bag.





--------------------------------------------------------------------------------


Using Consultants
When and Why Managers Seek Help From the Outside
Almost half of all project managers use consultants sometime during the ERP implementation process - in roles
ranging from minor, to technical, to pivotal.  It is important to remember that consultants are not your employees
and have no on-going benefits to benefit from implementation.  Don't rely on consultants to control their own costs -
they are notorious for making changes, using a larger staff, and taking more time than is necessary.  Even the best
consultants need to charge as many hours as possible, and may use you as a profitable docking station between
other efforts.  Maintain full responsibility for who's working on your project and how much time they're billing you.

Maintain full responsibility for the project.  Consultants make ready scapegoats for project managers who don't want
to take the blame themselves.  While consultants can be held accountable, they are never to blame.  (They also may
not be credited with a successful project either.)  They are there to fill in knowledge gaps and provide expertise on a
temporary basis.

Consultants can help your team "think outside the box," a difficult skill to cultivate when you're busy with day-to-day
operations.  Outside specialists represent a true bargain when they provide something you will only need once, at a
fraction of the time and cost required to invent it yourself.  A consultant operating in a specialized niche keeps up
with current trends, and, within that niche,  can do it better, faster, and cheaper than you can.  If, however, the skill
set is one you'll be needing after implementation, then it's best to go through training yourself.

Consultants also can be valuable for staff augmentation, helping with the extra work that develops as the project
unfolds.  When temporary staff is brought in, use them to do temporary activities, such as keeping the current
system running.  If you are converting data, building new procedures, and using the new systems, use your existing
people.  This gives them knowledge they will need in the future.





--------------------------------------------------------------------------------


Who Are the Decision Makers?
Seeking a Supportive Steering Committee
Every company has decision makers, the people who make things happen.  Seek out those who impact operations
the most - in an official capacity or not - and place them on the steering committee where the project manger can
interact with them in a group.  Limit the project manager from having to explain decisions time and time again.  If a
project manager's decision is to be overridden, it must be within a steering committee meeting, never from the
outside.

Essentially, the project manager is the key decision maker.  There will be times throughout the project when this
person will be called upon to make difficult choices, sometimes prioritizing tasks, other times resolving conflict
between people.  The project manager must be capable of making, defending, and standing by every decision -
backing down will only decrease the likelihood of a project completed on time.

A project manager derives power from the commitment of corporate management to the project.  Yet management
is often held hostage to market conditions and ongoing financial problems.  Not all companies have the resources to
perform projects during downtimes, so commitment is key.  Commitment alone can keep a project going.  Without
the desire to see a project through, projects that begin as attempts to gain more control over operations or to
replace old technology often fail by the wayside when management attention is drawn away.

Management attention usually has a time limit.  Generally, it is advisable to finish any project with the original
project team and a stable steering committee management team.  New members will have goals and agendas that
may disrupt the overall project and slow its completion.  Plan on having management's attention for a year, starting
with the purchase decision.   If implementation lasts longer that this, break the project into year-long pieces, and
approve each section with renewed management commitment.  For large companies, a year-long constraint seems
unrealistic, but longer timelines often result in projects that either are grossly late or complete failures.

Seek out those who impact operations the most - in an official capacity or not.





--------------------------------------------------------------------------------

- END Part 1 -
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
HOME