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.

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

So far we have been looking at how to do some testing, and then do some basic scripting and mapping as we do more testing. In doing so we have (hopefully) been learning more about the system we are building but our main focus is on making sure it is still performing the way we want to.

Now we are going to evolve our testing onto a proper OODA loop.  I have created another article to explain what an OODA loop is, but for our purposes it means this:

How fast and how well can the team move between the following 4 tasks?

1. Observe the world around them – the way users are operating, the way the system is performing and the way things are coming together.
2. Orient themselves or make sense of all that data (interpreting, analysing, integrating and assessing).
3. Decide what to do next with all that information.
4. Act on their decisions as a cohesive group.

To do this we need a little lesson in OODA regression testing theory

Regression testing is a series of loops not one straight line of work

With regression testing, most people think it is like a line rather than a loop:

1. Understand the system
2. Create some scripts and then make a list of them (map them)
3. Run the tests to break the system
4. Fix the bugs

But this misses two key ingredients in our OODA loop – both of which are related observing what happens when we act and then learning from it:

• By running one set of tests we should be able to learn more about the system so we can test it better next time; and
• By running one set of tests we should be able to learn more about the system so we can use that knowledge to update our requirements, create training material and pass what we have learned on  to others.

So the real process looks a little messier when you first look at it:

But that looks like a lot of work

Fortunately it is really what we have been doing in day 1 and day 2. So for the next couple of days we will simply repeat what we did in day 2, and add these questions:

• Should we improve the way we capture and track bugs?
• How do we pass potential new requirements? Who should decide whether to act on these?
• How can we improve our test scripts and maps?
  • Should they be more sophisticated?
  • Should we drop some in favour of more exploratory testing?
• How do we pass on what we are learning?

Each of these questions relates to one of the Act boxes in my diagram and you will notice that each of them then becomes another OODA loop within the model.

My suggestions for early improvement

I think it is a good idea to start writing out the most common or critical test scenarios in a “Use Case Like” format.  This turns out to be a good way to pass on information for training, a good way to automate and a good way to show people what to do when they are testing the ssystem

I also think it is a good idea to at list start collecting a list of questions and known (or expected) answers.  This is often done in the format of an FAQ.

I think it is a good idea to write down the work arounds your are finding. If these never get fixed then you have some warnings to include in the release notes. Of course, they might be fixed later but even so it will be useful to remember them as you continue testing.

Finally, I think you will realise that  your are finding several “trivial bugs” that the team don’t want to fix. Rather than tracking these as defects or “unlikely to do requriements” you could also record them in an FAQ like format so that they become known errors or, in common IT terms “Unexpected features”.

So you can see that I don’t see regression testing as breaking the system. Instead it is the engine that is driving our continual learning (and hopefully improvement) of the system.

But it leaves two questions unanswered:

• Where would you start if you actually had to do a performance agreement; and
• How would you actually know what was expected of you if you didn’t?

The situation is made worse, according to the links in Shane’s article, when you want the team to be jointly accountable for shared success rather than individual success.  This is important if you want to work out how to evaluate testers or BA’s for example, because their purpose is to make the team successful rather than to stand out on their own.

So here is my first attempt at a pragmatic performance agreement:

Performance agreements are conversations rather than documents

Rather than trying to write out a performance agreement, just ask yourself these questions.

When you are done, ask your boss and key stakeholders the same questions. I suspect that each person you speak to will have a different view and this should highlight a number of key issues that you need to resolve, that would not normally be picked up by a written performance agreement.

Of course, you can and probably should document your performance agreement now:

Fill in details below

Now go back and check what your boss and key stakeholders think. Don’t let them off the hook though, push them to rank your responsibilities and add as many as they want, subject to then listing which are the top 3-5.

You can then add option fields to add more depth to the agreement if you want still greater clarity and focus.

Obviously this is hard. But I think it will highlight the key expectations you and others have for the work you are doing.

But now we have a baseline, you want to use this baseline to review your progress and also adapt to the inevitable changes that are occurring every day.  Read my OODA loop article and see if you can find a way to apply this to your continuously evolving performance targets.

This last bit is hard so maybe you can find a better way. Otherwise this whole thing is just a starting point for more conversations with your boss and stakeholders. But then I guess that is the point, we want to have a starting point to orient ourselves and then we want to continuously improve the conversations we have.

I guess I am still a bit old school, because I still think the OODA loop is the essence of the agile approach.

So what is an OODA loop?

OODA loops began as an approach for fighter pilots to avoid dying. It is a way to train fighter pilots and also a way to design fighter aircraft, develop tactics for air combat and win wars in the air.  It turns out that it is also really useful for agile projects, production support teams and anyone rolling out a product in a competitive market.

But what is an OODA loop?

I am only producing a quick summary of the idea here because I want to adopt the approach when I am doing some regression testing. But you can get more information by going to Wikipedia and exploring the links it has there.

The basic idea goes like this

• In a rapidly changing world, you can come up with a plan but it will be out of date before you can text your friends to tell them that you plan is ready to share.
• So rather than just executing your plan you need to get really good at observing, interpreting and reacting to what is happening around you.
• But as you react, you also impact the world, which then reacts to what you have done and is immediately different to what it was when you started to react to it.
• So now you need to observe what is going on again, interpret it and react again faster than your competitors because otherwise you are always playing catch-up.
• What is worse though is that it is not only about how fast you react, but how effectively you do so. If you are acting on the wrong information or you are interpreting it incorrectly then that is often worse than not reacting. So you need to be really, really good at observing, interpreting and reacting to things.
• But things get even worse, because you cannot just react to what others do, you need to also take the initiative and come up with new moves and new ideas before the other guy does.
• But of course while you are getting good at observing what happens and thinking up cunning new ideas, the world is moving so rapidly that you already need to be reacting again.

And so the loop repeats (unless you are a fighter pilot; in which case you will be shot down before you react).

But what is the OODA loop?

Based on all of this, some guy called John Boyd came up with the idea that a fighter pilot will be successful if he or she can be both really fast and really effective at doing the following four steps continuously:

1. Observing the world around you:

• For a pilot this means noticing what the instruments are telling you as well as what is happening outside your cockpit (eg what your friends and enemies are doing, or whether what you see contradicts what your instruments are telling you; and
• For a project team this means observing the impact that your previous decisions and actions have had, as well as how the evolving system is performing. And in some cases it also means observing what your competitors, suppliers and business customers are experiencing.

1. Orienting yourself to what you observe:

• For a fighter pilot this means making sense of huge amounts of chaotic, complex and often contradictory information as you observe it. The problem is made worse because the pilot already has his or her own assumptions and expectations and these alter the way the pilot will interpret what he or she observes, sometimes for the better and often to the pilot’s detriment.
• For a project team, orient means exactly the same thing.
• For both doomed fighter pilots and project teams, this is the piece that we often don’t have time to do, or that we do incorrectly without even realising it. But that means either we cannot make a decision or that we make the wrong one. Either way it means that things become overwhelming and you end up crashing and burning.

1. Deciding what to do about it:

• Apparently a lot of people who do well in the early stages of pilot training bomb out when they get to aerial combat training because they simply don’t trust their instincts enough to make a decision when they are in practice dogfights … or they ignore their analysis and make poor decisions in the heat of battle.
• This is also where a lot of clever people bomb out when they become project leaders, senior BA’s or testers. They can analyse information but they do not seem to be able to make effective decisions based on that analysis.
• The situation gets even worse for many teams where different people are making logical decisions on their own “OODA” loop, but this is not aligned to the analysis and decisions that others are making.

1. Acting on your decision:

• Obviously for a fighter pilot there is no point in a decision that is not acted on quickly. But just as importantly, if the pilot lacks flying skills then he or she may attempt to do something and fail – which ends with crashing and burning.
• Once again things are similar in the project team, if a decision is not acted on quickly then it is out of date and the team have to redo their analysis and if the team are poor at executing their decisions then they quickly become muddled as events overtake their planning.
• Sadly, no matter how fast you act in a rapidly evolving situation, you still need to adjust to events that are transpiring as you act. And each time you act, you alter the complex system you are part of, both for better and for worse. So you need to rapidly return to the Observe step, observing the impact of your action and the other changes that are occurring at the same time.

So what?

Most of the good project managers I work with can relate to the OODA loop even if they have not heard it explained in quite those terms. In fact this is how I predict which project managers who will be lucky in their projects and which will seem to work hard and do all the right things but then crash and burn.

More than that though, I think that this is what separates a brilliant BA from a mediocre one.  Rather than simply regurgitating what people say  and therefore passing the already out of date information back to the decision makers, a good business analyst is the one who actually drives the OODA loop in the team.

So when you have good BA’s the decision makers feel like they are undder pressure, but there is a feeling that they are fine tuning old decisions and making the right new decisions as the project evolves. But with a bad BA, decision makers have no idea what is going on after only a few days on the project, or they skip the analysis phase in pursuit of timely (and often ill-informed) decisions and then pay the price later as the project seems to get harder and harder.

But what does all that have to do with regression testing?  I hope to make that clear in the next enthralling episode of my series on regressions testing, day by day.

Inteviews are pure twaddle

Controversially, he claimed that interviews are appalling and should be completely abolished … which would seem to be a strong position for a business analyst to take these days. But then Mark Twain was around at the beginning of last century and we have learned a lot since then. Maybe he just didn’t know any better.

Since Mark Twain’s time, we have invented computers and the whole IT industry. We even invented the term “the business” so we could blame someone else if what we built turned out to be stupid rather than brilliant.

Then we invented the role of the business analyst to make sure that we actually understood what “the business” needed, rather than just blaming them.

The business analysts came up with the obvious idea that they should interview people to find out what they want before we build things. We hope this will result in us building something valuable instead of just allocating blame when we do something dumb.

A century has passed since Mark Twain wrote the letter I refered to and given how much we have learned since then, can’t we just ignore his outdated views? Sadly I think he turned out to be right.

Mark Twain claimed that the written word and the spoken word are fundamentally different. He claimed that if you interview someone and write down what they said then you will produce twaddle . In fact he said:

“The moment “talk” is put into print you recognize that it is not what it was when you heard it; you perceive that an immense something has disappeared from it.

That is its soul. You have nothing but a dead carcass left on your hands”

Later in the letter he says he would not talk in his sleep if he could not talk better than the wording found in most (reported) interviews. He claims that to capture the meaning of what someone said, you can never merely write down what they said. In doing so you will lose all the meaning that they had in their tone, their body language, the conversation before and after the part you wrote down and so forth.

This is exactly what I have seen happen when a business analyst writes down what someone said and calls it a set of requirements. You are left with “nothing but a dead carcass left on your hands”.

A good author or (if they exist these days) a good journalist does not interview people and simply write down what they said. Insteadthe author collates information from multiple discussions and then interprets it and compares it to other information they have gathered from research or even their own analysis. Then they go back and confirm their understanding, not just of what was said, but what the implications are and whether what was said was what they stakeholder really meant.

In the same way a competent business analyst does not simply write down what someone said – even if they can do in in Agile stories, UML or some other clever form of stenography.

Rather, a competent business analyst does what the job title implies.  He or she analyses, interprets, validates and chalenges what was said. Through this analysis they discover  the meaning of what has been asked for and the implications of delivering it.  They can then go back and talk to people or write down what they understand – in a written form that is effective rather than “twaddle”.

In other words they write requirements and do not simply quote what people said without the “soul” or meaning of the conversation.

So I would expect the requirements written by a BA to be in a different form to “talking”, or I would expect the BA to go back and read what Mark Twain wrote.

If you agree with me then lets write good written requriements and have good spoken discussions and lets make effective use of the written or spoken word when we do.

On the other hand if you disagree with me then blame Mark Twain – it was him that said you write twaddle and produce nothing but the carcase of the conversation you are meant to be analysing. All I did was quote him. I actually think you are a nice person and not at all a murderer of requirements.