SAP ROI — Enterprise Architecture & Business Solutions

Software modifications must be discouraged but sometimes they make perfect business sense. Remember, software exists to support the business, not the other way around.

As an inexperienced project leader back in the 1980’s, I once informed an executive at a large aerospace manufacturer we were going vanilla with our enterprise software implementation. Absolutely NO software modifications or enhancements allowed I proclaimed! His response stayed with me and still rings true today…

“Steve, you mean to tell me we are going to allow a one million dollar software package dictate how we run a fifteen billion dollar business?” I was lost for words. Finally I said, “if we modify the software, future upgrades could be more difficult to implement”. His response “so what, I need to run my business”.  The lesson is…..you need what you need. Software is intended to support the business, not the other way around.

Make no mistake; if you can really go vanilla do it. I am not encouraging software modifications because they take time and cost money. However, regardless of what the sales people tell you, no software package is infinitely flexible and configurable. At the same time, we all know software must address the key business requirements. This “zero tolerance for modifications” philosophy is fine for those that do not have to live with the software limitations. So what is a project manager to do?

In many cases, software modifications are not a huge deal when properly controlled and managed.  After all, no one writes a single line of custom code until at least the project manager and the executive sponsor say so. In other words, proposed modifications should be well defined, business justified (vs. alternatives) and then approved by senior management (with a full understanding of project impact).  When executives approve a mod in this manner, they have made a conscious decision to expand scope, incur additional cost and extent the project schedule. There is nothing wrong with this since they did it for good business reasons.

The religion that software modifications are universally evil comes mainly from the software industry. In fact software vendors can make you feel like a criminal when you sheepishly tell them you modified the software (dumb old me). The reason is vendors want clients to upgrade their software and do not want mods or anything else to get in the way. The idea is to sell the client related software and plenty of consulting services with each upgrade.

While software modifications increase the difficulty of software upgrades, in many cases this issue is over-blown. This is particularly true when keeping the number and complexity of mods under control. First, whether we like it or not, many organizations never upgrade their software. Others may do it only once over the entire life of the system. Also, there are upgrade tools available today that make the process of retrofitting custom code much easier. Finally, do not assume the promise of future software functionality will replace the need for mods. Even if the functionality is delivered, do not be surprised if mods are required to make it work for your organization. Software vendors use buzzwords to describe functionality but when you take a hard look; many times the functionality doesn’t go far enough.

I will not discount the fact that some software vendors refuse to address customer issues associated with modified programs, and for good reasons. However, most vendors will assist when the issue is critical and push comes to shove. Also, keep in mind that some vendors will fully support custom modifications as part of their business strategy. Furthermore, the risk of compromising support from the vendor becomes less of an issue when enhancements are designed to minimize the impact on existing code and tables. Finally, no custom code should go into production unless it is thoroughly tested and then tested again (and maybe again).

Always schedule and budget with the understanding that some mods could occur. Do not have a line item called “software modifications” (this is politically incorrect and sends the wrong message-again no one is encouraging mods). Bake it into miscellaneous, contingency, or related project line items.

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

Editor’s Note: 

Steve Phillips runs another blog at the IT Toolbox and offers some really great insight on doing technology projects.  Visit his site for more info.

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

Related Posts:

• Using SAP to Improve Revenue and Profitability
• Achieve Breakthrough ERP, SAP, or IT Project Success: 1 of 4
• Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP
• Competitive Pressures and Value Propositions, Is Lean the Answer?
• ERP Business Case: Do You Really Need a New System?

Series Introduction Note:  The next 3 parts of this series contain step by step instructions and pointers on managing the RFP process (Part 2), conducting the vendor selection (Part 3), and then how to use the blueprint process to correct any discrepancies and lay a solid foundation for succes (Part 4). 

If you are an IT decision maker and you’re tired of pressure to achieve results that your system vendors or integrators can’t seem to deliver, use these steps to get the most for your money and achieve breakthrough results. Much of this article can be applied to any major project effort your company undertakes.  While some of the suggestions offered here can seem harsh or difficult from a people management perspective they can make a huge difference in your career prospects, credibility, and any future budget requests. 

Neutralizing the vendor proposal scams, clearing the smoke and looking past the mirrors for your ERP, SAP, or technology project requires a little clarity up front before you start your vendor selection.  It is possible to achieve breakthrough business results using technology and business software systems like SAP if you approach your project with the right perspective. 

That Brown Smelly Stuff they are Selling is NOT Chocolate

Promises, promises, sales scams, smoke, mirrors, and vendor proposals, you’ve heard it all before–, the sales pitches promise you a chocolate pie but all you get is some very expensive, and very smelly, dark brown fertilizer.

What these sales pitches never tell you and never deliver on is the “how” to make all of those chocolate pies.  As former General Electric front man Jack Welch calls it “the secret sauce.”  Sure, they describe some super-special secret sauce, they tell you all about their wonderful “Willy Wonka Chocolate Factory” but they only describe a fictitious place, an imaginary state of being. 

Fairy Tales and Vendor Selection Promises

I’ve been on lots of projects where someone dreams up what I call “mutually exclusive requirements.”  These are things that are completely contradictory, they are the old “either / or” logic gates.  You can have one, or the other, but you can’t have both.  Lots of presentations have the sales person delivering tons of promises that no one can deliver on.

Then reality sets in after you’ve signed the contract and the sales person leaves.  A strange odor begins to permeate the whole project.  But this usually happens very slowly over time so that you go through the “boiling frog” syndrome.  You smell a little here and a little there, but like most people you get used to it and think this is just the way it is.  You dismiss early signs that there may be something wrong, or you chalk it up to isolated incidents.  After you transition to a live environment and it is too late you suddenly realize it was not a chocolate pie you were getting but something else that is brown and smelly. 

When someone on the project has to deliver on the sales person’s promises some members of the vendor selection team are no longer involved in the day to day project delivery of those sales promises–, even if they are they often forget everything that was promised.  They only remember a few of their pet peeves they saw or heard during the presentation.  When the sales person describes lots of what sounds like chocolate you end up with lots of brown smelly stuff that is NOT the chocolate you were promised!

After the sales pitches and the promises what you end up with are blown technology project budgets, blown technology project timelines, and buggy custom-coded solutions for “off the shelf” packaged applications.  Fear not, there ARE things that can be done to reduce these results that are so very common with technology projects.

And even if you are misled by a vendor there are still things that can be done after you start with that vendor to ensure you don’t get taken.

SAP, ERP, and Technology RFP – Getting the Most Out of Your Technology Investment

There are several opportunities in early stages of your SAP, ERP, or other technology project to lay the ground work for genuine breakthrough results.  Along with the breakthrough results these early steps can help to set the tone and foundation for a very successful on time and on budget project.  There is just no reason for companies to continue to get taken by some of the unscrupulous or questionable practices in the technology and IT marketplace.

Even after you have selected your system integrator or implementation vendor you still have several chances to make sure they deliver their very best–, the very best tools, resources, and quality of workmanship.  If you change out questionable consultants early in your project then you will set a clear expectation of the caliber and quality of resources you will accept from your vendor.  Doing this early is the best time before they can do any serious damage.

General Patton once said that “War is Hell!” and business in today’s global economy is WAR!  The question you need to ask yourself is if you are in a war in the marketplace do you want raw recruits who are going to go through boot camp at your company, on your dime?  Or do you want veteran Navy Seals, Marine Snipers, and Airborne Rangers?  Raw recruits are usually cheaper, and that experience from those veterans comes at a cost, but who do you think will give you the best chance of winning the war for marketplace position?

Let me tell you, that Marine Sniper will hit his targets at 1,000 yards, but the raw recruits will not only miss, but in doing so will also give away your position and open you up to attack.  So in the end you decide which is more important.  You decide if it is better to take your chances or to take steps to make sure you’re not paying Navy Seal prices for raw recruits.

There are three key events or timeframes early in the project when you can create the best environment for breakthrough project success.  Two of these areas have no risk and at all and one of them contains a moderate amount of risk.  These three key events are:

1. During business case development, RFP creation, and first pass rough project scoping.
2. The actual vendor selection process, vendor proposal reviews, and system integrator contract.
3. During and at the end of the blueprint process.

These key events contain several ways you can take control of your own business destiny and help to ensure the technology investment you make will move your business forward.

Four Part Series:

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

Related Posts:

• Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP
• Breakthrough Project Success: 3 of 4, Vendor Selection and Contracts
• SAP Reimplementation for Little More Cost than a Technical Upgrade Part 2
• SAP Reimplementation For Little More Cost than a Technical Upgrade Part 1
• SAP Implementation Partner or Company Selection Criteria

We won’t cover a detailed breakdown of RFP sections or RFP strategies but we will hit on some of the high points.  These high points together with a few ways to neutralize some of the vendor sales strategies can help to ensure you are getting the very best vendor or resources for the job.

This stage is probably the most intense for any company considering a technology project.  There is a lot of preparation to get a solid RFP that can set the stage for breakthrough results and solid payback for your technology investment.

The key foundational activities for a good RFP include a solid business case, a clear statement of scope and then the development of the RFP itself.  Some guidance can be found here in this article on and ERP and SAP business case for ROI, business benefit, and success.

What Type of IT Vendor, System Integrator, or Implementation Model

One other thing to consider during the RFP process is what type of vendor or implementation model you are looking for in your proposal.  There are a number of vendor options and each has their strengths and weaknesses but a review of the pros and cons of each is for another day. 

You may wish to employ a well established system integrator; a “boutique” consulting firm; or completely manage the project with your own selected staff of contractors; or you may want to consider a hybrid approach.  If you are considering the contractor route, of staffing a project yourself, you might wish to review the screening methods to find the right consultant Part 1 and Part 2.

You will also need to determine your project implementation model.  Will you do a pure time and materials approach, or fixed fee, or time and materials with penalties for under-delivery (over budget, over time) and rewards for over delivery (under budget, early), or time and materials with cost controls, or a blend of some of the approaches.

You may wish to include the characteristics of the experience of the consultants you want in your RFP as well.  For example you might insist that you want the team leads to all have small and mid-sized business (SMB) implementation experience and they should have done production support work.  Why are those important?  In my experience the SMB consultants have the deepest module and troubleshooting experience.  Consultants with production support experience understand ahead of time some of the problems a company will face after go live and can address it during the implementation portion of the project.  This site has several articles related to the important considerations around go-lives.  At the end of this post I’ve included a list of articles from my experience doing production support about the areas I have seen over the years that cause the most pain after you go live. 

Since consultants will be guiding your business, dealing with sensitive company information, and helping to set a new direction and focus, it is important that you are getting the consultants you are paying for and not the fakes, frauds, or con artists that are out there.

Dealing with System Integration Vendor Proposal Methods

Bigger system integrators tend to rely on the “wow” factor of fancy customer lists, huge size and scope, and other factors which may not always translate into a better solution for your business.  In the end, you have to ask yourself, what really matters to you as a company?  Is it flashy presentations that show off how great the vendor is, or is it the ability to deliver real results for your business with the people they bring to the table?  Sometimes it will be the large vendors or system integrators, but sometimes it won’t be.  The real question then is how do you make sure you are getting what you pay for whether it is one of the “Big X” vendors, a smaller boutique firm, or even staffing and running your own project?

Here are some steps you can take to help neutralize some of the sales pitches and focus on what really matters–, which vendor can really deliver the best results?

1. Determine in advance a list of business requirements you want the technology spend to address.  These should become the basis for your whole project, the guiding reason for the technology spend.  Understanding the business goals which are behind any of your company KPIs is important to help focus technology investment.




2. Develop a rational scoring protocol that addresses how well a vendor adhered to your RFP, scored section by section, and weighted to what is important for your company.




3. Set a slide presentation limitation.  Say, no more than 50 total slides for the actual presentation and no more than another 50 slides for an Appendix of supporting information.  If a vendor is unable to capture the important items to your company and its results (rather than touting how great they are) in 50 slides they may not be the best fit.




4. In your RFP it should be spelled out explicitly that customer qualifications and customer references can ONLY come from the specific resumes of the consultants being proposed for the project.  Ignore all the “gee whiz aren’t we special” because we have so many great customers our company has worked with.  If the customer list doesn’t represent the skills and talent they are proposing for your project, why do you care who else they have done business with?  You may also wish to note that any deviation from this will be scored harshly after all, who really cares if they have worked with every one of your competitors if none of those consultants will be working on your project?




5. During the Vendor presentation require an actual demo of some of the system functionality.  This will help to ensure that they vendor is bringing actual knowledgeable consultants to the proposal because they will have to take the time with some of their internal resources to be able to set the demo up and to have some of their knowledgeable consultants on site to show you the system functionality and to answer questions. 




6. Ensure that the vendor provides the implementation tools and samples of each of the templates and resources they use for the project.  Offer to sign an NDA to eliminate any of their arguments about “proprietary” information.




7. Include a provision in the RFP that unverified or unverifiable claims of business benefit will be scored harshly.  You may wish to note in the RFP that if a statistic or a reference to benefit is noted anywhere in the vendor’s presentation, whether on paper or during any oral presentation that it must be supported by an authoritative or verifiable source otherwise including it will be scored against them.  Unfortunately it is a routine practice for vendors to “promote” questionable or unverifiable “results” statistics and throw numbers around to try to persuade you.  The practice is fine so long as it is legitimate.  If a vendor claims they helped company “X” gain “Y” benefit then insist that you need a verifiable source for BOTH the benefit and for how the baseline for the benefit was established and then how the change was measured.  You may even wish to include such a provision in your RFP to the vendor so they know up front what your expectations are for their “claims of superiority.”




8. Make it a requirement that the system integrator or staffing firm provide an affidavit attesting to verification of consultant skills and background.  A lot of attorneys can draft a sound verification affidavit covering the due diligence used for screening project resources.  If you are a public company your executives have to sign off on financial statements under penalty of the Sarbanes-Oxley legislation (in the U.S.) so you might as well have your implementation vendors do the same.  If they won’t do solid background checks or verifications why do you want them at your company?




9. Have an explicit contract provision that your implementation vendor may only provide contract resources from the vendor’s direct staffing partners.  That contract agreement should spell out that those staffing partners may not use additional staffing partners more distant.  The reason is that as you move further away from the immediate implementation vendor, and as each partner takes their “cut” of the rate, you end up with more and more fakes.  After you begin to move further away from your prime vendor, everyone’s “cut” begins to reduce the final rate to much less than a normal market rate to the end contractor and any contractor with real experience will only go so far in rate concessions even in a down economy.  As a result you only attract fakes, cons, and liars.   




10. Include a provision in the RFP that asks the vendor to describe their process for handling less than ideal or less than optimal consulting resources.  Be sure that provision includes specific language noting that you would like to know their approach and policies on credits as well.  In this provision of the RFP make it explicit that this section will be scored heavily so that it may affect the overall decision process if the policy is not adequate.  You may even wish to go so far as to note that even if the vendor scores well they could be disqualified for not having a reasonable policy here.

The idea with this and all of the other tactics and techniques you intend to use is to set a clear expectation about the quality of the resources the vendor provides and the quality of the project you expect.  By doing things like this from the beginning and carrying them out throughout the early stages of the project you will set the stage for success and have the greatest opportunity to achieve breakthrough results with your technology investment.

For obvious reasons there is a heavy emphasis on getting the right resources.  After all, the people delivering the project and influencing or affecting the direction of your business are more important than the vendor behind them (so long as that vendor is reputable).

After developing your RFP the next stage is to determine the list of vendors you wish to submit to.  And you may even wish to throw in a couple of “wild cards” to the normal vendor selection just to get a different perspective from another type of vendor on how they would do your project.  The more knowledge you gain early in the process the more sophisticated of a client you will become.  The more sophisticated you are as a technology customer the better your results will be.

For those breakthrough results ask yourself what is important to you as a business, and what you believe you need to achieve that.  Be sure to build those expectations into your RFP somewhere and score them accordingly.  In the end what really matters in all of this is are you getting what you expect?

Some of the Biggest Production Support Problems with your SAP Project to Avoid:

Planning For a Smooth SAP Go-Live: Part 1
http://www.r3now.com/planning-for-a-smooth-go-live-part-1
(introduction, security and authorizations)

Planning For a Smooth SAP Go-Live: Part 2
http://www.r3now.com/planning-for-a-smooth-go-live-part-2
(master data, data transformation methods)

Planning For a Smooth SAP Go-Live: Part 3
http://www.r3now.com/planning-for-a-smooth-go-live-part-3
(process issues, blueprinting, testing, and change management)

Planning For a Smooth SAP Go-Live: Part 4
http://www.r3now.com/planning-for-a-smooth-go-live-part-4
(custom development, costs and consequences of inexperienced developers)

Four Part Series:

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

Related Posts:

• Achieve Breakthrough ERP, SAP, or IT Project Success: 1 of 4
• Breakthrough Project Success: 3 of 4, Vendor Selection and Contracts
• Competitive Pressures and Value Propositions, Is Lean the Answer?
• SAP Reimplementation for Little More Cost than a Technical Upgrade Part 2
• SAP Reimplementation For Little More Cost than a Technical Upgrade Part 1