Skip to main content

Tag: Career

The Agile BA: For An Agile Team, You Complete Me

Written by Bob Woods on . Posted in Articles. 2 Comments on The Agile BA: For An Agile Team, You Complete Me

It’s a fantastic invention really.

It most likely was derived out of sheer necessity and in some cases desperation. In many varied situations you can pull from it a wide array of tools which will get the job done when you need it most. It’s a versatile, useful, multidimensional asset; a must have for those who dare to brave the unknown.

Swiss Army Knife? No…but that’s kind of cool too.

I’m talking about the Agile Business Analyst.

I chuckle a little inside when I hear the contrast between some Agile ‘purists’ and Waterfall BA’s who live on different islands when it comes to the Agile team roles. On one side you have the self-proclaimed ‘agilista’s’ who evangelize the rainbow and lollipop world of completely cross-functional teams, with each team member well versed in development, testing, analysis and project management.

I personally feel that these individual folks got into their specific line of work for a reason. (Don’t get me going on this ‘BORG’-like scenario where everyone can, at a high level, perform all functions when needed. I have yet to witness it in real life.)

On the other side you have traditional BA’s saying, “Where do I fit in here? I don’t want to code. I can test but don’t want to do it as a career. I like my BA job just fine but don’t want to limit myself to traditional methodologies. Where do I fit in the Agile world?”

Ladies and gentlemen, I give you the Agile BA.

Let’s take a moment to break down why this role is so crucial to an Agile team.

Imagine a far-fetched scenario where your technical experts aren’t great communicators (there’s that smile). Imagine another far-fetched scenario where Product Ownership isn’t 100% dedicated time-wise to the team. Throw in just for giggles the idea of an over-utilized QA team that is viewed as a bottleneck in quick to market delivery. Oh…and by the way…we are Agile and assume we don’t have to document what we do (no matter what SOX, HIPPA, FTC, ISO or anyone else has to say).

To summarize, we have poor communication between business reps and development regarding needs, poor quality due to overworked and under-appreciated QA, and compliance/legal/information assurance breathing down our necks because they need something, anything, showing we actually are thinking through how we handle data.

For some, this little picture painted here might represent exactly where you live now! For others it may paint a picture of where you see yourself headed.

I give you the Agile BA.

Let’s start with the developers. They need someone who can talk business-eez and translate that into technical jargon. They can’t get the PO to spend any dedicated techie time with them but the need is still there on a somewhat daily basis. Now, don’t mistake this to say the BA should play the PO role. One voice makes the call on value and priority in the backlog. But an Agile BA will have a great relationship with the product owner and help create a bridge between the two by becoming a business to IT translator.

The most common area of success I see in this “translator’ role is when teams practice the “Three Amigo’s” approach to development. This is where a developer, tester and BA will sit down and hammer through the known details of each story before any actual work is done.

Ever needed something from someone who spoke another language? Remember that feeling of utter relief you felt when the Good Samaritan who could translate stepped in to assist? They didn’t tell you where to go, but they could sure help in getting there.

I give you the Agile BA.

How about our testers; our QA brethren? They are the ones who get code at hour 11. They are the ones who are pushed to sacrifice quality for time. How can our Agile BA assist?

Being as familiar as they are with the backlog of work, requirements, and business/technical needs, they are ideally suited to assist in some of the higher level testing efforts that will help ensure new levels of quality. They are careful not to encroach into the technicalities surrounding the QA world, but make themselves available to QA as an additional resource to ensure completed requirements before passing on to their PO for final approval. They are many times best placed as a final set of eyes to keep the team from the burden of unwanted rework. In this scenario I have seen the BA become the product owner’s right hand (wo)man.

QA can feel a little on an island at times. They are the bearer of bad news and the messenger is often killed in these circumstances. They need someone to help evangelize quality and point out what we will simply call ‘opportunities for improved code design’.

I give you the Agile BA.

Finally, agile documentation (not an oxymoron).

There are companies out there, who I won’t address by name, which have refused to adopt Agile approaches due to the perception that their compliance level will be at risk (no pun intended) because of the perceived lack of sound documentation in Agile practices.

It’s important to remember that great Agile teams will do what is needed to provide the business with top value. If the business has determined that a certain level of documentation is required in order to continue to provide this kind of value, than the Agile team had darn well better plan for that documentation need.

Working software is, according to the Agile Manifesto, of considerable value to the business. But remember that the manifesto does not say documentation is without value. It simply states working software is considered of more value.

Well…yeah… of course. We want the software, predominantly. But real world tells us that we need to prove compliance and best practice data security. It’s hard to do that with a poorly written user story!

I give you the Agile BA.

With their day-to-day involvement on the Agile team, inclusive of the product owner, they are ideally placed to help define which parts and pieces will create the most value from a documentation standpoint. They can work with the team facilitator/scrum master/etc. to find out who needs what, and then help translate that into streamlined and useful (valuable) documentation.

Funny thing is the teams I’ve worked with find the Agile BA to be one of the most critical roles on the team! We can swap out a developer if need be. Rotate the testing around a little if you must. But please, PLEASE don’t take away our business analyst!

There is a side effect though. Our Agile BA’s are often asked eventually to become product owners themselves. Why?

Well let’s walk through this again…

  1. They have experience in translating business needs to developers
  2. They know what to look for in quality products
  3. They have experience working with business partners in backlog prioritization
  4. They can determine streamlined documentation needs that fit business value
  5. They know what it means to be engaged with an Agile team day after day.

I’ll be honest here…that’s a product owner worth their weight in gold.

Agile is all about providing value. When you look at the many ways an Agile BA provides value to their team, how could anyone question whether or not there is a seat available at the table? The Swiss Army Knife is considered a must have by some (Swiss Army anyone?). It’s flexible, useful, valuable…dare I say…Agile?

Make no mistake, as timeless as that tool is, the time is coming very soon when you won’t see an Agile team without their handy-dandy Agile BA which you will have to pry from their cold dead hands!

Don’t forget to leave your comments below.

BA-elzebubs Glossary Four – The ‘B’s

Written by Marcos Ferrer on . Posted in Articles.

My brilliant readers know this piece of fun. Get credit in my next blog by offering more “B”s (and “C’s”) in the comments at bottom.

BA: See Business Analysis or Business Analyst.

Baseline: 1. A method of slowing progress to fit communal bandwidth; for example, the monthly rhythm of a change control board. 2. A clear, consistent, concise definition of feasible requirements suitable for: a) ruining with last minute executive confusion and “demand” deliverables; or b) for improving with carefully considered change management.

BB: Profession following BA.

BC: See BB.

Benchmark: 1. The mark made on the bench by project teams that watch what others do, similar in value and concept to the “hashmark”. 2. Solution speed comparison tests, as in “Wow, Amazon’s on-line store put us out of business in less than 10 years.”

Benefit: 1. Value that a solution might provide if implemented successfully; 2. The source of stakeholder fear of a solution. Example: “Digital blueprints mean that we don’t have to drive all over the county fetching and delivering blueprints, but driving around is more fun than actually supervising sewer work, on-site, most of the day.”

Best Practice: NOT what you are doing. Believe it. Diagnose it. Now change it. Repeat. Now you’re getting it – oops, not quite! Keep trying.

Beta Test: Formal term describing a solution that is not ready for commercial release, but is released to a limited number of users who help by giving feedback to the developers. Apple modernized this practice by releasing to all users while dropping the “beta” designation and using the word “free” instead. Microsoft is fighting back by moving to alpha releases but continuing to charge money, giving the illusion of product maturity.

Bit: 1. An information technology word never to be discussed with a business stakeholder. 2. A canned response to common stakeholder concerns. Example: “When the stakeholder objected to the process model, the BA bit them in the ear and the stakeholder dropped the objection”.

Box: A polite word for those in an organization who write the checks for “change consultants”. They do this for their own protection. Example: “He wanted Org X to get out of the box, so he hired the change consultant, but it turned out that he WAS the box, so he fired the change consultant!”

BPMN: 1. A notation for modeling a business process domain for stakeholders who can’t pretend to read but have no trouble pretending to understand a picture. 2. An alternative to sticking with text rendered so large that it can be confused with a picture. See PowerPoint discussion by Edward Tufte.

Brief: A highly compensated, highly expensive way of communicating. The most successful executives are brief in their communications (“of course this will be everything you want”) and in their tenures (“good luck, it was nice working at you”).

BS: Business Synthesis. What did YOU think?

Bug: A critical yet unexpected system feature from a developer. These (widely misunderstood) features help ensure that the developer’s software gets tested thoroughly once it is already released. Testing before release is optional – see “Baseline”).

Business: None of yours, hopeful elicitor :).

Business Analysis: The precursor to Business Synthesis.

Business Analyst: Anyone precursing Business Synthesis.

Business, Monkey: 1. The illegal trade in endangered primates. 2. Any decision made in the “C” suite without any sense of the impact on end users.

Business Requirement: 1. As commonly practiced by business executives, a business requirement is any requirement promoted by a “business” person in the organization, suiting the “business ego” needs of that stakeholder, in direct contradiction to BABOK. Example: “When this is over, we will still be a Microsoft shop, won’t we”? * 2. As defined by the BABOK, a business requirement describes the needs of the organization as a whole, and not groups of stakeholders within it. Example: “When this project is initiated, existing systems must continue to operate without additional downtime, as measured by existing availability reports.”

Business Rules: 1. Code buried deep where no businessperson can find it, known only to programmers, who can’t explain it. 2. Arbitrary wants that are un-code-able, as they cannot be explained. Example: “The system should automatically pick the best employee for promotion.” 3. Actual policies that govern transactions and entity relations of great value. These policies are typically kept out of code so they can be modified on the fly by spontaneous human judgment. Example: “No insurance company should carry more than 33% of all liability” is easily modified to add the phrase “unless the insurance company is run by people who assure us that all is OK and besides they are our friends.”

Button: The solution to everything. Examples: “Can’t we just add a button”? or “Can’t the system just push the button for us”?

Enjoy! And give BA-elzebub (not me!) some “C’s” below (Cache, Cynicism, Customer, Cost-Benefit, Critical-Path more) should your Cranium Crave Creative Comprehensibility by Chuckling Colleagues 🙂

Don’t forget to leave your comments below.

Definition-of-Done – Are We There Yet? Part-1

Written by Robert Galen on . Posted in Articles.

Introduction

There are several terms used for it within agile contexts. Sometimes you hear:

  • Done
  • Definition-of-Done or DoD
  • Done-Ness Criteria
  • Acceptance Criteria
  • Release Criteria

Sometimes you even hear it repeated, as in: This story isn’t complete until its—“Done…Done…Done”.

Apparently the more “done’s” you have, the more emphasis there is on completeness. Although I don’t think I’ve heard more than four “done” used in a row.

Done-Ness

Consider done-ness to be the criteria that constrains the teams’ work. If the team were building a bridge, then it would be the engineering rules, practices, inspection steps, local regulations, and completion requirements that would permeate everything the construction team would do. In many ways, the Definition-of-Done should seep into every aspect of agile team collaboration. If agile were a game then DoD would be the “rules” of the game…and the rules would be read, understood, and consistently applied across the team.

I’ve always been a strong proponent of a 4-layer view to done-ness. In this worldview, the layers build upon one another, moving from individual-based work, to story-based word, to sprint-level work, and ultimately to a release. I’ll often use the term “guardrails” to indicate the guideline nature of the criteria in guiding the teams’ efforts. Now let’s review each of the four levels in turn.

Work Product

This is the layer of the individual contributor. For example, your front-end developers should define some rules, conventions, and standards for how they design, develop, test, and deliver their UI code. The adherence to these standards should be defined specifically as done-ness criteria. This same logic applies to each functional role within your agile teams. Everyone should define a set of criteria that surrounds professional delivery of their work products.

  • Who contributes these? Usually there are two sources. Probably the most powerful is each team defining its own engineering rules. So there is a strong sense of uniqueness as you move from team to team. The other source is more organizational. Say for instance you’re working at a large web design shop where there needs to be consistent UI coding conventions and standards across the teams. I would expect “someone” in the organization to define these—and then for each team to adhere to these broader done-ness criteria in addition to their own.
  • Some examples: I literally gave one above, in that you might have UI development standards. Another example could be coding standards for you primary language or technology stack. Still another could be process based, for example, an “agreement” at a team level to try to “pair” as much as possible on each user story OR to have a “pair review” prior to checking in each story.

Story Level

This is the work delivery level. If you are using user stories, then done-ness surrounds defining a rich and meaningful set of acceptance tests per story and then holding yourself accountable to delivering to those functional constraints. Remember, acceptance tests are incredibly useful as design aids and test aids when the team is sorting out the nuance of each story. I consider that the most important part of the acceptance tests—the business logic design hints.

You should also develop clear quality goals at this level. It may sound prescriptive, but I like the criteria that all bugs that have been found in the development of a story to be fixed prior to declaring that story complete. These aren’t legacy bugs, but bugs created and found during the development of the story. I can’t tell you how many times teams run into problems at the end of the sprint in delivering a completed story with no known bugs.

  • Who contributes these? The Product Owner is ultimately responsible for defining the functional conditions of acceptance for each story. However, there are also inputs from the organizational side. For example, agreeing that each story will receive a solid pair-based code review or that a complete set of automated unit tests (TDD) will be developed and running before checking in and “declaring victory” might be decided as overall quality criteria that impacts every team.
  • Some examples: I gave several above. Clearly the story has to meet the Product Owners established acceptance criteria. I also like the notion of the Product Owner signing off on each story. That is, they review it, demo it, and determine that it is indeed—done. Then they physically sign-off on the story. Usually story done-ness also surrounds the design integrity, process steps to develop and test the story, and known bugs.

Sprint-Level Criteria or Sprint Goal(s)

This level is focused towards how well the team has met all of the goals and criteria they set forth when the planned their sprint. A large part of these criteria are typically driven by a successful sprint review or demo. I like the notion of “connecting the dots” between the sprint goal and the sprint review, so the team should think about the goal as a cohesive demonstration of business value from the customers’ point of view.

In my classes I often get asked, can a sprint have multiple goals, i.e. deliver on multiply focused activities? The answer is probably yes, but what the question is really looking for is the ability to say:

The goal of this sprint is to deliver 524 hours of work towards these specific 12 User Stories that are sized at 27 Story Points.

I think this is an incredibly poor goal because of the tactical, work effort focus. For example, there is no “customer” or no “demo description” in this goal. I’d much prefer goals that have a clear connection to the customer, value, and their challenges embedded within the goal. Having 2-3 separate goals articulated in this way seems fine too.

  • Who contributes these? Truly it’s the responsibility of the Product Owner to define or establish a goal for each sprint. I usually encourage them to bring a tentative sprint goal into sprint planning and then align that with the team and the agreed sprint work as part of the sprint-planning meeting. It then becomes a shared and achievable goal.
  • Some examples: If, for example a team were working on an ATM project, then a few related sprint goals might include: Complete single customer sign-on and account interrogation to include balance and transaction lists for the past month. Another one might be: Complete and demonstrate all deposit based activity (single/multi/business) account transactions with receipt printing. Only check deposits will be supported. I hope you see the connection to real-world customer usage scenarios. I’ve found these goals, which have open-ended functional details, to best inspire the team to “solve a problem” versus “deliver a set of stories”.

Release-Level Criteria or Release Goal(s)

If you’ve ever been part of a team that delivered software in more waterfall environments, a common practice is to create release criteria. These are project constraints requirements that are usually established at the beginning or early on in a project. Often they are consistent from project to project or release to release, because they quantify organizationally important criteria. For example, quantifying whether you could release with specific levels of bugs (both in priority and count) or quantifying how much testing (coverage) needed to occur prior to a release.

One of the unfortunate parts of many agile adoptions is that these sorts of criteria have been dropped. I think they’re incredibly valuable in defining meta-requirements or key constraints for the teams to adhere to within each release. Typically they exist anyway within the organization, but calling them out creates a focus on them in planning, execution, and delivery. They’re particularly important in at-scale delivery—so that multiple teams are maintaining a consistent focus on their overall release goals.

  • Who contributes these? Usually they’re defined outside of the team proper. Either being defined by the Product Ownership team or Chief Product Owner as part of establishing the definition of a release. As I mentioned, they often carry-over from release to release. They are typically “not optional”, so the organization needs to be willing to block a release or drop a feature if it does not meet the release goals.
  • Some examples: I’ve already mentioned allowable defects in the release and test coverage as solid examples. Global performance targets or usability constraints are often mentioned in applicable projects—so there is often a focus on non-functional requirements. Process constraints or commitments might also be mentioned, for example, the fact that each user story needs a minimum of 70% automated test coverage before being considered a candidate for your release train.

Getting Done-Ness into your DNA

Creating a list of your Done-Ness Criteria is only the first step. Just because you have created and communicated them, doesn’t mean that everyone is supporting them. The next step is establishing a culture where everyone aligns with and personally supports the criteria. Not just when things are going smoothly, but when the going gets tough as well.

You know that your done-ness has seeped into your culture when the team sees no other recourse but to do things the right way. I’ll share this example from my time leading teams at iContact that illustrates this cultural transformation:

We were a SaaS e-mail marketing software product and our customers used us 7×24. In fact, our weekends were often quite busy as SMB owners worked on their next week email campaigns. There was one weekend where a nasty mail sending component bug cropped up. It brought down our ability to send email, which clearly affected all of our clients. Not only that, when this happened, we would queue the mail. So this started created an endlessly increasing pool of mail that would cause delays even when we fixed the bug.
So the pressure was on.
Our teams would normally assign a “support engineer” for weekend support. The engineer in this case was notified of the problem, looked into it, and devised a repair. As part of our DoD, we’d agreed that no fix or repair could be checked-in without a paired code review. Now keep in mind—this was a holiday weekend, so people were on vacation. The support engineer determined that he needed a review with two others who were experienced in this area of the mail-sending stack.
He found them via text messages and phone calls and they all committed to a distributed/remote code review session on Saturday afternoon. They discussed a few issues and changes related to the repair, and then he completed those adjustments and released the repair.
When I came in on Monday morning I was amazed at how committed the team was to doing a proper review. It would have been the easiest thing in the world to have either checked-in an un-reviewed repair OR waited until everyone was back on Monday. But the support engineer and their teammates were committed to our customers and to their Definition-of-Done. It was in their DNA.

Why Done?

So after all this discussion, you might be asking yourself – why all of this focus on done? Why does it matter?

It matters from several perspectives:

  • It helps with your estimates. Pre-agile methods, I’ve used done-ness like criteria in my teams because I felt that if we didn’t have clarity around what went into completing our work, how could we estimate our work. That’s the very point we’re focusing on here. Clear understanding of what is expected in completing our work.
  • It helps with your quality. It provides guidance to the team surrounding what makes each step or deliverable complete. It focused on quality of the steps. And it amplifies consistency – so that every check-in or deliverable meets a consistent level of completeness.
  • It helps your Product Owner and customer gain confidence as the team delivers. And it’s not just confidence on the individual stories. It’s confidence on the overall plans and teams ability to meet their commitments with consistent quality.

Is it a panacea for any of the above? Of course not! But it is a key driver for some of the core behaviors that agile tries to amplify in teams. That’s why you hear so many agile coaches “harping” on it.

Wrapping Up

I often emphasize Done-Ness as a place for the organizations leadership team to influence the behavior, focus, and results of their agile teams. I encourage them to get engaged with establishing a deep, broad, and relevant set of criteria for their teams. I ask them to align their DoD to the business, customer, and constraints. I sometimes call them “guardrails” because of my view that they can keep the team “safely on the road” in their delivery of business value and results.

Since I see so many sparsely defined DoD’s it the real world, I usually ask for organizations and teams to over define them – risking a bit of prescriptiveness. I’d rather have more clarity than less guiding the teams.

Hopefully this article has helped clarify a view to what done looks like in agile teams. Now go take a look at your own Definition-of-Done and see if you need any adjustments?

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

References

A Review of the PMI’s New Business Analysis for Practitioners: A Practice Guide

Written by Phil Vincent on . Posted in Articles. 2 Comments on A Review of the PMI’s New Business Analysis for Practitioners: A Practice Guide

The PMI recently published its new Business Analysis for Practitioners: A Practice Guide and is making it freely available (at least for a limited time) to anyone who wants to download a copy. If you are planning to write the PMI-PBASM certification exam you may find this useful because it interprets the PMBOK® Guide concepts of scope, requirements, acceptance criteria and stakeholders from a business analysis perspective.

The Practice Guide is aimed at project BA’s who may be involved at any point “ from identifying business needs to solution implementation.” It is intended to address project-related issues about requirements and business analysis. So for all of you who spend most of your time supporting an existing system, or working in continuous process improvement, or if you are involved with strategic business analysis, this publication is probably not for you. However, if you are involved as a BA working on projects, and especially IT system projects, then you will likely find this Practice Guide to be relevant.

With the upcoming BABOK® Guide v3 moving away from the project focus, it makes sense that the PMI would want to fill in the details about project-based requirements management because that is still such a significant problem for most projects.

A Practice Guide; Not a Standard

The stated purpose of the Guide is to “define what business analysis is, and to demonstrate the practical application of the discipline”. It is only a guide, not a standard or a body of knowledge like the BABOK® Guide or PMBOK® Guide. Think of it as a 200 page text book written by a group of folks who really know their stuff, but was not subjected to a thorough review, nor a consensus-based review and revision.

In some ways, this is simpler to read than the BABOK® Guide or the PMBOK® Guide because the various business analysis techniques are described within the context of when they could be applied. With a few exceptions, the Practice Guide just describes the techniques, but doesn’t tell you how to apply them.

Unlike the BABOK® Guide or the PMBOK® Guide, this Practice Guide should be read from front to back. The Practice Guide sees business analysis as inherently being a process, starting with the definition of the business need, and working through the requirements to solution evaluation. The story builds as you work your way through it. When a technique is only mentioned but not described in one of the chapters, it is assumed that you are familiar with it because it was described previously in the book. In some cases, it’s not obvious that the process is not sequential, and less-experienced business analysts may not recognize that the order in which techniques are introduced in the Practice Guide is not always necessarily the order in which they should be applied.

The PM-BA Relationship

One of the features of the Practice Guide is that it clearly spells out how the PMI expects business analysts and project managers and other project participants to work together. Sprinkled throughout the text are Collaboration Points which detail how the two roles should work together. It often assumes that a business analyst reports to a project manager, or is more concerned with lower level details than the project manager, or lacks the experience, expertise or insight of the project manager. It doesn’t really address the dilemma of the person in the role of both the business analyst and project manager.

Requirements

The PMI Practice Guide does not discuss the similarities between needs and solutions, requirements and designs. That’s really too bad because users often come to a business analyst with what they think are requirements but which are really solutions. PMI assumes that we are only dealing with requirements. But some of the examples, such as the use case example, feature model and the report layout example, do not demonstrate requirements, but rather specify the design of a solution.

Documentation

The PMI has always been concerned with documentation and it is no different here. One of the major problems introduced by a requirements document of any sort is that once the project is over, no one seems to keep the requirements documents up-to-date, and so the support teams quickly lose sight of why the solution is the way it is. PMI could have helped to shift the mindset away from text-based documentation of requirements, and moved toward model-based requirements. Instead, they chose to differentiate between models and requirements. This approach could continue to impede the ability of BA’s who support solutions to get access to the requirements that were incorporated into the solution.

Organization and Content

The PMI has defined business analysis in terms of 5 domains:

  • Needs Assessment
  • Business Analysis Planning
  • Requirements Elicitation and Analysis
  • Traceability and Monitoring
  • Solution Evaluation

The Practice Guide explains the major tasks of each domain and the approximate order in which those tasks should be performed, and describes the techniques that could be applied within that domain.

Needs Assessment

This first section provides an explanation of how to understand problems and opportunities, and provides a pretty down-to-earth explanation of how to conduct a situation analysis, SWOT analysis and root cause analysis. Some of the examples are pretty good, and the supporting diagrams are easily understandable . This is a useful step-by-step guide about conducting a needs assessment, with more focus on understanding the problem or opportunity than on recommending a solution.

Business Analysis Planning

The discussion on stakeholder identification and analysis is pretty thorough and serves as a good guide or checklist.

The Practice Guide uses the term “business analysis plan” to refer to all information that is documented regarding business analysis planning decisions, and explains that the business analysis plan works in conjunction with the requirements management plan. The business analysis plan is a part of the overall project work plan, and so must be developed in collaboration with the project manager.

A possible point of confusion for people studying for the PMI-PBASM certification is that the PMBOK only mentions the requirements management plan, not the business analysis plan. The Practice Guide relegates the requirements management plan to a more narrowly focused role which may not be consistent with exam questions. Even the Guide is not 100% clear, since the glossary definition of the requirements management plan doesn’t exactly match what is described on page 46.

The suggestions about what to consider when developing the business analysis plan are pretty extensive, but there is no real help about how to develop the plan. Many business analysts are uncomfortable with such comprehensive planning; the description here could be overwhelming. There is an opportunity to provide some guidance and examples here, I think.

Requirements Elicitation and Analysis

The Practice Guide only describes how to elicit by asking questions, and doesn’t talk about the need to use research or experimentation as primary elicitation techniques, or to corroborate information provided by stakeholders. It pretty well assumes that you can get most requirements by asking the right questions of your stakeholders, even if they don’t know all of their requirements, or may have difficulty articulating them.

The discussion on analysis suggests using a combination of models to understand the requirements, and to identify gaps, and that’s a good thing. It’s too bad that the Practice Guide doesn’t suggest ways that business analysts can collaborate with stakeholders to develop models concurrently with elicitation, since that approach can be pretty efficient, speeds up validation and consensus, and encourages early buy-in from stakeholders.

A useful table is provided on page 90 to categorize the different types of models and the purposes for which you would use them.

There are simple examples of how to use most of the models, and the diagrams are clear and easy to follow. In almost all cases, precise notation is ignored in favour of a clear explanation, and I think that’s a workable approach.

Overall, the discussion of the analysis models seems more appropriate for a systems analyst than for a business analyst. All of the diagrams drift into the solution design, and miss the solution requirements.

The discussion of requirements documentation seems to lose sight of the models, and is biased towards extensive text-based documentation.

The description about writing requirements is pretty thorough.

The suggested techniques for resolving requirements conflicts are a worthwhile read.

Traceability and Monitoring

The PMBOK® Guide exerts a substantial influence on this chapter. The heart of the described approach to traceability is the Requirements Traceability Matrix (RTM), a concept right out of the 1980’s. Yes, it is worthwhile to take a disciplined approach to traceability, but a matrix is a very cumbersome tool for managing many-to-many relationships between requirements, and between requirements and designs, solution components and test cases. A lot of potential overhead is introduced in the discussion about requirements attributes; you don’t always have to use all of these attributes; in most cases, a few key attributes will be all you can handle.

The discussion on managing changes to requirements is also a little outdated because it promotes the idea of doing an impact assessment on every change request before the request can be considered for approval. The trouble with this approach is that at the project planning stage, nobody ever plans enough time to do all of these impact assessments. If there are many change requests, the project team can burn up a lot of project time assessing potential impacts of changes that will go nowhere. What the Practice Guide could suggest is to obtain a preliminary approval before doing the impact assessment to prevent the project from wasting time on change requests that will never be approved.

The focus on the project perspective of change requests misses out on the business analysis perspective of assessing change requests in terms of the impact to solution value after the project is completed.

Solution Evaluation

This section deals with validating the solution, and then evaluating the solution after it is in operation.

Solution validation and acceptance is discussed in-depth, and includes a good discussion of planning considerations to test and validate the solution. Transition planning to support the solution implementation is also covered in some detail.
The discussion about ongoing solution evaluation is limited to the planning that might occur as part of the project work.

About the Team of Authors

I was a little surprised that the PMI chose to have many of the same people who were extensively involved with the development of BABOK® Guide to lead, contribute or review content for this PMI Practice Guide. You would think that such a large organization as PMI with such a global reach would have found a different group of expert contributors. Are these really the only business analysis experts in the world, such that both the PMI and the IIBA must rely on them so heavily? The good news, of course, is that those experts have been doing a lot of deep thinking, sometimes together, about business analysis for several years, and so the resulting product is pretty solid.

Given that the same people were involved in the creation and review of both publications, it should come as no surprise that much of the content is similar between the PMI’s Practice Guide and the upcoming BABOK® Guide v3. Parts of the discussion on Solution Evaluation are strikingly similar in both publications.

One disappointment is that some of the techniques that are described in the Practice Guide are not generally applied business analysis techniques. When I did an Internet search on some of the terms and techniques with which I wasn’t familiar, I was disappointed to discover that the top ranked hits are associated with some of the Practice Guide’s authors’ companies.

Conclusion

The PMI’s Business Analysis for Practitioners: A Practice Guide is a useful addition to your business analysis toolkit if you work on IT projects that follow a sequential lifecycle. Every now and then there is some acknowledgement of adaptive (it really means Agile) projects. It is a first step at extending the requirements process and requirements management practices that are identified in the PMBOK® Guide.

It will likely be most useful to people who are new to business analysis, although even experienced BA’s are likely to get some tips. It is focused on business analysis within the context of software projects, and for BA’s who report to a project manager. Professionals who already have one of the PM certifications may find this to be a useful resource as they try to earn a second certification.

The PMI has indicated that it is planning to produce a consensus-based Requirements Management Practice Standard in the future. This Business Analysis for Practitioners: A Practice Guide, is a good start.

Don’t forget to leave your comments below.

Ask the Naked Question: How To Ask the Right Question part 4

Written by Steve Blais on . Posted in Articles. 1 Comment on Ask the Naked Question: How To Ask the Right Question part 4

blais Mar3

In the previous episodes, we established a framework more conducive to asking the Right Question, increasing the probability that you will ask the Right Question, if even inadvertently. We talked about what to ask, and to a degree when to ask it. Now let’s wrap up with talking about how to ask the Right Question.

“How” is as important as “what”

The quality of the response is affected not only by the content of the question, but also by its manner of delivery, especially its pace and timing.
Michael Marquadt [3]

The trick to asking the Right Question may not just be in knowing what to ask, it may be in knowing how to ask it. This requires good questioning skills according to Andrew Griffiths who states that in addition to getting good answers, “good questioning skills will empower you and can transform your confidence, ability and results”. This being the evidence of leadership which “… is all about asking questions: the right questions at the right time in the right way”. [1]

Ask naïvely

Even though we know what information we want, we don’t want to assume we know what the answers are actually going to be. We may have asked the same question of eighteen other responders and gotten the same answer 18 times in a row, but the 19th time we ask, we want to ask it as though we never asked it before.

But, Steve, you might say, if I’ve been rummaging around the call center asking questions of everyone to define a new call center system, won’t the people I’m asking questions of know that I’m asking questions that have been answered by someone else?

Sure, and if you preface your question with “I’m not sure I understand this, which is why I’m asking you” or something similar, the person will tend to answer your questions as though he or she is the very first person you are questioning.

The same holds true for confirmation questions. When you preface the question with “so I understand this is how [fill in the blank] is done, is that correct?” You will get the close-ended response of “Yes”. And this is good for confirmation. However, if you start the confirmation question from the opposite point of view (“I’m having trouble understanding this, perhaps you could clear it up for me…”), you will likely get an answer that confirms your previous information and also adds new information or at least includes the personal perspective of the responder.

Getting Naked

To the degree possible, getting the Right Answer and not just a superficial response requires us to convince the responder that we genuinely want to know the answers to the questions we are asking and we invite all the information they have on the subject. This means approaching the information gathering session with a degree of humility as described by Patrick Lencioni in his book, Getting Naked. Lencioni suggests that we should be “so concerned about helping [our customers] that [we should be] willing to ask questions and make suggestions even if those questions and suggestions could turn out to be laughably wrong…readily admit that we don’t know and be quick to point out – even to celebrate – [our] errors because protecting [our] intellectual ego is not important to them.” [2]

There is one somewhat universal truth when it comes to getting answers to questions: people will not tell you something that they think you already know. When you ask a question and appear to already have knowledge about the subject, the responders will give you very generic and high-level answers. No one likes to give a detailed answer to then hear the other person say, “yes, right, I know all that, but what I really want to know is…” Appearing less knowledgeable gets more information for example using the approach Denzel Washington does in the movie Philadelphia, “tell it to me like I am six years old.”*

The trick here is to curtail your natural inclination to “discuss” the situation or responses by offering your opinion or knowledge gained on the topic. When your goal is to gather information, focus on the flow of information – coming to you and not going from you to the responders. Remind yourself that you will have plenty of time in review sessions and other engagements to exhibit your grasp of the situation and solution.

And Listen Naively

Listening naïvely is the technique in which you appear to be a sponge willing to learn everything that the responder can tell you about the topic.

To get the most information and the Right Answers, the questioner has to listen naively. That is, listen with no preconceived notions, exerting zero judgment, absorbing all information that is proffered without analysis. In other words, the questioner must hear the information as though for the first time. This is difficult because it requires the questioner to be totally in the moment and focused.

When you establish the information gathering session “frame” (as discussed in the previous article), you set the stage in the responder’s mind that you are in need of this information. It also reminds you to sit back and listen as though for the first time.

In other words, just ask the questions, the naked questions, unadorned by preface, explanation, suggestion, direction, assumption, or supposition. Here’s an example: when the responder does not understand the question and asks for an explanation, rather than give an explanation or background, rephrase the question so that you continue to ask questions rather than provide answers. As stated, there will be plenty of time to provide the answers when all the information has been collected.

You will find that people love to tell you what they know and if you are listening naïvely, they will tell you a lot more than your questions ask, perhaps even filling in the gaps between your questions.

Avoid Asking the Wrong Questions

“If they can get you asking the wrong questions, they don’t have to worry about answers.”
Thomas Pynchon

The opposite of “right” questions would likely be “wrong” questions. So if there are a few “right” questions, the rest must be wrong, unless there is some middle ground between right and wrong like mediocre.

Therefore, one solution might be to adopt the stance that all questions are “right” with a few exceptions which might be considered “wrong”

  • Questions which caused the information gathering session to be terminated by the responder: “so, before this new system replaces your job and we lay you off, can you describe some of the things we can do to make the system better?”
  • Questions which stemmed the flow of information: “yes, we get that. You clearly do not understand what we are looking for here. What happens when…?”
  • Questions which resulted in the same information you’ve already received (except when you are specifically looking to confirm information obtained from another source).
  • Questions that result in an abrupt change to the responders’ focus: “so to continue with the Accounts Payable voucher process, what did you think about the best picture award at the Oscars?”

Since cognitive studies have shown that we humans tend to remember the negative things more than the positive things that happen to us, we most likely remember those “inappropriate” questions a lot more and a lot longer than we remember the hundreds of “right” questions asked. And this remembrance of the less than optimum questions might explain why so many of us agonize over the “right question” issue.

So perhaps the best advice on how to ask the “right” question is to simply avoid asking the “wrong” questions. If you don’t ask any “wrong” questions, then clearly all the questions that you ask must be “right”.

Some Good Advice

Marquardt offers some good advice for asking the Right Question to elicit the Right Answer:

  • “Respond without judging the thoughts, feelings or situations of other people
  • Consider yourself a beginner, regardless of experience
  • Avoid focusing on your own role (which can lead to a self-protective approach) and take the role of an outside observer, researcher or reporter
  • Look at the situation from multiple perspectives, especially your respondents’
  • Be tolerant of yourself and others
  • Ask clarifying questions” [3]

Tips for Asking the Right Question(s)

Here are some final thoughts that might help you ask the Right Question.

  • Review your questions to see if you have the ‘right’ answer in mind, before asking the question. If you do, then either delete the answer, and all other judgment from the question, or don’t ask it.
  • Continually refer to the responder’s previous answers or comments for subsequent questions. This not only reaffirms what the responder has said previously, but it also reminds the responder that you are listening carefully to what the responder says, thus encouraging even more information to be shared.
  • Avoid focusing on your role or your deliverable. Focus on their problem or their part in the problem / solution. Be prepared to discover that they may not consider the problem you are striving so vigorously to solve to be important to them or not even a problem at all.
  • Ask the questions delicately and naïvely, and listen naïvely to the information provided. To paraphrase the X-Files: the Right Answer is in there.
  • Ask just the questions, naked unadorned questions, and keep asking

In the end, the Right Answer is the result of piecing together a lot of answers generated by a lot of Right Questions. You will be obtaining the Right Answers from people who probably don’t even know that they know the Right Answers. And this is the magic of information gathering and problem-solving. Go forth and ask more questions.

[1] Griffiths, Andrew, Ask a Stupid Question, Lightning Press, UK, 2012
[2] Lencioni, Patrick, Getting Naked, Jossey-Bass, San Francisco, 2010
[3] Marquadt, Michael, Leading with Questions, Jossey-Bass, San Francisco, 2014

* In the movie “Philadelphia” which involved an insurance trial in which Tom Hanks was the plaintiff, Denzel Washington was the lawyer called in specifically because of his knowledge of the complex insurance laws and regulations. Throughout the movie, in depositions and during the trial, Denzel Washington, as the lawyer, said to witnesses and others who were describing aspects of the case, “Tell it to me like I am six years old”. As an expert, he didn’t need for it to be made simpler, but those who were judging the case did, and by requesting the witness to respond in the simplest way possible reduced the ambiguity, vagueness and potential misunderstanding of the response.

Don’t forget to leave your comments below.