SAP & ERP Consulting from the Customer Point of View

Why SAP Process Understanding, Troubleshooting Ability, and Knowledge Transfer Techniques are Missing in SAP or ERP Projects

Because an ERP system like SAP has a single database or a single instance of data, a full process chain of dependencies is developed.  Every organizational function becomes dependent on the process steps before and after it no matter what department or area is responsible (Kallinikos, 2004).  Because of these dependencies, a data error is no longer contained in a single isolated system as in times past.  Each data error, or each problem that occurs has both upstream and downstream consequences and the corrections cannot be made in isolation. Improper configuration or system design can have huge impacts on the amount of effort to correct the data and to maintain the system in an ongoing fashion (Sia and Soh, 2002).

A good consultant’s role on an SAP or other ERP project is to guide the company through design decisions and make the system settings to support those design requirements.  This is usually called the “implementation” process.  During this process they should be focusing on knowledge transfer as well.  However, many of the “consultants” who implement SAP or other ERP systems have little process or troubleshooting understanding (see A Cautionary Tale About SAP Knowledge Transfer).  As a result of this lack of consulting experience, or of the number of fakes in the marketplace, knowledge transfer is usually not sufficient.

Speaking in technical terms may make a consultant SOUND smart or knowledgeable, but it does not mean they ARE smart or knowledgeable. The mark of experience, intelligence, and knowledge is the ability to make the complex or technical seem simple or at least understandable.

For long term business benefit and ROI your implementation vendor must provide consultants with solid overall process understanding.  Without this process understanding, as well as their module specialization, those consultants will not  be able to achieve a process oriented implementation.  If they do not have a process understanding how will they help you realize any process efficiencies or improvements during the design process?  Without the overall process understanding how can they guide your company through the change management process needed for competitive business transformation?

If you fail to demand that the SAP implementation vendor provides strong end to end process consultants your company will struggle with day to day operations after the consultants are gone.  Without those strong end to end process consultants your transition to proficiency with the system will take much longer and be more difficult.  In the end any increases in productivity, or in business value will take much longer to realize, if you ever realize them.

SAP systems are typically implemented for business transformation.  That transformation generally is related to process improvements, automation, and customer focus; to address competitive pressures and business value propositions.  One of the most important components of that business transformation effort is the change management and knowledge transfer (however you describe those activities).

Achieving SAP Maturity by Using the Correct Knowledge Transfer Techniques

Business transformation and change management techniques are often described by many different names:  knowledge transfer, learning organizations, sustainment, production support, knowledge management, agile enterprises, etc.

There are a number of quality change and training programs available for SAP projects but few of them achieve a level of competence needed for an SAP Center of Excellence.  As the next post lays out, Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project 2, change management and knowledge transfer for business transformation requires several activities.  A more complete list of knowledge transfer methods includes:

1. Transactional processing (typical keyboard training).
2. Business process understanding (some projects use this method with transaction flowcharts for showing dependencies).
3. Master data dependencies (few projects do this level of end user training because it is generally the implementation consultants who have this level of understanding).
4. Operational processing (fewer projects still do this type of training because this is the production support “troubleshooting” type of training that requires seasoned consultants to be on site long enough to help users work through the issues).
5. Ongoing knowledge transfer activities such as ad hoc troubleshooting meetings with all affected users (work through problems as a group in a conference room).
6. Continuing communication about tips and tricks after the system is live.

For long term success in the marketplace, beyond the operational excellence proposition, a continuing change and transformation program needs to be undertaken after the system is live.  This requires post production support efforts to begin evaluating real areas of opportunity in the marketplace.  Organizational and business change is no longer an option, as Mike Myatt notes, it is an imperative in today’s global economy (see Leading Change and Change Management http://www.r3now.com/leading-change-and-change-management).

Poor Knowledge Transfer Planning or Methods and Implications for Long Term System Support and Cost

One of the biggest workforce readiness problems with any SAP implementation is that the consultants who implement the system rarely have any significant production support experience.  Without that production support experience, and the end to end process understanding, it is impossible for meaningful knowledge transfer techniques you need for long term success.  Without the understanding of support they are unable to address items 4, 5 and 6 listed above.  And without that complete level of knowledge transfer organization maturity takes much longer.

That lack of production support experience (and I do not mean the month or two after go-live, but longer term support) means these consultants don’t know how to design a solution that avoids some of the “lessons learned” from the past.  They do not know how to prevent you from “driving off the road” with your solution after you go live because they have never had to live with the decisions and “solutions” they have provided.  Most of the consultants who come to these projects do not understand how to untangle, resolve, or fix problems that occur in the system when it is productive (cf. Scott and Sugar, 2004).  Because they aren’t even aware of what to expect in a live environment they don’t have any basis to transfer that knowledge of troubleshooting techniques or methods to you as the customer.  As a result your support pains may be far greater and last much longer than you anticipate.

This same lack of consultant experience with post-production issue resolution prevents them from being able to transmit operational understanding to you, the client.  In other words, consultants without deep and broad experience are not capable of ensuring you have a relatively smooth go-live.  So not only do they fail to design solutions that are more streamlined or automated, they have little ability to ensure you have a smooth go-live experience.  When you combine this lack of support experience with the number of outright fakes and frauds in the SAP consulting space it is no wonder there are so many unhappy ERP customers (see Screening Methods to Find the Right SAP Consultant Part 1).

My experience has been that consultants who lack this broad and deep experience with production support rarely know what needs to be tested before the system is live.  And without adequate testing you can expect to find ongoing data and system design or setup problems for some time after you go live.

How Do You Remedy the SAP or ERP Knowledge Transfer Plans and Methods to Support Change Management Processes?

1. If the consultants speak in overly technical terms, have a language barrier, or if there is a lack of overall process understanding ask your SAP implementation vendor to replace them (see Screening Methods to Find the Right SAP Consultant Part 2).  Speaking in technical terms may make a consultant SOUND smart or knowledgeable but it does not mean they ARE smart or knowledgeable. Baffling the uninitiated with technical jargon is a classic smokescreen to mask inexperience and incompetence. The mark of experience, intelligence, and knowledge is the ability to make the complex or technical seem simple or at least understandable.
2. Communicate to ALL internal company project members before the project begins that they will be responsible for long term support and training of end users.  Let them know that they must immediately notify project management if any consultant(s) have significant barriers to transferring knowledge or understanding.  This must be communicated early in the project because by the time the knowledge transfer for training begins it will likely be very disruptive and risky to make the needed resource changes.
3. If you need to remove a consultant don’t wait until the timeline is so tight it would create a significant project risk. Include a contract provision that if a consultant is replaced for lack of skill, language barriers, or other reasons related to skill, performance, or ability to ensure knowledge transfer that a credit for at least the prior 4 week’s billing is due (four weeks is reasonable for you to discover the problems and is not unreasonable to insist on a credit).
4. Avoid customized or technical solutions for anything except mission critical requirements or for solutions that directly address business goals and marketplace competitive pressures (see SAP Implementation Focus, Software Engineering or Business Process Engineering?).
5. Use the RFI and RFP process to solicit comments, methods, tools, and resource examples of how knowledge transfer will be handled.  Be sure to leverage a Request for Information process and the RFP process as an educational experience (see Breakthrough Project Success: 3 of 4, Vendor Selection and Contracts).
6. Use the RFI process to ask for sample consultant resumes, and the RFP process to insist that final resumes for the actual project must be submitted.  Note in the RFP that any non-response may disqualify the vendor.  SAP is mature enough that there is no reason an SAP implementation vendor should have problems providing key resources.
7. Check with client references from the consultant’s resumes who are submitted (and not the sales pitch references) for application skill, ability to do knowledge transfer and for change management skills.
8. Construct your services contract with an expectation of knowledge transfer (which I define as “operational independence”) or with a penalty for failing to do so.    For some ideas on how to structure a contract agreement to cover this see the section titled “Operational Independence is the Key Success Criteria or Measure of SAP or ERP Knowledge Transfer” toward the bottom of the post  A Cautionary Tale About SAP Knowledge Transfer.
9. Be ready for a drop in productivity right after the system goes live.  However this should be a temporary situation and the better the knowledge transfer and change management has been the less pronounced and shorter the duration will be.  If done successfully there should be an improvement in overall productivity after the initial drop.
10. As you move into support mode after going live then begin to document the transaction processing steps necessary for fixing, resolving, or troubleshooting problems that arise.  Conduct weekly or bi-weekly training and knowledge transfer sessions to internal employees and provide different tips, tricks, or techniques for problem solving.
11. Monitor progress within each process area and continue to keep the communication program going within the company after the system goes live.

=========================

Kallinikos, J. (2004), “Deconstructing Information Packages. Organizational and Behavioral Implications of ERP Systems.” Information Technology and People, Vol. 17, No. 1, pp. 8-30.

Scott, J. and Sugar, D. (2004), “Perceived Effectiveness of ERP Training Manuals.” Proceedings of the Tenth Americas Conference on Information Systems, New York, pp. 3211-3215.

Sia, S. and Soh, C. (2002), “Severity Assessment of ERP-Organization Misalignment.” Proceedings of the Twenty-Second International Conference on Information Systems, New Orleans, pp. 723-729.

Related Posts:

• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Series on SAP Competency Center or SAP Center of Excellence
• Opportunities for INNOVATION SAP, HELLO?
• Using SAP to Improve Revenue and Profitability
• SAP System Vendor Project Success Criteria 1

Previously I explained the two primary types of implementations–, with SAP or any other ERP package you will do business process engineering or software engineering.  The differences in these two types of implementation approaches will have a major impact on your total cost of ownership (TCO) and your long term application life-cycle costs.

——————————-

Software Engineering or Business Process Engineering?
http://www.r3now.com/sap-implementation-focus-software-engineering-or-business-process-engineering
April 29, 2010

There are two primary ways in which SAP (or any ERP system) can be implemented in your company; you make your company fit the software or you make the software fit your existing processes. These two methods provide the end-point markers or goal posts and all implementations fall somewhere between them. They present the classic options you have available, either you do a software re-engineering project or you do a business process re-engineering project.

No matter which route you choose, there should be clear business justifications for the approach you take. In other words, do you have specific processes that are part of your core value proposition or processes which create significant competitive advantage in the marketplace? If your processes are that unique to your business model are there other ways to gain the same process advantages? These types of key questions help to clarify whether or not there is a business justification for one approach or another.

——————————-

Software Engineering (SAP or ERP Custom Coding) Still Requires Change Management

If you choose software engineering you will still need change management processes but the transition will not be as extensive.  However by choosing the software engineering route (changing the system to match your business) up front development costs will be far higher, long term support will be far more expensive, and depending on the extent of the custom solution you will be tied into a particular vendor.

Generally less-experienced consultants choose the software engineering route over business process engineering because it reduces their experience requirements.  It is easier to insist that only a custom solution will work if they do not know how to use, setup, or support some standard functionality in SAP (see e.g. A Cautionary Tale About SAP Knowledge Transfer). This is also the “cop out” approach when some consultants (or system integrators) do not know how to guide a business through the critical change management and knowledge transfer efforts needed to accept new processes or concepts.

In some limited situations changing the software (or doing custom coding) to match your business is necessary.  If it is truly lined up with business goals and objectives, or if it addresses marketplace or competitive pressures so that it allows you to be a more effective business then the custom development is likely justified.  On the other hand if it is to avoid the difficult change management process in areas of the business that do not directly affect competitive pressures or reduce costs, etc., then it is probably not justified.  Instead you are better to engage in the intense change management strategies and processes to make the transition to a new way of operating.

In the short term custom coded solutions may “fit” your current business environment, and those custom solutions may reduce some of the resistance to “change,” but there are longer term consequences.  But there is a significant trade-off.  To the extent that you rely on custom coding and modify the system you are locked into your original vendor.  If you need something changed later, or if you want to add additional functionality you no longer have the option of selecting any number of qualified or skilled consultants from the general marketplace.  Therefore you have less leverage to contain costs (see ERP Consultants: Is the Promise of Knowledge Transfer just part of the Sales Pitch?).  And while the change managements costs may be lower initially by changing the software, those costs are simply transferred to other areas of the project.  And often times at a much higher cost.  If you decide on modifying a package application like SAP then you will pay a higher cost for developer time than for the change management and training effort.  You will also have far higher support and maintenance costs making your entire application life-cycle far more expensive (see SAP Implementation Focus, Software Engineering or Business Process Engineering?).

SAP Custom Coded Solutions Introduce Significant SAP Project Risk

As the number and complexity of development objects increases the risks to business operations increases.  This statement may seem obvious either before a project begins, during testing, or after a project is finished, but in the heat of an implementation it can easily be overlooked.  Along with this, to the extent that business operations are subject to risk so is a company’s financial performance.

Every time you custom code an SAP solution you introduce potential performance problems, additional processing overhead, potential coding mistakes, and worst of all, unforeseen process problems and gaps.  Along with these risks you do not have the benefit of the dozens, or hundreds, or in some cases even thousands of previous customers who have used, tested, fixed, and worked through the issues with new functionality offered by the application vendor.

It is all too common to find numerous bugs and fixes in custom programs once a system goes into the live production state.  Even the best coders can rarely account for every nuance, variance, or variable in processing that might occur.  When the development becomes even more complex it is even more important to evaluate whether there are standard system options which can handle some or all of the requirements.  Complex development often leads to much more significant bugs, including in areas that they might integrate to or transfer any data to or from.

Unplanned ERP Application Maintenance Costs Escalate Over Time

Once the custom coding is completed, if the software vendor (like SAP) releases patches or fixes to other functionality, or if you find a problem that the software vendor has a fix for you may in turn break some of your custom coded solutions.  Once those are broken, your business operations may suffer, and you are at the mercy and cost of getting the custom development fixed.  And on any large package application like SAP, you will likely be applying fixes (SAP OSS Notes) to the system from time to time for several years.  This doesn’t mean that the software is necessarily buggy, only that small nuances or optional functions have been discovered by some other customer that you might benefit from.  Each application of these changes then requires more extensive testing because of the custom coded solutions.

SAP or ERP Custom Solutions Still Need Sufficient Knowledge Transfer and Documentation

As part of my knowledge transfer techniques and plans in that situation I made sure that every small section of custom code was extremely well documented, and the entire solution was well-documented.  The client did the testing and was thoroughly trained on the custom solution, the dependencies, the master data requirements, the implications of master data throughout the process, the use of the coding, etc.  In other words, a thorough knowledge transfer process was carried out with the critical techniques and methods for the client’s long term independence.

There are times when a custom solution is necessary, but could you imagine a “con”sultant** trying to do this without deep knowledge and understanding of SAP’s Sales functionality?  This company had been told several times, by several “con”sultants** that what they wanted to do could not be done and there wasn’t an aftermarket product to support their need.

Custom Coded Solutions (Software Engineering) Limits Your Training Options

For the custom solutions and the customized functionality you no longer have the option of going to the SAP training programs to learn the system functionality (so you can configure it yourself).  You are tied into the original vendor at premium rates to maintain your system.  If the customizations are extensive enough, you will be pressed to use the original vendor to do any future upgrades or system work.  Essentially you have cut yourself off from competitive bidding because the cost of a complete re-implementation may be cost prohibitive.

Expect much higher application life-cycle costs.  Are you ready to be the only customer with that specific solution that is not supported by the application vendor (except at super-premium rates)?

An Example of a Necessary SAP Custom Solution With Business Justification

Don’t get me wrong, there are times when a custom coded solution is necessary.  While SAP’s application is very broad and very deep, it still has some gaps, or you may have some genuinely unique requirement.  For example I was at a client recently who wanted a Trade Promotion Execution solution.  Not just reporting or analytic functionality (like the CRM solution), but a true sales and marketing execution “cockpit”.  This cockpit had to be completely flexible so that they could do any mix of products, in any quantity they defined, to qualify for either additional free items or additional items at a discount, or some of the items ordered in that combination at a discount.  On top of that it had to be able to have limits so that as certain thresholds were reached, within a certain period of time, the customer would no longer be eligible for the promotion, or they would qualify for a different promotion.

The requirements and flexibility were so comprehensive that it would have entailed an entirely new application sub-module from SAP.  As a result I worked with them to design and implement a custom solution to handle all of these requirements.  This was mission critical for them, it was aligned with a key business need, and it was focused on customer retention and acquisition.  This was all done within the existing SAP provided order processing framework. On occasion I provide limited support for this custom solution (however they are fairly independent), but it was well documented, tested, and trained before I left.  In over a year in production there has only been a couple of minor issues with the entire solution and it has worked well for them with numerous creative order and marketing requirements.

Their sales and marketing programs have allowed them to profitably grow at a greater rate than any of their other competitors.  This growth and profitability has occurred during a major economic downturn.  I can’t say that my solution is completely responsible for that, but what I can say is that they were a sophisticated SAP shop who had clear processes and marketing requirements and the solution enabled them to be more efficient and effective with their marketing programs. This solution allowed them to reduce the previous 4 – 8 week development (custom coding), testing, approval, and roll out time line for each promotion or sales program to only a few days.   They also gained additional analytics of program and promotion effectiveness. This solution has allowed them to be very proactive in customer acquisition and almost instantly reactive to competitors for customer retention.  Their competitors have no competing solution and are subject to highly manual processes or long lead time custom solutions.

In this case the custom development was clearly connected to a specific business requirement that was mission critical and focused on customer and revenue growth.  In my opinion that is certainly an appropriate justification for a custom solution.

Conclusion on Custom SAP Solutions and Application Life-Cycle Support Costs

The costs and consequences of custom solutions to overall life-cycle support are generally far higher than they may initially appear.  For example there is the:

• initial developer cost together with
• the application consultant’s time,
• additional documentation,
• additional knowledge transfer,
• additional testing beyond standard functionality requirements,
• long term (unplanned) support costs with the incumbent vendor,
• no standard or vendor provided training,
• changes, fixes, or bugs are not included in vendor maintenance payments,
• additional upgrade testing or “lock in”,
• paid vendor maintenance may actually “break” custom solutions requiring additional rework,
• etc.

If there is not a strong business justification for a custom solution you are much better off trying to make the standard system functionality work.  To the extent you do you will reduce overall long term support and maintenance costs.  One other key consideration is that by reducing the number and amount of custom solutions when it comes time for an upgrade your change management and testing time will be signifantly reduced.  You will have already made the initial process change requirements by changing to standard system options and you will not have to verify, fix, and extensively re-test all of the custom development.  Standard functionality is supported by the software vendors normal patches, fixes, or OSS Note based enhancements. 

In the end there should be a strong justification for custom coded fixes and solutions.  Carefully consider the cost / benefit ratio for any custom coded requirement.  Sometimes custom coded SAP or ERP solutions make good business sense, other times they are a train wreck waiting to happen.

Related Posts on SAP Change Management, Knowledge Management, and Training

——————————-

Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project
http://www.r3now.com/change-management-strategies-and-knowledge-transfer-processes-for-a-successful-sap-project
May 24, 2010

People, organizational, and change management strategies on an ERP implementation are usually more difficult than the technology implementation. One of the biggest problems in workforce preparation for ERP applications like SAP is the type of training they receive. The types of training you decide to use are all part of the knowledge transfer strategies, techniques, or methods to support business transformation.

Most companies only perform the traditional scripted keyboard training which consists of carefully controlled individual transaction exercises. The typical system implementation focuses on training individual transactions without the explanation of dependencies or processes. This works for initial exposure to the system–, for learning the user interface and the new data entry requirements. Typical training methods generally do not transfer process related knowledge critical for success such as:

• The significance of the data that is entered.
• Where that data is integrated into other parts of the system.
• What the underlying data dependencies are.
• What types of troubleshooting steps to take.
• What interdepartmental impacts exist.
• What part of the overall process is affected.
• Etc.

Together with these common gaps in knowledge transfer techniques and methods there is little ongoing follow-up after the system is live such as:

• Communications about maintenance or performance tips and tricks after the system is live.
• Additional troubleshooting training or techniques as they arise.
• Where to find key data and information for decision making.
• Etc.

===========================

**  Please pardon my periodic references to the con artists (“con”sultants) in the marketplace.  My frustration with the frauds and cons in the marketplace is the amount of damage they have done.  Frankly I believe it is a testament to SAP’s ability to produce implementation methodologies and control structures that the sheer number of frauds in the marketplace have not destroyed far more implementations.  I’ve paid my dues and have worked my way through the ranks in:

• training,
• then to configuration,
• to project / module lead positions,
• through numerous full-cycle projects in multiple modules,
• to project management,
• and then out on my own as an independent contractor,
• and then to trying to strategically grow a business with only the very best.

——————————-

Leading Change (and Change Management)
http://www.r3now.com/leading-change-and-change-management
May 17, 2010

While there is little debate that the successful implementation of change can create an extreme competitive advantage, it is not well understood that the lack of doing so can send a company (or an individual’s career) into a death spiral. Companies that seek out and embrace change are healthy, growing, and dynamic organizations, while companies that fear change are stagnant entities on their way to a slow and painful death.

Agility, innovation, disruption, fluidity, decisiveness, commitment, and above all else a bias toward action will lead to the creation of change. It is the implementation of change which results in evolving, growing and thriving companies.

——————————-

A Cautionary Tale About SAP Knowledge Transfer
http://www.r3now.com/a-cautionary-tale-about-sap-knowledge-transfer
February 3, 2009

Genuinely seasoned consultants recognize that the time they have spent “in the trenches” cannot be replaced by one project’s knowledge transfer; therefore, they are not threatened by encouraging your understanding. Many talented consultants thrive in an environment where they are challenged, and learning, and solving problems. It is a dimension of a successful consultant’s personality and character. So transferring knowledge is second nature to a skilled and experienced consultant.

Most often the truly skilled consultants with practical business and work backgrounds are the ones who can speak to issues in plain, understandable terms. They have been through the go-lives, they have done the production support for the user community, they have had to work through the complex or thorny processing issues, they’ve seen where things were done right (and not so well) and they have gained a solid process understanding. They do not have to rely on “fast talking techie speak” to keep you confused and in the dark. And if you’re not clear on what they are saying how are the project team and user community going to understand them?

——————————-

ERP Consultants: Is the Promise of Knowledge Transfer just part of the Sales Pitch?
http://www.r3now.com/erp-consultants-is-the-promise-of-knowledge-transfer-just-part-of-the-sales-pitch
February 10, 2010

Most ERP projects are filled with promises of software knowledge transfer from the consultants to the client. Yet once a project is over, in many cases, the client is clueless when it comes to making software configuration changes, and may even struggle with performing basic transactions in the system. So what gives?

In spite of all the lip service given to knowledge transfer, the problem is there never was a real strategy to make it more than just a dream. Secondly, when push comes to shove this once important concept of learning suddenly becomes something we worry about later (and of course, it never happens). This is similar to consultants building a spaceship to get you to Mars with the understanding we will not plan the return trip until after you get there.

——————————-

Software Engineering or Business Process Engineering?
http://www.r3now.com/sap-implementation-focus-software-engineering-or-business-process-engineering
April 29, 2010

There are two primary ways in which SAP (or any ERP system) can be implemented in your company; you make your company fit the software or you make the software fit your existing processes. These two methods provide the end-point markers or goal posts and all implementations fall somewhere between them. They present the classic options you have available, either you do a software re-engineering project or you do a business process re-engineering project.

No matter which route you choose, there should be clear business justifications for the approach you take. In other words, do you have specific processes that are part of your core value proposition or processes which create significant competitive advantage in the marketplace? If your processes are that unique to your business model are there other ways to accomplish the same process advantages? These types of key questions help to clarify whether or not there is a business justification for one approach or another.

——————————-

Related Posts:

• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Planning For a Smooth Go-Live: Part 3
• SAP Implementation Partner or Company Selection Criteria
• SAP Implementation Focus, Software Engineering or Business Process Engineering?
• SAP Development Landscape and Systems: Misguided Practices Carry Huge Costs

Twelve Tips to Avoid an ERP Schedule Disaster

In my previous blog entries, we established the need to develop a valid ERP project schedule to serve as a tool to manage the project and set the right expectations (in terms of time and budget). The point is ERP planning is not about throwing darts to come up with dates or forcing a schedule to say what we want it to say. We can wish all we want, but a schedule should reflect project realities, and agreed upon planning assumptions.

In addition, we previously emphasized there are several key inputs into the project scheduling process. Two of them often destroy the validity of the schedule before we even get started:

1) Token client input, involvement, and no ownership of the plan,

2) Glossing over the important project scope details.

Project Plan Training

The goal of this article is not to get into a laborious discussion of cranking a project schedule. The discussion will focus on what the practitioner can do, when constructing the plan, to make sure it is a good predictor of the future. The assumption is the reader has a basic understanding of project planning concepts such as “work breakdown structures”, tasks, task durations, task dependencies, deliverables, and resources assignments. If not, take a basic project-scheduling course, and get any other assistance required.

Project Planning Software

It goes without saying some type of project scheduling software is necessary and a basic understanding of how to use it. However, contrary to popular wisdom, a mastery of Microsoft Projects, or any sophisticated project-scheduling tool, is not a prerequisite for constructing a valid schedule.

ERP Project Plan Templates

Furthermore, it is OK to use a schedule “template” as a starting point, particularly if one has questions about project phases, deliverables, and basic task dependencies as they relate to ERP. Templates, deliverables, and other information are readily available on the internet, and from software consultants and software vendors. However, templates are no substitute for getting educated, planning the project details, or, for that matter, getting the help to develop the schedule when needed.

The Sales Proposal is not “The” Project Schedule

In addition, it does not hurt to reference the sales proposals from consulting firms that may have quoted the project, but do not take them too seriously. Why? Sales proposals are just that… a sales pitch, not the real project schedule.

Sometimes it is very difficult to get this concept across to management since many want to hold the consultants accountable for unrealistic schedules (and budgets). What they fail to realize is the schedule is not the consultants, but rather the clients. Furthermore, when the schedule in the sales proposal is wrong (and they usually are) the client pays the price down the road, and the consultants are the beneficiaries of schedule and cost overruns.

The schedule used to manage the project is produced after consultants are selected (when using them), and as mentioned before, after the project scope and client project planning responsibilities are clarified. In addition, prior to publishing any schedule, specific project objectives, the project organization, roles and responsibilities, and time commitments of the team, are finalized and approved by senior management. A decent estimate of the budget is also an input, though the approved schedule is used to finalize it.

In all fairness to consultants, when developing a sales proposal there is simply not enough time, or justification of consulting resources, to get into the details required to flush out a valid schedule. Remember, vendors do not make money on proposals unless they are accepted. Therefore, they spend most of their time getting the client to accept it, and less time making sure it is right.

Avoid the Subtle Pitfalls

Some of the items listed below many not appear on the surface as a big problem. However, the devil is in the details and when one considers the cumulative affects, the results can be a project that ends up hopelessly behind schedule.

#1: Methodology Matters: Understand the ERP Deliverables

Most ERP projects use the “traditional” implementation approach, rapid deployment, or somewhere in between. Whatever methodology you intend to use, get into the specifics of the implementation process, and understand what it truly entails. This is because methodology affects activities, what is delivered, and content of each deliverable. In other words, it will have a huge impact on the work performed (among many other things).

For example, some rapid deployment strategies (wrong, right, or indifferent) skip the formal project team-training step and do it on the fly during the project. Another example is “current process analysis”. The traditional approach treats this as a distinct phase with “current process map” deliverables. On the other hand, rapid deployment may involve informal current environment overviews, discussions, and more or less jump right into prototyping. The point is not to get into the pros and cons of any particular methodology. Nevertheless, in this example, both have a “current process analysis” line item in the methodology, but the level of detail, the type of work, and the physical deliverables can be very different.

#2: Organize the work breakdown structure around business processes

ERP software is implemented around business processes. So why not organization the schedule the same way? This approach also makes the schedule easier to develop and understand. Whether we are talking about team training, current processes, “to be” processes, design, configuration, testing, or end-user training, the common thread is the focus on business processes. Granted, not all project tasks are easily organized in this manner, but most are.

#3: Allow reasonable time to define the unknowns

Any project task with the word “define” or “design” in front of it usually implies more unknowns, more issues, and more decisions. When you stop and think about it, an ERP implementation is about making decisions. In fact, deciding something can take longer than the execution of the decisions.

Therefore, unreasonable timelines to understand the issues, gain consensus, and make decisions can kill a planned go-live date in two ways. First, the schedule is not real to begin with. Secondly, when we rush to complete analysis and design because of unrealistic timeframes to make informed decisions, rework is enviable.

#4: Recognize the project tasks between phases

For example, it is not realistic to assume one will complete the first round of Conference Room Pilot Testing on Friday and immediately jump into round two testing on Monday. The point is there are “wrap up”, “transition”, and “preparation” tasks required to complete one phase and start executing the next.

In the testing example above, the team must wrap up documentation of round one test results, discuss new issues identified, make more software set-up changes to address the issues, prepare additional test cases, and perhaps set up additional data for round two testing.

In this example (like others), some of this can be accomplished concurrently within the round one testing timeline, but certainly not all of it. Considering there are dozens of phase transition points on any project, this can add up to one big schedule mistake.

#5: “Decomposed” project tasks

There is a human tendency to generalize any topic and not consider all the details and implications involved. The sum of all generalizations over the course of a project can be significant.

The best way to help avoid this is to break down tasks into their components and estimate the duration of each component separately. One should decompose each task to the level where the logical steps required to complete it are revealed. One does not have to take this concept to extremes. However, in the end, an effort to do this will result in a much better picture of the project and timeline.

#6: Take advantage of “earliest possible” and “latest possible” starts

Most know project tasks have “dependencies” that must be acknowledge in the schedule. In other words, one cannot start Task B until Task A (predecessor) is first completed.

However, many tasks (as initially defined) are not truly serial in nature, particularly at the highest level of the work breakdown structure. That is, tasks within a given phase can run concurrently with the previous phase to a certain degree. By recognizing this, one can construct a plan to take full advantage of “earliest possible start dates” and “latest possible starts dates” for specific activities.

Again, first decompose each task into logical components. Then take the resulting tasks and link them to their true predecessor task. This allows for the earliest possible start for project activities, which is particularly important for those on the critical path. However, there are a few exceptions where a latest possible start makes the most sense. For example:

A) It is usually best to schedule most training as close as possible to the time of need (as late as possible). But also remember, the task of developing a training schedule can start as early as possible

B) Tasks that share resources with those on the critical path could start as late as possible to smooth resource loads when necessary. In this case, the task does not start immediately after the completion of its predecessor. This is called using the “slack time” associated with non-critical task. The idea is to focus resources on the critical path until the latest possible start date of the non-critical items.

#7: Consider the “estimated level of effort”

As discussed in my previous blog, when defining project scope also define the “level of effort” (and complexity) required for each scope item. This comes into play when estimating task durations.

With regard to “level of effort”, the time to define, design, build, and test, system interfaces and software customizations / enhancements are almost universally under-estimated. The obvious goal is to minimize any type of custom program development when it is feasible to do so. This is because when it gets out of hand, custom development will end up on the critical path.

#8: “Theoretical” vs. “actual” resource capacity

One cannot assume because an individual is committed to working on project 32 hours per week for example, all this time is spent on tasks appearing in the schedule. There is a concept of “theoretical” capacity versus “actual or observed” capacity that should not be ignored.

For example, when planning the capacity of a machine in a manufacturing plant, the capacity used for scheduling usually excludes changeover times, average downtime, etc. This same logic holds true for project scheduling. One way or another, actual resource capacity should be reflected in task durations.

This resource consideration may seem trivial at first, but do the math and assume a twelve-month schedule where four people are spending three hours per week on activities not in the formal schedule. In this case, the schedule assumes it has these 624 hours, but the truth is it does not.

#9: Include quality checkpoints & follow-up activities (plan for rework)

These type of activities are not necessarily formal events, but normally include things like “design reviews”, presentations for approval or feedback, etc. These, and the associated follow-up tasks, are important to include in the plan not only for quality purposes, but also because “changes” normally result.

Feedback and change for the better are good things, but even small changes, can cause rework. This is called “planned rework” since it should be expected and already in the schedule.

#10: Protect the Schedule

We all know everything does not always happen according to plan. Nevertheless, there is such a thing as being proactive to increase the likelihood that it does.

In terms of scheduling, the question is: “what can we do in advance to make sure Task B happens according to plan”. The other angle is “what can go wrong with Task B, and how can we prevent it from going wrong”. This thought process is particular important for activities on the critical path since slippage here means slippage in the go-live date.

The following is a very simple example of “protecting the plan”. How many times have you scheduled an end-user training class and only half the people show up? A simple way to help prevent this is a letter or email (actually created by the project manager) from the highest-level manager at the facility. It communicates the training schedule, who is to attend, and attendance is expected. This letter goes to all attendees plus their managers. Do you think attendance will be better the next time around?

However, why put this simple item in the schedule? One reason is by the time the letter is created and sent, several weeks could go by in most organizations. Secondly, this communication is very important for the success of training, so enter a task for it.

#11: Verify the structural integrity and sanity check dates

Project schedules are usually developed “top down and then bottom up”. This means start with the top of the work breakdown structure, define and decompose tasks, link dependencies, add resources, durations, and then move back up the structure to clarify and validate.

After several iterations, check for structural integrity of task dependencies and relationships since this is where most errors occur. The integrity of the tasks on the critical path must be 100% correct and durations validated and validated again. The project planning software tool can usually help with some integrity checks.

#12: Document and communicate assumptions

When presenting the proposed schedule include project objectives, scope, resources, and time commitment assumptions. Also, document and communicate all other assumptions that surface from all parties involved when building the schedule. Be diligent about this. The reason is people tend to forget the assumptions baked into the plan. This is particular true if the project falls behind schedule.

Conclusion on ERP Project Planning

Again, the scheduling process is not performed in a vacuum. It requires the involvement of all key client stakeholders along the way. Senior management approves the final version. When the schedule is not acceptable, there are only a few choices. Change project objectives (lower expectations), apply more resources to the critical path, or reduce scope. Anything else is wishful thinking.

=========================

Editor’s commentary - Steve Phillips runs a great blog which is linked here:

http://it.toolbox.com/blogs/street-smart-erp

Be sure to visit his site and support his efforts!

Related Posts:

• Some Reasons SAP Projects are Over Budget and Over Time
• ERP Project Planning – Getting Real (Part 1)
• SAP Implementation Projects: Still Crazy After All These Years
• More on Vendor Selection Criteria and Methods for ERP Project Success
• ERP Project Plan: Getting Real Part 3