NOTE: This is the first of a series of columns dealing with the selection and implementation of MRP II/ERP applications software. Projects, teams, methodologies, vendors, RFPs, requirements/needs, justification, training, attitudes, platforms, technology, reengineering, vertical software and best-of-breed decisions will be covered herein. If you have any areas of particular concern for coverage in an upcoming column, contact Dick Kuiper at 503-697-9455.

---

By Dick Kuiper

All application software projects involve risk. Even the simplest of efforts probably has only a 90 percent chance

of total success (i.e., the project is on time, within budget and attains all planned benefits). Too often even the best run projects fail because of issues beyond the project team's control. Rogue elements of the corporate infrastructure are like reefs; they may be unchangeable, but they can be navigated around when their presence is known.

Your project will not be conducted in a vacuum, but instead will be realized within the confines, both physical and psychological, of your company. The company culture can either increase the likelihood of success, or breed failure. The longer and more complex a project, the greater the impact of the corporate culture on its outcome.

So what are some of these telltale signs of infrastructure problems?

1. Key personnel not involved in selection process. For key individuals to fully commit to the implementation effort, it is essential they be involved in the selection, i.e., the system chosen must be their system. It is much harder to sabotage, either intentionally or by accident, decisions in which you've been fully involved.

2. Managers do not cede important responsibilities to the project team. Managers who jealously guard their sacred cows of the status quo complicate even the simplest decisions. The project must have established baselines within which the project management can make basically unfettered decisions.

3. Managers do not commit to improvement goals. Many are quick to espouse the need for the project, but are then unwilling to commit to quantifiable measurements — they sign up for the intangibles, but after that all bets are off. Justified projects don't have to search for management support; credible benefits based on hard numbers serve only to increase the pressure and likelihood for success. Avoid the temptation of including reduced headcount (downsizing) in the justification, since this reduces overall support and goodwill, even from those whose jobs are not threatened. Translate the value of productivity gains into growth and profit opportunities.

4. When the going gets tough, a scapegoat is found. Some management groups are all too willing to pinpoint one person to take the fall when a project hits the skids, but very few failures can be laid at the foot of a single person. Management must make it clear that the project failure is a failure for all involved, possibly even affecting bonus decisions. The very willingness to blame others promotes failure since it provides the real guilty parties a convenient escape hatch.

5. Management does not share responsibility for failure. The world is full of people ready to take responsibility for success, but failure is a lonely orphan. It must be made clear that failure, like success, will be spread fairly, with an ample dose for management. By its very nature management is never blameless (high-level decisions are not neutral, they can be brilliant or dismal like many other aspects of business), and all of non-management knows this — their share must be visible to all.

6. Internal politics not resolved quickly. Large projects create the need for many interdisciplinary decisions, resulting in political infighting (even in companies claiming to be free of politics). If the project manager is not empowered to resolve conflicts, there must be a project committee structure to deal quickly with these situations as they occur.

7. Employees and managers are not committed to success. Large projects have no room for doubting Thomases, and the higher the level, the more disastrous the problem. Change their minds, indoctrinate them, disarm them or remove them, but they must be dealt with. Small doses of skepticism can be valuable sanity checks, but unchecked negativism will doom a project. The road to failure is littered with the bodies of project managers too timid to deal with their internal adversaries.

8. Project manager is not a key user. Project managers must come from the user community; all must know that they will be living in the new world they are helping create. The next most important quality of the project manager is that he or she demands respect and cooperation. This is no popularity contest. Step on toes, if necessary, to capture the full attention of management.

Good projects are positioned for success through commitment. If you view your project as a boat, then picture the successful project team getting the key managers and users fitted with lead boots. Swimming to shore if the boat sinks should not be an option. And even though projects with total commitment can still fail, projects with less than full commitment will fail.

The successful project team must recognize the corporate culture (especially its ability to command commitment), warts and all — exploit the strengths and mitigate the weaknesses to ensure success. When all involved feel that their success depends on the project's success, the likelihood of a timely, cost-effective implementation soars.

Copyright © 2020 by APICS — The Educational Society for Resource Management. All rights reserved.

Web Site © Copyright 2020 by Lionheart Publishing, Inc.
All rights reserved.


Lionheart Publishing, Inc.
2555 Cumberland Parkway, Suite 299, Atlanta, GA 30339 USA
Phone: +44 23 8110 3411 | br> E-mail:
Web: www.lionheartpub.com


Web Design by Premier Web Designs
E-mail: [email protected]