Let’s develop a project schedule people can believe and support. After all, it is people that must make any schedule a reality.

When it comes to ERP project planning, there is nothing wrong with an aggressive schedule. In fact, it is encouraged. However, being dumb about it is a different story and only results in a plan that is eventually tossed out the window. We are now operating in the blind and later must deal with the ramifications of unrealistic expectations.

Edicts do not always work 

First, there is a false premise when senior management edicts a date, it will somehow automatically happen. No matter how well intended, edicts with no supporting detail behind them rarely accomplish anything (or cause even more confusion). In addition, some organizations waste years selecting ERP software or approving a project, then attempt to slam-dunk it within six months or less.  Finally, some use the same bad software for eons, and then suddenly wake up one day and insist on replacing it almost overnight. I have some bad news; “it ain’t gonna happen”.

Project Managers can be their own worst enemy

Some project managers publish dates without a clear understanding of how they are going to get there. Others develop valid schedules and later cave in to unreasonable schedule demands. These demands usually come from people that understand little, if anything, about the project details. As a project manager sometimes you just have to say “no”, and take the political risk of doing so. It comes with the territory.

The Sales Pitches are Over; it is Time to Deliver the Goods

In the meantime, some software consulting firms are no help in setting the right schedule expectations. Many more or less throw darts to come up with dates or attempt to use “templates” as a substitute for project management experience. Other software consultants intentionally “low ball” the schedule and do the “bait and switch” maneuver after they get their foot in the door. It is amazing how many clients fall for the oldest trick in the book. 

It can get worse. Even after services are sold to the client, some firms continue to act like sales people (or master of ceremony) not project managers. For whatever reason, they cannot bring themselves to tell client management any bad news. This is unfortunate because the client is paying consultants big bucks for their expertise.

The point is, when outside help is required to develop a project plan,  get project management consultants very familiar with the software and have scheduled the implementation many times before (on projects within a similar industry, scope and complexity). Also, hire consultants that will not sugar coat the real issues. What you need now, more than anything else, is the truth. Finally, never let consultants develop a schedule in a vacuum. The client must be heavily involved from the start, help shape and develop the plan, get their hands dirty, and understand the assumptions behind it.

There are Consequences to Your Project Planning

One might say, “So what, we missed the schedule. We will revise the schedule, and give it the old college try again”. Unfortunately, when we totally miss the mark, good things rarely happen:

The Project Plan Relationship Between Time and Money

An invalid schedule usually means a blown budget down the road. When a project budget reflects a twelve-month schedule, but it actually takes sixteen months, do the math, and assume consultants cost at least $150/hr and you probably have more than one.

The Calm Before the Storm

While it appears everyone on the project is busy working on something, the question is, are they working on the right things, and at the right time? When they are not, it usually means delays and rework later. This is not about poor budget estimating; it is money that otherwise should not have been spent. This is one reason why software consulting cost can average 60% or more of the total project cost. I do not know about you; but this is an unacceptable percentage from my perspective.

Deflating Those that Must Make Your IT Project Happen

When a project schedule really is not doable, it is not hard for most people to figure out. In this case, do not expect the project team to get too excited about attempting to implement a plan that is doomed from the start. I cannot say I blame them. 

Feeding the Naysayers

Any project has doubters throughout the organization, but when we incur schedule slippage due to poor planning, this only fuels the informal grapevine. “See, I told you they do not know what they are doing”! This certainly does not help the cause of the project, the team or make “organizational change management” any easier.

Taking Project Planning Shortcuts

No matter what implementation approach or methodology utilized, in order to get back on schedule people sometimes do nutty things. The result can be a host of unintended consequences such as poor software quality, higher cost, lack of user acceptance and failure to achieve project objectives.

A Project Schedule is Not a Wishlist

The goal is to produce a valid project schedule that achieves project objectives. In addition, a schedule the project team and key client stakeholders believe, support, and can actually use to manage the project.  

In terms of a timeline, a good project schedule is not necessarily one that depicts what we ideally want to occur. Nor is the sole purpose to “light a fire” under those that must make it happen. Above all, the project schedule should reflect reality.  If not, no one except the project manager and consultants will own it. The problem is, for the schedule to actually materialize; all key client stakeholders must first believe it, in order to get behind it (including sr. management, the project team, IT, key functional managers).

Once senior management agrees on project objectives, scope, resources and the schedule is properly developed, adjusted and verified, the project “is what it is” (whether we like it or not).  When we cannot live with the proposed dates, there are only a few options available: 

              Apply more resources to the critical path,

              Change the project objectives (goals, benefits, etc),

              Reduce project scope (modules, interfaces, processes, etc)

All of the above can eliminate associated tasks or reduce task durations. However, permanently cutting objectives or scope for the sake of meeting an arbitrary schedule is not very smart. When it comes to resources, there is a law of diminishing returns. For example, assigning nine people to screw in a light bulb is not going to get it done any faster. Above all, when moving up schedule dates, avoid “voodoo” scheduling. This is when we manipulate the dates forward, to get the schedule to say what we want it to say (with no valid cause and effect justification for doing so).

Define the Project Path to Get There

A project schedule should convey specific project deliverables, supporting tasks, task durations, dates, responsibilities (resources) and recognize the relationship between tasks (dependencies). This does not imply any plan is perfect since scheduling is just as much an art as it is science.

However, when the right people are involved and proper detail, durations and dependencies built into the “work breakdown structure”, many of the assumptions and imperfections at lower levels of detail tend to cancel each other out. This means at the highest level of the schedule, planned start, and planned completion dates for key project deliverables / milestones should be reasonably accurate (including the go-live date).

This level of the plan(sometimes referred to as the “Schedule of Deliverables”) serves as an important road map with regard to where the project is going and when we want to get there. The dates at the individual task level are less relevant (except on the critical path), but they do serve as input to planning weekly activities as the project unfolds. They also are a day-to-day gauge to tell us if the project is on track per the original plan.

It is Sometimes Hard to Argue With the Facts

Finally, a project schedule (with the details to back it up) is a project manager’s best defense against those that insist on unreasonably aggressive timelines. In other words, anyone can throw dates around, but it is hard to argue with the work required and the sequence in which it must be accomplished, particularly if the goal is to be successful. On the other hand, a project plan and schedule with no detail is wide-open for criticism, second guessing and manipulation.

In previous blog entries, we discussed the importance of proper definition of project scope, assigning the right internal resources to the project team and getting all key client stakeholders heavily involved in the planning process. In my next blog, we build on this foundation and discuss how to construct a project schedule while addressing the common and not so obvious pitfalls. Finally, we close out this project planning series with a discussion on methods to estimate and budget for software consulting cost.

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

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 work!

In a CIO article published on April 9, 2009, SAP had 25 – 30 contract attorneys working on the litigation and it had cost them millions.  Over and above that SAP also claimed that their legal discovery process had also cost over a million dollars as well [FN1].   That was just over a year ago. 

There are additional interesting twists and turns in this saga and while I am not claiming SAP is completely innocent there are certainly lessons to be learned.  For example, one writer points out that Waste Management’s leadership was terminated for “agressive” accounting practices, and then replaced, and shortly afterward the SAP ERP implementation was started.  It would certainly be reasonable to assume that that new management was not familiar enough with the company or its employees to find the right people to make the right decisions.

Waste Management was a company in crisis. SEC Administrative Proceeding No. 3-10513 had found the following: “As early as 1988, members of Andersen’s audit engagement tram recognized that Waste Management employed ‘aggressive’ accounting practices to enhance its earnings.” In the brouhaha that followed, Waste Management’s board fired the company’s management.

Waste Management’s executive suite attained their current positions in 2004. As such, it seems that the company had a lot on its plate at once: overcoming an crisis, appointing new leadership, and launching a major ERP project…

If SAP’s software is indeed a “complete failure,” Waste Management’s executives might well have been asleep at the wheel; no one should pay $100 million and wait two years to find out they’ve bought a defective product. [FN2]

The normal course of litigation over the failed SAP implementation had both parties making claims and pointing fingers.  There were the claims, and the counterclaims, and the back and forth, and the armies of lawyers, and the thousands of pages of court filings, and the millions spent by both sides on the litigation.  It was time for this to finally end.

Waste Management claimed in its lawsuit that they “wanted an ERP package that could meet its business requirements without large amounts of custom development…” They also claimed “SAP used a ‘fake’ product demonstration” and “SAP’s technical team had ‘recommended that SAP deliver to Waste Management a later version of the software than the version SAP in fact delivered’.” They also claimed SAP knew the software was “unstable and lacking key functionality…” [FN3]

SAP claimed in its legal counterclaims that “Waste Management didn’t ‘timely and accurately define its business requirements’ nor provide ‘sufficient, knowledgeable, decision-empowered users and managers’ to work on the project.” [FN3]

SAP Implementation Failure Lesson Learned

First, as I have often noted, senior management support is critical for success.  However their support is not enough, what the Waste Management lawsuit points out is that risk management (risk identification and risk mitigation) are critical components of an SAP project.

Too often we hear about the “success factors” of an SAP or large ERP project.  But behind those success factors is the risk if those factors are lacking.  In this case it seems entirely reasonable, and plausible, that Waste Management did not provide key, timely information or key decision-makers as SAP had said.  However, I also find some of Waste Mangement’s other claims they made in later pleadings that the SAP sales force had a strong hand in creating the problem because the sales person was concerned about getting their million dollar commission. 

So, while I do not put a lot of store in serious application gaps or problems, I do give some credence to their claims about the nastier side of business.  The acceptance of sales scams and the failure of SAP to adequately assess and then mitigate the implementation risks.  The idea that the company did not provide good resources, or that those resources would not make decisions is likely valid but those are known risks that should have been raised to the steering committee.  In the end, this lawsuit should have never happened.

[FN1]  SAP: We’ve Spent Millions So Far on Waste Management Suit.  CIO.com from IDG Press. http://www.cio.com/article/488866/SAP_We_ve_Spent_Millions_So_Far_on_Waste_Management_Suit (retrieved 5/11/2010).

[FN2] SAP sued by Waste Management, March 27, 2008.  http://itknowledgeexchange.techtarget.com/sap-watch/sap-sued-by-waste-management/ (retrieved 5/11/2010)

[FN3] [FN3]  SAP, Waste Management settle lawsuit.  Business Week. May 3, 2010. http://www.businessweek.com/idg/2010-05-03/sap-waste-management-settle-lawsuit.html (retrieved 5/11/2010)

Previously I’ve offered insight and suggestions on the topic of reducing SAP project stress in a 2 part series:

But recently on LinkedIn, in the Project Management Group someone raised an interesting question that I have had to deal with on a few projects.  They asked:

“How do you respond to a senior project member who wrongly accuses you and have your bosses and team copied on email?”

Because I have been doing SAP projects since 1994, in highly charged corporate environments (including corporate politics) I have experienced this situation a few times.

Someone will pop off about something and they do not know what they are talking about.  They may be completely clueless or they may be wrong, but the message is inappropriate and it has now gone out to a number of individuals.  There are effective ways to respond to this situation.

1. DO NOT RESPOND IMMEDIATELY unless there is some absolute imperative that you must. Your best bet is to appear professional, let things cool, and get your own emotions in check so that you do not escalate this into a full blown war.

My personal experience has been that about 50% of the time this has happened to me, as long as I do not react in a rash manner, they are quickly resolved. By not responding immediately I have experienced the following corrections where I came out looking like a hero:

- On a few occasions some senior leaders on the client side (or the consulting side depending on who initiated the flame) have responded back to the e-mail initiator and corrected them. 

- On a few occasions the individual was known as a hot tempered instigator.  As a result of not getting the immediate response they wanted I had 2 people became irrational, try to escalate the situation, and exposed that they were completely nuts.  One of those two was fired shortly afterward.

2. WRITE the response e-mail immediately but DO NOT SEND IT! It gives you a chance to vent some of your frustrations and clarify some of your thoughts. Save the message, come back to it later (generally a day later), review it and re-write it in a much more dispassionate manner.

3. DEPERSONALIZE your response if you do send it. Avoid the use of any personal pronouns. Deal with the issue and not the person. If they continue to attack you and you continue to point back to the issue they look like a completely unprofessional idiot in front of everyone else.

4. ALWAYS be professional and try to empathize with the initiator even if you know they are vindictive or have some ulterior motive. In other words, you might say something like “I understand why this might be thought, but please consider…” Their response will speak volumes.

5. Your response to everyone should make it clear that you would like to schedule a meeting to review the issue face to face. The message should make it clear that there is no reason to take up everyone’s time and this can be resolved with the key stakeholders.

Your professional response speaks volumes. As a project manager you will gain everyone’s respect. Everyone who knows about it will realize that in dealing with you that even if they screw up or get a little over the line that you will deal with them in a professional manner as well. It helps to reduce project stress and defuse potentially ugly situations.

Some Past SAP Project Experiences with Improper E-Mails with Wide Distributions

While at Hitachi Consulting I was a mentor for one consultant who experienced a similar situation and gave all of the counsel listed here.  They followed these suggestions and let the situation die down.  The next day the client individual who had responded so improperly openly apologized and things were much smoother from then on.

I have seen this “provocative” type behavior from several consultants who were complete frauds!  They work to hide their own incompetence by sabotaging your ability to manage a project, or by creating unnecessary conflicts with other co-workers.  Because the SAP world is full of frauds it is one of the ways they create diversions from looking hard at their work product and experience.

I have seen this type of provocative behavior from client employees who were worried about layoffs and saw the attacks as a way to look important.  I have seen this type of behavior from client employees who lied about their own talents / skills / experience to get onto the SAP project.  Once they found out they were in over their heads they created havoc to distract from their lack of contribution.

The reasons really do not matter as much as how you, as a project leader or a project participant deal with the situation.  Handling stressful or highly charged situations is not easy but in this line of work you will have to deal with it.

The idea of innovation in business or IT is generally an aspiration to most.  Leaders and managers occasionally mention the need to innovate but when they stop to consider what that means many of them abandon it as an impossible dream.  They wait for some strange spark, some odd occurrence to somehow spark the flame of new beginnings. 

Execution of the Innovation Process

Inspiration for innovation or creativity can come from anywhere.  Frequently the innovation problem isn’t a lack of good ideas, or even innovative solutions–, too often it is a lack of execution.  Even though I’ve laid out a proposed business model for an innovation process in the post From Collaboration to Innovation to Market – Toward a Working Model too often the champions, or the owners for the process are missing from the major stages of execution.  There must be an “owner” or a “champion” at each stage, they might be the same person, or it might be a different person, but each stage needs someone to champion the new innovation to maturity and then to completion or it will die in the process.

The three stages I have defined are concieve, develop, and market.  For example, the conceive stage might have a marketing or sales person “own” that process to its development handoff.  That does not mean that engineering or some other key person from the development area should not be active in the early conception stages, only that the stakeholder(s) with the most influence at that stage should own that portion of the process.  At the develop stage it might be key product or service leaders who then move the idea from infancy and from concept to tangible product or service offering.  And then finally the market stage must have a champion from sales or marketing (or both) to ensure that it is properly positioned and prepared for market trials and finally the sales launch.

Without that critical leader at each stage of the process there is little chance of many successful innovations in products or services.  Your innovation engine will quickly run out of gas and go nowhere.  If you pursue any kind of innovation initiative without these key champions any “innovation” that survives will likely be more like minor tweaks or changes, more like continuous improvement than real innovation.  Those small incremental changes are the only things that might survive the process without strong leaders moving them forward.

Business Product, Service, and IT Innovation Series

A structured approach to innovation, to creating new products or services is possible, but it takes a deliberate, concerted and focused effort.  I’ve laid out the various posts on this site that explore how to create a business-centered innovation process:

From Collaboration to Innovation to Market – Toward a Working Model
http://www.r3now.com/from-collaboration-to-innovation-to-market-toward-a-working-model

A process oriented approach toward a process model for moving from collaboration to innovation to market. A first pass at integrating collaboration with a structured creative process and moving from idea (conceive) to design (develop) to market (sell).

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

Business Strategy and IT Strategy to Reproduce Apple Innovation
http://www.r3now.com/business-strategy-and-it-strategy-to-reproduce-apple-innovation

Overview of Apple Innovation and the focus on Jobs as the head of Apple. The apple innovation secret (if it can be called that at all) is about relentlessly pursuing the customer experience at the point of customer frustration. Where there is customer frustration or customer dissatisfaction there is opportunity for gaining market share for the company who is able to address that point of frustration.

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

Striving for a Customer Focused Approach to Innovation 1 of 3
http://www.r3now.com/striving-for-a-customer-focused-approach-to-innovation-1-of-3

Categorizing and Defining the 3 primary types of corporate innovation. I’ve dubbed these as “Stoic” (minimalist or continuous improvient); the “Stretch” (striving for a known future state); and the “Maelstrom” (directionless chaotic storm of ideas). The names you use really don’t matter, but these are the 3 types of what companies call “innovation” that I have seen.

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

Striving for a Customer Focused Approach to Innovation 2 of 3
http://www.r3now.com/striving-for-a-customer-focused-approach-to-innovation-2-of-3

Explaining the use of an “innovation narrative” in the “Stretch” type of innovation. This method produces a future state narrative which may not be achievable but provides a customer and market focused direction to aspire to for new products or services. That narrative acts as a future state blueprint for product or service development to move toward.

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

Striving for a Customer Focused Approach to Innovation 3 of 3
http://www.r3now.com/striving-for-a-customer-focused-approach-to-innovation-3-of-3

Practical ideas and practical application of some methods of moving toward an innovation culture. Some specific examples around how SAP (the big ERP vendor) has been very successful at integrating their customers, vendors, and their internal organization into an extended development dialog are explored. Includes an overview of how this all ties into the collaboration model I started in a post entitled “From Collaboration to Innovation to Market – Toward a Working Model”.

Good luck on your innovation journey!

Your Primary SAP Implementation Focus

There are two primary ways in which SAP can be installed 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. 

Let me assure you, SAP as an application has such a massive depth and breadth of functionality, combined with a significant number of industry vertical solutions that this decision can not be underestimated.

SAP Software Engineering or Business Process Engineering

As a business what is your core competency?  If you bring the right business people to the project, is your business competency software engineering or process design to meet customer / marketplace requirements?  If you think of it in those terms the answer for any successful business is clear, you do what it takes to meet customer / marketplace requirements (unless you are a software company).

If your core competence were software engineering and software design you probably wouldn’t need many consultants.  When it comes time to do your SAP implementation the best approach is the one that leans heavily on vendors who can provide the right consultant for your needs. 

If you want to stay closer to the business process engineering goal post (change the business to fit the software) then consultants with heavy project experience will likely be able to help you through the critical change management activities.  In any event your focus will be more on training, communication, and change coordination (see Screening Methods to Find the Right Consultant – Part 2). 

If your goal is to re-engineer the software application then you will focus more on technical competence of the army of coders.  Along with this a significant amount of time will be spent on business process analysis and fit gap analysis (the old “as is” and “to be” analysis).  And together with that your testing will need to be far more extensive and thorough; the number of “break-fix” support resources for your go-live will be significantly higher; you will need extended support resources (read, expensive consultants and developers) for a much longer period of time.  Mind you some of the change management activities will still be needed; they just won’t be needed quite as much.

If your goal is business process re-engineering you will need solid consultants who know the application.   They need enough skill to ensure that the thousands (and in some cases tens of thousands) of system settings are made to meet 90 – 95% of your business needs without any custom coding.  SAP is that broad and that deep in terms of functionality and in terms of industry specific options.

Should You Do SAP Software Engineering or Business Process Engineering?

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. 

If those unique process areas directly impact your industry or market position then they might make sense for customized modifications.  However in less unique areas, such as purchasing, or accounting, or inventory management, it makes more sense to try to stay close to the standard functionality.  Sticking close to the standard system functionality may require change management, but it will be far more cost effective and less troublesome throughout the entire application lifecycle.  With very few exceptions, be very suspicious of the consultants who frequently seem to need something custom coded.  It may be required, but you should still be suspicious.  Over the years I’ve done SAP the most common area for custom coded requirements is in Sales and Distribution (SD).  The only reason it is required there is because these are customer facing processes most companies just will not change how they do things no matter how compelling your case may be (this is why as a consultant we jokingly refer to SD as the “land of user exits”).

No matter which goal post your implementation is closest to (“out of the box” standard or “make it fit our business”), there should always be a direct business-related justification for custom-coded modifications.  Usually this is not the case.  The most common reason I hear on projects for modifying things is “this is the way we’ve always done it.” 

The closer you stay to the “out of the box” goal-post the less expensive the entire application lifecycle will be: 

• The initial implementation will be less expensive.
• Ongoing support and maintenance will be less expensive.
• Upgrades will be less expensive.
• And there will be fewer issues and bugs to resolve.

Of course many system integrators love custom-coded solutions.  The more you customize the more revenue they make, both in the initial implementation and in ongoing support and maintenance (which is NOT covered by your SAP support contract).  The more customized the solution the more dependent you are on them for maintaining and supporting it.  And if you go all out with changing the application to match your business processes, and if you build lots of custom solutions, then you might as well get used to those expensive consultants (who have billing rates at 2 – 4 times your salary) as long-term pseudo-employees of your company.  You will likely be paying them for several years after you go live.

Differences in SAP Consulting Models Depending On Your Goal Post

If you are content with modifying, coding, customizing, and otherwise re-engineering SAP your consulting needs lean more heavily toward software engineers.  You will likely require an “army” of ABAP and Java programmers together with lots of consultants who have deep experience evaluating processes and writing technical design specifications for all of the custom coded work. A number of very large consulting firms specialize in this kind of talent by bringing numerous “generalists” to the table.  These are supposed “process experts” with little or no specialization in SAP but are tasked with designing your SAP solution.

Maximize Your SAP Investment

If you wish to use the application to its fullest extent, with minimal modifications or customizing [FN2], then only consultants with deep application experience will do.  As my friend Steve Phillips writes, there are times when modifications are needed and they are justified (see ERP Software: Are Modifications Always a Bad Idea?).  However knowing when that is and when there might be other alternatives takes a significant measure of experience and a very deep understanding of SAP (to know what the application’s limitations are).  For the biggest benefit and the most productive solutions it also takes consultants with some measure of work experience before they started doing consulting work.  The most experienced consultants will be able to more accurately identify when it would be best to change the business processes rather than changing the application.  They will be able to evaluate the personalities and culture of the area they are responsible for and understand how much change they can absorb and whether or not certain functionality is appropriate.

Because of the depth and breadth of SAP’s ERP solution there is literally no substitute for real, verifiable, and deep experience.  If you have any desire at all for staying close to the standard functionality then the “generalists” many large consulting companies offer and the “low cost” providers simply can not do the job.  The reason is simple.  The generalists just don’t have the application exposure or application experience to know when you should, or should not pursue custom alternatives.  The low cost providers usually (though not always) provide questionable resources with sketchy and hard to verify experience OR they take a project approach that is so narrowly limited in scope that the end result is frequently less functionality and less automation than before. 

Whether your vendor considerations are a low cost provider or one of the big consulting companies there is no substitute for experience if you want to stay close to the standard system functionality.  I still learn new things all the time because of SAP’s massive depth and breadth (even after doing SAP projects since 1994 and being an entrepreneur and tech “geek” since the mid 1980’s). 

Consequences of Custom Coded SAP Solutions

The custom solution will require significant testing and may require additional iterations.  It is a very frequent occurrence that a custom-coded solution goes into a live productive system and new bugs or other unintended consequences occur.  These bugs and fixes are not supported by SAP’s software maintenance and online solution database.  That means every fix requires additional levels of coding, rigorous testing, and verifying that some new dependency from the fix does not affect or break something else–, unintended consequences of the change.

The custom coded approach requires much more skilled and disciplined project management around testing and coding quality checks.  While testing is critical for every project, and for every part of the system that is going to be used, the custom-coded testing requirements are very different.  Where testing standard application solutions is more for fit and function (does it do what it needs to and is the data correct) the custom coded solution has new dimensions of dependencies.   Some of the things you have to consider are:

• Does the custom coded solution even work as planned? 
• Does it create new data dependencies and new data maintenance requirements? 
• Does it interfere with the operation of other system functionality? 
• Does it create new dependencies requiring additional processes to be coded to “bypass” other standard system functionality that it is not compatible with?
• Does it create performance problems? 
• Is it coded correctly so that data inconsistencies do not occur? 
• Can it scale up? 
• Are there regulatory implications (such as in healthcare and FDA validation)?
• Etc., etc., etc.

The list really could go on and on, but this provides some idea about the differences in testing requirements.  And it isn’t that the standard options don’t have these same issues, they are just less intensive and less dependent on correction. 

Frequent Custom Coded Messes and Ongoing Maintenance Costs from Bad Design

The standard application functions need to be tested more for fit and function, not whether or not they even work.  And if you do discover an actual problem with the standard options your SAP maintenance agreement covers SAP providing a fix for their own application.

These issues may be present with a standard solution as well; however you have the benefit of many other customers discovering these items; referring them to SAP for a correction; and then SAP providing a solution as part of the standard maintenance.  For example if you notice a performance issue with standard functionality it may require an hour of researching SAP OSS (Online Support System) Notes, and then applying the fix in that note at some convenient time.  Depending on the system setup and design, testing may be performed relatively quickly.  And here again, the level of testing even for applying note fixes depends on the amount of custom coding.  If there has been a lot of custom coding the testing will be extensive to ensure that the custom coding was not broken by a “standard” system  fix.

For the custom coded solution, this relatively “easy” fix might take the time of an experienced system guru (an SAP Basis expert) to run performance traces and logs, then after the source of the performance problem is isolated program debugging, program fixes, testing, possibly additional iterations of fixes and testing, and then moving it to production and hoping something else doesn’t break.

The level of project management skill is more significant with the level of testing rigor for large projects with significant amounts of custom-coded solutions.  The number and types of variations of testing and potential problems is also more significant.  Rather than just testing for fit and function (as with standard functionality) the level of integration testing between and among all other areas is increased.  And where the standard SAP solutions have had the benefit of hundreds, or even thousands of customers and system integrators beating on it and testing it, you are the only company testing or resolving your custom solution.  No matter how thorough you are and no matter how skilled the consultants are something will be missed.

On top of this, inconsistent or poor coding methods can cause huge problems and creates major risks.  I have seen many problems that are not readily apparent during the “controlled” testing that most projects do which causes huge problems in a production environment:

• Whole tables (all records) being locked from processing rather than individual table records thereby preventing all users in all locations from being able to process similar functions.  Single record “controlled” testing did not reveal this until live in production.
• User exits (custom coding points in the source code provided by SAP) coded improperly so that they create other records or other processes before the record that triggers the requirement is completed.  If anything happens and the initiating record does not post then an inconsistency is created.  Again, another anomaly that is a rare occurrence and probably would not be discovered in testing.
• Massive performance problems from poor coding and repeated select statements that are unnecessary (rather than using proper join statements in selects to minimize the number of database hits).
• Badly coded forms that cause entire transaction processes to “crash” without any indication there was a problem.
• Poor use of fields for selection options, or missing selection options that then process massive data tables without any restrictions.  This is not seen in the “controlled” testing and may only be discovered after larger amounts of data are available.
• Direct table updates that bypass normal system checks and create huge data “messes” and data “orphans” when they do not process correctly.
• Over engineered and overly complex custom solutions when much simpler and more elegant options were available.  Sometimes the option is change the business process rather than trying to custom code a more painful “fix”.
• Hard coded program values rather than using parameter tables so that every time a key value changes in a company or organization the program has to be modified, re-tested, transported, and then hopefully nothing that is dependent on it gets broken (because other dependent programs may have hard coded values) .
• Etc., etc., etc.

I’m always amazed at the amount of “hidden costs” of all of the “gee whiz” we really need that custom solution which too many system integrators are happy to accommodate.  Sure, some of it is required, but some of it is also a complete waste when there are other alternatives.

In the end it is your system and your solution.  There are always some good reasons to move some areas of the application toward the goal post of modifying the software to fit your business processes.  However many times standard functionality, or only slight variations on the delivered standard functionality is all that is needed.  The more you are able to minimize the custom coded solutions and make the changes to standard application options the less expensive your application lifecycle will be.  In the end some things will need custom coding, but minimizing that will minimize your costs and headaches as well.

Always keep in mind that there are tradeoffs, just like pushing on one side of a balloon.  As you push in one area it comes out in another.  If you choose to keep the application closer to standard functionality then you will likely need to budget accordingly for change management because processes and jobs will be changing.  If you make the application fit your business processes change management issues may not be as significant (but they will still be there), but you will pay more throughout the entire application lifecycle. 

What can you do to minimize this?  Insist that every custom coded request be supported by a specific business justification, and then insist that a whitepaper be written that shows what other alternatives were considered and why they would not work.

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

[FN1]  One thing to keep in mind is that SAP’s ERP application primarily addresses value propositions related to operations.  It is not because the functionality and the capabilities do not exist to do something different, it is because system integrators don’t generally know how to do it.  While there is both functionality and the ability to build integrated custom solutions within the application for increasing revenue and profitability this is rarely done because the marketplace hasn’t demanded it (see Using SAP to Improve Revenue and Profitability).

[FN2]  In SAP there is a technical type of “customizing” that is more like core application modifications or adding additional and specialized custom coding to existing places in the software where this is allowed.  However, there is another type of “customizing” that is frequently referred to as “configuration.”  This type of customizing is very different.  It involves setting up new standard system data types, such as new document types for POs, Sales Orders, Accounting Documents, Production Orders, etc., and then making standard system settings to support specialized business process requirements.  Because the “configuration” type of customizing in SAP has literally hundreds, and in many cases THOUSANDS of potential settings and options for any single process chain (such as order to cash, requisition to pay, plan to produce, etc.) there is no substitute for experience.  These requirements and more also mean there is no room for fakes or “freshers” as they are often referred to by the consulting fraud factories (see Screening Methods to Find the Right SAP Consultant and Screening Methods to Find the Right Consultant – Part 2).

Recently I was reviewing academic material on ERP / SAP Project success factors.  One particular study stood out because it laid out 22 specific success factors by project stage.  [FN1]  Even though this study dates from 2001, the Critical Success Factors (or CSFs) still ring true today, and the conclusions are consistent with what I have seen on SAP projects since I started in 1994. 

While the sample size was somewhat limited (86 completed questionnaires) the data and information provided was useful for understanding some of the key or critical success factors.  The stages reviewed were:

• Initiation – business need, software selection, vendor selection.
• Adoption – beginning of the implementation process and system design.
• Adaptation – implementation, adjustment, and business fit stage.
• Acceptance – go-live and productive business use of the system.
• Routinization – the overall acceptance and sustained productive use of the system.
• Infusion – long term acceptance and use of the system as well as additional functionality additions.

Based on the academic literature when the study was done, there were 22 key ERP Project Success factors that were defined (in order of the study’s response importance):

This study went on to break out the top 5 reasons, by project stage, for project success.  And what I have done is added one additional dimension.  I assumed a sampling error rate of at least 3%.  As a result, in each of the project stages there are areas that are statistically significant, and areas that are more likely dependent on each individual project.  One important item to note is that while any particular project may have a completely different makeup, equating to entirely different factors of importance, these initial assumptions provide a great place to start an analysis.

Top 5 Success Factors by ERP Project Stage:

To make as much sense of the data as possible I assumed the lowest value of the top 5 was my baseline value and anything within 3% of that value was within any margin of error (the sample size may actually make the margin of error closer to 5%).  As a result, anything within that margin of error I am considering a “toss-up” for any particular project.  However, anything outside of that 3% range I am considering statistically significant and having much wider and more general application to most projects.

However, no item in the top 5 list by each stage of the project can be underestimated or overlooked.  After all, these are the distilled “critical factors” for project success by project stage. 

One thing that stands out in this analysis is that through much of the project stage, and then after the system is productive and live, interdepartmental communication and cooperation rank consistently at the top.  Right behind them, top management is a consistent theme, and then vendor related prospects round out the top (vendor support, partnership with vendor, vendor’s tools, and project team competence).

Conclusion on ERP Project Success Criteria – The Top 3 Recurring Success Themes Across All Dimensions of an ERP Project

So, in broader or more general terms the academic literature bears out my personal experience.  Across the entire project and application dimension the key success factors for ERP projects like SAP are (in order of importance):

1. Interdepartmental communication and cooperation.
2. Top management involvement (presumably this would help encourage the first item as well; see the post entitled “The Real Reason Executive Participation Creates IT Project Success”).
3. The quality of the implementation vendor (consultants, tools, etc.).  For more information on selecting a quality vendor see this four part series:

               Achieve Breakthrough ERP, SAP, or IT Project Success: 1 of 4
               Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP
               Breakthrough Project Success: 3 of 4, Vendor Selection and Contracts
               Breakthrough Project Success: Part 4 of 4, Last Low Risk Chance for Results

So Why do SAP or other ERP Projects Fail?

Obviously there can be any number of reasons why they would fail.  Even the 22 success criteria for ERP or SAP projects listed in this post is not comprehensive.  However you can be sure that when there are consistent themes across nearly all dimensions of a project, any of them that are lacking would create significant risk for failure.  At some future date I will be publishing a proprietary and unique evaluation model which will help to clearly identify the key project risk areas specific to your company and your implementation.  

For a quick summary of the 3 key areas and one of the high risk areas that you have the least amount of control over consider the following: after having selected the application system and the technical infrastructure to support it, these three items are critical ingredients for your ERP project success.  Top Management involvement and interdepartmental cooperation are directly and completely within a company’s control, however the ability to influence the type of vendor is only indirectly controllable through the selection process.  If the vendor selection process leads to the selection of a less than optimal vendor you may not realize your desired business benefits even if you get everything else right.

What this study points out even more clearly is why it is so critical to have consultants with verifiable experience (Screening Methods to Find the Right SAP Consultant), who can bridge the technology to business gap with strong communication skills (Screening Methods to Find the Right Consultant – Part 2). 

The second item related to top management involvement may have reasons not considered here or in other resources; like the ability to imprint future strategy and business direction on the technology implementation.  The post already noted (The Real Reason Executive Participation Creates IT Project Success) points this out and demonstrates the importance of senior level management involvement in a project.

Without those quality resources provided by your consulting or resource vendor your chances for project success diminish significantly.

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

[FN1] Somers, T., and Nelson, K., (2001) The Impact of Critical Success Factors (CSF) across the Stages of Enterprise Resource Planning Implementations.  Proceedings of the 34th Hawaii International Conference on System Sciences.

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

For help with RFP preparation, building a business case, and defining the critical success factors that lead to an optimal vendor selection contact us today. What have you got to lose in making the call or writing?

Bill Wood
 +1 (704) 905 – 5175

For an overview of some of our services, whether it is SAP staff augmentation, SAP permanent employees, project QA and audits, or several other areas we might be able to help see our service page ( http://www.r3now.com/services ) and if you have any other questions please visit our contact page ( http://www.r3now.com/contact ) for more information.

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

Thirteen Dimensions of Project Scope

In many cases the ERP project plan is not worth the paper on which it is printed. Worse yet, many project managers shoot themselves in the foot by prematurely committing to a project schedule and budget that sets unrealistic management expectations. The problem is once cast, expectations will not go away and only come back to haunt you later.  Could this be one reason why many ERP projects “fail”?

Even when the schedule and budget are “formally” published, inadequate definition of project scope (and boundaries) is a major reason the plans are invalid and quickly tossed out the window. In other words, we need a project scope, schedule and budget that closes expectation gaps. A project plan people can believe and use to actually manage the project. What a crazy idea!

Project scope not only drives baseline project schedule and budget; but it also sets user expectations regarding what they will get (and not get) within the software functionality. When users are later told something is out-of-scope they really need, the project is in for many unhappy users or scope creep that results in surprise cost and schedule overruns. Take your pick.

Finally, a good scope document represents a major tool for the project manager to control the project. Like a referee in a football game the project manager needs the ability to throw the yellow flag. However, it is always best when all parties involved understand the rules of the game before the ball is put into play.

Purpose of this Project Scope Article

The purpose of this article is not to imply good or bad scoping decisions. The goal is to assist the practitioner in understanding the key elements of scope, potential implications, and set the right expectations. Next this enables the practitioner to develop a schedule and budget that is real and people can support. After all, it is people that must make this plan a reality.

I make reference to the “dimensions” of project scope. This is because scope and boundaries do have dimensions in terms of different views of the project, level of detail and other twist that warrant a separate and distinct perspective on scope. With regard to the actual deliverable, most of the dimensions below should contain a list of items, and each with a “degree of complexity or effort” (high, medium or low).  In the next blog entries, we discuss how this information is used to develop a project schedule and budget.

The Thirteen Dimensions of ERP Project Scope and Boundaries

1) Align scope with project objectives

The fact is most organizations implement ERP for business reasons. Therefore, project objectives (what you want to accomplish) must initially drive project scope, not the other way around. It is never a good idea to proclaim the project will solve all the world’s problems, and at the same time, limit scope to the bare bone necessities to get the software running on the computer. This is where “rapid deployment” strategies get into trouble since they are  designed to limit scope for the sake of time and cost (though outcomes are far from guaranteed).

Furthermore, last minute acts of desperation to cut scope to get back on schedule are usually done without a full understanding of the original objectives that are now compromised. Therefore, if scope is to be cut half-way through the project, objectives and expectations must be realigned with the new reality.

On the other hand, too much scope beyond what is required to achieve objectives (and for the software to function effectively) is not a good thing either. This is usually not a popular philosophy among users, but a necessary one since “scope creep” is inevitable to some degree on any project. Therefore, early on it is important to “condition” managers and users that the system is not intended to be “all things to all people” and expanding scope will not be easy. In fact, once approved, any proposed changes must be business justified and approved by senior management.

2) The Number of “Sites” involved

For the purpose of this discussion, a site is defined as: 1) a physical location, or 2) a logical site. For example, there could be more than one “business unit” at a location, each having its own customer service group using the same software. In “multi-site” scenarios, the scope issues are three fold.

First is the coordination and communication effort required to get and keep all team members, key managers, and users at each site on the same page. Not to mention, I have yet to see any multi-site implementation where a certain amount of politics and finger-pointing between sites did not slow progress. This does impact project effort and how quickly things move along.

It gets worse when the same software module is to be installed in more than one site. In this case, decisions regarding “common” versus “unique” requirements at each site are necessary; and this takes time. This also plays into the decision to treat a given business process at each site, as a single or separate process from a design and set-up perspective. In any event, if the plan is to “reinvent” the wheel for each site, this will increase complexity, schedule, and cost (scope).

Finally, each scope dimension below should be defined at the site level (if the goal is to get a good picture of what the project truly entails).

3) Software Modules

The modules to include in scope drives the overall footprint of project. No doubt, this is one of the first steps in addressing scope. The bad news is when some put a project plan together, the software modules in-scope are one of only a few things considered.

The problem is without further definition, it is difficult to understand what “modules” mean from the standpoint of establishing expectations with users and estimating project duration and budget.

Beyond the fact that modules lack sufficient detail, some modules are more involved than others. For example, anything with the word “advanced” in front of it usually means more complexity, more risk, more time, and more money.

In addition, whether a module implies advanced or not, some modules are  inherently more difficult to implement for most organizations. As an example, the Purchasing module in most packages is usually less of an issue than the Sales Order module. This of course is not universally the case; but level of complexity should not be ignored.

4) Key Features and Functions within each Software Module

This is a lower level of software detail often over looked. Each module has features, functions, and capabilities. It is always best to consider  the capabilities to be utilized right up-front. Otherwise, consultants and the team will waste time and money setting up software functionality that client management has no intention of implementing (or adds little value to the overall objectives). Granted, some discovery may be required to understand the applicability of features and this is never a perfect process. However, this is different then going far down the road spending time on features of marginal value (and no one cares about).

5) Business Processes

The client must identify the business processes to automate. In doing so, one must get into the “sub-process” level. For example, “Procure-To-Pay” is a major business process; but this alone does not tell the story. When we go to the next level, it starts to have meaning.

For example, within this major process, some of the “sub-processes” include: 1) Quotation process, 2) Requisition / Approval process, 3) PO process, 4) PO Receipt process, 5) Invoice / Voucher match process, and 6) Payment process.

6) Business Process “Variants”

All too often people assume a particular “sub-process” (examples above) represent a single workflow. However, in many cases nothing could be further from the truth. A simple example is “receipt of a purchase order”. In most companies, there are many types of purchase orders that are received and transacted very differently (and for good reasons).

As a result, from a scope standpoint each may require unique analysis, system set-up, and testing to the point they should be treated as separate sub-processes (or perhaps children of a sub-process). No matter what we call them, when included they expand scope and must be recognized.

7) Degree of Business Process Redesign anticipated

It is one thing to say a business process is in-scope; but again this is only half the story. This is similar to the complexity factor, but I like to highlight it separately because it can have huge project implications.

For each business process, it begs the following questions:  How convoluted is the current business process? Does it need significant reengineering? Are you planning to implement an entirely new operating philosophy? On the other hand, are you attempting to automate a current process that is well defined and works well today?

There is no right or wrong answer here, but the more one must redesign a process, the more decisions to be made (usually the longest pole in the tent), the more design work to be done, the more emotional it gets, the more issues and unknowns, and the more testing required. There is nothing unusual about any of this, but there is no way around it. When significant process changes are needed, schedule and budget for it accordingly.

8 ) The Number and Complexity of Data Conversions

In scoping conversions, get to the level of understanding the key files in the new software (target system), where the data is coming from (source system or otherwise) and how it is going to get there (manual or automated). Also, do not forget how history records are to be addressed (if at all).

The level of effort comes into play with the following considerations: 1) Source data clean up required prior to converting, 2) The format of key fields in the existing system and the need to get the data into the format of the new software. This includes not only field sizes, etc for important data items, but also how the data is used within the business. 3) The anticipated complexity of the conversion process, program logic required and level of effort to test. 4) Keep in mind, it could be much less time consuming to load data manually versus the alternative of writing conversion programs.

9) The Number and Complexity of Interfaces

This includes interfaces between “other” systems and the new ERP system. The time and cost to design, develop, test and maintain interfaces are almost universally under-estimated. The cost issue includes design and mapping of interfaces, third-party developers or additional “middleware” required (software and hardware). From a quality standpoint, even when thoroughly tested, no interface is fail proof (expect problems at some point).

Therefore, ideally one wants to replace as many legacy systems as possible within each project phase to minimize or eliminate temporary interfaces (that exist only during the transition) and permanent interfaces (to legacy systems deemed outside the final project scope). This tends to be the case even when a few modifications to the new software are required to replace the legacy system.

Expanding the number of modules (to eliminate interfaces) is a trade-off between interface scope and additional module scope. From a user perspective, interfaces are usually assumed the path of least resistance, but often times they later find out this is not the case.

Each interface and the level of complexity should be documented in the project scope. When identifying interfaces, realize there may be more than one interface between two systems (and some going in opposite directions). Therefore, what may initially appear on the surface as a single interface may actually be two or more interfaces.

Do not forget “one-off” databases in the user area that are out-of-scope but linked with the legacy system. They may or may not be supported by the IT department, but nevertheless, can be critical to the business. Also, interfaces to other new third-party software or hardware included in scope must be acknowledged.

It can get worse. Interfaces may force customization to the target or source system to add additional fields and screens to either system (to support the data needs of the other system).

Finally, the complexity issue includes (but not limited to) the frequency of the interface, real-time or batch updates, sequencing and dependencies of data transmissions and data format issues that impact the complexity of interface program logic (similar to data conversions). The question from a user standpoint: Must the users work in both systems (instead of one today)? If so, for how long?

10) The Number of Reports

The number of reports should be estimated since the accumulation of all reports can represent a significant effort. First, get a complete list of reports (from ALL current systems to replace), the distribution list for each, and frequency of usage.

Ask the users to review the list and comment on what reports they “must have” within the new system (wrong, right or indifferent – at this point we are trying to estimate. It is OK if the revised list from the users is full of assumptions) However, this will eliminate many reports that exist today.

Next analyze the list to see if the “must have” reports can be combined, eliminate by standard reports from the new system (or with slight modifications) or the availability of data on-line (or via spreadsheet user downloads) from the new system eliminates the need to write reports. Once this is accomplished the list should be more manageable.

Finally, add a contingency of about 15% to 20% to cover new reports the team or users will eventually asked for once they figure out the additional information available in the system.

11) The Number of End-Users

Whether there are twenty end-users or a thousand end-users, the team still must do all the process and software work for implementation. However, the number of end-users impacts the number of “key users” (subset of the entire population) to be heavily involved. Of course, the more people involved, again, the greater the scope. Not a bad thing, just reality.

The number of end-users also affects the end-user training timeline and resources. During the planning phase, it is necessary to get a handle on training time and resources requirements. Think of this as a rough-cut end-user training plan (not a detail training schedule). Do not wait two months before training to start this planning.

The project team must train end-users as close to go-live as possible. Training more than three or four weeks prior to go-live is a problem since users will not retain what was learned. The more one compresses the timeline to meet this objective the more resources typically required.

This time constraint could drive the need for more trainers since some training sessions may run concurrently. It can also impact the number of facilities, equipment and other resources that otherwise could become bottlenecks. Therefore, one must consider the trainers and resources now in order to get the right people involved early on, estimate a duration for end-user training in the schedule and to properly budget for it.

12) Software Customizations or Enhancements

Most know by now software “mods” (customizations or enhancements) increase risk, time, cost, and can negatively impact software quality. Therefore, eliminating or keeping them to an absolute minimum is always recommended. However, in the real world organizations make mods and often for very good reasons. The question is: How do you handle them during the scoping and planning phase of the project?

Here is the answer. After evaluating software, when there are strong perceptions mods are required, do NOT automatically include them in the project scope unless ALL of the following apply:

A.    Software limitation is verified

Early testing / verification (immediately after the software evalution) has been performed to confirm the software limitations exposed during the evaluation.

B.    Functionality is linked to key project objectives

The proposed mod is deemed by management as critical to the success of the project.

C.  It is understood what is required and how the mod is to be made.

The mod is defined in terms of specific functionality, external design attributes(screens and logic) and how the mod will be accomplished from an internal design standpoint. Internal design means: Are we proposing outright “customizations” to existing programs and tables? Or changes through more external “enhancements” that integrate with the system while attempting to minimize the impact on existing programs and tables? (for the sake of future upgrades).

D.   The Mod is “pre-approved” for scope planning purposes only    

Management has “pre-approved” the mod with a full understanding of alternative solutions and project impact (extra time and cost). Pre-approval means the mod is recognized as “in-scope” and included in the schedule and budget, but NO coding is allowed to proceed as this point.

E.    There really are no other viable solutions

The need for the mod is tested and verified again during the prototyping phased (usually following project team training and runs currently with current process analysis). The reason is, regardless of the original perceptions, once the team learns more about the software and looks closer at different ways of doing business, a proposed mod may not be required after all.

F.  Final Approval

After prototyping, if a mod is still deemed necessary, estimates are revised and present to management for a final approval. Afterwards,  the scope, schedule and budget are revised accordingly and the modifications can now proceed.

Get a Jump Start on Modifications Discovered Early On – They are on the Critical Path

Disposition of proposed modifications discovered during the software evaluation process must occur before the “official” design phase of the project . This allows for an “early start” in programming the modifications. The balancing act to consider is while any proposed mod must be understood and justified (with due diligence), waiting too long to start coding can put the schedule at risk. Always remember, most mods are on the “critical path” within the project schedule.

Other Potential Modification Scenarios

In the situation where some mods are expected, but none are yet defined or approved, it is a good idea to build some reasonable “contingency” in the schedule for good measure(even though senior management must later approve any mod and the project schedule is revised accordingly).

When there is a “no modifications allowed” policy proclaimed by senior management, do not plan for any. If mods are later proposed, they must be approved by senior management. In this case, the decision to expand scope rest with senior management, not the project manager.

13) Boundaries (what is out-of-scope?)

For all dimensions of scope discussed above, it is always best to go back and document what is “out-of-scope”. This more clearly establishes the project boundaries. The reason is people sometimes “hear what they want to hear”, and make assumptions on their own about what “in-scope” means.

We have all been there before when the manufacturing manager says (for example): “Steve, I thought shop floor control included wireless data collection!”  Response: “Sorry Joe, that is not what we meant.”  The point is, “in-scope” states what is included, but it only implies what is not include.  Why not state the out-of-scope items up-front to avoid confusion or prevent someone from attempting to slide it in the back door later?

The problem is even though the project manager may “win” this particular scope issue, he or she may actually lose in the long run when Joe no longer supports the project. It is better to get Joe on board with the decision early on or recognize it as in-scope before we put the ball into play.

Conclusion

The “Scope and Boundaries” document is a key deliverable within the “scoping and planning” phase and is completed before the project schedule and budget are finalized and the project is officially launched.

The scope document is the responsibility of internal project manager, with the help and guidance of the consulting project manager. It requires the participation of the executive steering team, executive sponsor,  project team, application consultants, key managers (process owners) and some knowledgeable and influential end-users. Though many are involved and provide valuable input, scope must be managed very closely, and tough decisions are usually required by the project manager and senior management.

The final version of the scope deliverable is next presented to all the above as a last review. Depending on how formal the organization, it is  signed-off by the executive steering team. Now, as a project manager, you have something valid to serve as input into scheduling, budgeting and later controlling  the project. 

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

After doing SAP projects since 1994, I still can’t believe SAP’s customers don’t use the old “Seven Habits” step of starting with the end in mind.  What do I mean by that? 

Start your SAP project with REPORTS and BUSINESS requirements! 

Come on now, WHY do so many projects wait until they are live with some new system to figure out what the reporting requirements are?  Reporting requirements must become part of the initial SAP scoping exercise.  Even if it is not spoken, every business that undertakes a massive ERP or IT project like SAP wants actionable information from the system after it is installed.  You want critical information that can enable you to:

• Make better management decisions
• Make better financial decisions
• Determine what products or services have good margins (and which ones don’t)
• How different product lines or geographies are performing
• What future business directions you should take based on ACTIONABLE information
• What competitive pressures in the marketplace to focus on
• Etc.

Aside from the operational automation and getting business processes defined, reporting is the key for :

• compliance,
• operations decisions,
• sales and product (or service) decisions,
• and for every part of the business. 

Reporting is so critical to a business yet on almost every project it is treated as an afterthought.  Too often “reporting projects” start after the system is in place and people start working in it.  From a budget and cost perspective you don’t need all of your reports done as soon as the system is installed, but the system must be designed from the beginning to support all of the data needed for those reports.  It must be designed from the start to produce actionable information after the operational and automation components are implemented. 

If you start from the beginning with your reporting requirements you can ensure that the system design addresses any reporting gaps.  By doing this from the beginning you will not have the system installed and then be disappointed that it does not provide you with the key actionable information you need for your business.

Using Reports for Driving Meaningful Business to IT Alignment

Without knowing in advance what the final actionable reporting requirements are you will not be able to take advantage of some of the really great information that a system like SAP can offer.  When an SAP system is properly implemented and constructed SAP provides mountains of data and field options.  There is the ability to add custom fields, re-purpose existing fields [FN1], and add other data dimensions so that you can track and report on any piece of information in any way you can imagine.  However, if this is not planned for in the beginning, and then set up and trained so that you can maintain that data, then after you go live you may be disappointed. 

If you do not do this up front exercise you may discover that you need certain key data requiring expensive rework, expensive customization, and additional time budgeted.  And in the worst case, depending on the system design, you may end up creating a design dilemma causing even more trouble down the road.  Worse still you may discover that the way the system was designed and implemented may prevent you from ever realizing key decision-making information.

There is one other benefit from this approach as well.  By defining end-state reporting needs and end-state actionable information needs you can use this during vendor selection to separate the capable from the incompetent.  The ideal situation would go so far as to provide actual desired end-state reporting examples (field names, field values, etc.).

By doing this exercise you also have the additional benefit of focusing the entire project, right from the beginning, on the end-state goal.  This will help to distill the project down into actual business needs and business requirements for success.

Where to Begin with SAP Scoping and Reporting

Every customer considering an SAP implementation should carefully read through the article on developing an SAP business case (ERP and SAP Business Case for ROI, Business Benefit, and Success, PDF version attached here). 

The key steps to getting the most from your SAP implementation or your SAP scoping exercise is to start with the tools and resources SAP provides free of charge to their customers (and prospects).  There are a couple of tools in particular that every customer, or prospective customer should insist on working with before doing their SAP implementation.  The first is the SAP Solution Composer [FN2], it is a free download and it is a great tool for understanding how to scope your SAP implementation.  As mentioned in the article linked above on developing the SAP business case, it is a great tool for:

• Developing an initial scope
• Creating process lists for starting some of the critical change management discussions
• Communicating in a “new” but common language about the processes.

The next tool available for a high quality project is the ASAP methodology.  It is an active HTML and Java script based repository which contains templates, resources, materials, and a project plan for ensuring you have a successful implementation or upgrade. 

Take Inventory of Your Existing Reporting Landscape and Define Desired Metrics

After your initial SAP scoping exercise it will be important to take an inventory of all of the spreadsheets, databases, and system reports that exist.  From these you can get a good idea of what will need to be accommodated in the system.  And from these existing reports the master data requirements that are required can also be derived.

After gathering the existing reports, begin short duration management workshops to define desired reports.  In other words what has been lacking from the business decision-making process that would provide strategic or tactical insight going forward.  For more information on one reporting and metrics strategy see the posts related to defining and understanding real Key Performance Indicators for business performance (see Why Indexed KPIs are Critical for Business Performance and Success, and Using Key Performance Indicators for Building a Strategy Focused Organization).

Once the initial operational requirements, existing reporting requirements, and desired reporting requirements are defined a final scope and blueprint can then be determined which will propel the business forward strategically into the future.

Conclusion / Summary on

Early Reporting Requirements in SAP Scoping and Blueprinting

In the end I’m still suprirsed at how many organizations finally get around to SAP reporting requirements after the system is already implemented an in place.  Just because you consider and plan for them from the beginning does not mean that you have to complete them by the time the system is in.  On the other hand, you will need them at some point so having the key data and understanding the business drivers for key information is crucial in your SAP implementation.

Too often the reporting metrics, goals, and drivers for business decision-making are treated as an afterthought.  Those reporting metrics and the business goals, key performance indicators, or business direction they represent are generally the reason for the huge investment in new systems to begin with. 

Stop and think about it, how will you ever know if any of the business-centered success criteria was delivered if you don’t have a clear direction in advance?  Those reporting requirements must include current and desired actionable data requirements in some measure of detail.  Certainly as a company and then during the sales cycles the buzz words and generalities of the information end-state are discussed;

• during the early research,
• during RFP preparation, and then 
• during the vendor sales cycles when all of those promises are made about a “future state” for your business. 

Some of the actionable data requirements, or efficiency improvements, or competitive improvements, or other business drivers are also explored during this period.  If they are not captured and distilled into some detail, and then included in your RFP and project charter how will you know if they were ever delivered without defining these critical business justifications for the system to begin with?

One other thing to keep in mind is that no system, no matter how good or how well implemented will change a business by itself, but properly implemented it will provide the actionable information to make sound business decisions for marketplace success (see also SAP as a Change Enabler, Using SAP to Improve Revenue and Profitability, and Change How You Look at SAP to Create ROI).

[FN1] SAP provides a huge number of fields that are never used on most projects.  Some of them are directly tied to application functions and can not be used, still others are not and without doing any custom coding or application changes you can use some of these fields for other purposes.  This “re-purposing” of some fields is a very easy, cost-effective way to solve a number of issues.

[FN2] Go to http://www.sap.com and search for “Solution Composer” (or use this link http://www.sap.com/solutions/businessmaps/composer - retrieved 4/13/2010).

Additional SAP Project Success Reading:

ERP and SAP Business Case for ROI, Business Benefit, and Success

Why SAP Projects Fail to Deliver ROI (and How to Change IT)

Innovation Begins with Customer Collaboration

 Customer collaboration is more than surveys, polls, focus groups, or social media input.  Even though these can all be components of a collaboration strategy, several of the approaches are one way when what is needed is a customer dialog and customer engagement.  Outlets like Twitter, Facebook, or some type of forum software help create a dialog but if a company is not ready to hear the truth about their products they may be in for a shock.  For example, see the second half of the following post under the section entitled “A Technology Change that will Force You to Work More Closely with Customers .“

For any company that does not already have an open forum it will be critical to add this to your application portfolio.  This external forum is the first real bridge to customer integration.  Full collaboration integration into ERP applications like SAP is possible by taking a focused approach to how the application is used (SAP, ERP III, SOA — Learning Organizations through Social Media Collaboration).  Properly deployed collaboration tools do not need to be expensive, complicated, or difficult and properly implemented they can transform organizations (ERP III – Is the Integration of Collaboration the Future of Enterprise Applications).

SAP has been very successful at creating a pair of portals which integrate customers, consultants, and vendors into the process and product development through its customer ASUG (Americas SAP User Group), SCN (SAP Collaboration Network), and their partner Eco System (vendor participation).  These are all tremendous examples of how SAP as a company is integrating meaningful social media tools and collaboration initiatives fully into the Enterprise. 

Just how successful is this? 

Although media outlets made a huge issue out of the ASUG based “rebellion” of the customer base over SAP’s proposed maintenance fee increase, it is a testament to the importance and power of collaboration with end customers.  Although SAP may have considered the backlash over maintenance fees a failure, it should be considered instead as satisfying customer expectations.  After all, the global economy has been struggling, competitors like Rimini Street have targeted application support, and customers have long questioned what they get for the support.  A successful press to increase maintenance fees would have likely led to wholesale defections of customers to Rimini Street and would have created a massive market opportunity for other support vendors.  The mass defection to support vendors like Rimini Street could have easily cost far more than just the lost maintenance fees, it could have cost significant upgrade revenues as well.

What can You Do to Create Customer Focused Innovation?

The first and most obvious place to start is to glean a measure of customer intelligence to understand their frustrations with the current marketplace and their desires (Business Strategy and IT Strategy to Reproduce Apple Innovation).  Some type of forum, or other discussion mechanism freely available to customers for feedback is a good place to start.  Company managers and employees should be required to participate in those forum discussions to begin to gain greater insight into the customer perspective, including their frustrations, desires, and concerns.

From that exchange many of the customer drivers can be derived to begin assembling the innovation narrative around new products or services, or around significant improvements to existing products or services. 

The thing to remember here is that you don’t have to create the “miracle” product or service.  You don’t even need to create the product or service that meets the “ideal state,” you only need a product or service that is noticeably better and different than your competitors.  Within the framework of the narrative you can continue to move your products ahead by making them more and more like the “ideal state” narrative over time.

Great Employees Make for Great Customer Experience

Facebook as an Inexpensive Marketing Outlet and Employee Recruiting Tool

Facebook may work well as an inexpensive marketing channel for promotions and offers.  As such, properly constructed, you might be able to “train” an extended customer base to visit Facebook for new offers or promotions.  However, I personally see a different application for Facebook in particular.  I believe its utility is best served as an employee recruiting tool.

Tools like Facebook have a legitimate place in the enterprise even though a recent Harvard Business Review case study demonstrated that their use for businesses with huge customer bases is limited (Social Media Fads and the Risk to the Enterprise).  They do serve a purpose if properly connected to a specific business purpose.  Toward that end, Facebook in particular can generate a “tribe” of loyal customers who might make the best pool of potential employees to recruit from.  What the Harvard study showed was that Facebook was most likely to attract those who are already fans, and who would make the best employees of your company?  True fans as employees are far more likely to be satisfied and far more likely to produce a good customer experience for others as your employees.  They are also much more likely to defend the brand and to actively engage in meaningful dialog with customers to understand where there might be opportunities for innovation.

Conclusion

I’ve provided a few examples and a starting place for a framework for customer focused innovation.  As I previously laid out in a post entitled “From Collaboration to Innovation to Market – Toward a Working Model” there is a rational approach to innovation in the enterprise:

Conceive

• Collaborate (technology integration)
• Gather intelligence and research
• Ideas (customer immersion narrative)
• Socialize (customers, employees, other stakeholders)

Develop

• Prioritize (emerging trend or fad)
• Prototype (mock-ups, story boards, paper prototypes, actual working models)
• Pilot (finalize design, costing, materials or talent, etc.)

Market

• Market trial
• Refinement
• Sales Campaign

This collection of posts has been an initial attempt to bring some definition or a starting framework to an area that has little guidance and little academic research.  The whole area of innovation seems to be a black box to most.  This has been a bit more of a challenge than I had originally expected and I expect that as I continue to toy with these ideas and approaches that something more concise will eventually emerge.  To that end I would be curious about your feedback and input if you have been so courageous as to look through the material.

Innovation at the Point of Customer Frustration, Whether it is Articulated or Not

Previously I published a post on Apple’s innovation techniques and that my personal analysis of Apple’s approach showed it really wasn’t magic, “Business Strategy and IT Strategy to Reproduce Apple Innovation.”  Apple’s approach, as telegraphed by Steve Jobs, has always been to address customer frustration points or areas of strong customer desire that the marketplace is not addressing.

As an example, the other day I saw a Dyson vacuum cleaner advertisement.  After addressing the innovations of a bag-less vacuum, and replacing the wheels with a large pivot ball Mr. Dyson said their mission was simple, to “solve the obvious problems others seem to ignore.”  This is the perfect example of developing innovative solutions around customer frustrations.  In this case the vacuum cleaner bag and wheels had become so accepted and routine that it is doubtful many customers articulated those problems. 

The same innovative approach requires a business to understand their customers, intimately know what they are looking for and why, and then understand what the frustrations or the limitations of the current products or services are.  From there a narrative of the new product or service can be created, innovated, piloted, adjusted, and then rolled out to the marketplace.

The key to innovation success is to directly connect all innovation efforts to a specific customer or business purpose.  That connection requires you to get close enough to your customers and your marketplace to understand their frustrations, but also their difficult to articulate desires. 

Today’s Innovation is Often More About the “Creative Maelstrom” than Innovation

Innovation purists would not agree with the limitations or restrictions on the process that I have proposed.  But innovation purists also live in a creative fantasyland where they do not allow constraints like budgets, deadlines, practical application, or other real-world considerations to get in the way of their creative maelstrom.

An ugly reality for the “creative purists” who insist that is what innovation requires is the limitations of business.  Businesses of all kinds have limited resources, limited capital, and limited ability to create new things.  So an effective method to reduce the amount of time and cost to create new products or services is needed.  And not just time to market with some incremental change or enhancement, but completely new products or services.

On the other hand, many businesses are far too restrictive and shortsighted on what they refer to as “innovation.”  What many call “innovation” is a pursuit of small, incremental changes that yield smaller and smaller benefits over time.   This type of “innovation” is usually minor adjustments of existing products or services.  And while this focus on continuous improvement is useful for controlling costs, quality, and even customer satisfaction, it rarely produces innovative breakthroughs.  If an innovative breakthrough occurs within the context of continuous improvement it is generally on a micro scale (dealing with a small component or feature of a product or service) and rarely on a macro scale (a completely new design departure for a totally new product or service).

Stretch Innovation Examples with the Application of the Innovation Narrative

A very reasonable approach to innovation of new products or services is similar to that taken by Thomas Edison or Alexander Graham Bell. 

When Edison set out to invent the light bulb he was trying to solve a particular problem–, that problem was known and in some of the historical literature he was quite aware of the “ideal future state” he was trying to achieve.  He wanted to bring light to the darkness without the use of fire.  He sought to solve a customer focused problem by replacing the use of fire and fuel oils with an electric bulb.  The idea was to eliminate the risks of fire hazard or noxious fumes that the current flame based technology presented.

Edison’s relentless pursuit and passionate drive to produce a light bulb shows his understanding of pursuing an ideal future state innovation narrative, even if it wasn’t spelled out like modern mission and vision statements.

The same could be said of Alexander Graham Bell.  Bell’s narrative was that he wanted people who were far away to be able to talk to each other as if they were next door.  Bell’s was also a relentless pursuit of an ideal future state innovation narrative even if the narrative wasn’t written on paper.

The difference with this approach and those great history-making inventors is the addition of a structured approach to defining and then articulating the innovation effort.  To that end I have devised a very simple approach, or the beginnings of a process model, for moving from innovation to market “From Collaboration to Innovation to Market – Toward a Working Model.”

Creative Writing in the Innovation Process (The “Innovation Narrative”)

I was recently reading an article about a creative writer who was candid about his inability to live up to the authors he admired.  As a result he retooled his creative skills and turned to industrial design.  From what I saw some of the things he created were eye-pleasing (and popular) works of art with a functional design. 

He mentioned that he started the design work because he could construct a narrative to immerse the customer in each individual product.  I’ll call that the “innovation narrative.”

That is certainly an interesting approach and a great use of his creative writing talents.  There isn’t any reason why this type of design methodology couldn’t be used by business and technology.

The Stretch option, or the striving for the future state requires the construction of a narrative which would be similar to a home elevation or artist’s rendering rather than the entire blueprint.  Over time the details of the blueprint are filled in by the innovation architects within an organization.  Those innovation architects “build out” the various parts of the future state through development of new products or services which move toward the ideal future state. 

This type of innovation, design, and prototyping is similar to creating mission and vision statements for a business, but they are product or service focused.  They are discrete and customer or market specific. 

The Innovation Narrative as a Change in Innovative Design Approach

An “innovation narrative” is nothing but a fancy name for a written statement about the end state of a new product or service.  It incorporates positive changes about what customers do not like about a particular product or service with things a customer likes, or desires.  It also looks at un-served, underserved, or completely new applications for the product or service.  The narrative carefully evaluates the marketplace from an outsider’s perspective, or as close as possible from the customer’s perspective to understand where there are unmet desires for a product or service.  This tries to capture a customer’s perspective of “if only I could do X with this…” or “I wish this would…” or in the service sector “why do they…” or “why don’t they…” or “they really should (or should not)…”

Done effectively this narrative then serves as a guiding framework for development of the new products or services.  For products, it generally involves a departure from the current “form, fit, or functions” of current products.  For services, this would involve significant modifications to service delivery methods, quality, and polish or composure.

The skill to create an “innovation narrative” already exists in the marketing departments of most mid and large sized companies.  What is lacking is the capture of the critical data to develop the narrative and its timing. 

Marketing Involvement in Innovation

At many companies marketing involvement frequently occurs after a new or revised product is either conceived or already underway.  The marketing department then sets about how to position that business item and how to help the sales force sell it and generate “buzz” around it.  But if marketing veterans were involved in the early design stages, at what engineering refers to as the “fuzzy front end” they might be able to make a dramatic difference.  They can use their sales and marketing talent and ability to create an “innovation narrative” around what the new product or service should be at final delivery in the marketplace.  They could create that future state product or service that can only happen if they had a magic wand.

Marketing, sales, and engineering or design should be involved right from the beginning.  Talented marketers generally have a fair understanding of how to position products or services and the sales people are responsible for selling them.  By incorporating key sales and marketing people into the early stages of product or service development the entire process becomes more customer-focused. 

The idea here is to create a narrative that contains the details of the customer frustrations and marketplace aspirations.  The narrative should include the “hard stuff” like the articulation of customer aspirations that the marketplace has a hard time articulating.  And it has to be more than just meaningless marketing hype too, it must contain enough detail to immerse the narrative in the customer’s actual perspective about the new product or service.