Managing the People Side of an SAP Project: Live Q&A with Doug Whittle

For many project managers, managing the technical and project-based components of an SAP initiative is the easiest part of their jobs. With so many diverse personalities involved in a project, it’s no wonder that managing the human side of an SAP project often presents the greatest challenge to project managers.

In a live Q&A, Managing Your SAP Projects 2016 speaker Doug Whittle shared best practices for leading and managing others throughout your SAP project. Ask your most pressing questions about engaging stakeholders, kicking-off a project, and harnessing the different working styles within a team. Read the transcript below

Transcript: 

SAPinsiderMatt: Welcome to today’s Q&A on managing the people side of an SAP project! I’m pleased to be joined today by Doug Whittle, President, Whittle Consulting Group, LLC. Doug will be sharing his expertise from over 40 years of IT and business experience in implementing training, support, organizational change, and communication strategies for SAP implementations. Doug will be speaking at the upcoming Managing Your SAP Projects 2016 conference taking place November 2-4 in Orlando, and December 5-7 in Copenhagen. For more information and to register, visit www.sapprojects2016.com. Please give him a warm welcome!

Without any further ado, let us begin. Doug is already answering a number of questions now. In the interest of time, please keep your questions brief. 

Comment From Ash: In some projects where SAP is replacing a non-SAP legacy system, there are change management challenges. This is especially true if the leadership of the organization has been involved in the development of the home-grown legacy system. What are some best practices to manage people issues in such projects?

Doug Whittle: One of the best “sales” strategies for moving a legacy system to SAP is identifying the current issues that users are having with the legacy system—their complaints, their wishes, where they are lacking functionality, etc. – and pinpointing areas that you are sure will be resolved with the new SAP system and processes. Users are interested in the answer to “What’s in it for me?” (WIIFM). Go back to your original business case: how did you justify the new system in the first place? Hopefully some of your selling points can be taken directly from there.

There are times, however, when the main benefit of a new system is based on “What’s in it for the organization?” (WIIFO). If you have reluctant leadership, I would use those organizational benefits as talking points in addition to addressing the benefits it can bring to their respective teams. I always recommend that someone entering a major change initiative think of themselves as “sales people.” You not only have to “tell” people what is happening with the change, but you also have to “sell” it. 

Comment From Raj: An SAP implementation project sometimes removes redundant members of the workforce on the business side. While gathering requirements for  the implementation, consultants are often engaged with the business users. But the business users themselves know that, after providing the relevant information and after the completion of the project, he or she might not be needed in the organization. They also know that not all of the business users get to use the new SAP system. A very few are needed, and redundant users are asked to leave due to the inherent automation SAP brings in. Therefore, there is very little motivation (and more often no motivation) from the business users to share relevant information. With this perspective in mind, how do you think the consultant can get the needed info? Any personal experience or real world experience in tackling this is appreciated.

Doug Whittle:

From my experience, I haven’t necessarily seen large-scale reductions in workforce as a result of SAP implementations. Rather, I have seen the employees’ job responsibilities and roles change, oftentimes significantly, as a result of new and hopefully more efficient processes. Even that change can be frightening for some employees (e.g. “I’ve been here 30 years and have always done things the same way”). From the beginning, a strong senior management message must be crafted and distributed that states the organization’s expectations of its workforce regarding changes to job roles.

Employees do have choices—they can either get on board or, if they choose to not support the change, they need to understand that the organization does not support that behavior. The change messages that accompany your initiative must support the organization’s current cultural values. Or if the new SAP implementation is the result of moving to new cultural values, everything that is communicated must support that new set of values. I’m a huge fan of “truth in packaging.” In other words, if it is the intent of the organization to reduce the workforce, that message needs to be honest and clear from day 1. But part of that message should be (if it’s true): “We will have roles for those who work with us to reach our new desired state.”

If some employees absolutely refuse to cooperate in the requirements gathering, I believe that’s a performance issue that must be addressed early, rapidly, and with swift consequences if the performance doesn’t improve. I tell people there are three primary reasons why people resist change: 1) I don’t like it (the change); 2) I don’t understand it (the change); or 3) I don’t like you (the messenger). Identify which of these is driving the resistance—and build your change strategy based upon that reason and individual.

Comment From Celeste: Hello. User adoption of the Solution Manager tool has presented many challenges to our organization, not only on business user side but also on the technical side. Despite providing live training sessions, comprehensive training by role documents and functional job aids, and quick reference guides, we continue to be challenged in getting folks fully on board with the processes. Do you have any tips/suggestions around our challenge?

Doug Whittle: My first question would be, did you test/pilot the training content and materials with actual representative end users before you released those programs and materials? Too many times, organizations release training content and materials that are not developed from the frame of reference of the actual end user for whom it’s intended. In other words, if a highly technical developer writes the job aids and documentation, it may be written in a “language” that is not user friendly. Did the training actually provide hands-on, supervised lab time, or was it someone standing in front of the group and talking to the group, rapidly traveling through screens and examples with little or no time left for the users to actually practice and learn? Yes, it could be that some of the people who are not fully on board with the new system and processes are just being stubborn and difficult. But too many times, I’ve seen content and materials developed that are confusing, inadequate, or simply not understandable by the “average’ users. Hence, I’m a huge proponent of involving actual end users in piloting all content and materials before they are released to the masses. I can almost guarantee that a good piloting/testing phase will result in significant changes to your content. I would also make a pitch for having individuals on your team who understand the fundamental principles of adult learning and the “art” of designing effective training and support materials. It is a whole different technical skill set that a typical IT person probably doesn’t have. 

Comment From Andres Valenzuela: Can you teach a PMP new to SAP projects how to deal with the personalities in their team and complexities in SAP projects before they get their first SAP project to manage?

Doug Whittle: Absolutely! But only if that individual desires to learn and practice those skills. One of the first things I would want a PMP to learn is the concepts of “working styles.” This addresses how you work effectively with different personality types. There is solid theory and science behind these concepts, and those who embrace these concepts have seen significant improvement and have gained great self-confidence in their ability to work with a variety of different personality types—something that you will encounter every day of an SAP implementation. I will be presenting a session titled “Managing the SAP Marathon: Using Knowledge of Working Styles to Build and Maintain a Winning Project Team.”

The PMP should also have a deep understanding of the dynamics of organizational change: how different people respond to change; how to recognize the different phases of change; how to help guide people through the different phase of the change process, etc. The PMP should also be knowledgeable of the stakeholder assessment and mapping process. Come join me for my preconference workshop titled “A Roadmap to Project Success: 3 Critical Success Factors for Engaging Your Stakeholders from Day 1.” This session addresses more of the “technical” skills involved with identifying how you will use different strategies and approaches to engage various stakeholders.

Finally, a PMP must be competent in the overall art of communication—and I believe the preceding elements just mentioned provide you with a firm base for how to communicate effectively. I will be talking about the specific elements of the communications process as well as addressing some of these other concepts in my other preconference workshop titled: “The People Piece of Project Management: Things They Don’t Teach You about Managing Projects that can Make Your Job So Much Easier.”

Comment From Guest: How do you get support from peers for introducing a new process as part of a project plan?

Doug Whittle: Try to identify the key “pain points” that your peers acknowledge are current state issues and problems and that will be resolved as you move to the future state (new) process. A key to helping people get on board with change is how you answer the question “What’s in it for me?” (WIIFM), which tackles the issue from their point of view (POV). Whenever possible, get a representative of differing POV’s on board at the beginning when you are working on the new process. They then become “partners” in the change process. You’re doing the change with them instead of to them.

Comment From Rosemary Peh: Although change is coming hard and fast in the utilities industry, I have found that its speed is relative and, considering that, slow to come and slow to be accepted in this space. What is the number one action that can be proactively taken in SAP implementations for utilities that increases the success of embedding new processes, thinking, and behaviors that fully leverage the new system’s capabilities well beyond the go-live date?

Doug Whittle: Look at change implementation at two different angles: Are you doing the change TO the stakeholders or are you doing the change WITH the stakeholders? It makes a huge difference. If you invite me (as a representative stakeholder) to work with you at the beginning and through the thought processes, I am now part of the solution. I have skin in the game. I am part “owner” of the outcome. That’s a very different mindset than if I feel like you’re sitting out there somewhere in space, creating new systems, processes, and ideas, and you’ve never tapped into my experiences and opinions. It’s understandable in the latter situation that I could become resentful, bitter, and perhaps try to obstruct your progress. This is where a thorough stakeholder assessment prior to beginning a change makes a huge difference in who you invite into the thought process and how you use them. While you have to limit the physical number of those stakeholders, a thorough stakeholder assessment helps you identify who the key representatives of each primary stakeholder group are. Then it’s critical for you to emphasize that those representatives must be communication conduits between the project and the rest of their representative population.

Comment From John @ Frank IT Ch…: What are your thoughts about leveraging change champions and/or other natural pockets of energy to accelerate business transformation? How do you choose the best people, places, and timing to activate them? Thanks!

Doug Whittle: Using change champions is a must-have for effective change leadership. I know I keep referring to stakeholder assessment and mapping, but that is precisely where you figure out where your pockets of champions or pockets of detractors exist. Based upon the physical map you create, you can then build your best “battle plan” for who to engage and at what level. I will be doing a half-day workshop on the concepts of stakeholder mapping and give you examples of how this process works.

Comment From sweber: Have you had any experience moving to agile project management in the SAP world? What can make it successful for the team?

Doug Whittle: I have had only brief experience of using agile project management in SAP, so I’m probably not the best spokesperson to address specifics related to this. I suspect some of the basic principles of change management still apply–how you tell and sell the benefits to your key stakeholders.

Comment From Casey: Do you have any key tips or tricks for introducing, developing, and deploying a training program for all levels of users at an organization that has been live with SAP for 8 years, but that was essentially burned by the implementation partner in regards to setting up and maintaining an initial program?

Doug Whittle: Without knowing the specifics, I would suggest starting with a thorough assessment of the “current state.” Part of that assessment is doing a stakeholder assessment. Who are your various end users? What are their levels of skill and expertise? You most likely have some end users who are quite proficient simply because they are self-directed and figured things out along the way. (That being said, some of them may have “figured it out” in a way that isn’t what you would want as standard operating procedures.) Your assessment will uncover another block of users who are struggling with even the basics.

Once you have a good idea of the “blocks” of users and their various levels of skill and knowledge, I would then design different levels of training (or retraining) that are specific to those blocks. I would probably try to lump my end users into no more than three groups: those who need to almost start from scratch (they’re struggling, they’re frustrated, they’re creating high support demands); those who are getting by but are still leaning more than you would like on the support resources; and those who are pretty self-sufficient and could most likely be moving into more advanced levels of usage if you created the right learning modules for them. The types of training you use for the groups, the detail of instruction, and the amount of hands on (versus demo) training will vary. The group learning the basics should have much more hands-on experience, while the advanced group can most likely learn with simple demos and job aids. The middle group will probably need some mix of the two.

Comment From what is the best m…: For a functional consultant assigned to manage an SAP project for the first time, what are your recommendations?

Doug Whittle: Judging from the years of war stories I hear when I’m at conferences, the IT team is probably doing pretty well with technical skill levels and knowledge of SAP functionality. More than likely, they could use some help with the “soft skills” areas: how to work effectively with different styles of people, how to communicate clearly, how to lead change, how to lead effective meetings, etc.

Comment From Matthew: Part of the territory that comes with being a consultant is that many customers or individuals believe the idea that “Since you are a consultant, you are out to get me and make a buck doing so.” I have found that being transparent and giving several options to achieve goals tends to mostly remove this stigma. Do you have any other tips or tricks that will help show these individuals that I really do have their best interests in mind, and I am here to make their transition as smooth and successful as possible?

Doug Whittle: I can totally identify with what you’re saying. And your first point (transparency) is absolutely a great focus. I would also focus on ways to help shine the spotlight on those team members who are doing the right stuff and who are succeeding (probably because you’ve been working effectively with them). Whenever possible, give them the credit and applause; let management know how those individuals are rising to the challenges. I also think that the more you do to help them learn the same skills that you have (e.g. people skills, meeting management, etc.) the more you help them become more self-sufficient and valuable to their employer. In some ways, you’re working yourself out of a job. But I’ve always believe that those consultants who do just that will never lack from new opportunities.

Comment From Andres Valenzuela: How do you reduce the amount of meetings and follow-up sessions for a complex SAP project when the consultant seems frustrated with the amount of meeting time but still fails to deliver or communicate progress and results?

Doug Whittle: The “art” of meeting facilitation is critical for a successful SAP project. If you learn about good meeting management and you follow those principles faithfully (agenda, roles, time limits, documentation, participation, etc.), you will be amazed at how much more productive people are. Above all, meetings must be tightly managed and directed. It’s a discipline that will need to be learned by everyone who is expected to attend your meetings—and to be honest, it will involve some “pain” at the beginning because too many of us for too many years have been victims of poorly managed meetings. We have trudged along for too many years with meetings that have no leadership, no structure, no stated objectives, and thus, few results other than frustration and lost time. If you are at this year’s Projects Conference, let’s grab some time to talk through some examples I can share with you of what helps drive well managed, results-driven meetings.

Comment From Andres Valenzuela: How do you distinguish a PM that knows how to deal with all this complexity from one that has managed many SAP projects but has never learn these skills properly?

Dough Whittle: You need to do some homework before you hire that project manager. Follow up with people who have worked with and for them. If your PM is an internal person, don’t rely just on who they list as references. Also do some exploration into who else in your organization may have had interactions with them. During the actual interview phase, I would pose questions to them that present a common issue or problem and ask them how they would address/resolve that issue. Listen carefully to their answers—you will learn a lot about who they are from those types of questions. “What if…” questions are valuable as well. If you aren’t familiar with the concept, do some reading and research on “situational interviews.” There are all sorts of web articles as well as whole books written on the subject.

Comment From Guest: How do you make the introduction of new technologies as part of an SAP project implementation easier?

Doug Whittle: It’s a combination of good change management techniques (which includes meaningful and timely communication) and the right level of training. Good change management includes selling and telling.. “Selling” means helping sell the benefits of the new technology from the point of view of who will be expected to actually use that technology (in other words, those individuals are legitimately asking WIIFM [“What’s In It For Me?”]) The telling part is using thorough and meaningful communication combined with the appropriate level of training on how to use effectively.

Comment From Andres Valenzuela: How do you deal with a senior consultant who is very good at his job in SAP but has terrible communication and relations with other members in an SAP project?

Doug Whittle: My first question is, has someone addressed these concerns directly with the sr. consultant, including specific examples of the wrong behaviors and issues that have resulted from what you refer to as “terrible communication”? Step one is to address the problem directly and reach an agreement that a problem exists. If he/she won’t even acknowledge that a problem exists, there is little to no hope that he/she will make any positive change. Step two is to ask him/her to identify alternatives and approaches for remedying the problem, along with an honest discussion of the risks and benefits associated with each alternative. Step 3 is to reach an agreement on the actions to be taken, timelines, and measures of success (e.g. how will we know that progress is being made?). Step 4 is for that individual to identify a clear strategy for ongoing measurement and follow-up. Step 5 is to reinforce positive achievements as soon as they occur and address specific instances of negative behaviors immediately. I will discuss these coaching concepts in my preconference workshop “The People Piece of Project Management: Things They Don’t Teach You about Managing Projects that Can Make Your Job So Much Easier.”

Finally, I want to remind you (and everyone else who hires consultants) that at the end of the day, YOU, the client, own the client/consultant contract. If they aren’t meeting your expectations; if they aren’t willing to change to meet your business needs; if they aren’t the right person for the job; it is your responsibility to your organization and to your project team to replace that individual. No client should be burdened long-term with the responsibility to “train” a consultant in basic people skills. I am amazed at how often I see examples of “the tail wagging the dog.” If you don’t address this early, it can be demoralizing for your project team. 

Comment From Guest: What are some best practices for managing team members that work from multiple locations?

Doug Whittle: First of all, be sure you balance your time between those who might be onsite with you with those who are working at a distance from your location. It’s easy to forget about the “distance” team members, and they will realize that at some point if they feel they’re being neglected or given less attention. Second, I would make sure that everyone is connected on a regular basis in meetings that utilize whatever distance conferencing tools you can use. But keep in mind that, in all fairness, these meetings shouldn’t always be conducted on U.S. time preferences. Those of us in the states may have to actually come early or stay late to get on another country’s daylight work time. Third, I would try to get everyone on my team physically together at least once a year. I realize that’s a great expense, but there is something to be said for face-to-face working (and playing) time with the entire team. Finally, the project/team manager needs to visit each site on some regular basis–boots on the ground, so to speak. Every location is proud of what they do at their site and feel valued when their manager visits them on their home turf.

Comment From Guest: What are your preferred tools for the ‘mapping process’ to guide people through the different phases of the change process?

Doug Whittle: I use a five-phase change curve model: Denial, Resistance, Exploration, and Commitment. The fifth and most challenging phase falls somewhere between Resistance and Exploration and is called Quitting and Checking Out. Keep in mind that everyone does not process change in the same order. In other words, some may start a change by being in Exploration. But if they have a bad experience, they may then go into a state of Denial or Resistance. We also don’t experience change on the same timeline and at the same speed. The whole objective of using a change model is to encourage forward and positive movement, winning people over to Exploration and Commitment and then engaging those people as change champions to bring others on board. I will share the change curve model I use in my half-day workshop, “The People Piece of Project Management.”

If you’re interested in learning more about the mapping process I use for stakeholder assessment and strategy, join me for the other half-day workshop I’ll be presenting: “A Roadmap to Project Success: The Change Curve and The Stakeholder Mapping Process are Both Critical Project Management Tools.”

Comment from Jeroen: Hi Doug. The adoption of SAP SaaS solutions has great impact on project structure, governance, and activities (WBS) as traditional project streams (like infrastructure, solution development and testing, and transfer to AM team) are heavily impacted. This results in different roles & responsibilities for the project team and business stakeholders. How do you see the impact on the people side? Regards, Jeroen.

Doug Whittle: Any time you change roles and responsibilities for anyone, that marks a change for people, and as such, you can also expect a wide variety of responses to those changes. You will have some individuals who embrace that change initially and are able to maintain that excitement for change throughout. Others may embrace the change initially, but after a while, their enthusiasm may wane—perhaps because they encounter difficulties, perhaps because they weren’t prepared for the degree of impact that the change has on them, or perhaps because the reality is different from their expectations.

Two things enter into our responses to change. One is the whole theory of a change curve (which I will discuss in some of my sessions at this year’s conference). We don’t all experience change at the same level, at the same speed, or even in the same phases. The second element revolves around the concept of working styles. Some individuals enjoy change; they like “living on the edge”, and they embrace risk and new experiences. In fact, many of these people actually promote the idea of change just because they are always on the hunt for the new and exciting and different. Others are slower to adapt to change—they avoid risk, they want to see “proof” that the change will work before they get on board, they want to see data and facts that support the reasons for making the change, and they want to know they will be supported throughout the change cycle. Putting these two elements into play is why managing change is such a complex (and interesting) concept to explore.

SAPinsiderMatt: Thank you Doug for participating in today’s Q&A!

Doug will be speaking at the upcoming Managing Your SAP Projects 2016 conference taking place November 2-4 in Orlando and December 5-7 in Copenhagen. For more information and to register, visit www.sapprojects2016.com.

For many project managers, managing the technical and project-based components of an SAP initiative is the easiest part of their jobs. With so many diverse personalities involved in a project, it’s no wonder that managing the human side of an SAP project often presents the greatest challenge to project managers.

In a live Q&A, Managing Your SAP Projects 2016 speaker Doug Whittle shared best practices for leading and managing others throughout your SAP project. Ask your most pressing questions about engaging stakeholders, kicking-off a project, and harnessing the different working styles within a team. Read the transcript below

Transcript: 

SAPinsiderMatt: Welcome to today’s Q&A on managing the people side of an SAP project! I’m pleased to be joined today by Doug Whittle, President, Whittle Consulting Group, LLC. Doug will be sharing his expertise from over 40 years of IT and business experience in implementing training, support, organizational change, and communication strategies for SAP implementations. Doug will be speaking at the upcoming Managing Your SAP Projects 2016 conference taking place November 2-4 in Orlando, and December 5-7 in Copenhagen. For more information and to register, visit www.sapprojects2016.com. Please give him a warm welcome!

Without any further ado, let us begin. Doug is already answering a number of questions now. In the interest of time, please keep your questions brief. 

Comment From Ash: In some projects where SAP is replacing a non-SAP legacy system, there are change management challenges. This is especially true if the leadership of the organization has been involved in the development of the home-grown legacy system. What are some best practices to manage people issues in such projects?

Doug Whittle: One of the best “sales” strategies for moving a legacy system to SAP is identifying the current issues that users are having with the legacy system—their complaints, their wishes, where they are lacking functionality, etc. – and pinpointing areas that you are sure will be resolved with the new SAP system and processes. Users are interested in the answer to “What’s in it for me?” (WIIFM). Go back to your original business case: how did you justify the new system in the first place? Hopefully some of your selling points can be taken directly from there.

There are times, however, when the main benefit of a new system is based on “What’s in it for the organization?” (WIIFO). If you have reluctant leadership, I would use those organizational benefits as talking points in addition to addressing the benefits it can bring to their respective teams. I always recommend that someone entering a major change initiative think of themselves as “sales people.” You not only have to “tell” people what is happening with the change, but you also have to “sell” it. 

Comment From Raj: An SAP implementation project sometimes removes redundant members of the workforce on the business side. While gathering requirements for  the implementation, consultants are often engaged with the business users. But the business users themselves know that, after providing the relevant information and after the completion of the project, he or she might not be needed in the organization. They also know that not all of the business users get to use the new SAP system. A very few are needed, and redundant users are asked to leave due to the inherent automation SAP brings in. Therefore, there is very little motivation (and more often no motivation) from the business users to share relevant information. With this perspective in mind, how do you think the consultant can get the needed info? Any personal experience or real world experience in tackling this is appreciated.

Doug Whittle:

From my experience, I haven’t necessarily seen large-scale reductions in workforce as a result of SAP implementations. Rather, I have seen the employees’ job responsibilities and roles change, oftentimes significantly, as a result of new and hopefully more efficient processes. Even that change can be frightening for some employees (e.g. “I’ve been here 30 years and have always done things the same way”). From the beginning, a strong senior management message must be crafted and distributed that states the organization’s expectations of its workforce regarding changes to job roles.

Employees do have choices—they can either get on board or, if they choose to not support the change, they need to understand that the organization does not support that behavior. The change messages that accompany your initiative must support the organization’s current cultural values. Or if the new SAP implementation is the result of moving to new cultural values, everything that is communicated must support that new set of values. I’m a huge fan of “truth in packaging.” In other words, if it is the intent of the organization to reduce the workforce, that message needs to be honest and clear from day 1. But part of that message should be (if it’s true): “We will have roles for those who work with us to reach our new desired state.”

If some employees absolutely refuse to cooperate in the requirements gathering, I believe that’s a performance issue that must be addressed early, rapidly, and with swift consequences if the performance doesn’t improve. I tell people there are three primary reasons why people resist change: 1) I don’t like it (the change); 2) I don’t understand it (the change); or 3) I don’t like you (the messenger). Identify which of these is driving the resistance—and build your change strategy based upon that reason and individual.

Comment From Celeste: Hello. User adoption of the Solution Manager tool has presented many challenges to our organization, not only on business user side but also on the technical side. Despite providing live training sessions, comprehensive training by role documents and functional job aids, and quick reference guides, we continue to be challenged in getting folks fully on board with the processes. Do you have any tips/suggestions around our challenge?

Doug Whittle: My first question would be, did you test/pilot the training content and materials with actual representative end users before you released those programs and materials? Too many times, organizations release training content and materials that are not developed from the frame of reference of the actual end user for whom it’s intended. In other words, if a highly technical developer writes the job aids and documentation, it may be written in a “language” that is not user friendly. Did the training actually provide hands-on, supervised lab time, or was it someone standing in front of the group and talking to the group, rapidly traveling through screens and examples with little or no time left for the users to actually practice and learn? Yes, it could be that some of the people who are not fully on board with the new system and processes are just being stubborn and difficult. But too many times, I’ve seen content and materials developed that are confusing, inadequate, or simply not understandable by the “average’ users. Hence, I’m a huge proponent of involving actual end users in piloting all content and materials before they are released to the masses. I can almost guarantee that a good piloting/testing phase will result in significant changes to your content. I would also make a pitch for having individuals on your team who understand the fundamental principles of adult learning and the “art” of designing effective training and support materials. It is a whole different technical skill set that a typical IT person probably doesn’t have. 

Comment From Andres Valenzuela: Can you teach a PMP new to SAP projects how to deal with the personalities in their team and complexities in SAP projects before they get their first SAP project to manage?

Doug Whittle: Absolutely! But only if that individual desires to learn and practice those skills. One of the first things I would want a PMP to learn is the concepts of “working styles.” This addresses how you work effectively with different personality types. There is solid theory and science behind these concepts, and those who embrace these concepts have seen significant improvement and have gained great self-confidence in their ability to work with a variety of different personality types—something that you will encounter every day of an SAP implementation. I will be presenting a session titled “Managing the SAP Marathon: Using Knowledge of Working Styles to Build and Maintain a Winning Project Team.”

The PMP should also have a deep understanding of the dynamics of organizational change: how different people respond to change; how to recognize the different phases of change; how to help guide people through the different phase of the change process, etc. The PMP should also be knowledgeable of the stakeholder assessment and mapping process. Come join me for my preconference workshop titled “A Roadmap to Project Success: 3 Critical Success Factors for Engaging Your Stakeholders from Day 1.” This session addresses more of the “technical” skills involved with identifying how you will use different strategies and approaches to engage various stakeholders.

Finally, a PMP must be competent in the overall art of communication—and I believe the preceding elements just mentioned provide you with a firm base for how to communicate effectively. I will be talking about the specific elements of the communications process as well as addressing some of these other concepts in my other preconference workshop titled: “The People Piece of Project Management: Things They Don’t Teach You about Managing Projects that can Make Your Job So Much Easier.”

Comment From Guest: How do you get support from peers for introducing a new process as part of a project plan?

Doug Whittle: Try to identify the key “pain points” that your peers acknowledge are current state issues and problems and that will be resolved as you move to the future state (new) process. A key to helping people get on board with change is how you answer the question “What’s in it for me?” (WIIFM), which tackles the issue from their point of view (POV). Whenever possible, get a representative of differing POV’s on board at the beginning when you are working on the new process. They then become “partners” in the change process. You’re doing the change with them instead of to them.

Comment From Rosemary Peh: Although change is coming hard and fast in the utilities industry, I have found that its speed is relative and, considering that, slow to come and slow to be accepted in this space. What is the number one action that can be proactively taken in SAP implementations for utilities that increases the success of embedding new processes, thinking, and behaviors that fully leverage the new system’s capabilities well beyond the go-live date?

Doug Whittle: Look at change implementation at two different angles: Are you doing the change TO the stakeholders or are you doing the change WITH the stakeholders? It makes a huge difference. If you invite me (as a representative stakeholder) to work with you at the beginning and through the thought processes, I am now part of the solution. I have skin in the game. I am part “owner” of the outcome. That’s a very different mindset than if I feel like you’re sitting out there somewhere in space, creating new systems, processes, and ideas, and you’ve never tapped into my experiences and opinions. It’s understandable in the latter situation that I could become resentful, bitter, and perhaps try to obstruct your progress. This is where a thorough stakeholder assessment prior to beginning a change makes a huge difference in who you invite into the thought process and how you use them. While you have to limit the physical number of those stakeholders, a thorough stakeholder assessment helps you identify who the key representatives of each primary stakeholder group are. Then it’s critical for you to emphasize that those representatives must be communication conduits between the project and the rest of their representative population.

Comment From John @ Frank IT Ch…: What are your thoughts about leveraging change champions and/or other natural pockets of energy to accelerate business transformation? How do you choose the best people, places, and timing to activate them? Thanks!

Doug Whittle: Using change champions is a must-have for effective change leadership. I know I keep referring to stakeholder assessment and mapping, but that is precisely where you figure out where your pockets of champions or pockets of detractors exist. Based upon the physical map you create, you can then build your best “battle plan” for who to engage and at what level. I will be doing a half-day workshop on the concepts of stakeholder mapping and give you examples of how this process works.

Comment From sweber: Have you had any experience moving to agile project management in the SAP world? What can make it successful for the team?

Doug Whittle: I have had only brief experience of using agile project management in SAP, so I’m probably not the best spokesperson to address specifics related to this. I suspect some of the basic principles of change management still apply–how you tell and sell the benefits to your key stakeholders.

Comment From Casey: Do you have any key tips or tricks for introducing, developing, and deploying a training program for all levels of users at an organization that has been live with SAP for 8 years, but that was essentially burned by the implementation partner in regards to setting up and maintaining an initial program?

Doug Whittle: Without knowing the specifics, I would suggest starting with a thorough assessment of the “current state.” Part of that assessment is doing a stakeholder assessment. Who are your various end users? What are their levels of skill and expertise? You most likely have some end users who are quite proficient simply because they are self-directed and figured things out along the way. (That being said, some of them may have “figured it out” in a way that isn’t what you would want as standard operating procedures.) Your assessment will uncover another block of users who are struggling with even the basics.

Once you have a good idea of the “blocks” of users and their various levels of skill and knowledge, I would then design different levels of training (or retraining) that are specific to those blocks. I would probably try to lump my end users into no more than three groups: those who need to almost start from scratch (they’re struggling, they’re frustrated, they’re creating high support demands); those who are getting by but are still leaning more than you would like on the support resources; and those who are pretty self-sufficient and could most likely be moving into more advanced levels of usage if you created the right learning modules for them. The types of training you use for the groups, the detail of instruction, and the amount of hands on (versus demo) training will vary. The group learning the basics should have much more hands-on experience, while the advanced group can most likely learn with simple demos and job aids. The middle group will probably need some mix of the two.

Comment From what is the best m…: For a functional consultant assigned to manage an SAP project for the first time, what are your recommendations?

Doug Whittle: Judging from the years of war stories I hear when I’m at conferences, the IT team is probably doing pretty well with technical skill levels and knowledge of SAP functionality. More than likely, they could use some help with the “soft skills” areas: how to work effectively with different styles of people, how to communicate clearly, how to lead change, how to lead effective meetings, etc.

Comment From Matthew: Part of the territory that comes with being a consultant is that many customers or individuals believe the idea that “Since you are a consultant, you are out to get me and make a buck doing so.” I have found that being transparent and giving several options to achieve goals tends to mostly remove this stigma. Do you have any other tips or tricks that will help show these individuals that I really do have their best interests in mind, and I am here to make their transition as smooth and successful as possible?

Doug Whittle: I can totally identify with what you’re saying. And your first point (transparency) is absolutely a great focus. I would also focus on ways to help shine the spotlight on those team members who are doing the right stuff and who are succeeding (probably because you’ve been working effectively with them). Whenever possible, give them the credit and applause; let management know how those individuals are rising to the challenges. I also think that the more you do to help them learn the same skills that you have (e.g. people skills, meeting management, etc.) the more you help them become more self-sufficient and valuable to their employer. In some ways, you’re working yourself out of a job. But I’ve always believe that those consultants who do just that will never lack from new opportunities.

Comment From Andres Valenzuela: How do you reduce the amount of meetings and follow-up sessions for a complex SAP project when the consultant seems frustrated with the amount of meeting time but still fails to deliver or communicate progress and results?

Doug Whittle: The “art” of meeting facilitation is critical for a successful SAP project. If you learn about good meeting management and you follow those principles faithfully (agenda, roles, time limits, documentation, participation, etc.), you will be amazed at how much more productive people are. Above all, meetings must be tightly managed and directed. It’s a discipline that will need to be learned by everyone who is expected to attend your meetings—and to be honest, it will involve some “pain” at the beginning because too many of us for too many years have been victims of poorly managed meetings. We have trudged along for too many years with meetings that have no leadership, no structure, no stated objectives, and thus, few results other than frustration and lost time. If you are at this year’s Projects Conference, let’s grab some time to talk through some examples I can share with you of what helps drive well managed, results-driven meetings.

Comment From Andres Valenzuela: How do you distinguish a PM that knows how to deal with all this complexity from one that has managed many SAP projects but has never learn these skills properly?

Dough Whittle: You need to do some homework before you hire that project manager. Follow up with people who have worked with and for them. If your PM is an internal person, don’t rely just on who they list as references. Also do some exploration into who else in your organization may have had interactions with them. During the actual interview phase, I would pose questions to them that present a common issue or problem and ask them how they would address/resolve that issue. Listen carefully to their answers—you will learn a lot about who they are from those types of questions. “What if…” questions are valuable as well. If you aren’t familiar with the concept, do some reading and research on “situational interviews.” There are all sorts of web articles as well as whole books written on the subject.

Comment From Guest: How do you make the introduction of new technologies as part of an SAP project implementation easier?

Doug Whittle: It’s a combination of good change management techniques (which includes meaningful and timely communication) and the right level of training. Good change management includes selling and telling.. “Selling” means helping sell the benefits of the new technology from the point of view of who will be expected to actually use that technology (in other words, those individuals are legitimately asking WIIFM [“What’s In It For Me?”]) The telling part is using thorough and meaningful communication combined with the appropriate level of training on how to use effectively.

Comment From Andres Valenzuela: How do you deal with a senior consultant who is very good at his job in SAP but has terrible communication and relations with other members in an SAP project?

Doug Whittle: My first question is, has someone addressed these concerns directly with the sr. consultant, including specific examples of the wrong behaviors and issues that have resulted from what you refer to as “terrible communication”? Step one is to address the problem directly and reach an agreement that a problem exists. If he/she won’t even acknowledge that a problem exists, there is little to no hope that he/she will make any positive change. Step two is to ask him/her to identify alternatives and approaches for remedying the problem, along with an honest discussion of the risks and benefits associated with each alternative. Step 3 is to reach an agreement on the actions to be taken, timelines, and measures of success (e.g. how will we know that progress is being made?). Step 4 is for that individual to identify a clear strategy for ongoing measurement and follow-up. Step 5 is to reinforce positive achievements as soon as they occur and address specific instances of negative behaviors immediately. I will discuss these coaching concepts in my preconference workshop “The People Piece of Project Management: Things They Don’t Teach You about Managing Projects that Can Make Your Job So Much Easier.”

Finally, I want to remind you (and everyone else who hires consultants) that at the end of the day, YOU, the client, own the client/consultant contract. If they aren’t meeting your expectations; if they aren’t willing to change to meet your business needs; if they aren’t the right person for the job; it is your responsibility to your organization and to your project team to replace that individual. No client should be burdened long-term with the responsibility to “train” a consultant in basic people skills. I am amazed at how often I see examples of “the tail wagging the dog.” If you don’t address this early, it can be demoralizing for your project team. 

Comment From Guest: What are some best practices for managing team members that work from multiple locations?

Doug Whittle: First of all, be sure you balance your time between those who might be onsite with you with those who are working at a distance from your location. It’s easy to forget about the “distance” team members, and they will realize that at some point if they feel they’re being neglected or given less attention. Second, I would make sure that everyone is connected on a regular basis in meetings that utilize whatever distance conferencing tools you can use. But keep in mind that, in all fairness, these meetings shouldn’t always be conducted on U.S. time preferences. Those of us in the states may have to actually come early or stay late to get on another country’s daylight work time. Third, I would try to get everyone on my team physically together at least once a year. I realize that’s a great expense, but there is something to be said for face-to-face working (and playing) time with the entire team. Finally, the project/team manager needs to visit each site on some regular basis–boots on the ground, so to speak. Every location is proud of what they do at their site and feel valued when their manager visits them on their home turf.

Comment From Guest: What are your preferred tools for the ‘mapping process’ to guide people through the different phases of the change process?

Doug Whittle: I use a five-phase change curve model: Denial, Resistance, Exploration, and Commitment. The fifth and most challenging phase falls somewhere between Resistance and Exploration and is called Quitting and Checking Out. Keep in mind that everyone does not process change in the same order. In other words, some may start a change by being in Exploration. But if they have a bad experience, they may then go into a state of Denial or Resistance. We also don’t experience change on the same timeline and at the same speed. The whole objective of using a change model is to encourage forward and positive movement, winning people over to Exploration and Commitment and then engaging those people as change champions to bring others on board. I will share the change curve model I use in my half-day workshop, “The People Piece of Project Management.”

If you’re interested in learning more about the mapping process I use for stakeholder assessment and strategy, join me for the other half-day workshop I’ll be presenting: “A Roadmap to Project Success: The Change Curve and The Stakeholder Mapping Process are Both Critical Project Management Tools.”

Comment from Jeroen: Hi Doug. The adoption of SAP SaaS solutions has great impact on project structure, governance, and activities (WBS) as traditional project streams (like infrastructure, solution development and testing, and transfer to AM team) are heavily impacted. This results in different roles & responsibilities for the project team and business stakeholders. How do you see the impact on the people side? Regards, Jeroen.

Doug Whittle: Any time you change roles and responsibilities for anyone, that marks a change for people, and as such, you can also expect a wide variety of responses to those changes. You will have some individuals who embrace that change initially and are able to maintain that excitement for change throughout. Others may embrace the change initially, but after a while, their enthusiasm may wane—perhaps because they encounter difficulties, perhaps because they weren’t prepared for the degree of impact that the change has on them, or perhaps because the reality is different from their expectations.

Two things enter into our responses to change. One is the whole theory of a change curve (which I will discuss in some of my sessions at this year’s conference). We don’t all experience change at the same level, at the same speed, or even in the same phases. The second element revolves around the concept of working styles. Some individuals enjoy change; they like “living on the edge”, and they embrace risk and new experiences. In fact, many of these people actually promote the idea of change just because they are always on the hunt for the new and exciting and different. Others are slower to adapt to change—they avoid risk, they want to see “proof” that the change will work before they get on board, they want to see data and facts that support the reasons for making the change, and they want to know they will be supported throughout the change cycle. Putting these two elements into play is why managing change is such a complex (and interesting) concept to explore.

SAPinsiderMatt: Thank you Doug for participating in today’s Q&A!

Doug will be speaking at the upcoming Managing Your SAP Projects 2016 conference taking place November 2-4 in Orlando and December 5-7 in Copenhagen. For more information and to register, visit www.sapprojects2016.com.