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

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 fake consultant

One of the most pervasive problems with SAP or any other ERP project is the sheer amount of fraud.  It is so rampant with such huge financial effects in any other area it would be seen as organized crime.  I’ve previously written about SAP consulting screening methods and required skills, but there is one key method to filter through the huge number of frauds–, simple experience verification.

Many organizations that have SAP periodically need experienced consultants to help with specialized requests, requirements, new functionality, or to occasionally backfill employees.  Because contract staffing is not a key portion of their business they turn to staffing firms or recruiters.  Unfortunately too many of the staffing firms and recruiters have only one interest–, to collect a paycheck.  Very few of these recruiters care about how they get that payday so it is up to you as the customer to ensure you are not getting ripped off.  There is no incentive for them to carefully screen candidates–, no background checks, no former project verifications, nothing.  A recruiter’s goal is to get them through the interview and have your organization hand over the cash.  The cheaper the resource they can find (i.e. read “fake”) the fatter their margin if they can convince you to use them.

The consulting fraud in the SAP arena (and ALL of the business application space) is widespread and out of control.  For more background and information on some of my experiences with this you may wish to see some of the following posts:

• Screening and Interview Methods to Find the Right SAP Consultant
• Screening and Interview Methods to Find the Right Consultant – Part 2
• A Cautionary Tale About SAP Knowledge Transfer
• Corporate and Personal Liability for Fake Consultants
• SAP Technicians or Experts
• ERP Consultants: Is the Promise of Knowledge Transfer just part of the Sales Pitch?
• Successful SAP Project Team Composition – Technicians or Experts?
• The Consultant Certification Ruckus

Just in case you think this is just complaining, take a look at an actual timeline of consulting at a real company where an internal employee periodically posts some of the horror stories they are dealing with; http://sapmesideways.blogspot.com/.  Although the employee at that company does not come out and say they are dealing with frauds, con artists, fakes or “SAP freshers,” I’ve seen this so many times that if that company checked these “con”sultant’s backgrounds I could guarantee a very high percentage of SAP fakes or “freshers.”

Protecting Your Organization from the SAP Fakes and SAP Frauds

If your organization would like something different you can do at least one small thing to protect yourself.  AFTER a staffing or recruiting firm has submitted a candidate demand they include references, from the last 3 projects listed on that consultant’s resume.  The ONLY references I accept are client resources, still at those organizations, and on an e-mail address that is clearly at that organization.  If they cannot provide these then my immediate assumption is they are a fake.  If the staffing firm doesn’t get the message you will not accept fakes then do not do business with them EVER!

The ONLY references I accept are client resources, still at those organizations, and on an e-mail address that is clearly at the organization.

Think about that a minute, even if you miss out on someone who has the actual experience you are looking for, do you really want to pay those kinds of rates for someone who was so uninspiring that no one even remembers them?  What about their consulting skills?  Were they a bump on a log that hid in the background and made little or no contribution to the direction or success of the SAP project?

Step by Step to Find the Real SAP Consultants

If you decide to use a staffing or recruiting firm, make it a hard requirement that they provide ONLY candidates who can provide an e-mail reference STILL EMPLOYED at each of that consultant’s last 3 clients.  This is basic employment verification stuff but few if any of the staffing firms do this unless you insist it is a requirement.  And nothing less than a direct verification from someone who is still at that organization will work because I have seen many “stories” about how they have some other reference or the person left and are now working at “XYZ” company instead.  Would you accept that from a permanent employee candidate?

The next step, AFTER the 3 prior project references still at those companies (on the company e-mail address / domain) is copy that portion of the resume listing that consultant’s experience at that company into an e-mail message to their reference.  Send the message with a notice they used this information on their resume to indicate their experience and you would like to know if they can verify that the candidate’s experience is consistent with what is listed.  If that cannot, or will not, then that is the end of the screen for that person.  I do not bother to waste any time with a phone screen until that verification step is complete.

What are some of your thoughts or suggestions for screening out the fakes, frauds, charlatans and con artists?

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

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:

• How the SAP Consulting Peter Principle Works
• Reduce SAP, ERP, or Technology Project Stress: Part 2
• Screening and Interview Methods to Find the Right Consultant – Part 2
• Some Reasons SAP Projects are Over Budget and Over Time
• SAP System Vendor Project Success Criteria 1

SAP Offshore Development Cost

If you are capable of providing detailed design specs where there is almost no deviation or thought required then this is a great option.  The instant your SAP design requires a measure of experience and insight to make judgment calls, or to look for data or processing that is not explicitly spelled out in detail, you are headed for huge hidden costs. 

The level of detailed spec design work by SAP functional consultants merely shifts the development time and costs to the higher priced resources where it is “hidden” from TCO and sales quotes.  If you are capable or writing “functional” specs that are really more like technical specs with specific table and fields spelled out in detail, program pseudo-logic defined, every possible alternative anticipated, and no detail left out then SAP offshore development works well.  If you are not prepared for that level of detail and “perfect specs” then you are likely headed for a much larger invoice in change order costs and hidden functional time than you ever anticipated.

Offshore resources are often smart, industrious, and hardworking but the ugly reality no one talks about are the real rates because these resources do NOT have any significant amount of SAP experience.

This is the final post in this series.

• Part 1 – SAP Offshore Development Project Experience
• Part 2 – Hidden SAP Offshore Development Costs
• Part 3 – Where Does SAP Offshore Development Make Sense?

A quick “test” for the SAP outsourcing or SAP offshore fit is the nature of the work.  “Commodity” services are a perfect fit for SAP outsourcing or SAP offshore work. 

If the effort involves any type of innovation, business transformation or needs any level of change management then SAP outsourcing or SAP offshore development may be dangerous and it WILL cost you far more than you are led to believe.

SAP Upgrades Might Support SAP Offshore Development

One area I have seen where SAP offshore development work makes sense is with upgrade projects.  Much of the development work there is re-working existing objects where the requirements from previous projects have been well tested and adjusted.  Or, if there are enhancements the gaps are well-known and understood so that the detailed SAP development requirements can be easily defined.  From this standpoint SAP offshore review and adjustment of existing code makes sense.  There is little in the way of experience needed to use the syntax checker and to do the occasional program adjustment.  And other than poor coding which causes performance problems the risk is lower.

SAP Production Support Might Work With SAP Offshore Development

In a fairly stable production environment, where there are not a lot of enhancement or new functionality requests SAP offshore support might work well.  The “fix” requirements are very specific and limited so that these types of small adjustments or corrections work well in an offshore environment.  Even for some of the smaller and less complicated enhancements or improvements SAP offshore support might work well.  However, for more extensive troubleshooting, or very complex requirements, you are likely better with some sort of local or onsite support. 

For a more details see Outsourcing Your SAP Application Support.  This provides some insight and a little framework for understanding the SAP outsourcing or SAP offshore fit.

Conclusion on SAP Offshore Development

Regardless of the hype and sales pitches SAP Off Shore development has far more Total Cost of Ownership than anyone has been led to believe.  There is a place for it but that is rarely in a new project or an extensive rework of complex processing requirements.  While you may not see the costs, the offshore project model will cost you unless you are fully aware of the requirements and hidden costs that are never defined in any of the sales pitches or materials.  Of course they will never tell you SAP offshore development might cost you far more than higher priced local resources in many situations.  If they had that level of integrity you would never engage with them for those services. 

For more information and insight on this topic see IT Outsourcing, Off Shore Support, Cost Cutting and IT Department Changes.  That post provides some additional insight on helping to understand where SAP internal resources should focus as well as where offshore support might make sense.

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

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:

• Hidden SAP Offshore Development Costs
• 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 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 Offshore Development

There is a time and a place for everything–, even SAP project offshore activities.  Unfortunately in the quest to save money the wrong approach can sound good on paper but cost you far more than the sales pitches would lead you to believe.  The SAP offshore sales pitch uses enticing rates like getting an offshore developer for about 15 to 20% the rate of an onshore resource (about 1 / 5^th to 1 / 7^th the price).  The initial reaction to all of the sales pitches is “wow, that will save us a bundle!”  The truth is sometimes it does and sometimes it does not.  And in many cases it can even cost you far more in hidden costs than local (higher priced) developers.

This is the first in a 3 part series on SAP offshore projects:

• Part 1 – SAP Offshore Project Development Experience (this post)
• Part 2 – Hidden SAP Offshore Development Costs
• Part 3 – Where Does SAP Offshore Development Make Sense?

I’ve worked on 3 projects where off-shore resources were used for the initial project and 2 others where they were used for upgrade.  This is the “inside scoop” from my experience.

The Real Reason Offshore Development Seems So Cheap

Let’s set the record straight on one thing immediately, there is a REASON those rates are that cheap.  In the global SAP world it has less to do with the wages of the host country than you might realize.  In the SAP space there is still strong demand for strong SAP skills globally so market forces plainly dictate that real experience will pay market rate no matter what country it is.  Work Visa requirements for many countries with high SAP skill demand will allow the importing of actual skills –, heck, they let massive numbers of total fakes and frauds in the United States so real experience (rather than faked) makes it easy to move out of these host countries for far higher wages.

When Off-shoring Might Cost You More Than Local Resources

When your SAP project depends on large amounts of custom development work you may be in for reverse “sticker shock” at the actual hidden costs.  And by reverse “sticker shock” I mean it is like getting a car for 25% of what you thought you would have to pay BUT you find out the tires, battery, seats, steering wheel, and all of the key components of the car are “required” add-ons that you have to pay for separately.  But they only show you the nice, finished, new car with all of the “extras.”  The actual cost for a HUGE portion of the offshore development is hidden and that rate you were quoted is a joke! 

Your “offshore” resources have very little if any actual SAP development experience no matter what kind of a sales pitch you are given.  What you are ”hiring out” is some smart college kid who is learning on your dime but *maybe* under the supervision of an experienced developer.  Yes, the rates are lower but in today’s economic climate you could probably find some aggressive local college kids who would do as good or better, for the same wage, and without any language barriers.  Maybe you should consider that and bring in one of those expensive local resources to train, shepherd, supervise, and teach them.  At least then you have the skills in house.

Some of the huge costs that are buried for a new project are in the whole development process itself.  SAP functional consultants, who are typically higher priced than technical or development resources, end up taking 2 -3 times the effort spelling out requirement details.  That extra effort translates into hidden cost that you do not see but it creates a great target for the offshore resources to “blame” for why they are struggling–, “I’m waiting on the functional consultant…” or “the spec had to be re-written…” or “it didn’t have enough detail…”  A truly experienced local resource already knows and understands the table structures, data sources, actual requirements, and has probably done similar SAP development work or reporting.  With a higher level spec in plain English, rather than detailed design with pseudo-code required for offshore work, local SAP resources can churn out a polished first pass development effort which needs only minor tweaks, takes less time to test and adjust, and has better performance.

The actual cost for a HUGE portion of the offshore development is hidden and that rate you were quoted is a joke! 

There really are situations where Offshore development is ideal for your SAP project, just don’t be surprised if the overall project “savings” you expect don’t materialize on a new project or one with complex development requirements.

How Can You Tell If You Are Being Bitten By Huge Hidden Offshore SAP Costs?

The one simple metric that will clearly illustrate if you are a victim of hidden offshore development costs is the total CALENDAR timeline for all development work.  In other words, after you get past the excuses, the finger pointing, the supposedly finished items that are always being reworked, etc., the calendar timeline tells all. 

No matter how many times the offshore development tries to suggest they are having problems getting “complete” functional specs, or how often they say they are done but have defect after defect to resolve, or whatever the excuse is, the simple calendar test will tell you the TRUE project impact.  If it takes 90 calendar days to complete development to the point that it can be used (defects corrected, tested, and ready for production) then it doesn’t matter if they estimate and then claim completion at 3 weeks.  The other 9 weeks to actual completion is project time that is taken from SAP functional resources, reworked development, business resources, etc.  So there is a huge hidden cost no matter what claims sales people may offer.

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

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?
• Hidden SAP Offshore Development Costs
• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Industry Specific SAP Consulting vs Deep SAP Application Experience
• Using SAP to Improve Revenue and Profitability

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

SAP consultant results

No matter what size company or organization you have the type of consulting experience you choose will have a huge impact on the results of your SAP solution.  For high speed projects consultants with several small or mid-sized SAP project experiences tend to be more well rounded.  They have skill at delivering the more difficult SAP solutions with standard functionality and at a faster pace than their counterparts with significant amounts of large project experience.

Why are SAP Consultants with Many Small and Midsized Projects Uniquely Qualified?

The small and midsize business segment of SAP implementations use smaller teams, smaller budgets, and tighter timelines.  Contrary to popular belief a small or mid-sized company’s SAP implementation often has the same process requirements, similar industry needs, common competitive pressures, and all of the other issues that go with doing business.  In other words, their business software application requirements are exactly the same as their larger counterparts.  However, they must deliver similar or better results than their larger counterparts with fewer resources.  Consultants who deliver solutions in this space must know their area of responsibility well because they are often one deep, without others to fall back on.  They have to cover the integration touch points and other project activities together with their own module.  This type of effort is usually performed by other groups and numerous other consultants on larger projects.

Consultants who have worked in the small and mid-sized space don’t have the luxury of the big consulting firms, on their mega projects, where they can specialize in one little component of a module at a time. They don’t have the luxury of massive numbers of people coordinating small, discrete components of an overall effort.  Small and midsized SAP implementations often don’t have the resources or budget for large change management and training staffing, separate data conversion groups, separate testing staff, or other key areas of the project.

The consultants with many years of small and mid-sized business exposure are able to do in a few hours, or possibly a few days, what takes consultants with less exposure weeks to figure out. Even if it is a bit of a stretch, they have enough background, enough exposure, and enough experience to be able to start immediately with 80% or more of the solution. From there it is just detailed testing of different settings to be sure you have just the right combination and the process or transaction behaves exactly like you planned.

Small and midsized business consultants are less likely to need lots of custom coded solutions because they can figure how to do it with standard functionality, or how to “re-purpose” other functionality for your company’s particular need.

An SAP Project Examples of Complex Standard Functionality that Helped Avoid Blown Budgets and Timelines

I’ll provide one example here of many SAP experiences I’ve had where this experience made a huge difference in the SAP project result.  The SAP experience helped save the timeline, stopped the continual circular meetings, and finally moved the process along.

SAP Cross-Company Supply

I was on a very large project that had cross-company supply issues that no one had been able to resolve for about two months when I joined. There were weekly meetings, and weekly arguments, and no one could agree on the solution.  There was third party cross-company supply where one company would take the order, transfer the requirements to a separate company who would actually carry out the delivery and bill the other company who then billed the end customer and collected the payment.  This was also being done in different countries, with different currencies, cross-company pricing markup, and foreign trade.  After a few weeks of this dragging on after I arrived on the project as the SD team lead  I knew something had to be done.  All of the “Big x” consultants claimed this could not be done without mountains of custom code and that standard SAP would not work.  These consultants did not have a lack of years in SAP, or large projects doing SAP, it was a lack of experience having to deliver results on a compressed timeline with standard functionality.

The SAP Blueprint was over and we were still in design on a key set of processes.  After several discussions where it was mentioned this was standard functionality and strong disagreements together with claims that only custom coding would work I had enough.  I took a couple days to set up and prototype the entire solution.  The standard SAP functionality did over 90% of everything that was needed for every process and transaction they needed. After the prototype was set up, and without telling the other consultants who insisted it wouldn’t work (and claimed they wouldn’t support it if it did), I set up a meeting with all of the key stakeholders and the client project manager to demo the new functionality.  It was a huge success and the ridiculous arguments and endless discussions to flow out processes for unneeded custom ABAP solutions finally stopped. The solution was nearly complete with almost all standard functionality. [FN1]

Big SAP Project Experience Effects on Compressed Timeline and Budgets

When you want to do a compressed timeline project with resources (consultants, managers, coordinators, etc.) who come from big SAP projects you end up with unnecessary struggles.  Their “experience” has conditioned them to believe these types of projects cannot be done, they rely on too many middle layers of coordination / management, they struggle with the intense need for integration coordination, and undermine attempts to gain momentum because they are not used to the pace.  These large projects often provide the “luxury” of deferring discrete components of an area to others.  They provide big budgets, lots of time, each delivery area broken down into little tiny “chunks” and then handed off to others.  Some (though certainly not all) of these consultants and managers from larger projects are so uncomfortable with the pace and demands that they spend more time making excuses for lack of results and look for others to blame. The idea of delivery “ownership” over an entire area is a foreign concept to them.  Some of these consultants from larger implementations, with slower paces and many layers of coordination are lost without someone managing each tiny aspect of what they do.

~~~~~~~~~~~~~~~

[FN1] In fairness to the other consultants who thought this could only be done through ABAP custom coding, it does require a major amount of setup in SD, MM, FI, and EDI to work correctly. While it is all standard functionality, consultants with experience on very large projects have limited exposure to even their own module of expertise. As a result it is unlikely that the full breadth of this and other functionality has been seen outside of the small and midsized business space. In the small and midsized business space the consulting teams are smaller, and out of necessity are more knowledgeable within their module area, and because of the integration requirements with other modules they tend to gain greater application exposure to standard functionality options.

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

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:

• Industry Specific SAP Consulting vs Deep SAP Application Experience
• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Using SAP to Improve Revenue and Profitability
• More on Stupid SAP Vendor – Partner Selection RFI-RFP Processes
• How “As-Is” Process Mapping Can Damage Your SAP Project

SAP Project Insight

This is a continuation of the previous post which addressed early requirements for good SAP project management (see Effective Results from SAP Project Managers – SAP Program Managers).

SAP Project Management Responsibility

A manager’s primary responsibility, above all else, is to ensure the success of those they are responsible for managing.  Overall success of any initiative is directly tied to the success of those responsible for delivery of that initiative.  This is especially true in fast paced, moderate to large scale SAP projects.  If your reports succeed then you as a manager automatically succeed.

An SAP project manager or SAP program manager must focus aggressively on removing obstacles, encouraging success, and fighting against those things that would impede momentum.

Once again, I will re-emphasize:

I don’t blame client project managers because if they had all of the resources, skills, and experience, they would not need outside help.  These posts are focused on contracted help who are supposed to ensure your success.

What can SAP Project Managers or SAP Program Managers Do to Help Ensure Success?

One of the first requirements of a contract SAP project manager is to build momentum.  Once momentum is built that contract SAP project manager or program manager must do everything possible to sustain that momentum.  Some of the things which help to build, sustain, and then manage momentum include:

• An articulated obsession with building and maintaining momentum.
• Activities, tasks, responsibilities, and value added tools are defined ahead of time and not made up in real time.
  • People must understand what is expected of them – project requirements in the form of deliverables, tasks, and timelines are communicated early in the project and reinforced *before* transition points throughout the project.
  • These “expectations” must be laid out early in the project, throughout the entire project lifecycle (beginning to end) and have proper transitions built into the planning.
• Tracking mechanisms must be simple, easy to understand, and easy to manage.  Overly complex or involved tracking mechanisms destroy momentum and “cloud” visibility into progress.
  • Work efforts are relatively evenly distributed (resource leveling) and across all project participants (although lengthy these are very informative posts, see Reduce SAP Project Stress: Part 1 and Reduce SAP, ERP, or Technology Project Stress: Part 2).
  • No resources are allowed to be overloaded unless every available project resource is overloaded.
• During blueprint emphasis is focused on design that will enable execution, if it doesn’t enable execution (or Realization) it is a waste of time (see  How “As-Is” Process Mapping Can Damage Your SAP Project).
  • Project emphasis must be on execution – execution builds momentum.
  • There is an emphasis on coordinating activities rather than administrative overhead–, some administrative overhead is necessary but only to the extent that it directly supports execution).
  • Project management is actively and directly engaged in coordinating execution activities beyond checking off spreadsheets.
• After blueprint emphasis moves to execution over design.  Areas where design continues to be evident must be aggressively managed so that design only supports directly executable activities that are in scope.
• Risks to success are identified and mitigated throughout the project.
  • Issues, risks, decisions, or other obstacles to project success are regularly captured and worked to resolution.
  • Periodic QA reviews at appropriate milestones or intervals.
  • Obstacles to activity or execution are aggressively managed (with few exceptions there is no “we can’t do ‘x’ until ‘y’ is perfect)

Do You Have a “Slick Politician” or a Real SAP Project / Program Manager?

There are unfortunately too many politicians in the project manager ranks and too few “straight shooters.”  Project manager politicians are destructive to morale, on-time delivery, and are dangerous to budgets.  However there is a measure of diplomacy that is required so how do you know when you have a political SAP project manager or SAP program manager rather than a skilled and talented one?

A manager’s primary responsibility, above all else, is to ensure the success of those they are responsible for managing.

Think about that a minute.  If a manager’s primary responsibility is to ensure the success of those they are responsible for then what would be a sign they are not a good contract project manager?

If your reports succeed then you as a manager automatically succeed.

The worst kind of project manager is the one who will “throw others under the bus” to deflect from their own shortcomings.  They demoralize and discourage project team cohesiveness while crushing momentum.  They create an environment where people do not want to do anything at all for fear of becoming the next scapegoat.  When things go well they are the first in line to take credit for what went well (even when they weren’t involved).  They lack integrity and character.  They spend more time and effort trying to cover their own back side than on trying to ensure the project is delivered successfully.  If you see these signs in your contract project manager you should seriously consider firing them.

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

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 Success Factors for Vendor Selection – Responsibility Matrix 1
• Reduce SAP, ERP, or Technology Project Stress: Part 2
• Toward an SAP Center of Excellence or SAP Competency Center – PART 3

SAP Project Success

In all the years I’ve been involved with SAP I’ve often puzzled about what makes a really good project rather than some of the freak shows they call SAP projects.  After involvement in over 20 SAP projects I’ve seen a few of them go really well, a few that were more like horror shows, but most were mediocre.  I’ve often asked myself “Why?”  What makes the difference between a good project and one that is nothing short of a mess?

One key item that stands out is project management.  Even with the most talented and dedicated resources bad project management can ruin an otherwise great SAP project.

I don’t blame client project managers because if they had all of the resources they would not need outside help and guidance.

Before I get into this, let me define what I consider a “good” project.  A good project is one where there is a lot to do, but the stress level is not intense.  The timeline may be tight but it is achievable (maybe a little bit of a stretch).  The project is delivered on time, on budget, within scope and the result is high quality (a fairly smooth transition without a chaotic go-live).

Methodology Considerations for a Good SAP Project or SAP Program

The list below is from a synthesis of materials from SAP’s ASAP methodology, the PMI (Project Management Institute), and my personal experience over the years.  Much of this is contained in the SAP ASAP methodology in one form or another so you really have to wonder what any consultant is following if they claim to use it and these items are lacking.  In fact the latest ASAP Methodology version 7.1 includes a project start-up checklist to ensure key components are addressed.

Unlike several years ago when contract project managers had to rely on experience alone – the SAP ASAP Methodology is well-proven and mature today.

There are several key characteristics of a well managed SAP project which includes:

Early SAP Project or Program Management Activities (Before the Overall SAP Project is Fully Underway)

• Success criteria defined and communicated for the project.
• One of the first things that is defined for the project are the key roles, responsibilities, and tasks that will be performed by each participant group in the project.
• A clear, definitive project plan with WBS elements, networks, and activities planned for every major work-stream throughout the entire timeline.
• A clear list of deliverables, milestones, templates, and instructions on their usage are provided for the entire project.
• Deliverables are clearly tied to project value rather than useless administrative exercises (value added activities) (see SAP System Vendor Project Success Criteria & Factors 1 scroll down to Sections 8 and 9).
• Scope, time, issues, risk, cost, communication, and integration management plans, together with additional key components are defined.
• Various standards for the project are defined and documented, including but not limited to business process, development, configuration, enhancement, transport management, testing, etc.

If you are using outside contract project management resources and  these items are not substantially in place by the time you start your project you will likely have your timeline and budget destroyed.  Along with the blown schedule and budget your project will also be a pressure cooker filled with stress, anxiety, and frustration. These are also characteristics you find when an SAP project manager or SAP program manager is not qualified.  The chaos, tension, stress, and confusion caused by their inability to coordinate the many moving parts of the project are a direct result of their lack of experience and ability.

I don’t blame client project managers because if they had all of the resources they would not need outside help and guidance.

The project should be delivered on time, on budget, within scope and with high quality…

Conclusion on Effective SAP Project or Program Management Practices

You are headed for a project disaster when a contract SAP project manager or SAP program manager fails to ensure the following items are in place early in the project:

• responsibilities by group and role are defined,
• deliverables are well laid out,
• templates are properly prepared,
• forward looking expectations are set,
• coordination occurs between all project groups,
• etc.

I’ve only ever been on a few projects when the SAP project manager or SAP program manager failed to produce a properly detailed project plan.  Every one of those projects had one thing in common, they were absolutely horrendously stressful, difficult, and took more time and cost more than necessary.  Along with the failure to produce a proper project plan the lack of proper deliverables, proper roles and responsibilities, and all of the other things a good project plan would help you define were also missing.  If this happens to you FIRE those contractors, you are being bled dry and are headed for a budget and timeline disaster.

For much more detail on what happens when you have bad contract SAP project managers or SAP program managers see the post Some Reasons SAP Projects are Over Budget and Over Time.

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

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 Project Manager – SAP Program Manager, Lessons from the Trenches
• SAP System Vendor Project Success Criteria 1
• More on Vendor Selection Criteria and Methods for ERP Project Success