George Anderson explains several systemic issues behind why SAP project and support teams keep re-living the same mistakes year after year and then provides several measures and actionable next steps you can take to remedy the problem.
Key Concept
Several systemic issues help explain why our SAP organizations are often destined to repeat past mistakes. They range from organizational memory lapses to cultural dimensions and workplace realities.
John Dobbins and I recently outlined
the top 10 worst ERP practices that continue to be made year after year. In talking through this matter with other colleagues and customers, it seems that several systemic issues are at work, including degraded organizational memory, distracted work teams, and the absence of effective knowledge management. Behind the scenes, there are additional cultural or workplace climate factors that help explain these memory lapses and subsequent missteps. I outline these factors and bring them together in a way that allows for a bit of introspection, better awareness explaining why SAP IT and project teams keep repeating the same mistakes throughout the years, and specific actions intended to conquer this cycle of missteps.
Reason 1: Poor Staffing Continuity
I continue to see SAP project, development, Basis, and other support teams forget hard lessons learned. It’s not that the teams themselves are making the same mistakes over and over. Instead, many of these teams insist blindly or otherwise on recreating the wheel. So it’s really in the absence of learning from colleagues and others who have gone before us that we find ourselves repeating history.
Poor organizational memory is partly to blame. Lapses in organizational memory can be traced back to the fact that we no longer remember why we made the decisions we made. Why did we choose to deploy a single production instance of ERP? Why did we customize our warehouse functionality so heavily, or implement a particular third-party tax solution? Why did we choose to run Oracle’s database on Windows Server, fail to ensure staging reflected our production environment, or introduce Salesforce CRM instead of staying exclusively with the SAP Business Suite?
It used to be that you could walk downstairs and talk to Jane about your SAP BI instance strategy, or catch TJ in the hallway and chat about your infrastructure choices, or find Meghan in the cafeteria and hear all about your historical warehousing challenges. However, they’ve all moved on to greener pastures, retired, or been dismissed, and their replacements simply don’t have the answers. This in a nutshell provides context around the first systemic issue explaining degraded organizational memory: we haven’t retained the people involved in making past decisions.
This lack of “people continuity” plagues not just SAP technical teams but many large organizations today. Pressures to reduce SAP support costs through personnel reductions, forced early retirement, and replacement of expensive in-house resources (through internal turnover, outsourcing, offshoring, and transitioning work to inexperienced or disposable contractors) have drained organizations. Pressures to insource (bringing IT back in-house again to regain agility and control) followed more recently by pressures to “optimize” financial models through cloud services (sending IT back out to be managed by a cloud service provider) are further eroding institutional memory. Every swing of this SAP and broader IT staffing pendulum effectively clears our institutional RAM and reboots our SAP teams and business units. It’s almost as if every few years we welcome back the 1980s and start all over again with the organizational equivalent of a blank screen and a blinking cursor (see
Figure 1 if you were born after 1995).
Figure 1
Organization pendulum swings wipe institutional memory
Reason 2: Squirrel!
Second, in the midst of our organizational pendulum changes, our ERP project and support teams are more distracted than ever. I call this “organizational squirrel syndrome” (with props to the Disney/Pixar movie “Up”). We’re too easily distracted by the latest strategic initiative (deploying new on-demand analytics capabilities), the hottest technology trend (retiring tier II storage area networks in favor of cloud storage), or the must-have project of the day (introducing HANA and other in-memory platforms).
Leaner than ever, SAP Basis, development, and other support team skeleton crews are being asked to deliver more and more value with fewer and fewer people. Tight resource budgets, constant reorganizations, and fewer people wearing a greater number of hats have created a landscape where we simply don’t have the luxury or the attention span to do everything well. And here’s the scarier thing: after more than a decade of cost cutting, financial crises, mergers, and fundamentally changed business models, we’re used to it.
Reason 3: Poor Knowledge Management
Finally, to make up for all of our staff continuity issues, we should have been investing in and intentionally using effective knowledge management tools. We should have been capturing the “why” behind key decisions, noting which options were explored, and tracking why we made certain tradeoffs or compromised on certain decisions. In many cases we didn’t. No one ever seemed to have the time nor realized how important it might be down the road. We shirked that responsibility and its costs, hoping for the best, and ignored lessons learned. It’s no wonder we keep seeing history repeating itself. With little to no organizational consistency or record of events, and no friendly shoulders left to tap, we’ve forgotten how we got to where we are with regard to our:
- Business challenges (what business problems were we initially trying to solve?)
- Solution decisions (how were potential business solutions evaluated or weighted, and why were certain options selected and others discarded?)
- ERP technology platforms and infrastructure (what was considered, and how did we arrive at the mess we’ve got in place today?)
- Key architectures (what decisions were made relative to business, enterprise, application, data, technology, and solution architectures, what was actually decided upon, how was it all implemented, and where is it all documented?)
- Risks (what risks were identified and how were they managed, enhanced, shared, transferred, mitigated, eliminated, and so on?)
- Workarounds (where and why were tradeoffs necessary, and why did they make sense at the time?)
Our past missteps have gone a long way towards affecting what we value, how we operate, and how we change as an organization. But it’s exactly these things that often cause or contribute to our missteps. To avoid making the same mistakes over and over, we need to change what we value or what’s important to us. And that means changing our behaviors and standard operating procedures – our very team or organizational culture, covered next.
The Culture Snail
Organizational culture is a tricky beast. It changes and evolves over time, but typically does so very slowly – like a snail’s journey. Snails are simple and slow but nonetheless nearly unperceptively move from one place to another. They are amorphous, changing shape throughout their journey. They leave a messy trail, not unlike the customs and behaviors that organizations throw off as they themselves change. Like any living creature, snails adapt or wind up on a plate.
Snails also yield lots of baby snails, analogous to organizational culture’s team-oriented “workplace climate” baby brother. While some teams become very different from their parent organizations, most teams ultimately form a basis for homogeneity that from a distance reflects an overall organization’s culture. This culture changes little by little as new hires are onboarded and others leave.
The culture snail analogy is powerful in its simplicity in that it reflects the “what” over many successive points in time – what the organization ascribes to, what it believes in, what it does, the processes used to prioritize what it does, and the processes used to create a record of what’s been done. The “what” therefore includes:
- Leadership, in terms of vision, goals, values, and overall leader behaviors
- Values and biases, including what’s important in terms of behaviors (what’s displayed for all to see) and what’s bubbling below the surface (internal attitudes and biases for or against Oracle, Windows, outsourcing, development paradigms, the cloud, and so on)
- Capabilities, or what the organization does for its customers to create value and sustain itself (every team has a customer…)
- Prioritization, specifically the processes used to determine the sequence of what is to be done (from strategic transformation initiatives down to specific SAP upgrade projects, introducing new business functionality, incorporating new applications and bolt-ons to facilitate new functionality, automating ongoing operational tasks, and more)
- Knowledge management, including the processes used to learn and record that learning alongside ideation methods, innovation perspectives, and views on education and training
Though all of these are important, knowledge management is often an afterthought if it makes the list at all. But consider this: When we forget who we are, why we do what we do, and how we got here, the context surrounding the other dimensions is lost. Imagine the needless time and energy spent as executive commitment ebbs and flows on an ERP implementation, or as performing holistic SAP functional testing, improving master data management, enabling new access methods, building culture-sensitive teams, encouraging time off, increasing business agility through new functionality, enforcing a proper degree of order and structure, seeking out help, and other must-haves are viewed as optional. Ignoring several decades of ERP and other SAP lessons learned can’t possibly accelerate a team to a successful go-live or project outcome.
However, the “what” is only a piece of the culture puzzle. Organizational culture necessarily reflects the “how” and the “who” too. We can’t avoid making the same mistakes again and again if we don’t understand these two important culture dimensions and how they can be tuned to encourage new values and behaviors.
The Culture Cube
Though a snail analogy works at a high level, organizational culture and workplace climate are more than one-dimensional. Factors affect a culture’s depth (or “how” it gets things done) and its breadth or constituency (the “who” making up the organization). Together, these three dimensions can more effectively describe an organization’s culture and give us a better idea of how and where we might need to change so as to avoid making the same mistakes again and again. Several measures of depth that affect the “how” include the organization’s degree of or views on:
- Maturity, specifically how it informs the organization’s priorities and ability to execute against those priorities
- Efficacy, or how the organization’s effectiveness affects how well it does its job
- Quality, including the processes and attitudes that define acceptable levels of defects
- Risk, or the organization’s appetite for taking risks along with its ability to deal with negative risks or maximize positive risks
For each measure of breadth and depth, there are several levels of “who” including:
- The overall company or organization, which is comprised of teams
- Teams, which are comprised of individuals
- Customers, partners and vendors, and other key stakeholders, all of whom dramatically affect both individuals and teams
Bringing together the what, how, and who yields a simple but effective model for visualizing company culture or workplace climate: the Culture Cube (
Figure 2).
Figure 2
The culture cube reflects the what, how, and who of an organization
All living things change and evolve to adapt to their surroundings, reinventing themselves or succumbing to death. Maturity, efficacy, quality, and the appetite for risk ebb and flow. Changes over time in leadership, values, biases, capabilities, prioritization, and knowledge affect the whole organization. But it is individuals and their effects on their respective teams that propel an organization forward. Said another way, an SAP project or support team’s behaviors pave the way for change, covered next.
Behavior Trumps Everything Else
Organizational or team culture is the result of a bottoms-up process that takes its cues from the top and the middle (and thus includes every person in an organization). Leadership’s vision and actions, in-the-trenches team operational practices, shared values, and more all combine and inform one another to slowly remake organizational culture and workplace climate. Like gravity, it’s a constant and inescapable process. So while a new executive can come in and try to shake things up, changing culture through a “culture change initiative” is typically a waste of time. Leaders change culture by changing what’s important to individuals and teams, which in turn changes behaviors across the organization – up, down, around, and across (Figure 3). If you want to change the quality of your ABAP code or the velocity of your supply chain, you can’t reward the same old behaviors that got you where you are today. If you want to make fewer mistakes down the road, you need to change the road you’re on.
Figure 3
Changing an organization's behaviors ultimately changes its culture
What To Do About All of This
To really change an organization’s culture also requires an urgent reason. For many companies, that reason reflects something fundamentally important to the organization. Working through company reinvention, flirting with bankruptcy, or losing standing or key customers in the marketplace should drive urgency. In such cases, it’s naturally easier for individuals, teams, and organizations to unlearn their old ways and start adopting new values and behaviors – there’s an urgent reason for doing so. Effective leadership-modeling and driving new priorities and behaviors is paramount in such times.
While effective leadership is instrumental to navigating change, it’s just the start. Before facing such dramatic sea changes, it’s important for the organization to understand itself, its situation, and potentially how quickly it can change. Know your company-unique or team-specific culture cube and you’ll know yourself. Take a critical look at the “what,” “how,” and “who” that defines your organization today, and look for the weak links. And ask hard questions:
- Are you still actually good at what you do (your capabilities), and would your customers and competitors agree? What measures are you using?
- What do your methods of prioritizing strategic initiatives and other projects, or managing risks, or building quality into everything you do, tell you about the organization’s current values?
- Has anyone validated or measured your organization’s maturity or effectiveness?
- Have you identified a single compelling and urgent reason for change, and has this been communicated well in terms of a new vision or set of goals?
- Have you determined which of your current behaviors and values need to change to achieve the organization’s vision or goals, and started measuring those particular behaviors and values?
- How will you know that your culture is evolving along the “right” path? Will you measure change from one quarter to the next? How will you course-correct?
- Do you understand how individuals affect your work teams and in turn your company’s overall culture, and are individual changes therefore necessary?
- Does the team understand those behaviors and goals? What’s important to the team nowadays, what can take a back seat, and what needs to be better communicated?
- Are you focused on actually incentivizing the right behaviors (the new ones!) necessary to meet the organization’s new goals?
- Are your leaders modeling the new behaviors you need to see on the shop floor, in the warehouse, in IT, and in your own team? What changes need to be quickly made?
- How and where are you managing and retaining your organization’s knowledge and using it to accelerate the positive changes you need to see while avoiding missteps?
Your first order of business is to fix the problems behind your organizational memory lapses. Recognize that many of your key knowledge bearers are gone, and you’ve got more work to do than time on your hands. You need a lightweight system for managing the decisions you are making, and you need it today. So don’t over-complicate things! To get started:
- As a first step, put together a virtual team of your senior leaders and key contributors. Task them with cobbling together not only the knowledge repositories spread across your team, but with explaining some of the important business, system, and technology tradeoffs you’ve made recently. Have them provide a bit of history while filling in the gaps through their personal insight and experiences.
- Next, invest in and populate a proper team-wide knowledge management platform as you increase the circle of contributors. The more people who connect and share through this platform, the better your organization will communicate. It’ll amaze you. So will your ability to arrive at smarter decisions more quickly, reduce your systems’ downtime, and push greater agility throughout your team.
- Give responsibility and accountability for this knowledge management platform to someone passionate about the organization’s future – the higher in the organization, the better. Yes, it’s that important.
- Finally, incentivize, put procedures or tools in place to provide metrics, and then measure how the knowledge management platform is used.
Remember that you’ll need to reward new behaviors to make all of this “sticky.” Together with your virtual team, figure out those behaviors and the kinds of rewards that will continue to incent those behaviors.
In doing all of this, you might just avoid the kind of mindless organizational memory lapses that lead to repeating 1981 over and over again, or the kind of lapses that ultimately make your team irrelevant in our changing IT and business landscape. And isn’t that as critical as anything else on your plate today?
To walk through all of this and much more, attend my full-day pre-conference session “A Real-World Introduction to SAP for Beginners” at SAPinsider’s Project Management 2014 event October 26 in Atlanta, Ga. You’ll hone your SAP project and program management skills as I explore the top 10 mistakes common to ERP projects. You’ll then learn how to apply strategies to avoid these pitfalls. Real-world exercises, gamification techniques, lightweight quality and risk management tools, and more will help you leave the conference armed to make a real difference back in your workplace.
George Anderson
As a senior director and global program executive for an arm of Microsoft's consulting business, Dr. George Anderson leads teams of program and project managers, architects, and enterprise consulting professionals tasked with deploying various ERP solutions and other business applications. He’s co-authored several books including
SAP Implementation Unleashed and the
Teach Yourself SAP in 24 Hours series, serves as an adjunct professor teaching various project management and systems analysis courses, and holds a number of credentials including PMI PMP and several SAP and Microsoft certifications alongside a PhD in leadership/organizational change, an MBA with a concentration in Human Resource Management, and a bachelor’s degree in computer science.
You may contact the author at
george.anderson@microsoft.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the
editor.