Using a moments of truth analysis to assess a team’s readiness for change

I have previously blogged about a number of approaches to assessing a team’s readiness for change, including the 7-S framework and the arenas of change approach, but today I thought I would explain a less well known approach – the “moments of truth” assessment.

Actually I made it up so it is not too well understood outside of my own loungeroom.  The approach is essentially the same as the 7-S style of assessing the interaction of the multiple systems, skills, stucture and other elements of the team’s whole ecosystem. But this is a little different because we start by looking at when (and why) the team’s internal or external customers interact with it.  Then we assess the team’s ability to support those interactions.

Moment of truth(n)  a moment when a person or thing is put to the test

Collins English Dictionary as quoted at http://www.thefreedictionary.com

Any interaction with a client is “a moment of truth” for the team. It tests the connection between the team’s value proposition, strategy, implementation, staff, skills and systems and it generates the experience that lasts in the customer’s memory until he or she interacts with the team again.

A “moments of truth analysis” therefore starts by identifying the interactions a team has with its customers, stakeholders and potentially vendors.

Continue reading “Using a moments of truth analysis to assess a team’s readiness for change”

Advertisements

Preparing for a stakeholder interview part three – using “FOC”

I have just published a couple of articles on preparing for an interview. The first was on clarifying the goal for the interview and the second was on using an approach I called GRIFT to create a more robust structure.

The final stage of preparing for an interview is to come up with an agenda and preferred set of questions.  In some cases you might use a very detailed and structured approach, while in others you might not spend any time preparing your questions.

Either way it helps to have an overall structure for an interview and one approach you might try for this is to use “FOC” or Frame-open-close. You can use this approach when preparing for an interview or you can use it without any more preparation as the interview starts.

Continue reading “Preparing for a stakeholder interview part three – using “FOC””

BA’s need to learn question tennis before they end up as dead as Rosencrantz and Gildernstern

One of my favourite plays is “Rosencrantz and Guildenstern Are Dead”. It is the story of two confused people who are friends (?) with Hamlet (and minor characters his story).

Question tennis

One of the best scenes in the play is when the two characters play a game of “question tennis”. It is worth watching this short video if you haven’t seen it.

http://www.youtube.com/watch?v=fGEYFE7e_R8

The idea of the game is to keep asking questions so the conversation is always in the other player’s court. So each player must answer every question with a question. If they mistakenly answer with any other response then the other player wins the point.

But how does this relate to being a BA? Well, this is where I think a lot of BA’s run into trouble.

Continue reading “BA’s need to learn question tennis before they end up as dead as Rosencrantz and Gildernstern”

Preparing for a stakeholder interview part two – using the GRIFT model

The goal of your interview is the single most important thing to know before the interview, but it is also useful to know a bit more about what you are hoping to achieve before you start the interview.

So that is where I use the powerful “GRIFT” model to do my preparations.

Actually it is not a very powerful model, it is simply a checklist of things to think about, in some sort of order, before interviewing someone. GRIFT is short for the following headings

  • Goal (as defined in my previous article)
  • Roles (What is your role in the interview? What about the stakeholder?)
  • Issues (What issues to you think you might encounter? What will you do?)
  • Focus (What is your focus for the interview?)
  • Takeaways (What will you deliver as a result of the interview? Are there any action items?)

Since I explained the goal in my previous article I will explain the remaing items in this one – RIFT, I guess.

Continue reading “Preparing for a stakeholder interview part two – using the GRIFT model”

Preparing for a stakeholder interview part one – setting a clear goal

You might be surprised to find out that people often turn up to interview a stakeholder with little or no preparation.

You would probably not be surprised to find out though, that when the interviewer is poorly prepared, the interview results in a conversation without a real resolution and the interviewer has missed an opportunity to get off to a clean start.

So I thought I would add a simple (but very long) guide to some ways you can prepare for an interview. This article, and a couple that follow, are based on the “GRIFT” model that I developed while training BA’s.

Continue reading “Preparing for a stakeholder interview part one – setting a clear goal”

To be customer focused, shouldn’t we also be problem focused?

I have at times been accused of being too intellectually pure – apparently I can have a habit of analysing a problem when all that is needed is to get moving with a solution.

It may be true because I love to understand puzzles and problems. Perhaps it is true because I do enjoy playing those corny puzzle games on my outdated nintendo gadget even though I have no time left in my day and even have access to far more sophisticated games if I want to try them.

So maybe what follows is good advice or maybe this is my own bias.

I recently saw some great proposals for small projects and some pretty decent requirements. I could understand what people were proposing and even who would be using the solutions we were providing. And my advice each time was the same – “we are clear on what we are doing but not really why”.  In response people told me we were doing it because these customers want it (our team, people who purchase our software etc).  When I then asked why they wanted it, the response was “so they can …. “.

They can do (what our requirements say) but that is repeating what their requirements are, not explaining why they have them or how we know those are the real requirements.  So I generally asked why again and got a reasonable response:

  • They told us they want it; or
  • We can see them doing it now (or having that problem now).

Maybe this is enough – if people want it and they will use it then isn’t that why we build solutions?

Unfortunately the intellectually pure part of me detects more of a puzzle to wrestle with, so I am hassling people for one more piece of information – What specific problem are the users/customers going to solve?

Continue reading “To be customer focused, shouldn’t we also be problem focused?”