Paul Deis asked:
This is an excerpt of a paper originally written by George Miller, Founder of PROACTION. It has been modified and updated by Paul Deis, PROACTION CEO. This article is also available on our website: PROACTION – Generating Best Practices
Overview
Success or failure of a major business systems project is often preordained by how the groundwork is laid. Major change management efforts, such as ERP, Supply Chain Management and Electronic Commerce are often nearly enterprise-wide, involving multiple processes and departments. This paper focuses on how to avoid some of the pitfalls through improved project planning. It is fairly straightforward, not relying upon sophisticated methods and tools. It is written as if addressing a project manager.
Among the topics covered will be an overview of: charter, objectives, priorities, project rules, communications, education, project plan, resources/organization, team member job descriptions, personnel management, management support, budget, funding, third party participation, hardware, software, policies, procedures, task definition, sequencing, and resource estimating.
What is a “System”?
Before trying to plan and manage a major business systems project, it would be beneficial to agree on a definition of the word:
System – An organized way to accomplish an objective. A system consists of missions, leadership, goals, objectives, metrics, policies, procedures, education, training, organization, personnel, tools—it is not primarily a computer project, even though modern business systems tend to be dependent upon computer technology.
Address all of the system elements shown above, to successfully plan and manage a business system project.
Laying the Groundwork
Management Support
Most of us are aware of the importance of “management support” for a major business change effort in an organization. This support should be reflected in the wording and visibility of the project charter, described in the next section. It should also be exercised by key executives whenever the project is challenged for resources, focus, or leadership. Because of the wide scope and number of functional areas involved in a full business system implementation, it’s mandatory to gain understanding at the executive level for what must be accomplished, why, and how it is to be done. At least one true executive sponsor (definition of a true sponsor: someone who controls the needed resources and whose job may depend on success) is needed to increase the odds of success to a tolerable level. The sponsor is needed to encourage, defend, counsel and provide resources to the team. This is definitely not something to delegate to lower level people.
Charter
The “Charter” is a clear mandate for the project team, generally consisting of mission, objectives, scope, direction and authority. It is an agreement between top management and project management. For optimal results, it needs to be repeatedly communicated organization-wide and adhered to.
The charter should be brief—preferably a page or two. Its mission should be a powerful, but simple statement that all employees, suppliers and even customers could relate to, such as: “Being the automotive wire industry leader in quality and customer service.” The objectives should be clear, concise and quantifiable, such as: “provide same-day service on stock items by 12-31-96,” “Achieve six sigma quality in assembly by 6-30-97,” or better yet, “Eyeglasses in one hour.” A major project will likely have multiple objectives.
“Scope” tells the team (and the rest of the world) how far they should go. “Reengineering the test lab operations for the next millennium,” for example, would seem to give the team a little more latitude than “replace the outdated lab computer system.”
Direction and authority statements help make it clear to all concerned who will get it done and how far they can go. Example: “The Comet project team is comprised of direct representatives of each division General Manager who have full authority to formulate and approve policy and operations changes within the scope of the project charter.” Try arguing with that one at the next staff meeting, especially when such a statement comes directly from the Chairman and is signed by all of his/her staff.
Priorities
Major change efforts, such as business systems projects, consume a large portion of an organization’s resources and “mindshare.” There are a limited number of efforts of comparable scope that should be undertaken simultaneously. Such a project needs to be in the top three or four of an organization’s priorities at implementation time if it is to have a reasonable chance of success. If there are no more than 4-5 major company change priorities, the chance of success is greatly enhanced.
Project Planning Phase
Next, the team can get on with the defining of the deliverables, activities, operating rules and resource requirements needed to carry out the project mission and objectives. More specifically, this involves creation of a Project Justification, Project Task Plan, Communications Plan, Education Plan, Budget, Funding, and Team Member Job Descriptions. . . .
Project Justification
No matter what anyone tells you, make sure to do a project “justification,” “business case,” or “cost/benefit analysis.” If this isn’t done, it is much more difficult to defend your project priority and funding from other worthy efforts vying for the same resources, or from the first end-of-the month “crunch” demanding everyone’s attentions. You may need to do a rough cost/benefit analysis before getting any funding at all.
No matter what you call it, the justification should describe all costs attributable to the project, including people. Opportunity costs should be listed separately. All benefits should be cited, whether or not readily quantified or translated into dollars. “Soft” benefits need to be stated, such as “we need this to survive, since top competitors will probably do 75% of their business on the Internet within two years.” Skeptics as well as zealots need to “scrub” the analysis, since it may well be subjected to scrutiny later on.
It’s a good idea to run multiple scenarios based upon varying business conditions and levels of success. Skip the fancy mathematics—justifications aren’t all that accurate anyway, and even if they were, most people wouldn’t understand or bother to read a highly complex one. A justification is more like a yardstick than a micrometer.
Project Task Plan
In spite of all the books, training and wonderful software tools developed to assist project managers in carrying out their appointed duties, project planning is still a tough job, and one not often enough done well. While these aids are helpful, they are no substitute for experience, judgment and a good methodology. Basic project plan elements to be included are: Deliverables, Activities, Activity Descriptions, Sequencing, Responsibilities, Resource Requirements, and Timing. Due to the difficulty of relating to large numbers of tasks in a large project, major milestones should be included in the plan. These are the main things that most people will be looking at to measure progress. Don’t get bogged down in the minutiae of the detailed tasks.
Start with the Deliverables, which can be derived from the charter. Example: An implemented, working on-line order entry system meeting the specifications. Activities should then be developed which will lead to fulfillment of the deliverables. A trait of an inexperienced project manager is to develop overly detailed activity lists which then create a reporting nightmare and make it more difficult for others to follow to comprehend the plan and its status.
How to simplify the plan: 1) – Identify and show on the plan major Milestones, such as “Go ‘live’
with new inventory system.” Show the dependent activities needed to achieve ea
ch milestone. 2) – Make sure the activities shown on the plan don’t get too detailed. For example, “Load existing inventories” is probably sufficient. “List existing inventories, “key in existing inventories,” “Verify that data entered are correct,” and “Correct and reenter erroneous items” are probably too detailed. These should appear in separate Activity Descriptions,” to be administered by the designated people responsible for accomplishing them.
To provide an example, we were involved in a very nice plan for a comprehensive business system project for a $100M+ discrete manufacturer. It had 32 milestones, 340 activities on the plan. There were a total of about 2400 individual steps on the supporting activity description lists used by team members to manage their activities. Note that these steps were NOT used as nodes on the planning network.
Sequencing and timing can best be shown graphically on the plan, and might include start and completion dates.
Each activity should be assigned to a specific person responsible for accomplishing it. In recent years, project managers have been successful in assigning tasks to small teams, if said teams are small, cohesive, and the company culture is conducive to this.
Resources required should be estimated for each activity. Resource definition should be detailed enough to identify constraints but not so detailed that it becomes a major task just to create and maintain the plan. In a business systems project, key people are usually the most difficult resources to schedule. Dollars and equipment constitute most of the other resources. Once the resource estimates are complete, perform a time-phased resource load to determine the probable bottlenecks. Remember that all of this is based upon estimates, that the resources may not cooperate, and that things may not occur how or when you predicted. So, remain flexible!
Project managers each have their own project planning system format, type and software preferences. Some employ simple Gantt charts, while others prefer sophisticated “PERT” (Program Evaluation and Report Technique), CPM (Critical Path Method) or others. We recommend picking one appropriate for your and the organization’s style, as well as the size and complexity of the project.
Contemporary software typically provides the capabilities of calculating schedule dates, critical paths, resource totals, helping to identify problem areas, and providing varying levels of reporting.
Advice on organizing activities—Don’t set them up according to computer “modules,” no matter what the computer software and hardware people tell you. In most cases, the organization of vendor modules does not relate all that well to your actual required business processes or sequence of implementation. To avoid having the tail wag the dog, figure out how you want to run the business first, then how you would go about implementing the project. Hopefully, software selected will have some relationship to the business processes defined, but this is far from precise.
Sequence the tasks according to the priority of desired results, and to some extent, the precedence that tasks must be completed to provide deliverables. For example, if the top priority is to get improved order processing running first, don’t let the software vendor or anyone else tell you that the bill-of-material must be fully implemented first. It may in fact be necessary to implement part of it first, say, the part and description files.
A typical overall plan might be organized something like this:
1. Project Organization (groundwork, planning)
2. Education
3. Requirements definition
4. Upgrading existing systems
5. Cross-project liaison
6. Software/hardware selection/procurement
7. Conference room pilot, training
8. Implementation (by major process)
Communications Plan
Peoples’ understanding and perceptions of the purpose, progress and success of a project have an important effect on project success. In this era of “media” and “PR”, it’s surprising to see the lack of skill and attention paid to communications planning in large business systems or other change management projects.
An excellent communications plan keeps all stakeholders informed as to what needs to be done and what the project status is, and helps motivate them to be a part of the success. It may consist of memos, bulletin boards, articles in newspapers, newsletters and presentations to employees, suppliers, customers, the press, even tee shirts. Don’t go overboard with hokey trinkets. Project personnel and management sponsors should participate in communications. Department meetings, “open houses” and “supplier day”, are examples of communications tools to be used.
Even competitors may be targets of a communications plan- for “disinformation,” to demoralize or even recruit their people!
Education Plan
Effecting major change in an organization means that people need to do things differently. Doing things differently means that people must learn what to do differently and why, if they are to accept change. Such learning for a broad scope business project cannot be merely left to chance, but needs to be part of a coordinated, integrated education program. It encompasses philosophical and conceptual changes, as well as specifics of jobs to be performed. It may span executive through blue collar levels of the organization, as well as going outside to reach suppliers and customers.
For example, a new field order entry system might involve salespeople, sales management, customers who might directly use the new systems, internal order administration, engineering, purchasing, planning and accounting personnel. All these people need, in varying degrees, to understand why this is being done, how it will affect them, and what specifically to do differently.
Educating systems users and their managers is not the only education task. It will also be necessary to educate executive sponsors, steering committee and project team members, and maybe even customers and suppliers. Don’t commit the error of falling behind schedule because it is belatedly realized that team members require education and training before they can perform many of their assigned tasks.
The actual education activities may be delivered by inside and outside resources, including project personnel, trainers, third party representatives such as consultants, software suppliers, academics, customers, or even government organizations.
Budget/Funding
Chances are, at least some budget and funding will be needed before there is a detailed task plan and resource definition. The money to plan the project in detail may not be available until some budget materializes. The budget amount actually provided may have little to do with the resource requirements, but may be based upon available funds, politics, external pressures, or how well the project is sold.
Getting the “budget” is only part of the struggle. Actually getting the money, approvals and people is quite another matter, especially in large bureaucratic organizations, and very especially if multiple organizations have provided budget or must approve resource disbursement.
Team Member Job Descriptions
People are often assigned to project teams without a clear understanding of why they are there or how to conduct themselves after they arrive. Another way to improve results is to prepare job descriptions for everyone involved, from executive sponsors and project managers, on down to individual team members and department liaisons. Job descriptions should contain Objectives, Reporting Relationships (in cases of part time or “matrixed” team members, reporting relationships especially need clarification), Duties, and Qualifications. Use them to structure team member activities, to communicate their responsibilities to the organization, and to evaluate
team members, if applicable. If at all possible, try to make it app
licable, since this is one of the few levers that project managers have in this era of “matrixed” organizations.
Getting It Done
With the proper planning, execution is much easier. This section addresses Organization/Resources and Managing the Agenda to help improve execution.
Organization/Resources
People, money and equipment are the principal resources required. People are the hardest part, so let’s concentrate there. Even in large organizations, there appears to be a surprising lack of people with:
• Leadership talent—ability to motivate people and make things happen
• Broad knowledge and understanding of company processes. “Rightsizing” and organizational “flattening” in recent years have made this shortage even worse in many companies.
So, people who have these attributes are the hottest commodity around, because they’re in short supply. The aspiring project manager will probably spend more time and effort trying to obtain, keep, motivate and manage people than on anything else.
People requirements:
• Leadership- A project sponsor(s) is the first requirement. A major business systems change project probably won’t even get out of the starting gate without one and won’t succeed without a good, dedicated sponsor.
• Project Manager- Ideally, someone with a good reputation, well-connected within the organization, leadership skills, and in-depth knowledge of the business and desired systems skills.
• Project team members- People with the requisite background and skills to perform the various tasks needed to accomplish the objectives. This includes a mix of people with business, industry/technical and computer/technical skills.
So, you don’t have many such people? You’re not alone. The above desired attributes are in priority sequence, so compromise accordingly. Look for real “comers” who show signs of becoming what is needed, and who will grow into the role with time, mentoring, education, experience and self teaching.
Once a project manager is found, look for project team members with complementary skills. Request the best people available. If a good job of “selling” the project need and benefit to the constituent organizations has been done, recruiting will be easier. Unfortunately, not all executives will share the same perception of this project’s importance, and may try to “dump” less competent people on the project. This is another project “make or break” issue. Few incompetents can be absorbed, without fatally compromising the quality, productivity and even credibility of the overall effort.
Generally speaking, internal candidates are preferable, especially as Project Manager. A few new hires or even consultants can be absorbed; in fact some new blood is desirable. Be careful of bringing in too many from one place. For example, the author witnessed a power struggle between the resident “homies” and the “GE boys,” which became destructive – Corporate gang warfare.
For Organizational Structure/Reporting relationships, there are a number of possibilities. For example, large manufacturing companies often have an executive as project director, a steering group composed of other executives with skills or vested interest in seeing it accomplished. This steering group is responsible for seeing that proper direction is set, resources are provided, and that things happen as desired.
The steering group normally appoints a Project Manager and a project team is formed. This team should be staffed with people able to do the planning and execution to accomplish project objectives. There are different opinions on whether the team should be full-time, part-time, external or internal. We have found that a small full-time core team or at least a full-time Project Manager is just about mandatory for success of a major business system project in all but the smallest organizations. Other members are often on assignment from their “departments,” either full or part time. Although it would seem that an entire team of full-time members would be the ideal case, in practice, that doesn’t seem to be the case. This is probably true because members that retain close ties to their areas get better “buy” in from their department constituents and stay closer to the “real world.”
Larger teams sometimes appoint people to various supervisory, quality control, specialty and administrative posts. Don’t go overboard with this. It’s easy to end up with a large number of people in such “support” positions to the other team members, who, come to think of it, who are themselves support people. Smaller organizations, on the other hand, will tend to combine positions. Recently, we met a project sponsor who was also the Project Manager and Materials Management team member.
External resources are almost always used, to fill non-recurring skill needs, to educate and train company people, to provide advice, counsel and auditing of the system. There is nothing magic about engaging and managing outsiders, as long as you recognize differences in motivation, compensation, and organization.
For example, management consultants, if any good, are objective professionals. They are motivated by doing a good job, being recognized, being independent, and making money. The good ones work with you, not for you. Recognition of that subtle difference can make you a more successful Project Manager. Management consultants may report to the project manager, but there is often value in having them report to the steering committee or elsewhere in executive management. Some Project Managers dislike this, but there are often advantages to affording this high level of visibility.
Programmers often take very great pride in their work, technical skills, and may pride themselves on being different than the business types running the show. Listen to their concerns, learn from them, give them their space, but make the trains run on time.
Vendors may assign “project managers” or “account managers” to help you. Make sure they know whose “account” it really is. There’s usually no need to make a big deal about who is in charge, unless they’re unusually dense or egotistic. In fact, they may know a lot more than you about their areas of expertise—that’s why you’re paying them the big bucks. Get your money’s worth, and remember, these people often are under more pressure to bring in “billable hours” for their companies than to bring in your project on time and on budget. We’re not just picking on vendors—the same may be true of almost any outsiders, including consultants. They should always be provided with clear objectives, schedules, deliverables, budget, company liaison/controller, and performance measurements.
Managing the Agenda
Much time and effort can be wasted if the project isn’t effectively run. Good people, organization and project planning go a long way toward helping to accomplish this. Beyond that, Project Rules, Issues Lists, and Activity List Management can further improve a project.
Project Rules
Operating rules help structure the process and make things run smoothly, but don’t overdo it. There should be certain mores, methodologies, and tools used. These should be communicated in a specific manner. If left to chance and informality, these will default to standard practice, which is something that might need conscious effort to change. Rules should include meeting rules, approval process, procedures for getting things done, quality standards, etc., or problems will ensue. For example, one of the author’s clients had a practice of making sweeping procedural changes without formally rewriting the procedures, gaining concurrence, or even testing them first. After a disastrous experience, this unwritten policy was finally reversed and a formal change introduction process was implemented.
Issues Lists
One way to manage the project better and to make meetings m
ore productive is to use the Project Task Plan and a running Issues List as the main agen
da items for project meetings. Many projects have meetings which are largely a waste of time because team members don’t stay focused on the work they were assigned to do—finishing the project. Most project meetings should focus on the deliverables, tasks, and issues related to getting them done.
During the course of any project, team members and other stakeholders will perceive various problems and opportunities. These should be recorded on the issues list and assigned: responsible people to resolve them, priority, schedule, and an explanation of each issue. The project team draws upon this list and the task plan to help focus their energies on what needs to be accomplished.
As more is learned about the issues, and solutions are developed, the list is updated. Closed issues are kept so that the resolution is remembered and issues don’t need to be “solved” more than once.
Activity List Management
Making sure that the work gets done right is one of the most difficult jobs for a project manager, especially in a major business systems project, which often crosses a number of departments, functions, processes and skills. The first problem is being able to recognize whether something is done and done right.
The second is to determine how much has been completed for the resources expended (earned value), and whether the resources were really expended. This is especially important when a team member’s “home department” is charging the project for time spent.
The third problem is how to diplomatically communicate the need to do better or faster than what has been done, especially if there is a dispute as to earned value and quality of work performed. This has actually become more difficult in the current era of “empowerment” and “teams,” when the efforts of a project manager are more likely to be interpreted as micro-management.
Recommendations—In review sessions, have the team member or sub team walk through what has been accomplished, through presentations, write-ups, or demonstrations. If the project manager is not technically competent in the area under discussion, bring in a peer review group, such as users, outside experts, or “customers” of the process under examination. If there are specifications or requirements, check the work against these. Ask those reviewed how far along they think they are, how much time has been expended, and the estimated balance to go. Ask about unforeseen issues, or recommended changes. Ask the reviewers the same questions, possibly at another time. Check the time worked vs. earned value claims, against the original estimates, and compare to what you have observed. For example, if someone estimated he would spend 10 hours a week on his task, but reported 35 hours a week, and you haven’t seen him around much, and the work is way behind the power curve, there may be a problem.
Initially give the team member(s) the benefit of the doubt, since they often have other responsibilities, or are volunteers who have taken on more work to help with your project.
The True Nature of a Business Systems Project
We have heard about or encountered a number of projects that went bad because management failed to realize the true nature of the tasks. A business systems project is not primarily about computers or software. Granted, these play an important role in businesses now, but they’re not the main challenge. The main challenge is, simply stated, getting people to realize what has to change, then changing to accommodate it. If there is still any doubt about this, go back and re-read the definition of a system near the beginning of this paper. It’s about people, leadership, policies, procedures, etc. If there is still doubt, interview executives of companies who succeeded or failed in major projects. They usually talk about commitment, people and education as the pivotal factors—win or lose.
A few words of advice about selecting Computer Hardware and Software for major business applications. First, it’s too important to be left to hardware and software people. Nowadays, these choices can help make or break a company. Imbedded in software and hardware are management philosophies and implicit decisions about company focus, response times and industry standards. The people who run the company must be involved to ensure these choices are made, even if only to help instill “ownership” on their part and that of those who will use these new tools. You still need technical expertise, but don’t let selection turn into a contest to find the flashiest “platform” or the most “efficient code.” For more on selection advice, on the PROACTION web site you will find excellent information regarding the SoftSelect process, our Best Practice in the area of Enterprise software management and selection.
Next, you can’t understand how or even if software will work for your company without an intensive test drive, usually referred to as a “Conference Room Pilot.” This is not just a brief razzle-dazzle vendor demo, or even halting efforts at playing with the screens on your own, but is a sophisticated business simulation, run by your company and supported by competent technical and training resources, you can read the free article on this topic on the PROACTION web site, or purchase our Best Practice Course – Conference Room Pilot.
In Summary
Managing a major business systems project plan is a very significant undertaking. Hopefully, we have helped to expand your understanding of the size, scope and complexity of the task, although it is only possible to summarize a few important points in this brief paper. You have probably noticed that basic project management principles were adapted to fit the nature of an enterprise-wide business systems change management project. The author used a manufacturing company for a model, but this approach could easily be adapted to other situations. It is recognized that there are other equally or maybe more valid possible approaches.
ABOUT THE AUTHORS
George J. Miller, CFPIM, is Founder of PROACTION. Prior to selling the company to Paul Deis, George had worked with dozens of companies in assignments involving productivity, quality and service improvement, business systems, change management, acquisitions, divestitures, expert witness testimony, and others. Prior to founding PROACTION in 1986, he was Vice President of Marketing for Western Data Systems; Director of Planning and Development and Assistant Director—Operations for Purolator Technologies (PTI); Consultant for Booz-Allen & Hamilton, and Manufacturing Systems Manager for Becton-Dickinson.
Paul Deis, CFPIM, is CEO, PROACTION. He brings over 25 years of consulting and senior executive experience to his work, including detailed work with nearly 60 companies. Prior to acquiring PROACTION, Paul’s experience includes running a small ERP software company, leading other consulting businesses, prior work with PROACTION, Manager at Deloitte & Touche, VP Manufacturing at Raypak, Inc., where he was very successful with an early Lean management initiative, and dozens of projects in the areas of enterprise software, operations management, crisis resolutions, in a wide variety of industries, business types, and scales. Our website: PROACTION – Generating Best Practices