ASAP Methodology Background

In the mid 1990’s SAP had gained a significant amount of bad press and publicity around several high profile project disasters that the company knew were completely avoidable. At that time Oracle, Baan, JD Edwards, and PeopleSoft all had sales people making the case that SAP was too expensive, too complicated, and took too long to implement. In response SAP released the ASAP Methodology in the mid-late 90’s (around 1996 or 1997) because of the number of SAP projects that were going over time, over budget, and were at risk. It has been refined, polished, enhanced, and adjusted with SAP’s supported R&D resources and efforts for about 15 years now.

The ASAP implementation methodology has leveraged the PMI (Project Management Institute) best practices around project delivery and the Carnegie Mellon CMMI (Competency Maturity Management Integration) approach for maturing the delivery process. The ASAP methodology also includes a number of ITIL (Information Technology Infrastructure Library) components in the Phase 6 Run and the ValueSAP portions of the methodology. Agile techniques are an option which can be “turned on” if you like.

The toolset includes an implementation “Roadmap” which is a WBS based project template. It has full explanations, templates, tools, resources, checklists, etc. Together with that the original version also included an MS Access, and then an MS SQL Database application for selecting your solution options which would then generate a list of processes, transactions codes, template BPPs, and a full SAP centered Blueprint document, etc.

Today all of that functionality is still available but it is housed in Solution Manager. The ASAP Roadmap is just ONE component of the entire ASAP Methodology. The Roadmap is focused on effective Program or Project Management for accelerated project delivery with high quality results.

My Experiences with the SAP ASAP Methodology

I was originally certified in the ASAP Methodology in 1998 while at Grant Thornton. In that time I have had the privilege of using ASAP on several projects and as the project manager on a few. One consistent result of using the methodology is that projects are delivered and they are usually delivered on time and on budget (although not always).

Every major SAP system integrator claims some methodology and nearly all of them are similar to, or variations of the SAP ASAP Methodology.

I have only ever seen significant problems with ASAP when a system integrator started to use the methodology and then abandoned it part way through the project. At one recent client I used it as the framework to support a LEAN implementation methodology. That LEAN methodology has served as an ongoing framework to significantly accelerate numerous rollouts at probably 25% of the normal implementation cost of other SAP projects.  This was driven by the client project manager and facilitated by using the ASAP tools. 

Starting with the ASAP Methodology

Even before the first consultant comes on board the ASAP methodology provides templates and resources to cover key project and program management areas such as

• communication planning
• decision making
• risk management
• project management master planning
• resource planning
• steering committee tools
• external links to best practice resources for reference (PMI, ITIL, Internal SAP, etc., etc., etc.).

Why ASAP Instead of a System Integrator Methodology?

First, I have nothing against the system integrator methodologies and some are very good with great resources. Unfortunately my experience has been while they have them, and may start with them, they rarely stick to them throughout the project. Since it is their methodology you have little or no insight to cross-check or validate their methodology use.  With ASAP it is yours to use as an SAP customer and you have full insight into it and control over its use.

One of the primary reasons for using the SAP ASAP Methodology is like all things SAP there has been a mountain of R&D spend, development, adjustment, and support. Every SAP client (large or small) who uses the ASAP methodology can avoid the “proprietary methodology lock-in” which the system integrators will walk out the door with. Another important reason is you own it as part of the standard Solution Manager offering. 

As you probably know Solution Manager is already a required part of your SAP landscape.  The SAP Solution Manager portion of the ASAP Methodology can house key items related to scope, configuration, documentation, the implementation roadmap, and all of the key deliverables. As the system integrator rolls off the project you have a centralized repository which is SAP specific for any future employees, support, upgrades, etc. You do NOT get that with a “custom” system integrator methodology which is probably based significantly on SAP’s ASAP Roadmap to begin with. Using an SI methodology you will NOT get the full configuration and development scope monitoring tools which Solution Manager contains either.

The entire ASAP Methodology is part of your application licensing and support you pay for. Why not at least take it for a test drive and see what it can do.

For more information on the SAP ASAP Methodology for SAP customers use your SAP OSS ID and log onto http://service.sap.com/asap .

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

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

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

Related Posts:

• SAP System Vendor Project Success Criteria 1
• SAP IT Governance, SAP Program Management, SAP PMO Metrics
• 7 Tips for Effective Client Management of SAP Consultants
• SAP Program Management Requires a Type of CMMI
• Steering Committee Governance for an SAP Center of Excellence

SAP Program Success

SAP Program and SAP Project Management can be tough.  In a recent Focus.com expert discussion the issue was raised about who a Project Manager or a Program Manager should be accountable to on business application projects.  Should it be the business or IT?  To help clarify the accountability I asked a simple question of what deliverables, metrics, and tasks would be required?  By knowing what mechanisms the program or project manager(s) would be accountable it would be possible to determine who they should answer to.  There was a nearly universal lack of response.  In other words, how do you measure performance and how do you help to ensure results if you don’t even know what the individual, group, program, or business endeavor is going to use to measure accountability?

The most frequent response around accountability for program or project managers was a call for ”independence.” So when I raised the issue of project manager or program manager accountability, metrics, performance, and how to ensure project messes are avoided there were no takers.  Is it any wonder so many business application projects and programs get into trouble, go over budget and time?

SAP Program and Project Management Office Success

A good Program or Project Management Office provides the resources needed for delivery project participants to be successful.  Without this focus the value of an SAP Program or SAP Project Management Office is not realized.  The U.S. Department of Energy did a good review of performance and benchmarking for project management.  And while this was applied to a government program there is a lot of valuable insight for any SAP project or business application project [FN1].  

The U.S. Department of Energy had a committee evaluate success criteria and offered four sets or categories of performance measures to cover the 30 possible discrete measurements of project or program success.  Those four sets or categories were [FN1, pg. 1]:

• Project-level input / process measures. Assess the resources provided to deliver an individual project and the management of the project against standard procedures.
• Project-level output / outcome measures. Assess the cost and schedule variables of an individual project and the degree to which the project achieves the stated objectives.
• Program- and department-level input / process measures. Assess the total resources provided for all projects within a program or department and the degree to which program- and department-wide goals for projects and their management are met.
• Program- and department-level output / outcome measures. Assess overall project performance and the effectiveness of completed projects in supporting program and department missions.

Without this type of analysis and evaluation your project may be headed for trouble before it even begins.  When you start your large business application project what type of deliverables, output, or results do you expect from those who are leading the projects?  How will you measure and evaluate their performance?  If your evaluation of their performance is focused on how well they support the success of delivery teams, along with how well the projects are delivered (budget, scope, schedule, and quality) then you will be measuring the key project delivery values for success.

That same U.S. Department of Energy study provided guidance on the key components for a successful performance measurement system of program or project managers which can be applied to business software projects like SAP.  They noted key components of an effective performance measurement system include [FN1, pg. 7]:

• Clearly defined, actionable, and measurable goals that cascade from organizational mission to management and program levels;
• Cascading performance measures that can be used to measure how well mission, management, and program goals are being met;
• Established baselines from which progress toward the attainment of goals can be measured;
• Accurate, repeatable, and verifiable data; and
• Feedback systems to support continuous improvement of an organization’s processes, practices, and results.

The Answer for SAP Program and SAP Project Management Results

Over the years I have found the SAP ASAP Methodology helps to ensure SAP Project delivery.  The entire methodology is focused on project participant success; budget, time, and scope control; and quality control for project delivery. 

My non-cynical assessment for why it is not more widely used is because many SAP Program Managers and SAP Project Managers have not be trained to use these tools (or Solution Manager which contains them).  On the other hand there are some SAP Project and Program Managers who have a financial motive that can not be ignored.  They do not use the ASAP Methodology because it makes a client less dependent on them.  After all, why do you need an expensive program manager to deliver tools, templates, resources, guidance, quality control, and measurement utilities if you have a methodology that already contains all of this with step by step instructions to use it?

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

[FN1]  Measuring Performance and Benchmarking Project Management at the Department of Energy. http://management.energy.gov/documents/performance_measures_final.pdf

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

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

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

Related Posts:

• Why Use the SAP ASAP Methodology?
• SAP Program Management Requires a Type of CMMI
• Steering Committee Governance for an SAP Center of Excellence
• SAP System Vendor Project Success Criteria 1
• The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors

Manage SAP Consultants

Over the years the most successful SAP projects I have participated in had strong client side leaders. They had some knowledge and understanding of how to deliver large, complex, or difficult projects. Not just SAP projects but large complex undertakings. Their ability to deliver projects came from their ability to manage, direct, and engage with project participants. They took the initiative to directly manage their own projects.

Many of these leaders had something else in common, they understood you can become overly reliant on consultants to deliver a project –, it creates an artificial sense of security.

One project and leader in particular stands out from my past because of the attitude about SAP project delivery. That project’s senior leader used a phrase about consultants I found a little insulting but have since learned to appreciate. He had a “rented skills” attitude about consultants and frequently referred to us in that way. Along with that attitude he and the senior leadership of the company chose very strong leaders from within the company ranks to manage each module or key area of the project. And by strong leaders I mean REALLY strong leaders. During the course of the project a number of consultants were replaced when they did not perform up to the company’s expectations. That project was probably one of the best delivered projects I have ever seen:

• It had one of the largest SAP scope and functionality footprints.
• That project’s first phase replaced nearly 60 homegrown legacy systems.
• It was delivered ON TIME and WITHIN BUDGET.
• It met every business requirement.
• It was delivered across international company codes and business units (including foreign trade).
• And for similar sized companies, with similar scope, similar time frames, etc., it was delivered for probably 10 – 20% of similar projects.

That project was very different because the level of automation and how smooth the go-live went, and even the post-production support issues were far fewer than any other implementation I had participated in.

I participated in this implementation’s post production support as the SD lead and to help with reporting for about 6 months after we went live. They had slightly more support issues than many companies have with “stable” SAP implementations. This senior leader went on to become CTO and nearly all of the company’s leaders involved in that SAP project went on to senior level leadership positions.

How Clients Can Effectively Manage SAP Consultants to Deliver Results

The background I just provided illustrates one of the most important factors necessary for successful SAP project delivery. The Ivey Journal published by Harvard Press about “Leading Consultants to Exceed Expectations” (PDF file) went into detail on this issue. The key is in aggressive client management of SAP projects for companies that want meaningful results and value.

For me this involves a few critical components:

1. Develop a project or team set of values and expectations for project delivery. The expectations should be focused on action and execution.
2. Provide a training course to client participants on the latest SAP ASAP methodology. It can be made available through Solution Manager or as a stand-alone HTML download from the SAP Service Marketplace.
3. Define clear boundaries, tasks, and roles for all project participants. No one should have to try to figure out what they are supposed to be doing.
4. Every client project participant should be trained in how to manage and work with consultants. Use RACI charts to help manage consultants.
5. Every client project participant should be spelling out the specific tasks, assignments, and expected completion of deliverable for each project participant.
6. Each person on the project, whether contractor or employee, should have clearly defined deliverables, tasks, and criteria for success.
7. The client project participants should capture and regularly discuss lessons learned on dealing with consultants, including challenges and soliciting ideas on managing them.

Client and consulting leaders should accept responsibility for the delivery and execution of those they are responsible for. Be on guard for excuses, deflection, and blame-shifting. At times these are common consulting tactics to hide a skill, talent, or capability gap.

One key thing to consider is that any decent SAP consultant who has managed to deliver SAP project results can be difficult to manage at times. Because of their type “A” personality tendencies they need input and awareness of anything within their domain of influence. To manage high performing consultants the use of a RACI chart cannot be underestimated. Because of these tendencies project managers must activity work to solicit their input and feedback, and well as keeping them in the loop on what is happening in the project. If you fail to do this you are setting yourself up for trouble and unnecessary conflict. This is why a RACI chart is a useful tool on an SAP project.

For an overview of the key SAP project success factors, including allocating responsibility, please see this table which provides an overview of success factors:

Critical Vendor Management Success Factors for SAP Project Success

For a detailed explanation of each of these success criteria you may wish to review the series which analyzed them from the consulting selection point of view:

• SAP System Vendor Project Success Criteria 1
• SAP System Vendor Project Success Criteria & Factors 2
• SAP System Vendor Project Success Criteria & Factors 3
• SAP System Vendor Project Success Criteria & Factors 4
• SAP System Vendor Project Success Criteria & Factors 5

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

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

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

Related Posts:

• SAP System Vendor Project Success Criteria 1
• Why Use the SAP ASAP Methodology?
• SAP Offshore Development Project Experience
• How the SAP Consulting Peter Principle Works
• SAP Consultants for High Speed SAP Projects

Managing SAP Project Conflict

If you are determined to gain and then maintain SAP project momentum you will see stress.  Part of the requirement for momentum includes asking people to reach for stretch goals which can challenge (and deepen) their capabilities but also causes tension and even conflict.

One author says conflict is “a situation of competition in which the parties are aware of the incompatibility of potential future positions and in which each party wishes to occupy a position which is incompatible with the wishes of the other.” [FN1] 

In plain English, conflict happens when there are competing expectations and priorities.  Put another way, I want what I want and you want what you want and the level of our conflict depends on just how much each of us wants “it”.

Without hands on, active SAP project management it is likely that stress and conflict will destroy your SAP project momentum.  Active SAP project management is not about micromanaging people or their activities but rather finding the right balance around task execution and delivery while working through the stress that will arise.  As a project manager part of your key responsibility is to work through conflict to maintain momentum.  At its most basic project SAP project management is like babysitting adults who at times act like squabbling children (and I’ve been guilty of childish squabbling as well at times!).

Key Phases of SAP Project Stress Which Can Create Conflict

In relation to physical and life stress Canadian Physician Hans Selye (1907 – 1982) proposed 3 stages of stress in his 1956 book “The Stress of Life”: 

• Alarm
• Resistance
• Exhaustion

On an SAP project the alarm or panic stage occurs when you attempt to create a rapid project delivery pace.  The resistance stage occurs when the alarm does not slow down or stop the momentum that is gaining. Exhaustion or “checking out” can occur when the stresses and pressures of an overly aggressive timeline continue beyond what the project participants are able or willing to deliver.  A good SAP project manager must carefully evaluate and then manage the source(s) of alarm and resistance.

The key to good SAP project management is to maintain a sense of urgency that is strong enough to keep momentum high but no so urgent or so stressful that it causes people to burn out or check out.

There is a healthy level of tension which is needed to keep momentum going but knowing where that line is requires a project manager to be directly engaged with the project participants.  Even though it is critical to gain and then maintain momentum at times you also have to know when to ease up to allow the stress level to moderate. 

It is equally important for a project manager to know whether the alarm and resistance are from unskilled project participants who are trying to hide their lack of experience, or from unrealistic demands, or from the project as a whole. 

At First Most People Try to Deal With SAP Project Stress in a Productive Manner

Regardless of the reason for the stress, and ultimately what the conflict is, most people do attempt to mitigate the initial source of the stress.  The research shows they may:

1. apply extra effort to compensate for the greater demands,
2. they may attempt to overcome the stress by fixating on the task(s) which create the stress, or,
3. they may become anxious, worry, and then avoid the tasks.

If a project manager is skilled and recognizes these signs they can quickly intervene and help to alleviate the source of the stress.  Although it is critical for momentum to keep a forward looking perspective throughout the project there are times it is more productive to pause, reflect, and allow stress levels to lower.  When you see tension and stress building to an unhealthy level it may be time for a special recognition of how much progress has been gained to help people regain a sense of perspective and give them a chance to “take a breath.”

A good SAP project manager must carefully evaluate and then manage the source(s) of alarm and resistance.

Knowing when to back off the gas and recognize accomplishments and when to press the gas and push ahead is the most difficult skill for any project manager to develop.  It is like a professional race car driver who must know when to step on the gas, when to let off, when to apply the brakes, and when to step back on the throttle.  A project manager who is able to perform that balancing act demonstrates their experience and their people skills.  This requires direct engagement with the project participants on a day to day basis. 

This type of engagement by the SAP project manager needs to be in the project participants’ work environments, not just in planned meetings where people may not be as candid or forthright.  That direct engagement requires the project manager to serve as an active umpire, counselor, decision-maker, expediter, and all around gopher to help coordinate many of the integration activities. 

A Good SAP project manager GENUINELY UNDERSTANDS that their success depends on every other project participant’s success and will directly engage in activities which help promote the success of project participants.  Sometimes this means giving some project participants the opportunity to be successful on a different project  :)

As a final thought, an SAP project manager who needs a separate “integration manager” should be more carefully considered.  It may be necessary but do you really need a Microsoft Project administrator or a meeting monitor or do you need a manager for your project?  Needing an ”integraton manager” may be a way to avoid the day to day involvement that is critical for SAP project success.

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

[FN1]  Capozzoli TK. Conflict resolution-a key ingredient in successful teams. Supervision (60:11), 1999, pp 14-16

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

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

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

Related Posts:

• 5 Leadership Tips for Successful SAP Project Management
• SAP Project Manager – SAP Program Manager, Lessons from the Trenches
• 5 More Leadership Tips for Successful SAP Project Management
• SAP System Vendor Project Success Criteria 1
• Some Reasons SAP Projects are Over Budget and Over Time

One key to maintaining momentum requires an SAP project manager who is fully integrated in the day to day project activities.  That hands on approach to project management is crucial for overall project success.  Unfortunately there aren’t very many SAP project or program managers who are engaged in the day to day project execution activities.

“An SAP project manager or SAP program manager must focus aggressively on removing obstacles, encouraging success, and fighting against those things that would slow momentum” (SAP Project Manager – SAP Program Manager, Lessons from the Trenches):

1. Develop project deliverable and task tracking tools that are simple, easy to understand, and forward looking.  If a status tracking tool has more than 10 columns for a deliverable or particular task it is probably getting too involved, if it has over 15 columns (not task rows but details, status, and note columns) it will probably kill any momentum.
2. Set, then communicate, then reinforce an expectation that anything slowing down project momentum must be raised by project members immediately.
3. Create a formalized but simple decision escalation process.  If any project execution process is overly complicated it will reduce momentum or not be used.  This is especially true for decision making. 
4. All project activities MUST focus on execution because it is execution and action that maintain momentum. 
5. Continue to communicate the timeline, and use presentations for all key upcoming project activities–, have templates, deliverables, and instructions in plenty of time for project members to transition to the new tasks (a RACI chart can help here).

A Key Psychological Affect on SAP Project Momentum

Some time back I read an interesting study by a researcher about high performance teams that consistently met “stretch” goals.  The key difference between consistently high performing teams was in how they approached their assignments.  High performance teams consistently looked ahead at what needed to be done next to achieve their goals.  One of the interesting discoveries was when these same high performers were allowed to focus on their achievements and accomplishments their performance suffered.  They discovered when people stop to reflect on how much they have achieved and how far they have come they tend to become more satisfied where they are and naturally slow down.  That sense of achievement causes them to pause and become more content and therefore their forward looking productivity suffers.  However, as we will explore next week, there are times this is an effective project strategy to reduce tension and stress.

We see this all the time in the high performance area of professional sports.  How many times have you seen a professional team start out strong and gain a lot of ground on their competitors only to ease up and then lose that ground by the end of the game.  Sometimes these large gains are even erased and the other team wins!  The team that started strong started to look at where they were and relaxed a bit while their opponents, who were behind, started to look ahead and focused on how to turn things around.  The coaches and players of the team that was behind started looking ahead and planning for how to systematically win the game.

You SHOULD celebrate SAP project milestones and achievements but ONLY as a passing measurement point.  Part of that celebration or recognition of a milestone must be about the passing of that mark and looking forward to, or celebrating, how the next upcoming milestone or major achievement will be met.  You can also use  these recognition events to relieve project stress and pressure at the appropriate times.

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

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

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

Related Posts:

• More SAP Project Leadership Tips for Managing Conflict
• 5 Leadership Tips for Successful SAP Project Management
• SAP System Vendor Project Success Criteria 1
• Series on SAP ERP Project Success Factors
• SAP Project Manager – SAP Program Manager, Lessons from the Trenches

SAP Project Leadership

SAP Project Management drives me crazy!  As I’ve often said, I don’t generally fault customers or clients who hire outside help for SAP project management.  If they believed they had the answers they wouldn’t bother with contractors for guidance.

Too often I see SAP project management treated as more project administration without much leadership.  Just about anyone can be a checklist administrator.  What is lacking from many SAP projects is the project management leadership to move things along.  

After managing a few SAP projects myself and the many projects I have participated in over the years I’ve learned an effective formula for SAP project success–, it takes a project manager who can actually lead the project.  What do I mean by leadership?  I mean someone who actually pitches in, rolls up their sleeves, gets busy, and gets their hands dirty.  They must be directly engaged with the project participants, they need to spend more time with their “ear to the ground” rather than serving as passive administrators. 

The key dimensions of SAP project leadership involves enough direct involvement in project coordination to:

1. Create a sense of urgency to build momentum.
2. To maintain that sense of urgency and maintain momentum.
3. To eliminate obstacles, roadblocks, and impediments which slow (or even stop) SAP project momentum.
4. To manage conflict (which WILL happen if sufficient momentum is gained).
5. To set, manage, and maintain expectations with both the project participants and the broader areas affected by the SAP project outcomes.

1.  Creating a Sense of Urgency

I’m still amazed at how often SAP project managers or program managers avoid using project plans with WBS structures, tasks, activities, and the assorted milestones, etc.  The only sense of urgency they create is reactive firefighting.  Everything will always be last minute, single-threaded, chaotic, disjointed, panicked, and difficult to follow.  Without a structured project plan any dates are just aspirations at best and timelines will continuously be missed.  This avoidance may be from a lack of ability, fear, or an attempt to evade accountability, whatever the reason it happens too often.  Maybe you should be asking yourself what deliverables, tasks, and execution activities your contracted leadership should be providing.

The Effective SAP Project Plan and Project Structure

The most appropriate method to create a sense of urgency is to have a fairly tight timeline but with very clearly defined milestones, tasks, deliverables, templates, and instructions on how to support project execution.  Those deliverables must help to measure project progress and they must be carefully managed.  Communicating and then supporting the message that as an SAP project manager your goal is to ensure the success of the project participants (then living it out) will bring badly needed leadership.

Without a project plan and proper templates any sense of urgency that is created is really reactive firefighting.

For each project phase or upcoming milestone an SAP project manager must have well defined presentations of what is coming, the timeline,  templates, instructions, and the resources to accomplish each set of tasks.

Nearly every contract SAP project manager somehow manages to put together steering committee presentations so why do they have such a hard time putting together critical project supports?  What are they really presenting to the steering committee if they aren’t providing meaningful project guidance?

If SAP Project Decisions Need to be Made Get Them Made Immediately!

Over the years I’ve been blessed to have several pretty decent mentors.  Back when I was an early manager in industry, long before consulting, I got a major schooling from our GM (and a senior VP).  We had a problem come up and the GM wasn’t around to consult so I did nothing.  I was the operations manager responsible for all shop floor production areas–, over a dozen leads and over 200 employees at the time.  My lack of decision-making brought large portions of the production floor to a halt. 

A “manager” who doesn’t make decisions isn’t managing or leading anything.

When the GM/VP got back he immediately set about to get things going and made a number of snap decisions and provided immediate direction.  After things got going again he called me into his office and we had a short discussion about my career.He was polite but firm and provided me a very valuable lesson. 

The GM expected me to make the decision I believed was correct even if it turned out wrong.  He said that 8 or 9 times out of 10 it would probably be right and that 1 or 2 that might be wrong or maybe not the best decision it was easier to correct than doing nothing.  He promptly let me know if I made a bad decision he would hold me accountable but it would not be as bad as making no decision at all.  He would hold me accountable for my decisions to help me learn to make better decisions but if I couldn’t make a management decision to keep things going he didn’t need me because I wasn’t managing anything.

That was a profound insight.  As an SAP project manager if you won’t make the tough decisions to get things going and keep them going then what are you managing?

Decisions must be made as quickly as humanly possible.  Delaying key decisions, or delaying any decision making, creates the appearance of indecisiveness, reduces confidence in your ability to lead, creates constant “swirl” around key issues, and slows the project.  It also creates an atmosphere where others avoid decision-making and become embroiled in analysis paralysis (or “swirl”) because that is the culture you as the project manager are creating.

Next week, more on building and maintaining momentum and the sense of urgency.

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

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

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

Related Posts:

• More SAP Project Leadership Tips for Managing Conflict
• SAP Project Manager – SAP Program Manager, Lessons from the Trenches
• SAP System Vendor Project Success Criteria 1
• Series on SAP ERP Project Success Factors
• 5 More Leadership Tips for Successful SAP Project Management

SAP Program Management

Many may be unaware that SAP provides a broad set of tools and resources for Program Management and Competency Maturity Management (or CMM). Very few are familiar with SAP’s broad set of supports for this purpose such as the “new” ASAP Methodology Phase 6 “Run” enhancement. It is loaded with key information which aligns with Program Management responsibilities and CMMI.

So, what is CMM (or CMMI as it is more properly referred to)?

“CMMI (Capability Maturity Model Integration) is a process improvement approach that provides organizations with the essential elements of effective processes, which will improve their performance… CMMI models are collections of best practices that help organizations to dramatically improve effectiveness, efficiency, and quality” [FN1].

The entire CMMI methodology and development is maintained at Carnegie Mellon’s Software Engineering Institute. These CMMI standards have been applied in a vast number of organizations together with various methodologies. The CMMI approach is well suited to engineering and software development, design, or implementation. SAP’s entire ASAP methodology, and especially the “new” Run methodology incorporates a number of CMMI principles.

SAP Program Management is all about Competency Maturity Management (or CMM)

The contract SAP program manager is accountable for providing the key tools, templates, techniques, and resources to ensure projects are properly managed and delivered for business benefit. If they are not providing this type of methodology guidance, including key templates and techniques to deliver business benefit, what are you paying them for?

SAP Program Management or Project Management Gaps

After all these years one of my biggest frustrations is the lack of SAP contract program or project managers use of the ASAP Methodology. They all talk about it, and during sales presentations they use lots of SAP’s material, but as soon as the project begins you never see it. They seem to have absolutely no idea what they are doing.

As I have often said, I never believe that a client / customer of project management or program management services has the primary responsibility for this knowledge. If they did why bother hiring outside help and paying the rates for this service except for that contract “expertise?”

Contract SAP program management or SAP project management that is not able to deliver on clearly understandable methodology development are fakes. Anyone can call themselves a program manager, but what does that mean? What is the contract SAP Program Manager accountable for? What are they on the hook to deliver and how is their performance measured?

Using SAP ASAP and CMMI to Mature the SAP Enabled Enterprise

The SAP ASAP Methodology, in particular the Phase 6 Run section, should be studied by every SAP program manager before they start doing project or program work. Even though it is in the last ASAP Methodology phase, its greatest effectiveness is realized when you begin your internal SAP delivery maturity planning from the beginning of your SAP project.

One of the critical benefits of starting your CMMI related planning right from the beginning is your SAP project can be structured to support business integration at the outset. Using this type of maturity model integration as part of your project guidance can have significant benefits to the enterprise:

“Many CMMI using businesses have beneficial results to their bottom line… including improvements in schedule and cost performance, product and service quality, forecasting accuracy, productivity, customer satisfaction, return on investment, and other measures of performance” [FN2].

SAP has already done a significant amount of the work for you. All your program manager has to do is adjust the plans, alter the templates, follow the ASAP Methodology instructions, and build the resources to support this transition. You really must question SAP program manager service providers who do not keep up with the ASAP tools and delivery methodology that SAP provides and supports.

SAP’s Competency Maturity Model Starting Point

The following maturity model is just one small example of a powerful tool that is critical for long term technology and business integration [FN3]:

This model, provided freely by SAP as part of their standard ASAP methodology is a great starting point. Your contract SAP program manager should be able to use this as it is, or adjust it to fit your particular organizational needs. This is just one very small component of the Run Phase and an even smaller component of the entire ASAP Methodology toolset.

In many cases you would be better off sending your own internal employees to SAP ASAP certification courses and Microsoft Project classes and making use of their new found knowledge. At least then you would have a knowledgeable employee who could help keep an integrator who claims to use ASAP honest. And if they claim to use ASAP in their sales materials or sales pitches GET THAT CLAIM IN YOUR STATEMENT OF WORK AND YOUR CONTRACT WITH THEM!

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

For more information on related topics please see:

• SAP Project Manager – SAP Program Manager, Lessons from the Trenches
• Effective Results from SAP Project Managers – SAP Program Managers
• SAP IT Convergence Beyond Business to IT Alignment
• Create SAP Convergence Instead of Business to IT Alignment
• Integrating Business Stakeholders as Part of SAP IT Convergence
• Steps to Achieve SAP IT Convergence
• SAP IT Convergence is About Business Focused Integration
• Steering Committee Governance for an SAP Center of Excellence
• Using Your SAP Steering Committee for Business Transformation

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

[FN1] CMMI Overview: Software Engineering Institute at Carnegie Mellon University, retrieved November 5, 2011. http://www.sei.cmu.edu/cmmi/

[FN2] Why CMMI: Software Engineering Institute at Carnegie Mellon University, retrieved November 5, 2011. http://www.sei.cmu.edu/cmmi/why/

[FN3] SAP ASAP Methodology version 7.1, WBS 6.2.1 – Table 1: Maturity Level Characteristics. For more information on the SAP ASAP Methodology please go to http://www.sap.com/services/more/servsuptech/asap.epx

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

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

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

Related Posts:

• Steps to Achieve SAP IT Convergence
• Steering Committee Governance for an SAP Center of Excellence
• ERP and SAP Business Case for ROI, Business Benefit, and Success
• Why Use the SAP ASAP Methodology?
• SAP IT Governance, SAP Program Management, SAP PMO Metrics

SAP Offshore Development

My experience with SAP offshore development is that no matter how detailed your spec is their lack of experience with standard SAP transactions and functionality means they will never properly test their own creations.  Their results are more than just full of bugs, often times they crash when attempting to do even basic testing.  Repeat testing by expensive functional resources happens so frequently and consumes so much hidden time from parallel project activities that entire project timelines are frequently affected. 

Functional resources have to babysit and handhold these SAP offshore resources through the whole process because of the language barriers and lack of experience.  More functional time, more project management time, more unplanned distractions from functional Realization activities and your entire project timeline can be wiped out.  If that happens you have to pay even more for a missed development date because you have to move your go-live date.  And that cost is completely hidden from you by some of the shell games they play on their supposed efforts.  All of that functional time and the risks to the project timeline point to some of the real hidden costs of SAP offshore development. Develop, test, bugs, fix, develop, test, bugs, fix, rinse and repeat at least a dozen times.

A common SAP offshore practice is to keep throwing “crap” at you saying it is “done.”  With all of the crashes and bugs that are so common with offshore development, and especially all of the program crashes, how much testing could they have done?  The bigger question is how much is this really costing you and how do you find the hidden costs?

SAP Project Timeline and Budget Due Diligence

Because of the nature and pace of SAP project work whenever the issue of blown budgets and blown timelines come up most companies rarely perform root cause analysis or due diligence.  Instead the accusations and recriminations fly in the heat of the moment.  Meanwhile the offshore developers keep saying “we finished x development on y date… the functional teams didn’t support us…” or “the specs were bad and we had to make 20 changes…”  You name it, the extent of the excuses are never ending.

Evaluating Hidden SAP Offshore Development Costs

Because of how SAP “functional” consultant time (needed to support the offshore development) is hidden from you it never shows up anywhere in the rates you were quoted.  You really have no idea about the real Total Cost of Ownership (TCO) for that offshore SAP development.  The offshore company constantly claims the “specs were not detailed enough” or every microscopic change and adjustment becomes a “change order.”  I’ve even seen this where standard SAP functionality was completely broken by the development and the developers insisted because there was nothing spelled out in the design spec about allowing standard functionality to continue working a change order would have to be separately paid for!

On new SAP implementations the functional time premium can easily cost you 50% to 75% (and in some cases even exceed 100%) of the total development hours.  Think about that for your next quote as you try to put the pen (or your spreadsheet) to the numbers.  Have you really factored in the amount of high priced functional resource time needed to support those “inexpensive” offshore developers?  Between writing “super enhanced” specification documents, repeated endless functional testing of buggy SAP development, “training” of inexperienced developers, language barriers, “babysitting” the actual development, and the lost opportunity to focus on other functional Realization activities can kill any supposed savings.  It’s all a shell game.  You pay just about the same amount (and on many occasions even more) with far more headaches and lower likelihood of making your go-live date.

Even after all of this, there is still one more hidden cost that is not realized immediately at go-live–, the cost of poor coding.  You may have significant performance problems, constant bug fixes, and a whole host of other maintenance activities that you never planned or budgeted for.  Now this is true of any development but because of the language translation issues and the modest (at best) quality of coding you are likely to have incrementally more production maintenance costs with the offshore development.

Some Considerations to Help Reduce The SAP Offshore Development Shell Game

First and foremost NEVER accept the offshore development group’s code review options.  One way you can help to combat so much of this is to budget for at least one local developer, even at premium rates, to serve as a quality checker.  They do not have to review all of the code from all of the developers but they should look for the “tells” of experience over inexperience.  And your SAP statement of work (or SOW) as well as your contract with the offshore developers should include various protections about the quality and expectations of the development work and functional consultant time and contributions.  That SAP SOW should also include some definition around what a “change” is and what a “defect” is.  Without that everything will be considered a “change request” and destroy any supposed savings.

Next week the wrap-up part 3 of this series:  Where Does SAP Offshore Development Make Sense?  There are some situations where it is a great cost saving alternative.

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

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

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

Related Posts:

• Where Does SAP Offshore Development Make Sense?
• SAP Offshore Development Project Experience
• More on Stupid SAP Vendor – Partner Selection RFI-RFP Processes
• How the SAP Consulting Peter Principle Works
• Steering Committee Governance for an SAP Center of Excellence

SAP Peter Principle

Most of us working in business for any period of time have heard of the “Peter Principle.”  It was “formulated by Dr. Laurence J. Peter and Raymond Hull in their 1968 book The Peter Principle, a humorous treatise which also introduced the ‘salutary science of Hierarchiology’ …” [FN1]  While the exact quote is a little different, it has come to mean that people tend to rise to their level of incompetence in organizations built on hierarchies.

As an important caveat before getting into this topic, I have known many really hard working folks who have risen through the ranks the “old-fashioned” way –, through hard work and “paying their dues.”

My Experiences with the SAP Consulting Hierarchy

After over 20 years in IT, and over 20 SAP projects, I have seen the Peter Principle again and again.  It’s the nature of how the IT consulting world works.  It is frustrating, and it is enough to drive the competent, diligent, and most talented consultants absolutely crazy.

The “Peter Principle” happens in the consulting world because this is what organizations who implement SAP demand of their implementation vendors.  Sure, that sounds counter-intuitive and crazy, but unfortunately it is a sad reality.

You might be asking yourself right now, IS HE CRAZY?  Maybe a little, but on this point, let me assure you, it is quite true and in a moment you will see exactly how it happens and why.

Enter the Crazy World of Consulting – Why Consulting Incompetence is Rewarded

Once inexperienced, incompetent, or “less than optimal” consultants get onto your SAP, ERP, or other IT project, you are now set up for seeing the “Peter Principle” in effect.  On your implementation or upgrade project an inexperienced or incompetent consultant will ultimately make a mess, however it won’t be seen right away.  There may be signs along the way, but only deep experience will recognize this unless it is blatantly obvious.  There is always some reasonable sounding explanation, or some gibberish, or some babble that is pronounced with confidence but you don’t really understand it. Or, they have become polished and provide entirely rational and reasonable explanations, whether true or not.  After all, they are the “expert” you hired so they must know what they are talking about, right?  Nonsense!

First Sign of the SAP Peter Principle

“Blah, blah, blah”  I have no idea what you just said but just so I don’t look stupid I’m not going to challenge it.

As I’ve written on many occasions, part of the key skills and experience a good consultant or business analyst MUST possess is the ability to take the complex and make it simple.  ANYONE can take something complicated and keep it complicated, or worse still, make it more complicated, or, worst of all, make it a mess.  It takes experience and competence to take the complex and simplify it.  But all that “technical babble” and jargon sounds so convincing, so educated, so, foreign.  It’s a foreign language that you don’t completely understand and these incompetents know it.  Unscrupulous consultants know if they can make something up and sound as though they know what they are talking about you will believe them –, you hired them for their expertise.  They can game you to increase scope, or extending project timelines, or busting your budget and they do this because they are personable and manipulative.

How Can You Identify the SAP Con Artists?

Accountability, Responsibility, and Quality.  The cons avoid accountability or direct responsibility.  On a project where they are discovered they must be nearly forced to have clear accountability for delivery.  They must be pressed into doing what I call “due diligence” around a solution to make sure it will work correctly.

If you catch it early enough you can keep these incompetents from being rewarded for blowing your budget, causing project delays, and creating even MORE complicated and convoluted processes than you had BEFORE you did your SAP implementation.

How Customers Provide Perverse Rewards for Incompetence

The incompetent consultant’s area seems to have users who struggle with problems / issues / bugs that need the most fixing and the most attention.  By this time many companies have invested so much time and effort with the incompetent consultant that they don’t see any other options but to continue with this fraud.  The incompetent consultant is needed badly to support the mess they make for some time after you go live.

One way you can tell you have been manipulated or gamed during the project is by the quality, completeness, and accuracy of the solution the consultant delivers at go-live. 

From a consulting firm’s perspective, the incompetent consultant puts in lots of extra billable hours, helps them get extensions and budget increases, and needs to have lots of extra consulting support.  They are always behind, and no matter how hard “they try”, they always have another excuse for why the problems they cause really aren’t their fault–, it’s always someone else.

These consultants stay on long after go-live to ensure that their questionable solutions are supported by the same person who made the mess to begin with.  This is what customers insist on because by the time go-live happens they are “stuck” with the mess and “stuck” with the “con”sultant who made the mess.

Incompetent consultants tend to be VERY personable most of the time, and ingratiate themselves with the customer / client so that there is no question that they are working SO hard, and doing such a GREAT job.  It could never be their fault.

How SAP Consulting Vendors Reward and Promote the Peter Principle

For the consulting vendor, billing hours go up, staffing and utilization numbers are high, additional “backfill” support is needed and more people are staffed.  From their metrics and possible compensation incentives the incompetent consultant is doing a great job!  On the other hand the highly experienced, competent, and diligent consultants “work themselves out of a job.”  The competent consultants tend to have fewer go-live support issues, they usually have more engaged, involved, and knowledgeable users.  And they are just plain better prepared.  They are not “needed” as you go-live and you, as the customer, get rid of them to cut the blown budget wherever you can.

In a partner oriented firm the incompetent consultant is headed for being a manager, senior manager, managing partner, etc.  The incompetent consultant has great utilization, helps to get more staff on projects, and is always busy.

In the consulting companies incompetence is rewarded and incentivized by the consulting firms.  The most competent and diligent consultants are passed over for career enhancement precisely because of their competence – they may finish projects earlier than their incompetent peers and may be “on the bench” more frequently.

The more skilled the incompetent consultant is at being personable, at presenting a compelling case for why they are doing such a great job but you need more resources, the better positioned they are for higher level promotions.  After all, in consulting firms, senior level positions are focused on getting billable resources out and billing.  The more experienced and capable at this the better positioned you are for partner or senior management.

Stay tuned next week – details on how to spot them and then ferret them out…

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

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

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

Related Posts:

• Reduce SAP, ERP, or Technology Project Stress: Part 2
• Protecting Yourself from SAP Consulting Fraud
• Screening and Interview Methods to Find the Right Consultant – Part 2
• Screening and Interview Methods to Find the Right SAP Consultant
• SAP Offshore Development Project Experience

SAP consulting services best practices

Last week’s post took a hard look at the types of consulting services you need for a high speed SAP project (see SAP Consultants for High Speed SAP Projects).  Consultants who work on SAP projects in the small and mid-sized business space develop great breadth of SAP experience across an entire area.  This week we will look at the other side of that coin, consultant skills from large, long-term type SAP projects and what their experience provides.

Consultants on the larger, longer-term SAP projects may not develop the breadth of experience gained through smaller company experience but they develop depth of experience.   Small and mid-sized SAP implementation projects create breadth of experience while large projects create depth of experience.

How is Consulting Service Delivery Impacted by Large SAP Project Skill Development

On larger SAP projects the projects are usually broken out into sub-teams within a module or area.  These SAP consultants may cover a small subset of a module, or of the overall solution within a small subset.  As a result they spend much more time digging into the details of the functionality around that small subset of SAP setup.  That type of focus creates a high degree of narrowly focused specialization.

For example, a consultant who focuses on just the SAP GL Account setup will easily become an expert at every setting and every option related to its setup.  They will learn about the different posting possibilities, account settings, document types, how to deal with taxes, reporting issues, data elements that can be stored in the GL, etc.  An SAP SD consultant who focuses on order setup might become an expert at all of the copy rules around moving the data from an order to a delivery or to billing.  Depending on how the responsibilities are broken out they might focus on the different types of item categories and all of the functionality they drive.

Small and mid-sized SAP implementation projects create breadth of experience while large projects create depth of experience

Big SAP project consultants gain great depth of experience with very narrow areas of the application.  Those with many years of experience are great for projects that require specialized focus for complex processing around a very specialized area.  So if you are having a particular problem, in a very narrow area of the application, these SAP consulting skills may provide value.

SAP Consulting Services to Produce Business Value and Achieve ROI

Depending on what you are trying to achieve different types of consulting skills are required.  When you need SAP architecture, complex process design, involved SAP custom development, or other unique requirements you will want an SAP consultant with many years of all around experience.  That type of consultant needs both depth and breadth of experience with a well-rounded background in small, mid-sized, and large company SAP implementations.

The obvious but often overlooked fact is SAP consulting service delivery is directly related to the type of consulting experience you are provided

This type of experience will generally take around 10 or more years of experience.  I’ve written about this previously in Expert SAP Consulting to Reduce SAP TCO and Improve SAP ROI where the academic studies lay out the path to “expert performance.”  Unfortunately for most SAP customers they will rarely find this level of skill with any of the consulting firms or system integrators unless those integrators use contractors.  Few consulting companies provide these types of consulting services because as I’ve pointed out, if you haven’t moved up “through the ranks” after 10 years in a consulting firm, your future is pretty dim.

Where Can Customers Find These Skills or High Quality SAP Consulting Services?

One of the most important areas where you can make a difference in your solution results is to hire solution experts (see Industry Specific SAP Consulting vs Deep SAP Application Experience).  They are not easy to find, but they are out there.

If your SAP project is large enough to have more than one consultant per module then demand that at least one of those consultants has both depth and breadth of experience.  If they are the only consultant for an entire module you may wish to insist that they have a significant amount of small and mid-sized project experience.  If you need specialized skills then you will certainly want to consider large project experience in that particular sub-area of expertise.

As an SAP customer you have to insist on the level of skill and experience that a consulting company provides in their initial proposal.  In other words, your SAP RFP must call out what level of skill and experience you expect.  You must insist in writing on this and build it into your SAP consulting service contract with the vendor you choose.  Until SAP customers begin demanding this from the marketplace nothing will ever change, results will continue to be sub-par, and ROI from your SAP investment will continue to be lacking.

One last consideration is to be very, very careful of the consultants you or your SAP consulting firm hires.  There are so many frauds, fakes, and con artists out there it is frightening.  And I don’t mean just exaggerated either, but outright fabrication and fraud.  Unfortunately many of the staffing firms knowingly allow the fraud to continue (see Screening and Interview Methods to Find the Right SAP Consultant and Screening and Interview Methods to Find the Right Consultant – Part 2).

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

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

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

Related Posts:

• SAP System Vendor Project Success Criteria & Factors 4
• SAP System Vendor Project Success Criteria 1
• Reduce SAP, ERP, or Technology Project Stress: Part 2
• Series on SAP ERP Project Success Factors
• How the SAP Consulting Peter Principle Works