Ed.: This is the third post in a series of Q+A sessions focusing specifically on playback session best practices, with our in-house expert, Kris Komassa. See our previous coverage here and here.

Of course there is never a “finished” process. How often do you typically use a playback session to fine-tune a process that is up and running? How often do you do this, once a quarter? Twice a year? Can you give us a few examples?

We have a customer in Dallas that is unique because they have a very wide sales force who are all remote and need a number of approvals before they can close any business. We finished a project with them just a little over a year ago, and we’ve since done a number of other engagements on top of that original project, so the work is more or less constant. They’re a good example of fine-tuning and building on top of a first project.

The way that I always start off the new work with them is by having them do a playback for us to see where we are, and then have that segue into a talking session around what it is that they want to see or what new work they want to have done for them. So, we start with what we have already, instead of starting with what we ultimately want. This helps to create that delta between what they have today and what they’re looking for down the road. They’re a very active customer and good to work with for this reason - each new project flows naturally and organically from the ones that have preceded it. I’d recommend this way of working from one process to the next for everyone.

Read the rest of this entry »

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

When you run a flow during a playback session, business people can jump right in and start suggesting additions, etc. How real-time are the changes that are made, and how often do you iterate feedback on a given flow?

It’s a difficult thing, actually, and it varies by playback. The highest priority for me is to capture any and all feedback accurately, anything that anybody blurts out or cites in the playback.

Then I like to, for anything that is able to be fixed immediately, go in and change it right then and there. First, this puts the business perspective’s mind to rest to have it displayed for them, right there in real-time. And second, we don’t have to worry about that specific piece of feedback after the fact as a lingering action item.

But the trick to it is that you don’t want the real-time revisions to turn into a long discussion of what we should and should not do. If someone’s requirement is very clear, then we’ll do it immediately in the playback, but otherwise we’ll take it offline and come back to it later - you don’t want to hi-jack the entire session if there isn’t consensus or at least a clear directive in terms of what needs to be changed.

Read the rest of this entry »

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.

Read the rest of this entry »