Anatomy of an analysis session

Anatomy of an analysis session

Today, onsite at a client, I made a mistake in an analysis session, and in thinking about that mistake, I thought I’d capture some of my thoughts about the process I go through during these analysis sessions. Very VERY rough and some very amateur psychology, so bear with me, and give any comments you think are worthwhile. These are all things I do from experience rather than had planned out in the manner below.

Just to be clear, I’m talking about a project analysis, done to determine the needs for an implementation or development effort, not an industry analyst.

So what was the mistake I made? I listened to the people in the room who said we should start without waiting for one of the other attendees we were expecting. With the advance knowledge that firstly the senior members of the team were all present, and the other members of the team could adequately explain the processes he fulfils in the team, I agreed, something I would normally never do.

So why was it a mistake? To explain this, I need to spend a little time talking about what the objectives of this sort of analysis is.

In these analyses, typically workshops with particular functions at a company, your role is to discover requirements ~ typically executively mandated, and, at least in the business intelligence space that I play in, cross functional requirements. So going into this analysis, you have met few or none of the people involved, and they have little or no idea of what your role is and why they’re there, they got an email to arrive from their boss.

Your secondary role therefore is to get their buy-in to the general idea of the project you’re analysing for ~ no sales talk, just the idea that you’re on their side. You’re not an external consultant who’s going to make life difficult by changing things, you are there to help them.

Easier said than done right? Well, no, by nature people are friendly once you get on their side.
First tip: Use a boardroom/meeting room rather than an office, and arrive first. This way, even though you are at their offices, they’re arriving in your space.

As each person arrives, get up and introduce yourself individually. Hell, this is just common manners, but the number of consultants I’ve seen that treat this as “just another person from the client” shocks me. Don’t however introduce your company yet.

NB: Don’t start or introduce your company til everyone arrives. Do make small talk. This breaks down the barriers with the people who are already there, humanises you. And, for the person who you’ve waited for, it makes them feel like you think they’re important.

In addition, it means that everyone hears your introduction. And your introduction is vital to making the session productive.

Introduction

Start by restating your name, many people won’t have caught it during the introduction. Next your company, then tell them who brought you in ~ this association starts making you part of their company, puts you in context, and gives you an authority (if you’re working for the exec team of course… If you’re doing work for the HR team, forget the authority. But the rest matters). Explain the objectives of the initiative (you don’t know the objectives? That wasn’t the first workshop you had? Begone with you!), and be very clear about saying that no plan to build (implement/develop etc) anything is in place, that you’re in the analysis phase, and you *absolutely* have to have this groups feedback in order to decide what to build. Also be clear that there is a higher authority though, so it doesn’t bite you when do a different functions development first…..

Why is this so important? Well, as was demonstrated to me today, the late comer came in and to him it feels like we’re planning on doing something ~ so rather than saying “we have a pain here”, his approach was “how do you plan to fix this?”
And I can’t emphasise this enough. You are not here to fix anything yet. You are just finding out what to fix. By all means, if something has an obvious solution, you can say “oh yes, if we do X for you, that’d solve this easily ~ you are trying to get them excited.
The next thing I do is get each person round the table to give me a 5 sentence intro ~ what’s your name, what’s your title, what do you do?
It lets you get a chance to catch their name and politely capture it as part of your notes, and breaks the ice for those who otherwise wouldn’t have said a word so far.

So that’s the kick off ~ how to run the analysis? I’m going to touch on a couple points, but this is so very different from technology area (BI, MDM, custom dev, etc), from client to client, and even from workshop to workshop that there is no formula ~ but some guidelines that I use.

Start with a high level functional overview ~ what are the outputs that this team produces?
Move onto a process oriented discussion ~ how do you achieve this?
You’re likely to get a lot of “this doesn’t work, this would be cool” comments. Note them, but don’t take note of them yet.
Then, if you can, have them show you some of the work they do. Quite important, you aren’t really going to get a handle on it til you see it, and it’ll bring out the things they do they don’t remember that they do (90% of their jobs it sometimes appears!)

Summarise routinely to make sure you understand.

Your final step, and this is key: ask them which of the things they’ve mentioned so far are their pain points. Two things will come out. Something they’ve spent a lot of time explaining and saying “this little tweak would be cool, that little tweak will be great” will turn out to be something they accomplish pretty well ~ they’re proud of it, which is why they’re showing it to you. And something they haven’t mentioned (or glossed over) will turn out to be the biggest pain. It’s your role to mediate the differences, and come out with a list of priorities on the pain points. THIS IS NOT THE LIST OF PRIORITIES TO DEVELOP. This is just the biggest set of pains this team has. Often, the biggest pain is just going to have to stay the biggest pain because letting these guys deal with it is the most efficient way.

Final piece of your workshop is go over how the rest of your analysis is planned, when decisions are going to be made, and that they’re going to be invited to a regular user group even before their phase is allocated to start (WHAT!? No user group? BEGONE FOUL SHADE) so they can see how the other phases are progressing.

Quick overview, give me your thoughts.