In Episode 4 of “Walking the Tightrope”, Doug Whittle, President of Whittle Consulting Group, discusses some proven communication methods that help keep an SAP project team humming along.
Ken Murphy: Hi this is Ken Murphy with SAPinsider Online, and welcome to “Walking the Tightrope”, a series of weekly podcasts in advance of SAPinsider’s Managing Your SAP Projects conference, which will be held in Orlando, Florida, beginning Nov. 20. Today, I’m pleased to be joined by Doug Whittle, the president of Whittle Consulting Group. Doug will present a session at the conference that focuses on his area of expertise, which is the human side of project implementation. Good morning Doug, thank you for joining us.
Doug Whittle: Good morning, thanks for having me.
Ken: Doug, can you talk about the importance of assembling the right project team prior to embarking on an SAP project. How important is it to have a firm understanding of a team’s strengths and weaknesses, and what each member brings to the table?
Doug: Well, I think it’s probably the most critical piece about making a successful SAP project. The way I look at it, our success as a project team is going to be based on the successful relationships we build. And that’s with the team members, with the end users, our project sponsors, our business partners, our systems integrators. The way I look at this, if we would take a look at how much of any one of our given work days we spend in interaction with other people, colleagues, co-workers, vs. the amount of time where we’re just heads down by ourselves, the numbers say that this is the business of how you’re going to get along with people. So, my feeling is the sooner I can figure out how to work effectively with others, that I can get a better idea of how I can communicate effectively with those folks, the behavior, the attitudes, how do I deal with difficult conversations. That information about when’s the best time to approach an individual, when do you read the signs that you ought to back off a little bit. I think that can make a huge difference in the amount of energy we have to put on the project itself vs. on all of the politics of the people that seem to consume us many times.
Well, the first thing that I’ve always felt when I’m building a team is I strive for as much diversity as I can get
Ken: What’s important to consider when deciding on building a team with respect to in-house personnel vs. system integrators or other outside consultants? Are there any tips that you can offer for how to strike the right balance there?
Doug: Well, the first thing that I’ve always felt when I’m building a team is I strive for as much diversity as I can get on the team. And, really, I start with my in-house group. Do I have the best of what I need there to get started, and then take a look at where are the holes? Where are the areas where we lack either the knowledge or we lack the talent, or we lack even the personality that’s going to be needed to make this thing happen. So, if I was a project manager finding it difficult to deal with tough conversations, and building those executive relationships, probably one of the things I would look for in a systems partner would be someone who could coach me on that and somebody who could help me with that so that I could eventually learn. I know some people seem to think that, “Well, if everybody were just like me, wouldn’t this be a really great team? Oh, we’re all so similar in how we do stuff.” And I think the real energy comes when we have folks who don’t approach problems the same way, who don’t always have the same style of how they communicate and work with one another. Because then we can figure out where that sense of balance is. I hire to my weakness. I want folks who are surrounding me who know the things I don’t know, but I also look for those people who will then take the time to help me learn that. So one of the cautions I give folks when you’re hiring outside resources is make sure you discuss the idea of knowledge transfer. Make it very clear that someday you want to be independent and you want to run on your own, vs. always being dependent upon those external resources. So how is that knowledge going to get passed off? There are some people who are very good at that. There are other people who kind of like to keep that all sheltered within them, and you really do want at the end of the day to say, “I can know do this on my own, I don’t necessarily need the other folks onboard to help me with that.”
Ken: With a team in place and a project underway, how important then is it to maintain a constant communication pipeline within that team and with team leadership? It seems simple, but is this often overlooked or not given its proper due?
Doug: Well I think we jump so quickly into getting the project work done and meeting the deliverables, and everybody goes into these projects with the best of intentions. But so many times we kind of each get into our own little secluded piece of expertise or we sit down at our desk or cubicle and then we never leave that spot. And so I’m working on a piece that I’m interested in, that I know I can add value, but when do I kind of come up out of that rabbit hole and check with some other people to make sure are we still in alignment? Because eventually this is all going to have to be integrated. So I think we way underestimate the value of ongoing communication, continual communication; these small conversations that if we don’t have them we’re going to end up with some very large problems. There’s a couple of quotes that I use when I work with folks, and one that I’ve always remembered says “The biggest problem with communication is the assumption that it’s occurred in the first place.” And I think we have to catch ourselves on that. That we don’t necessarily live through, “Well, they’re just understand or they’ll just get it, and it’s just a system of osmosis.” If in doubt, you need to ask. You need to check in with somebody. You need to update folks on a frequent basis. I think the other thing that we – none of us really like conflict on a project. And so many times we hesitate to approach somebody directly, early on when we think there’s going to be an issue or a problem. “Well, if I just kind of keep my head down, maybe it’ll go away. If I don’t say anything and I don’t make a big deal out of it, we’ll figure out how to do this.” And the other quote that I use for that is, “When you’re in a hole, quit digging.” And so if you find that you have tripped up, or you know that there is an issue that’s coming up, trying to walk around it or avoid it, trying to ignore it and hoping that it just disappears rarely happens. And the issue is that if we don’t get some kind of early intervention and address that at an early stage, it just becomes bigger and bigger and that’s where we then have some of these kind of blow-ups that we see every once in awhile. On these projects which are extremely intense, they’re exhausting, there’s lots of stress. And so we just have to figure out where those release valves are and make use of them on a more frequent basis.
Ken: Lastly, from an organizational or change management perspective, is there another common pitfall that SAP project teams can avoid?
Doug: Well, I will repeat again that communication I think is the key to everything here. It needs to be continual, frequent, keep it simple – communication is one of those things we way underestimate how important it is and yet how complex it is. And in that regard, communication has to be two-way. And I always remind people that two-way means that I’ve got a sender and I’ve got a receiver. And it’s not just me sending you the receiver information, but it’s then me getting a response from you and listening to you, and figuring out whether indeed the message that I intended to send you was received in the correct way. And the only way I’ll know that is by checking in with you again, so this idea of “Well, I sent you an email last week” is not going to be an effective way to run the team. Somewhere we need to get that loop closed and I need some kind of a response from you, I need to seek that feedback from you and keep that thing going.
I think another thing that we way underestimate is the impact of change on the team members as this project goes on. We talk about managing change for the end users and for our clients and our customers who will get this SAP system in the end. And I don’t think we do that really well in many of these projects either. But we also have to realize that the members of our project team are going through significant change as they step on to these teams, as they give up whatever their old roles were and they’re learning new responsibilities and new systems and software and building new relationships. And as these projects go on, anybody who’s been on the team for over a year if you’d say how has life changed for you, they’d be amazed when they look back to say how much stuff has happened as a result of stepping onto an SAP team. So we need to kind of take care of our team members and realize that there’s a lot of stress and there’s a lot of pressure. Again, we need to have some release valves along the way that you just can’t keep going at this with such intensity that you never have a chance to lighten up.
And I think that’s the other thing, is that it leads us to change exhaustion. We are so busy meeting deadline No. 1, and when we meet it, rather than taking a little bit of a time-out and doing what I call a post-mortem to say “How did it go, what did we learn? How can we celebrate what we’ve done so far?” We jump immediately into the next piece, and eventually we just have bodies strewn all over the place from exhaustion. The last thing I’d recommend is as a team forms, as soon as you can come up with what I call team operating principles. How are we going to work well together? What’s important to us as a group in terms of how we stay linked and communicate, how do we support one another? Those principles usually can be some fairly simple three to five rules that we all have created and we buy into and we live by. And many times that’s the kind of stuff, a little bit overt that taking the time to do that early prevents misunderstanding and frustration and all the other stuff that comes with this down the road.
Ken: Again, this is Ken Murphy with SAPinsider. I’ve had the pleasure of speaking with Doug Whittle, president of Whittle Consulting Group. Doug, you’ve offered us some great insights. Thank you for your time this morning.
Doug: You bet. Thanks for the opportunity.