In a preview of his upcoming workshop at Managing Your SAP Projects 2013, consultant and conference presenter Doug Whittle provides best practices and advice for conducting post-mortems on SAP projects.
Dave Hannon: Hello and welcome, this is Dave Hannon with SAPinsider. Joining me now is Doug Whittle of Whittle Consulting. Doug is a presenter at the upcoming Managing Your SAP Projects event in Orlando in November and I’ll be asking Doug a little bit about the topics he’s presenting on there. Welcome, Doug.
Doug Whittle: Good morning.
DH: Doug, you’re presenting a workshop at the conference on performing post mortems for SAP projects. I wanted to ask you first: what led you to drill down into that topic? Is that a major challenge for SAP project teams these days?
DW: Absolutely, I think if the one thing we miss when we do these big projects is we don’t stop and take the time to do some kind of a post mortem, a follow-up, a check-up on how we did. We kind of either go by our gut, or we end up looking at the next deadline and we just jump right into that without really a chance to take a time out to say ‘how well did this really go?’
DH: Great, great. One of the questions I wanted to ask is about the optimal time to conduct a post mortem. What’s the sort of strategy there?
DW: Well I think if we haven’t done any kind of a review during the project cycle within 30 days after you go live, it’s definitely time to do that. Now when I talk about post mortems, I will also talk to folks about the idea that you don’t have to wait until the very end, and in fact, I think sometimes, if you stop midway through your project and you do just kind of a sanity check with your team, with your end users, with your business managers, that allows you to make some midterm corrections so that you don’t wait until the very end then realize you could have done some self-correcting along the way.
So even though we label these things post mortems, I think there are timings throughout your project lifecycle that you ought to be checking in with folks to see how are things going, anything we can change up yet, anything we need to do differently before we move ahead for the next piece of this.
DH: What would you say is the most common mistake when conducting post mortems for SAP projects?
DW: Well, I think there are a couple of things. Number one: if we don’t ever do any kind of summary of what we discovered, and share that back with the people who have participated, there’s little motivation for them to want to contribute in the future for other post mortems.
So the most important thing is once you looked at the data and you summarized it and you have some kind of results to look at, you need to go back and close that loop, share that with the folks you had included in this, and provide them with some kind of an idea of which of these areas are you going to respond to, how are you going to make changes, how do you plan to use the feedback.
If I don’t see that as a person who has been asked to participate in the process, I don’t know why I would want to take the time to contribute in the future because I’m not seeing any results of what I just contributed to the last time. So I think closing that loop is one of the most important things to do.
DH: What about the personnel – who typically should be involved in post mortems? Is it everyone on the project team, or is it more focused on the IT folks, or IT and Business combined?
DW: I think there are several audiences and, depending on, you can either combine them in a group – I have a preference, for instance, to take the project team and to do a post mortem with them and collect those results, then go out and do some kind of a sampling of your end users. And you may want to divide that between the folks who are down and dirty and actually using the system. You will probably also want to go back and check with a certain senior level of management and executives to find out what they’re hearing and seeing. And, again, each audience I go to, you want to keep that information separate so that when you’ve got all of your stakeholders surveyed in some way you can start comparing.
So this gets down to that idea of perception. If I’m on the project team, I’m pretty near and dear to this, and I may have some biases that I just think this went really well under the circumstances. It’s always important to double check, ‘is my perception, the same perception that the executives have and what about the end users, how is their perception similar to what we’ve pulled out as a project team, or are there a lot of contrasts on that?’
I think there’s also an interesting result that we sometimes get is that some set of answers from the executives and the senior managers that isn’t even in line with what we get from the end users. So a lot of this is just drawing information, a sampling, from each of your respective stakeholder groups if you can’t include all of them and then taking a look at that and saying: what are the consistencies, where do we all agree that we got some areas we need to work on? What are some areas that we’re seeing real inconsistencies because then you may need to go back and drill down even further with that particular stakeholder group, to get a better idea of why did we not think in that same information, sometimes on the very same question?
DH: Do you have any suggestions on the best format for these reviews, is it best to do them in person or if it’s a distributed team, is it better to use some kind of video session or something.
DW: Sure, the first my preference is always to do at least a part of the post mortem in person, there is a lot of information that you will get just by reading people’s faces when you’re present with them. Everything from the subtle body language to being able to pursue a certain question even further so there’s a drill down process you get to do when you’re doing that in an in-person way.
Now, that’s not always possible and our organizations have virtual workforces and work distributed all throughout the globe, so you may be able to have some of your folks who are on-site at a certain location conduct parts of that with the users and with the team members who are not in a certain location.
Written is another good way to do that; I’ll be giving some tools and methods and processes that I use to do that that are very simple and yet they bring in lots of information and lots of detail. I think you want to do kind of a sampling of a number of techniques and distribute those across the organization – and again I’m looking for patterns, I’m looking for consistencies and inconsistencies. We’ll be talking about a number of possible ways to get this information anywhere from electronics, from the written, from the Survey Monkeys, from the in-person and we’ll go through all those techniques.
DH: Right -- I know projects can become pretty intense as the deadline approaches. Can the post mortem be used as sort of a chance to build back those relationships that may have been strained in the heat of the project?
DW: Absolutely, I think that’s one of the biggest benefits of doing this. When I talk about organizational change, there’s a saying that says people don’t resist change, they resist being changed. And so if we are able to do some of this in-person, interviewing some of our key stakeholders, if we are able to tie back to them because we probably talk to them when we started these projects and we kind of go back to them – this allows us to figure out are there are some bridges that were burned along the way.
Are there some perceptions out there that we were not aware of? There could be some frustrations that are quite easily resolved even as we are visiting with these folks. And so this gives us a chance to send a very strong message back to the stakeholders: we do care about you; we do want to hear your feedback and your input. And if you do that follow-up, well, you’re also going to be reinforcing that: well, not only did we get your feedback but here is what we are doing as a result of what you told us.
Every one of those kinds of events that you have with your stakeholders is one more step to building a more solid reputation and building that relationship with your stakeholders and that’s, I think, the thing that we forget about most when we are given these intense projects. We did an up-front current state analysis, we heard what they wanted and we just put our heads down, we started doing the work, and we didn’t surface until we are ready to go live. That’s where we have lots of problems, so this is all about keeping that communication two-way, keeping it on-going, working on those relationships consistently throughout the process.
DH: Right, and lastly: anything you plan to cover in your workshops you think folks would want to know about?
DW: Well, I think the biggest thing when I’ve done this presentation in the past is people realize this does not have to be terribly complex and time consuming. One of the tools that I will show them is three simple words that you use to solicit feedback. And every time I’ve used that technique I come up with mountains of good, useable information.
So what I want to really stress in this and I think the big ‘aha’ moment for folks is that they walk away from this and they say ‘you know what, this is not that big of a deal to do and yet the benefits we get from it are tremendous’ and so this is all about simplifying what sometimes can be a very complex process and in, you know, the same way again continuing to build those relationships. And I think that’s the other thing that we don’t give enough credit to these kinds of post mortem events that we are building bridges every time we do one of these.
DH: Okay, to find out more about those sessions you can visit sapprojects2013.com. Doug Whittle of Whittle Consulting, thank you for joining us today.