Playback Central: The First Session

Ed.: This is the first in a series of Q+A sessions focusing specifically on playback session best practices, with our in-house expert, Kris Komassa.

People like to talk a lot about collaboration between business and IT, but it seems like a playback session, as a collaborative, iterative process baked into the development environment, is where the wheel finally hits the road.

When you start any engagement, any project work, the existing tendency is for business and IT to split off fairly early, but I try to keep them in lock step as much as possible, which is important in order to be successful ultimately.

That first playback session is the first formalized opportunity to get everyone back in the same room and on the same page. We try to immediately do a level-set, making sure that everyone has the right expectations coming in, and a clear understanding what is going to be covered. We ensure that there is an agenda of what is going to be accomplished, both from a business and an IT perspective, and that both sides also know their roles and the various responsibilities for the playback.

Then once the playback starts, I’m really big on having an ongoing ad dynamic back-and-forth between business and IT, and typically at first it is driven by IT because they’ve been more hands-on to date in the first parts of the project. There are also instances, though, where the business side is driving because you’re doing more process flow at the first part of the first playback, which is important to note.

Ideally, it’s a combination of both, starting in that first session. The important thing is that in so doing, we carve out specific and concrete roles for both business and IT with any playback that we do, and especially on the first one, so that the interaction is defined and expectations are clear.

What are some of the things you have noticed as being especially challenging when that dialogue first begins? What have been some of the most surprising moments?

When it comes to best practices that we’ve learned since I started doing these sessions about 2 years ago, one big learning for the first session certainly has to do with executive-level buy-in. One client example I can use is from a bank based in Chicago. They are using Teamworks to regulate fraud-related processes. For example, if someone steals your ATM card, and you call in to report it - it’s Teamworks that picks this up and manages this process. They also have multiple instances of Lombardi running for them in multiple locations, adding to the complexity.

This particular client has been great to work with, but their IT project maturity was relatively undeveloped at the time that we started with them, though they have been very eager to learn what we’ve been sharing. We were taking more of a lead with this particular customer than we might with others with more experience under their belts already. Going in, we did everything right up to that point, did it totally by the book, and we were pretty happy with the way things were going.

But when we did the first playback, there were several big surprises from the business perspective. Basically, the executives were planning on seeing some things that they didn’t ultimately see. We had to take a step back and say “what did we miss here, and why did we miss?” After talking with the stakeholders, we found that they had very different expectations around the UI and that some of the process steps were out of order, or not entirely correct.

Ultimately, we were attracting all the right levels of input within business and IT, but with one notable exception — we didn’t have the executive buy-in that we needed. We had wrongly assumed that the right expectations had been naturally channeling upwards, but this was not the case. As surprising as it was for a group that had already been working together very closely, we were totally caught off guard by some of the feedback that we got from the executive perspective. Going in, we assumed that the executive level was very “hands-off”, but in reality they were very interested (a good thing) in what we were doing and had a much deeper level of process knowledge than we had originally thought (also good). But we weren’t as prepared as we could have been.

The solution? Between playback 1 and playback 2, we decided to do a playback 1.5. This allowed us to make some quick changes before we got to the next stage. It was a proactive mechanism more than anything else to make sure that we had everyone properly bought into the process. And as a result, before we did anything in playback 2, we were confident that we had that executive-level buy-in, because we had built that into our own process. Rather than assuming that our project had visibility and would naturally bubble up to the appropriate levels, we had to formally build in a way of getting that all-important buy-in explicitly.

The lesson learned here was that we had very mature and process-experienced clients and a really IT savvy staff, but we didn’t have what we needed in terms of proper executive-level playback criteria for what they were seeing in the session. We were able to bounce back quite quickly with an intermediary session. We also learned that we shouldn’t take anything for granted, and in terms of the level of involvement and the overall approach, it is best to emphasize our best practices re: criteria and buy-in much as possible. There is always the risk of a disconnect, but we learned to make our recommendations as strongly as possible to avoid issues like this in the future.

Ed.: This Q+A series on playback session best practices will continue over the next few weeks. If you have any playback-specific questions that you’d like to have answered, either as a follow-up to the content discussed here, or just in general, leave us a note in the comments!