My first post of the SAP Retail Lessons Learned series, I provided some background information on the SAP Retail implementation project that will be used as the primary reference for the lessons learned. I also listed a few over-arching themes for the entire series as well as major Lessons Learned categories that will be featured in upcoming posts.

In continuing my series of lessons learned with SAP Retail I would like to cover the topic of Client Resources and Planning. Again, in general many of these lesson I have learned could be applied to any project and I can easily draw parallels from other SAP industry solution implementations that I have led in the past. I will do my best to highlight where I think there are specific retail differences.

There Are Never Enough Client Resources

This is the case on almost any large-scale project, not just SAP projects. It impacts smaller organizations and it impacts retail businesses more because they tend to run leaner IT organizations. So you might be saying to yourself, “big deal; what project not funded by the government doesn’t have enough resources?” This one point however might be the most important one I make in this series.

Think about it. In a new SAP Retail implementation you are going to completely replace the core of your IT business systems. This typically impacts all aspects of your business; Finance, Store Operations, Merchandising, and Warehousing. It typically reaches outside your organization and impacts your Business Partners as well. So how do you fix resource problems? As a leader, and I am specifically talking to the CEO (or your organization’s equivalent) here, because he/she is the only one that can make things happen on the resource front. CEO’s, you need to engage the entire business in this process in a meaningful and organized way from the project’s inception and kick-off all the way to go-live and post go-live support.

I know from experience that this kind of ideal C-suite-to-IT alignment does not always occur. My uncle was the president of a division of Honeywell that implemented SAP. I can remember talking with him about his project and being a little frustrated with him. He knew the project was important and impactful but from the language he used I could tell that he did not grasp the significance of the undertaking that an SAP implementation demands and that more overall focus and dedication from the organization as a whole would reduce the time required for the business to successfully adapt to the new system.

Don’t make this mistake in your implementation; engage the best of the best in your organization on the project, and engage the entire organization in meaningful ways throughout the entire project. The more exposure and input people have doing the implementation the easier the transition will be. Always remember, there is no such thing as “cutting corners” in SAP implementations (or any SAP project for that matter). You always end up getting as much from your SAP system as you put into it. Settling for adequate resources at bargain prices will do two things: cut immediate resource overhead costs and produce an adequate SAP system for your business.

Client Management Expectations For Their Internal SAP Resources Are Always Unrealistic

OK, so this is not specific to Retail; it is a recurring theme from all my SAP project exposure.

• First point: unless you have implemented SAP before you and your resources will automatically underestimate what it is going to take to get the job done.
• Second: don’t expect seasoned IT resources to work an SAP implementation and come out of it completely capable of supporting the system on their own after go live. One out of ten will be able to fly solo after go live,  the rest will need assistance for sometime in the future. (By the way, the ones that fly solo need to be rewarded significantly, if not they will be consultants within 12 months)
• Third: look at what you are asking of your resources. If you have them working on business requirements, functional design, test planning, test script creation, test execution, training, etc., do they really have the capacity to do any of these activities simultaneously while maintaining high-quality output? Engage more of the business and spread out the load. After all, implementing SAP is a business commitment, not an IT department commitment. I will make recommendations in other sections on where you can engage more of the business.

There Is Never Enough Time For Knowledge Transfer

Knowledge Transfer (KT) is an activity that is always held high at the beginning of the project but it is the first part of the plan and budget to get absorbed when things don’t go as planned and it is never replaced. In addition, it is never given proper consideration, planning, and execution like any other phase of the project. Failing in KT can potentially squander all the effort and investment you’ve put into an SAP project; new technology has ZERO value if your business users are not proficient at using the system. You should treat knowledge transfer planning and execution just like testing, with specific goals, topics identified and capacity planned. It should also be spread out thoughtfully across the duration of the project. Expectations / level of KT expected also needs to be clearly communicated to both the consulting team and internal team. You need to have realistic expectations here. At the end of KT, your internal resources (especially if new to SAP) will not be able to do what your consulting team can. Knowledge transfer is often approached using the “fire hose” technique. SPOILER: it does not work.

Fire Hose Technique –  Tasking several of your senior SAP consultants to simultaneously knowledge transfer to the same beginner SAP client resource via a two week brain-dump.

There are very few people that can effectively learn this way. Genuine knowledge transfer can only truly be achieved through doing, not watching or listening. Engagement and participation throughout the entire project lifespan will lead to knowledge transfer organically. The most effective way to execute knowledge transfer is to plan a PPS (Post Production Support) phase that keeps the consulting team engaged – some full time, some part time, and some as needed. This will enable the transferring responsibility and knowledge overtime. It is important to understand you will need to push the internal team here, you want the consulting team as a safety net not a crutch.

Client Resources Can Cause Delays Too

OK, now it’s time for me to call out all my clients from the past. This is more of a universal lesson learned but it especially applies to SAP Retail projects. Consultants and consulting teams are not always responsible for project delays. It is our job as consultants in most cases to take the heat and blame whenever deliverable dates are missed; that is part of our job function and it comes with the territory. What sort of things am I referring to? Information needed by the project team needs to flow quickly, and there is often information and tasks that extend outside of the identified SAP project team. It is important that from the top down those tasks are given priority and accomplished with a sense of urgency from Day 1. Oftentimes, teams have to push ahead making assumptions and then have to backtrack to fix wrong assumptions once they receive the information from the business. Good consulting teams never sit around twiddling their thumbs while waiting to receive all the information needed; they assume leadership and use good judgement to help their client be successful.

It is also important for SAP project leadership to monitor for “Analysis Paralysis”. While some consultants can be susceptible to this it is more often the client resources that come down with this serious condition. “Analysis Paralysis” is the most common reason projects get delayed. If you have unlimited budget then go ahead and try and think of everything. Otherwise you need to quickly review the information you do have, pour on some assumptions, and move forward. You will learn more as you progress through the project and can always go back and refine those critical things that you have missed. Prototyping and pilots give you more opportunity to move forward more quickly with an approach that can be refined as you get smarter.

One last point on client resources delaying projects: do not put procrastinators on your SAP Project team. You need to put your resources that hit the ground running and do their best to stay ahead. The average SAP project costs 16 million dollars. This is a pretty significant capital investment for any company. All it takes is one procrastinator in one area of the project to slow down the efficiency of the entire team.

So I got derailed a bit at the beginning of the week so I am behind schedule on my topic list.  I will do my best to cover planning this evening and post sometime tomorrow to keep on track.

Be on the lookout for my next post, which will Lessons Learned for the Planning phase of an SAP Retail project. The remaining schedule is as follows: