Tag: BABOK

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

Written by Phil Vincent on March 9, 2015. 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-PBA^SM 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-PBA^SM 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.

Is Business Analysis Undervalued?

Written by Daryl Chan on April 21, 2014. Posted in Articles.

Today I was talking to a friend about some cool work we’ve been doing recently around a “basics of BA capability uplift”, and were talking about the value of Business Analysis and Business Analysts here in Australia compared to overseas.

I offered the viewpoint that I felt Business Analysis is poorly understood and undervalued in general in Melbourne (my experience being mostly with large corporates). He agreed and compared it to his experience in Canada, where he did not find it to be the case.

What influenced my viewpoint? Well, the general attitudes I’ve experienced in my career as a Business Analyst, but more recently, some truly inspiring lines (spoiler alert: not at all inspiring) I’ve heard in the workplace recently, such as:

“So, what exactly does a business analyst do?”
“Just put the requirements into the BRD template, that’ll do.”
“I’ve taken my notes down as a mind map, and everyone else’s notes are quite linear. Ha, typical BAs!”
“The ideation stuff happens WAY before a BA gets involved.”
“Oh you don’t know how to do a PivotTable? Just give it to a BA to do.” (I think this one was my favourite.)

All the above of inspire certain feelings in me, some gentle, some a little more aggressive, but in general, something along the lines of below.

Communicating the value of business analysis

So why don’t people “get” business analysis and the role of a business analyst?

Well, I actually don’t think it’s down to the people who made the above statements. I think that their perception of business analysis is very much down to the way we (or we don’t) communicate what it is that Business Analysts do.
I believe that we need to take responsibility for communicating the value of the BA profession, firstly as individuals, and also as a community. (Side note: Kupe Kupersmith has recently written a great article here on a similar topic)

There’s a fine line though. Bear with me, I won’t suffocate you… yet. (via Cripplegate)

For instance, take a look at the some of the descriptions which have used to describe business analysis in the past. They’re all nice attempts, and whilst I don’t feel like they’re intrinsically incorrect, I also feel like they don’t adequately describe the full scope of what we can and actually do as BAs. They focus on the detail over the concept of Business Analysis.

Here’s a description which really hits the nail on the head for me though, and it’s straight from the good old IIBA website (and hopefully will be present in BABOK v3):

“Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders.”

What’s different you say? The real beauty of this description is that each of the highlighted words come together in a dynamic, conceptual model, without a single mention of tools, techniques, “business and IT”, spreadsheets or Powerpoint.

Business Analysis Core Concepts Model

It’s called the Business Analysis Core Concepts Model. There is a fantastic article by Julian Sammy which goes into this model in more depth here. Make yourself a cup of coffee/tea/other caffeine mask before you start, but it is an intelligent, thoughtful, worthy read – here’s a quick summary:

Change: a controlled transformation of an organization
Solution: a specific way of satisfying a need in a context
Context: the part of the environment that encompasses the change
Value: the importance of something to a stakeholder in a context
Stakeholder: a group or individual with a relationship to the change or the solution
Need: a problem, opportunity or constraint with potential value to a stakeholder

Principles of Business Analysis

So whilst these core concepts articulate the areas we cover as Business Analysts, what is it that we actually do with regards to these concepts?

Laura Brandenburg has created this neat BA manifesto:

“Out of chaos, we create order.

Out of disagreement, we create alignment.

Out of ambiguity, we create clarity.

But most of all, we create positive change for the organizations we serve.”

Not bad right? It definitely resonated with myself and my colleagues as a call to action which sets a strong vision for Business Analysis. From this vision, we drew out four core principles which we believe best represents BA from an overarching point of view:

Bring stakeholders together
See the bigger picture
Facilitate shared understanding
Focus on what is valuable

I am sure there are many more principles (such as the ones suggested in Steve Blais’s article) which can apply, but we’ve decided for a less is more approach. Much like the law, I can’t remember every single rule out of the thousands which exist – but I certainly try live and abide by the principles those thousands of rules aim to serve.

Likewise, with these BA principles – no matter what tools or techniques we use, wherever we are in the product lifecycle, no matter how agile or rigid the environment is – they provide foundational beliefs which we can use to help organisations do better, and we can always link back to these and each of the six core concepts in every aspect of our work as Business Analysts.

This is how I see Business Analysis in my head, and in fact how we structured our recent capability uplift. Very keen to see how it’s depicted in BABOK v3.

How we might talk about Business Analysis in future

We feel that the combination of these two approaches set the scene for everything we do as Business Analysts. We believe it’s a succinct way of communicating the value of Business Analysis across the breadth of activities we can perform, but also hinting at the detail we can dive into when necessary.

Business Analysts can facilitate as much as we can set direction. We can help teams achieve business value as much as we can understand and communicate the ins and outs of a complex system. And we can sure as hell innovate whilst also being able to create super sexy spreadsheets which will knock people’s socks off- just as long as it’s valuable. Or brings stakeholders together by creating shared meaning. Or helps them see the bigger picture.

Do you even Excel, bro? (via Pixel77)

I’d love to hear your thoughts on the topic – do you have any thoughts on the questions below?

How would you describe the perception of Business Analysis in your community/country?
What do you think of the Core Concepts/Principles approach to describing Business Analysis?
What are you doing to communicate the value of our profession?

Until next time.
Daryl

Don’t forget to leave your comments below.

Effective Requirements Planning

Written by Kathleen O'Brien on November 12, 2013. Posted in Articles.

Why do I need to plan?

When I think of requirements, a picture of Mr. Potato Head comes to mind. There are a bunch of pieces and an infinite number of ways to put the pieces together. You need an approach for building the requirements specification.

This same principle applies to requirement development. If you don’t plan before you jump into the requirements development, you may experience the following consequences:

Ineffective BA techniques
Inability to respond to project evolution in an organized manner
Missed timelines
Forgotten sections of requirements
Lack of alignment between the capacity of the team and the schedule

As Dwight D. Eisenhower said “In preparing for battle, I have always found that plans are useless but planning is indispensable”. Additionally, a requirements effort is a journey that you as the BA are leading a team along. If you don’t have a solid plan how can you communicate a clear vision to your team and gain their commitment?

In the BABOK, “Plan Business Analysis Approach” is the 1st task in the 1st knowledge area “Business Analysis Planning and Monitoring”. This highlighting that this task is the place to start when developing requirements. But so often we have no time to plan upfront. Our PM comes to us and says I need the requirements done in 2 weeks. As good team players we get them done but then pay the price by constantly changing the requirements since they were not done right. We all know the cost of poor requirements to IT organizations. Per the Standish Group Reports1, only 32% of IT projects are successful and 20% of the features / functions delivered are used regularly. Multiple studies have traced these IT failures to poor requirements definition.

Therefore, I am proposing we as BAs need to embrace the need to plan and to sell this to our PMs. I hope this article give you the background you need to develop a solid Requirements Approach and the ammunition to sell this to your PM.

A Requirements Approach allows you as a BA to:

Select the best methodologies and techniques for requirements development based on the needs of the project and stakeholders
Develop consistent requirements
Gain commitments from all stakeholders to provide necessary time and input
Respond to project evolution in an organized manner
Clearly communicate BA commitments and establish a BA contract with IT and business stakeholders

But it is not all about the BA benefiting! Developing a solid Requirements Approach benefits the entire team. For Project Manager, the Requirements Approach can be the basis for developing detailed, accurate project plans. For Business Partners, the Requirements Approach provides visibility which sets clear expectations and fosters a collaborative environment. For the QA professionals on the team, the Requirements Approach provides insight into the requirement deliverables so the testing efforts can be proactively planned at the start of the project.

The Lead Business Analyst develops the approach and collaborated with the other BAs on the project, the PM and the business partners to refine the approach so it meets everyone’s needs and incorporates the team’s diverse perspectives. The Requirements Approach should be an official project deliverable but does not have to be a 100 page document. A short document or a PowerPoint is sufficient. The goal is to think through the approach and get team buy-in, therefore right-size the deliverable to meet this goal.

How do I create a Requirements Approach?

A Requirements Approach is a roadmap for the developing requirements for a project. The Roadmap should cover all phases of requirements development:

Planning – Develop a plan for gathering and communicating requirements.
Eliciting and Validating – Extract information to prepare to document the requirements.
Documenting – Collate, author, and publish requirements to stakeholders.
Approving – Secure acceptance of the requirements from the stakeholders.

The following components should be defined for the Planning phase in the Requirements Approach:

Scope – Clearly define what is in scope for the requirements development effort and enumerate out of scope items. Note, this is not the scope of the project which should be clearly outlined in a different document.
Assumptions, Dependencies and Risks – List all things that effect or constrain the requirements development effort.
Standards – Define the industry, company and divisional standards guiding this effort.
Requirements Development Team – Define roles (both IT and business) and individuals that fill these roles.
Requirements Development Communication Plan – Define communications to be sent regarding requirements development to keep key stakeholders informed on progress. The key stakeholders are those defined during stakeholder analysis.
Requirements Development Project Plan – Key factors that affect the requirements development project plan such as BA resource constraints along with high level timelines and resources for the requirements development effort. A link to the requirements development project plan is also included.
Requirements Change Management – Define how changes to the requirements will be handled.
Methodology – This is the core of the requirements approach since it clearly defines how the requirements development effort will be structured.

Let’s discuss the methodology component in more detail. In the methodology component, the following should be defined:

SDLC methodology (Agile, Waterfall, Iterative, etc.)
Types of requirements to be developed (Business, System, Analytics, Integration, etc.)
Steps for defining each type of requirement
Tools, techniques and details for each step

To help make this more real, here is an example of a Methodology section from a real life project:

The Planning section is the bulk of the Requirements Approach. The table below shows the components for the other 3 phases:

That covers the components of a Requirements Approach. Just remember, this is not a once and done artifact! Get your initial approach defined but be ready to continuously refine as the needs of the project and team evolve.

Finally, use your tools to enforce your requirements approach:

To make getting started easier, I created a template.

Good luck with planning a successful requirements development effort.

Don’t forget to leave your comments below.

Sources:
1. Chaos Study 2009 – www1.standishgroup.com/index.php
2. BABOK v2.0 2009 – http://www.iiba.org/BABOK-Guide.aspx

Resources for Related Topics:
– Stakeholder Analysis – BABOK v2.0 Section 2.2
– Communication Plan – BABOK v2.0 Section 2.4
– Work Breakdown Structure – BABOK v2.0 Section 2.3.4.4

Eliciting Requirements: It’s Not Just What We Ask That Matters!

Written by Kelly Burroughs on September 4, 2012. Posted in Articles. 1 Comment on Eliciting Requirements: It’s Not Just What We Ask That Matters!

A lot of times when we meet with a subject matter expert to elicit requirements, the focus is on the questions we ask, and the answers they provide. We ask them what they do when this happens, or what they do when that happens. We ask them to tell us the actors involved and what the process is when something goes right, or what the process is when something goes wrong.

We guide them as we need to – nodding our head in agreement when they have hit an important point, or raise our hand to stop them and ask for more information. Or sometimes, we may just sit and record notes – typing away on our laptops or quickly jotting down answers in our trusty notepad.

But one aspect of eliciting requirements that seems rarely touched upon is the non-verbal side of these interviews – in other words, how we ourselves present ourselves to our subject matter experts – and in return, how they perceive us.

In everyday life, how do you carry yourself?

Well, you might answer that there isn’t just one answer – and that how we carry ourselves often depends on the situation we’re in.

At home watching TV? You’re probably slouched in your favourite chair, arms behind your head, a large yawn escaping your tired jaws – probably relaxing after a hard day on the whiteboard mapping out an overly complicated business process.

Outside talking to your neighbour? Well if it’s one you get along with, you’re probably hunched slightly forward, wildly gesticulating as you talk about your exciting day getting sign-off on your most recent functional requirements document. Or maybe if you don’t quite get along with them, you’re standing stiffly with your arms instinctually crossed, sternly asking them to please keep their dog off your lawn.

Point being that we often forget that communication is a lot more than just verbal, but it is largely non-verbal as well. It’s how we hold our arms, hold our posture, sit in a chair, express our faces, hold our poise, or move our hands that can actually communicate the most.

And that’s why when we’re meeting with our subject matter experts that we need information from in order to successfully do our jobs – we should not only be good at verbal communicating, but also non-verbal communication. Remember, that people are largely visual when assessing a situation – so how we present ourselves and conduct ourselves during an interview is just as important as the questions we ask in that interview.

So what types of non-verbal communication can be used when interviewing subject matter experts?

Eye Contact

Eye contact can be tricky – give too much and you can come across too aggressive or like you are trying to have a staring contest, but give too little and you can come across disinterested. Finding a balance is key, because maintaining eye contact is key to keeping the person talking. Eye contact lets the other person know you’re interested in what they are saying and encourages them to stay engaged in the conversation. If you want to maximize the time you have with the interviewee, be sure to lean forward into the conversation, establish eye contact from the beginning, and maintain it throughout the meeting at a comfortable level. Remember that it’s important to take notes, but it’s more important to maintain eye contact and display your interest – you would be surprised how much more information people are willing to share when you do so.

Express Yourself

Have you ever sat and spoke to someone who just sat there motionless staring at you? It’s not a good feeling, and worse – it does nothing to invite you into the conversation. Facial expressions let the other person know how you feel about what they are saying – a smile lets them know you agree, whereas a furrowed brow might let them know you don’t. Be aware of the expressions you are making during the meeting and try to keep them positive – and don’t be afraid to use your hands either. Gesticulating is one of the strongest forms of non-verbal communication and can be used to bring a dull conversation back to life.

Watch Your Posture

When I was younger, my mother was constantly telling me to sit-up straight and pull my shoulders back – and now I see why. Posture is one of the most telling signs that a person is interested in something or not. Start to slouch, and your interview may quickly follow.

Stay Poised

Staying poised can be hard to do if you’re not prepared – which is why it’s so important to do your research ahead of time, know the questions you’re going to ask, and have a plan in place for how you want the meeting to proceed. Being poised means being confident, and being confident means that the other person is going to feel more relaxed talking to you. Have you ever been in a meeting where the person leading is nervous, unorganized and seems unsure about what to say? It’s uncomfortable to watch. Keep your poise, keep your interviewees confident in you, and you’re more likely to get the answers you need.

Having said all of this, we need to recognize that non-verbal communication and the levels to which you display it, are different for everyone. Extroverts for instance might gesticulate a lot more naturally, but perhaps introverts come across more poised since they are more likely to research and prepare endlessly before the meeting. The important thing is to be aware of non-verbal communication and the effect it has on the people you are meeting with. Sometimes we only get one or two meetings with our subject matter experts to get all the information we need – so it’s important to remember that not only do we need good verbal communication, but also good non-verbal communication. Doing so will help you keep your actions positive, keep your meeting attendees engaged, and help you to get the information you need.

Don’t forget to leave your comments below.

Using Adaptability as a Guide to Navigate the Uneven Terrain of Requirements Elicitation

Written by Josh Jones on June 18, 2012. Posted in Articles. 1 Comment on Using Adaptability as a Guide to Navigate the Uneven Terrain of Requirements Elicitation

Adaptability is a word that is not used enough in the context of business analysis and collecting requirements. Though it is used in the project world, “adaptability” is more synonymous with project methodology or project teams as a whole than it is with requirements elicitation or requirements management. Being adaptive to your surroundings is what can save you from the perils of uncertain environments, non-engaged subject matter experts or the dreaded “analysis paralysis” effect. When it comes to adaptability, one things is certain: if you, as a BA, cannot adapt your approach for gathering requirements when something doesn’t go as planned (because all good BAs always have a plan) then you’re greatly reducing your chances of delivering top-quality requirements. Two of the more prominent areas that lend themselves to easy adaptability of BA styles are environment and facilitation.

Environment

As soon as an assignment or project starts, one of the first things BAs can do is figure out what kind of environment they are in. Not just figuring out the project environment, but more importantly, the requirements-gathering environment. Is it hostile? Is it new? Is it “friendly”? Or is it something completely different? One of the quickest ways you can establish what kind of environment you’re walking into is to focus your senses to the pulse of the project. Is the project’s health good? I.e., is the project team’s moral good/positive? Is the project status green? Are deliverables being met? If the project environment is healthy (good or green), then you, as the BA, should be able to easily adjust your style—if necessary—to be supportive in that environment so you can grow your knowledge and help promote the positive vibe. And it could be that you don’t have to adapt anything at this point. You could find yourself in a situation where everything is running smoothly and all you have to do is join in the fun and perpetuate the positive environment.

Conversely, if the environment is hostile (or bad) then it is essential—almost imperative—for BAs to adapt their style so they can be successful in that environment. Some signs to look for to determine if you could be in a hostile project environment are: project team member morale is low, people (stakeholders, SME’, IT, QA, etc.) do not get along due to project-induced stress, deliverables are not being met or the project is in a red status. One of the simplest, easiest things BAs can do to adapt their style to be successful in a hostile environment is to ask questions—but not just any questions. Be sure the questions you ask are thought-provoking and open-ended. Your goal is to foster insight and feedback from your project peers, not insult them due to a lack of knowledge or their potential ignorance. Additionally, you don’t want to make an already hostile environment worse by asking questions that are rhetorical (unless when proving a point or trying to get someone’s “light” to come on for their “ah ha moment”) or questions that could make you lose credibility. Steer clear of questions like, “Why didn’t we discuss this sooner?” “Why is that in scope?” or, “What are we trying accomplish?” These types of questions can incite frustration and can possibly damage your credibility as the leader of the requirements-gathering session. Try asking questions like, “What can we do from a process and functionality standpoint to fulfill the customer’s needs?” or, “What would the user think if we added this widget?”

Another thing a BA can do to find success in a hostile environment is create partnerships with project team members, SMEs and stakeholders built on credibility, trust and knowledge. Use your skills, strengths and past experiences to bridge gaps with other team members who are generating obstacles or who may be difficult to work with. The sooner you find common ground and create a healthy relationship with these folks, the easier it will be for you to extract requirements from them. The reason for this can be chalked up to the old adage that it’s easier to catch flies with honey than vinegar. Creating a partnership and building trust with project team members, SMEs and stakeholders will make it easier for you to have the conversations necessary to elicit requirements, especially in hostile/challenging situations where it can be difficult to pull information out of a resource that doesn’t play nicely in the sandbox. Is it possible? Yes. But it’s not easy. Trust me, I’ve been on both sides of that fence.

Facilitation

Whether you are in a healthy or hostile project environment, how you adapt your facilitative style is what could make or break your requirements gathering experience. Not only is good facilitation one of the key components for eliciting requirements, but it’s the one adaptive characteristic that a BA can tap into for quickly switching gears, changing directions and altering the landscape of requirements gathering. Picture this: you’re a lead BA facilitating a three-day JAD session with a mix of SMEs, IT resources and a couple project stakeholders. Everything is going smoothly. Your requirements sessions are fruitful (generating requirements), on time and on scope. Then, on day three you hit a snag when trying to drill down a business requirement to capture the desired technical functionality. You find yourself standing at the front of a room full of people who cannot agree on what the requirements should/can be. Something like this can happen at any time during the first session or over the course of a few weeks, depending on how fast your JAD sessions are moving and how much ground you are covering. But no matter when it happens, it’s crucial for the BA to 1) recognize that it has happened, and 2) adapt a facilitative style to get the group to reach a consensus on requirements and resume moving forward.

In my ten years of experience, this has happened to me numerous times and the one quick change I have found that provides an immediate positive effect is to spend 5–10 minutes taking a step back and reminding the group of the problem you are trying to solve (or new functionality you are creating). Often, JAD sessions stall because of a loss of focus. Whether it’s scope, project goals or the requirements themselves, when your audience loses focus, momentum slows and agreement dries up. Remind them of the purpose of why they are in the room to begin with. Doing so will remind everyone that they are on the same team and trying to achieve the same goal. After that, spend a few minutes rewinding the progress you have made to that point to show the group of the teamwork they’ve put forth to get to that point.

The next thing that helps get a JAD session back on track is to verify that the right people are in the room. Maybe your JAD session has run aground because no one in the audience feels comfortable making a decision about the functionality or problem being solved. Or, more realistically, they do not have the power to make the decision. (If you have run aground at the very beginning of your JAD session you might want to escalate to the PM to revisit the project scope with the team. I bring this up because more often than not, stalling out early in requirements-gathering efforts is usually due to unclear scope or a lack of agreement on scope.)Likewise, if you find your JAD sessions going well and you finish up early, take the opportunity to shift gears and adjust your facilitative style to be more thought-provoking by requiring a deeper level of detail in order to cover any extended requirements/functionality/process steps/needs if there is extra time. As a BA facilitating a requirements-gathering sessions, you must always be prepared for the worst- and best-case scenarios. The last thing you want to do is leave time on the table or possibly lose credibility by appearing to not be fully prepared for all scenarios. Though it is unlikely that the audience will see you as the latter, my motto is to over-prepare to keep yourself from under-delivering.

These are a few of the best practices that I’ve used to find successes when adapting my BA style to deliver top-quality requirements. And while there are other key components of adaptive adjustments for the BA space, use those mentioned above to get you started down the path of consciously thinking about adapting your BA style when environmental and/or facilitation conditions change. And don’t be afraid to challenge yourself to adapt to your surroundings; that’s how good BAs become great BAs.

Don’t forget to leave your comments below.