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 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.

When do customers interact with the team?

Starting this analysis is quite simple, although it could potentially be time consuming.

1. Find out what products or services the team provides to customers or stakeholders. This would involve their official products and also complaints, requests for information and other “back-office” approaches.
2. For each product and service, identify the times and context in which the customer interacts with the team. These are the “moments of truth”.
3. For each moment of truth, find out why the customer is interacting with the team and what they want to achieve out of the interaction.

What happens when customers interact with the team?

The next step is to understand how the team interacts with the customer in the moment of truth.

• Who initiates the contact?
• Is it a one off thing or part of an ongoing process?
• What happens?

Once you know when and how customers interact with the team you can map these into the series of interactions that typically create a “customer journey”.  This is the simply a typical accumulation of interactions the customer has with the team.  For  an internal accounting support team the journey of one of their customers (department heads) might be:

• Establish budget
• Receive monthly report
• Query strange amounts
• Request ad hoc report
• Prepare next year’s budget

Mapping the interactions from the team’s perspective

This is the point where you start to analyse the things that may be impacted by any changes you make to the team, as well as anything that could go wrong or be improved.

For each interaction you can ask questions such as:

• How often does this occur?
• How long does it typically take?
• Which other interactions will potentially impact this experience?
• What is the context in which this interaction is taking place?
• What was the last interaction the team had with the customer and typically how long ago  would that interaction have been?
• What inputs does the team need to support this interaction?
• What comes out of the interaction – from the team’s point of view and the customer’s?
• What skills and knowledge does the team member need to deliver this service?
• Who in the team is involved?
• What guides, manuals or tools does the team member rely on?
• What measures or service level agreements does the team have in place?
• What might go wrong?
  • What would cause this?
  • What would happen if it did?
  • What would happen next?
  • How might any potential changes make this interaction better or worse? Which of the above aspects of the interaction could potentially be impacted?  Which could negatively impact the potential change?

Assess the supporting processes if relevant

Once you have mapped out the moments of truth you can also map the internal processes that the team performs in order to be ready for those moments of truth.

Wrapping up the moment of truth analysis

The final stage is to consider how each of these elements interacts with the others to support or hinder the team’s ability to provide positive “moments of truth”. This can be combined with the 7-S or arenas of change approaches to understand how the team is currently set up to provide its services and how resilient they will be if and when you implement a particular change.

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.

Open and closed questions

Closed questions are those that require a short answer that is generally something the stakeholder could choose from a list (ie they have a finite or closed set of possible answers to choose from).

Closed questions include:

• Is that true? (Choose yes or no);
• What time did you get home? (Choose a time); and
• How many people went to the restaurant? (Choose a number).

Closed questions are good for restricting the answers you get. They limit the stakeholder to providing the specific information you want. But they also restrict the stakeholder from exploring or explaining a topic.

Open questions are the opposite. They provide the stakeholder with an infinite or open set of possible answers to choose from.

Open questions include:

• What happened?
• How did you do that?
• Tell me more about the issue (a statement that leads to an answer).
• Why did that happen?
• So what – what impact will that have?

Open questions are good for gaining an understanding of the subject matter and for exploring a topic in detail.

Framing the question

Sometimes an interview might feel very “stilted” or fragmented. The interviewer asks a question, the stakeholder pauses and then gives a vague sounding answer and then the interviewer pauses before asking another, unrelated question. It may seem to the interviewer that the stakeholder was reluctant to provide information while to the stakeholder it seems to be a disjointed and uncomfortable experience.

Where this is the case it may be that the interviewer is asking good questions but is not providing any context or structure to help the stakeholder think about and respond to the question.

For example, let’s assume that Steven grew up in Melbourne Australia. His family owned restaurants and he often worked in the kitchen after school.  He is now publishing a cookbook that includes a lot of the recipes he learned growing up.

An interview could flow like this:

The interviewer might get better answers if he or she asks open questions. But even then, the questions might come out as disjointed or unconnected, making it hard for Steve to answer without having to stop and think about each question.

On the other hand the interviewer could frame the conversation with a short introduction and then ask a simple open question:

Framing the question like this gives Steve a context within which to understand the question and also helps both Steve and the interviewer to create more of a flow in the conversation.

FOC – Frame – open – close

FOC or Frame-open-close is an approach to creating a structure around the questions.

It is often better to ask an open question to open the topic up for discussion and then follow on with a closed question to confirm that you understood what was being said. So it is common for experienced interviewers to deliberately plan an interview around open questions, which are then supported by closed questions to confirm or clarify your understanding to the answers given to the open questions.

Rather than just asking a question though, you can start by providing a short statement (or “frame”) to prepare the stakeholder for the type of question that will follow. Just as a picture frame is designed to help the viewer to focus on the picture, a frame in an individual helps the listener to focus their thinking on the question being asked.

This then gives you a pattern to follow:

1. Frame the question with a short statement to give your stakeholder some context.
2. Ask one or more open questions to explore the topic.
3. Ask closed questions or summarise what the stakeholder said in order to confirm your understanding before moving onto another topic.

FOC as an agenda for the interview

Just as you can structure your questions around a topic area by using FOC, you can do the same for the agenda of your interview.

This will at least give you a structure for the interview.

• You will start by framing the whole interview with an opening statement and then you will ask a series of questions.
• Your main questions will be open questions to allow the stakeholder to give a more detailed explanation than if you asked all closed questions.
• Finally you will sum up the interview by running through a summary of what you learned.

But of course for each open question you can also use FOC to create context and confirm your understanding of each major question or topic area.

For a more complex interview, you may find that the GRIFT approach (explained above) can provide the content you can use to create an introduction (or frame) for the whole interview.

The interview may also cover a number of topics that each consist of a number of questions and also justify an introduction (frame) and summary (close) to support those questions.

Similarly, a complex interview will often end with a list of action items as well as a summary of what was covered in the whole interview

The FOC approach can therefore be scaled up to give structure to the agenda and then scaled down to give structure to the individual questions.

In practice I often also use my “question compass” to explore each area.  I do this by using a structure like this

(new topic – frame): Which brings me to the question of how you incorporate ethereal conductive cooking into your recipes

(open – question compass): What do you mean by ethereal conductive cooking … etc

(Close) So ethereal cooking is a key part of what you do. (next topic)

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.

Questions in stasis stay in stasis

It is very common for a BA to ask a stakeholder a question the stakeholder does not know the answer to.  Then the stakeholder leaves the question for the BA to answer, but the BA does not know the answer so he or she parks it to be answered later.

But of course the question will not get answered since nobody is attempting to answer it. So the BA needs to learn to hit the question back to either the original stakeholder or someone else.

So when the BA hits a dead end then he or she should respond with “who can help with this?” then they should formulate and pass on the questions they have as soon as possible. Otherwise the issue seems accumulate more related questions until the BA ends up in a state of temporal stasis (ie they are frozen in time).

Questions with inconvenient repercussions lead to infinite delays

Many questions result in people finding out that they will have to make a trade-off between to related desires. But humans hate making trade-offs to they will subconsciously answer inconvenient questions with vague responses, general discussion points or responding questions.

Unfortunately, since the original question started to unearth some things people want to avoid, the vague responses will sit with the BA until the issue becomes urgent and then everyone will wonder why the BA is not doing anything, while to BA will think that he or she is waiting for more concrete information from somebody (or several people).

Once again the best thing the BA can do is hit the question back quickly. In this case the best solution is probably to ask very concrete and specific questions that will allow very little wriggle room.

The stakeholders will often respond vaguely two or three times in a row but persistent, concrete questions will eventually lead to the right outcome.

Interesting points

Often when a question is asked, a stakeholder will respond with “That raises an interesting point” or “I guess the real question is …”

Of course in both cases the response is not really a response to the questions but rather a potentially new question. So the best thing the BA can do is to immediately ask a question back, either to come back to the original issue or to explore the point just raised. Failure to do so will leave the ball sitting in the BA’s court.

In all cases

In all these cases and many more you might be able to think of, the best thing the BA can do is to ask clear questions of specific people as soon as possible when a question bounces back on them.  They may need to hit the question back several times, or even redirect it several times, but failure to come back with a questions means the BA will start to come under pressure to find the answers what people assume are outstanding questions.

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.

Roles

You will be interviewing and the stakeholder will be answering your excellent questions, but there might be more to the roles than that.

Who are you that the stakeholder should answer your questions?  It is important to establish your credentials and to be clear about why it is you that is doing the interview. Some things you might consider include:

• What project/team or company are you from? What does this mean to the stakeholder?
• What is your role in the project? Is this confirmed?
• In some cases you might also need to think about how you establish your credibility at the start of the interview.

Sometimes you will be working with a partner to do the interview, so it is important that you both know what each of you is doing. Is one the lead interviewer? Are you both taking notes or is just one of you? Are you taking it in turns to ask questions?

In a similar way, it is important to understand the role of the person you are interviewing. This might partly be dictated by their job title, but might extend to a more specific role such as:

• The expert in the field;
• The one sponsoring the project;
• The gatekeeper for the sponsor, speaking on their behalf but not in charge; or
• One of the stakeholders involved in the project.

Taking this even further, you might be interviewing them because they are the decision maker, the one who proposed the project or someone who is potentially negatively impacted by it. So you might change the structure and style of your interview based on the information you gather.

You might summarise your thinking by creating an “elevator pitch” that you can use when booking and beginning the interview.

An elevator pitch is a short statement (less than 2 minutes) that sums up what you are explaining. For example you might come up with:

Hi my name is [me] and I am [my role relevant to the interview].  I/We would like to find out [my goal] and thought you would be the right person to speak to because [person’s role]. Can I book half an hour to speak to you this week?

At this point you can also confirm that you are interviewing the right person or people (and that you are the right one to do the interview).

Issues

Now that you know your role and why you are doing the interview, you should stop to think briefly about any issues that you might encounter.

For example, you might need permission to speak to your stakeholder or it might be hard to find meeting rooms.  You might even encounter more serious issues like having to overcome a credibility gap because they do not support the work you are doing.

Once you discover any potential issues then you have a chance to think through how you can deal with them before you turn up at the interview.

Focus

Even though you know the goal of your interview, you might still want to clarify your focus for the questions you will be asking. For example, you might be focussing on specific aspects of the project, or you might just be focussed on setting up a plan to go forward with you communication strategy.

More specifically, you might find that you gain greater clarity and focus in your interview if you think about what questioning domain is:

1. Are you just doing the interview because you need to engage this stakeholder (hopefully not).
2. Are you confirming information you already believe you know? In which case you can provide that information and clarify it rather than asking a lot of general questions first.
3. Are you seeking the answer to specific questions? In which case you might list those questions out before the interview and make it clear at the start of the interview that this is what you are after.
4. Are you seeking to learn whatever the stakeholder has to say? This will mean a lot more open questions and a lot more clarification as you progress.

Understanding the focus of your questions will help you to keep on track in the interview and also help your stakeholder to understand the information that they can provide to help you.

You might also find that you get better results if you are clear on whether you are focusing on understanding:

1. The problem – in which case you will probe into the symptoms being experienced and the possible root cause(s) of those symptoms.
2. The vision the stakeholder has for a solution – in which case you will be asking questions about what they plan to do, how it will make things better and what it will take to achieve the vision.
3. An emotional or subjective reaction – in which case you will be asking questions about how the stakeholder feels about the topic or how others are likely to react.
4. The relationship you have with the stakeholder – in which case you will focus on questions and discussions that lead to establishing rapport.
5. The plan – in which case you will already know the vision for a solution and you will be asking about the steps needed to achieve the vision, the resources needed and the obstacles or constraints that will need to be dealt with.

It is possible to have a multiple focus in the interview, but if you do it will generally be easier to divide the interview into discrete sections, each of which has a specific focus.

Takeaways

Once you know the goal and focus for your interview you will know what you want to get from the interview and you can round this off by being clear on what you will do with the information or outcomes when you get them.

In many cases you will simply be collecting some notes to take away with you and if this is the case then it is a good idea to explain this to the stakeholder at the beginning of the interview. They might be curious to know what you are going to do with the information and if the learn this then they can structure their responses to support your goals.

In some cases you might be recording a transcript, an audio recording or a digital recording of the interview. If this is the case you may need permission from the stakeholder and you might need to plan time to ensure the tools and environments are available and suited to your needs.

Quite often though you will be preparing a report, a recommendation, a requirements document or a communication plan based on the interview. Clarifying what you are doing in this case allows you to confirm the questions you are going to ask and the sorts of things you will need to get out of the interview.

You might also require something from the stakeholder at the end of the interview, such as an introduction to the other stakeholders or agreement to you plan. In this case you should think about what you might want before the interview.

Similarly, you might find that you need follow-up information or further links and references. So before you go into the interview it might be beneficial to think about how you will get information. If you know you want things sent via email then it is natural that you would be ready to provide an email address to the stakeholder, for example.

Once you have all of this done, you are fairly well prepared. You should still spend some time defining your agenda and preferred questions, but you are now in a good position to do that, with the GRIFT model providing context and boundaries for the questions.

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.

This article covers the first part of the model – setting a clear goal for the interview.  The next article covers the remaining letters of the term – RIFT (being clear on the roles, issues, focus and takeaways associated with the interview).

The model is simple and hopefully useful way to think through the things you need to do before turning up to interview someone.

The model is also included in my change management course (available from in Australia and NZ through Software Education. Or you can contact me directly if you want to learn how to run the course yourself).

Anyway – on to the tip for today …

Be clear on why you are doing the interview

The most important part of preparing for an interview is to be clear on what you want to achieve.

If you are clear on your goal then the rest of the interview usually falls into place, while if you are unclear then you will usually get to the end of the interview without really being clear on what happens next.

In some cases the goal is pretty clear because you know what project you are part of and you are simply clarifying the scope for the next piece of work you are doing. But in other cases you may not know much more than the time of the interview and the person you are speaking to.

One approach to setting a goal is to use the focussing question approach:

How can [I] find out [something] from [the stakeholder] so that I can [something]

To use this approach you simply fill in the blanks:

• Who is doing the interview (you alone or you and X)?
• What information are you trying to get from the interview?
• Who are you interviewing?
• What are you going to do with the information you gain?

This seems simple and yet many people go into an interview without knowing these simple facts.

Generally in the initial interview you will be trying to find out:

• The goal of the change you are communicating or planning;
• Your role in that initiative; and
• The expectations the stakeholders have of you, in other words your scope and deliverables.

So your goal statement for an interview with a stakeholder called Sophie might look like this one:

How can I find out what Sophie expects of me on this project; From my interview with Sophie and by reading the project brief; So that I know who to interview before preparing my proposal.

However when you try to put this simple statement down on paper you might find that you actually want to find out quite a lot:

• Is Sophie really the sponsor?
• What is the project all about?
• How long will the project take?
• What is my role supposed to be?
• What is the scope of the project? What is my scope?

So the idea of trying to come up with a clear goal is to give you a chance to think of these things before you do the interview.

In fact even if you were ambushed by having to do an interview at short notice (and had no idea what was going on) you might still use this format to clarify what you are doing:

• How can I find out why Peter called me in for an interview without looking stupid …
• From Peter and John who are both in the interview …
• So I can avoid looking silly and still get a role on the new project.

If you do nothing else before sitting down to interview someone, working out your goal for the interview will still provide you with a pretty good chance of getting the right outcome from the interview.

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?

Most of the time the answer I get is the same – the problem they are solving is that they want to do this.  But I am still trying to work out what difference that make to them.  They are doing this so that (something is better) but what is better?

The answer I get is often that they can sell more stuff or do things faster.  But I still think there is a missing link and this is what I am wrestling with.

This is the requirement … it is for this specific user.  They want it because it will remove a problem or allow them to do something new

… but what is that thing and why do they want it?

So here are my new questions

1. Who is this for?
2. Why do they want it? Cool is that the real problem they have or is it a symptom of the problem?
   1. People often deal with symptoms of underlying problems, without really knowing the real problem.
   2. For new solutions people often ask for “accomodations”. An accomodation is a solution that is needed to compensate for the weaknesses in their current solution. Fo example, “we need more spare parts” might be caused by the weakness that our existing spare parts are poor quality and fail too often.  More spare parts will help, but better would be to remove the need for more spare parts.
3. So what problem are they solving when they get this?  What problem will they still have?  is this second problem the one we
4. Do they know they have that problem? how important is it compared to other things? How often do they have the problem?
5. What solution do they have in place at the moment?  (I know they don’t have this thing yet but they might have something even if it is hand-written post-it notes on their fridge) Have they tried anything else that hase faded away?
6. When we solve this problem, what happens next?  What will they want next, what will their issues be with our solution?

Maybe I ask too many questions when we have already been told what they want.  When I send people off to ask more questions they often get the response that things are urgent and their questions are slowing us down – “we know the requirement already -so let’s get on with the solution?’

We know the requirements already – we need to move onto the how we will implement the solution.

But if we are focussed on providing a solution we should know what we are solving shouldn’t we? And even if we know what the requirements are – what are they the requirements for?

Maybe I would settle for this much (but i will still have more questions).  In the book “Four Steps to the Epiphany” they recommend these questions for early adopters of products

1. Who is it for?
2. What problem will it solve for them?
3. Is it already hurting them? ie are they aware of the problem and if so how important is it to them?
4. What solution do they have in place?
5. Do they have a budget to pay for the solution?

But even then I will secretely have one more question, I can’t help myself – Who will this not help? Or who might use this but won’t care too much?  Then rather than solving the generic problem for all our customers (and being “lot’s of customers focussed), we can solve a specific problem for a specific customer.

I am presenting to the IT people of the future on what agile is (and is not).

Here is their rather long link to the presentation:

http://www.acs.org.au/nsw/index.cfm?action=event&area=9001&temID=eventdetails&eveID=30229661985484

Come along if you are local and part of the group (or can sneak in).

It is designed for experienced project managers and other project leaders who understand the fundamentals of project management and I am running it as part of the ongoing education program that the Sydney chapter of the Project Management Institue (PMI) run.

As well as my great presentation you will find they have a lot of good courses and workshops for project managers who are part of the PMI group in Sydney.

The course covers the fundamental principles that I see as underpinning agile approaches and is NOT a certification course nor an introduction to being a project manager if you have not done the role before.  But it will be a full-on day covering

• A brief context around where agile came from and what it is
• The concepts of value creation and waste in projects
• Adaptive planning and how it compares to traditional project planning
• The concept that success or failure really comes down to the people in the team and how they interact with each other

Here is a link if you want more information:

http://www.pmisydney.org/index.php?option=com_content&view=article&id=280%3Ashort-course-agile-principles-for-project-managers

Let me know if you are coming.

In fact SCRUM and agile approaches even try to define the bare minimum number of meetings that are needed and only have them (Actually one of my friends claims that they have removed all the meetings – “In agile we don’t have meetings, we only have workshops.  Meetings are discussions and Workshops produce something tangible each time”).

Yet the reality seems to remain that meetings (or workshops, or gatherings, or war councils) often end up getting in the way of doing the real work:

So what would you do if you had to look at the return on investment of each meeting?  Would they actually stack up from the point of view of making money for shareholders, making life easier for the crew or improving the experience for our customers?

I think it would be fairly easy to classify most of the meetings we have as:

1. Adding value – this meeting makes life better;
2. Necessary waste – I wish we didn’t need it, but we need to do it because we don’t have a better alternative; and
3. Complete waste – I would rather take the free donoughts and eat them at my desk.

I also think this is easy to do if you look at which meetings add value or create waste if we use the following structure that I often share with business analysts. Each meeting should have three things in it:

1. The framing of the meeting
   • State the goal or purpose of the meeting
   • Clearly state what is expected at the close of the meeting (eg minutes, an agreement, an action list etc)
2. The opening of discussion
   • Creating a list of things to be discussed, each of which is a mini-meeting. In other words we should not just wander randomly through topics as they come to mind (unless that really is the purpose of the meeting).
   • For each topic or agenda item, we can therefore create the following for it
     • Frame or introduce the goal of the topic and what we expect to get from the conversation
     • Discuss it
     • Close the topic by confirming what we found out, agreed or need to do next.
3. The closing of discussion
   • This could involve agreeing Who does What by When; or
   • This could include confirming what has been agreed and how it will be communicated (ie What will be communicated When by Who); or
   • This could include a summary of our analysis – eg documenting the requirements by Who and When.

We all have too many meetings, but if think of meetings as work then we should put them down gently or define how we will get value from them. I am sure your team is already super-double-extra agile, but with my team I sometimes think we need to go back to basics.

So we can’t do better then I am going to ask my crew from now on to at least agree to only turn up to review their meetings and either

1. FOC them (define the Frame – Open – Close for them);
2. Define them as necessary waste and come up with a plan to either make them really add value or make them unnecessary; or
3. Define them as waste and eliminate them unless there is good catering (actually – eliminate them anyway and move the catering to a useful meeting).

But there is not much I can add to this one.

People sometimes ask me for links to some of the material they see, either in course material or when I go wild and draw random things on the whiteboard/wall. So here is a link to a new initiative set up by the agile alliance. It appears they are finding and listing the wide range of techniques that people describe as “agile”.

It will no doubt be a good place to go if you are trying to understand the different “agile” practices  and potentially how they link together.

http://guide.agilealliance.org/