A great listener
Turn off analysis hat and really listen to what our stakeholders have to say.
- Using a variety of active listening techniques will help stakeholders realize I did really hear what they said and understood what they meant.
Define the problem before discussing solutions.
- Become a sounding board for new ideas and look for ways to help stakeholders discover technical possibilities
Reach across organisational boundaries, especially the gulf that seems to separate business and technology.
- Surface on both sides and forge new paths of communication between business and IT.
Strong Communication – facilitate working meetings, asking questions, listen to the answers (really listen), and absorb what’s being said.
- The ability to be a strong communicator in a virtual setting (via conference calls or web meetings) is equally important
Improve Analyst – Developer communication
Ability to communicate easily with Developers
- Understand the language of programming as I did this myself, at the beginning of my career
Look for opportunities to share business context with your technical team
- Will do wonders in establishing relationship with technical teams
Translate the technical language into business when Stakeholders require deep understanding
- Help a teammate
Overcome Common Communication Challenges
Learn along the way how to better influence your stakeholders next time
- “I told you so” or “remember last week when I pointed that out”
Leverage Techniques and Templates to Improve Communication
Be proactive with an issues list to drive attention to open items and breed accountability amongst your stakeholder team.
Avoid mystery meetings with quick and simple meeting agendas and start meetings by establishing context.
No project is without problems. In fact, the entire project is a solution to a problem. At the highest level
- Facilitate a shared understanding of the problem, the possible solutions, and determine the scope of the project – start by analysing the business process.
Evaluate multiple options before helping a team settle on a solution
- listen to stakeholder needs
- critically consider those needs and ask probing questions until the real need is surfaced and understood.
Documentation and Specification – the ability to create clear and concise documentation (the latter becoming increasingly necessary in a lean or agile world).
Analysis – use of a variety of techniques to analyse the problem and the solution – conduct analysis and deconstruct the problem or solution.
- The Business-Level, or how the business work flows operationally, often completed by analysing the business process.
- The Software-Level, or how the software system supports the business workflows, often completed through functional requirements models like use cases or user stories.
- The Information-Level, or how data and information is stored and maintained by an organization, completed using a variety of data modeling techniques.
Visual Modeling – create visual models that support your analysis, such as work-flow diagrams or wireframe prototypes to be able to capture information visually – whether in a formal model or a napkin drawing.
Facilitation and Elicitation – facilitate specific kinds of meetings: interviews and observations, requirements workshops, requirements review and validation sessions.
Business Analysis Tools
- use of basic office tools such as Word, Excel, and PowerPoint, Microsoft Visio.
- use modeling tools, such as Visio or Enterprise Architect (AXURE RP, ADONIS), requirements management tools (DOORS) or project (Clarizen) and defect management (there are really too many to list these days). It’s unlikely to find a tool that does not provide skills set that I posses and facilitate me to learn on-the-job.
Key Soft Skills
Relationship-Building – mainly stakeholders, which may be anyone who has something to contribute to the project and often will be many stakeholders from both, the business and the technical teams.
Building trust – stepping into a leadership role on a project team to bridge gaps.
Self-Managing – manage the business analysis effort, combining this role with the Project Manager role, which I find to be an strong advantage.
- proactive and dependency-aware
- commitment and respecting deadlines
- influence, delegation, and issue management.
A Thick Skin – receive a barrage of feedback on their documentation and proposed solutions
- be able to separate feedback on documentation and ideas from personal feedback
Deal with Ambiguity – embrace new information and learning as it surfaces, even if it surfaces later than we’d like.
Understanding of SQL, .NET, Perl, and VBScript
I have a conceptual technical understanding as it helps to analyse the problem to be solved and communicate with technical stakeholders
I don’t need to be able write code or run database queries.
I am specialized around a specific methodology:
- Agile Business Analysis
- discover what the business users need and want and determine what changes will have the most value to the business
- collaborate with business users across the organization, and to gain alignment on what is wanted and needed and ensure that those items in the product backlog and those details in the user stories represent true value to the business
- take a holistic view of the product backlog and find all those inner related requirements and inter-dependencies
- discover and analyse what those business processes are and help the business users implement the changes necessary to fully leverage that new software
- keep the backlog well organised and prioritised, and add estimates and filter through it, remove things, and add things so that the team can easily see what needs to be done in the next sprint, and the sprint after that
- Six Sigma – SIPOC, DMAIC, FMEA, 5 Why, 6 S,
- Business Process Modeling Notation (BPMN) – there are flow objects, connecting objects, swim lanes, and artifacts.
- When stuck using workflow diagram elements to represent a concept.
- When used in larger organizational objective that involves more formal modeling that is implementable in business process management tools.
Industry and Domain Expertise
I don’t need to be an expert in every domain or industry. In fact, that would be impossible.
- Telecommunication – B2B cable, Mobile and Cloud
- Manufacturing – Food, Water, Printing
There is a big difference between business analysis and business analyst roles. This means that as a business analyst we might specialize in any number of skills. It also means that even if we’re experts in business analysis, we may not qualify for all business analyst jobs.
Even the most senior business analyst, the kind who would qualify for the CBAP based on their years of experience across multiple knowledge areas, would probably qualify for less than the 50% of the business analyst job roles available today.
They simply don’t have the required skills.
If you are making a career transition, the stakes are even higher. Don’t expect to qualify for more than 20% of business analyst job roles.
At first this might sound bleak. But let it sink in.
Doesn’t that take the pressure off just a little?
Instead of chasing around dozens of skills you aren’t even certain you’d enjoy using, you have permission to focus on the relevant BA skills you already have.
We cover how this kind of focus can impact your job search in our business analyst job search process.
The Agile Business Analyst: 4 Crucial Strategies for Success
To follow-up from this video, let’s look at 4 crucial strategies for applying the business analysis process in an agile environment.
Agile Business Analyst Strategy #1 – Resist the Temptation to Skip Steps 1-3
Most agile practices make certain assumptions about what information the business stakeholders can provide and how quickly they can make decisions. These assumptions are valid inside steps 5-7 of the business analysis process. But steps 1-3 (Getting Oriented, Discovering the Primary Business Objectives, and Defining Scope) are still important.
As an agile business analyst, these decisions you help stakeholders make in these steps provide the foundation you need to effectively and iteratively deliver the requirements in step 5.
- The current capabilities assessment completed in step 1 will help you and your team discover simple, quick wins that can add value quickly.
- The business objectives discovered in step 2 will help your team prioritize the product backlog to put the highest value items first.
- The scope decisions made in step 3 will help your team stay on track and make meaningful adjustments to expectations.
Most often, these steps will start before the “agile” part of the project and it’s prudent to make time for them even as an agile business analyst.
(By the way, we cover each of the 8 steps of the business analysis process in our BA Essentials Master Class.)
Agile Business Strategy #2 – Create an Agile Business Analysis Plan (Step 4)
When it comes to step 4 – creating your business analysis plan – this is where it’s important for the agile business analyst to integrate the business analysis process into your organization’s version of agile.
Here are some specific questions you’ll want to answer as you work through your planning:
- How long are sprints scheduled for?
- What happens inside a sprint? Is there time for elicitation and requirements work or is the sprint all about developing and testing?
- What is the desired outcome of a sprint? Production-ready code is the typical standard but ready-to-test code is also a common deliverable in partially agile teams.
- How does the project team decide what to work on inside a sprint?
- What state does a product backlogneed to be in before a sprint?
- What state do the user storiesneed to be in before a sprint?
- Who is responsible for the product backlog and user stories? While these are natural responsibilities for an agile business analyst to take on, your project team may have a different way of doing things.
- What requirements work will happen inside the sprint?
Essentially, you want to figure out exactly how to fit your detailed functional requirements work into the agile process of your software development team.
Agile Business Strategy #3 – Plan for Multiple Iterations of the Detailed Requirements and Team Support (Steps 5-7)
Fundamentally, agile is an iterative development process. On the best agile teams I’ve been a part of, we developed a pattern of requirements, design, development, and testing that flows continuously so that everyone is always working on something meaningful. And this means the agile business analyst might be working on requirements that are developed and tested next week, or even tomorrow.
In the BA Essentials Master Class, we discuss specific ways to develop the detailed requirements iteratively in step 5. And it is important here to be sure you are eliciting, analyzing, and finalizing the requirements in an iterative, continuous fashion, so your product team has a steady stream of work for each sprint.
What’s more, while you are finishing requirements for the next sprint, you are also supporting the technology team during the current sprint (step 6). And you might also be supporting the business in implementing the changes from the previous sprint (step 7).
So steps 5-7 all happen, but they happen at the sprint level instead of at the project level, which means that in reality, you are working on all 3 steps at once.
In my experience, this is the biggest shift for us to get used to as agile business analysts, because this pattern of work requires us to manage our time extremely well and make sure we are working on only the most important tasks with each step. There is no time here for endlessly tweaking models or finessing the phrasing of requirements. Instead, we should be collaborating, reviewing, and getting all of our work “good enough” to take the next step.
Agile Business Analyst Strategy #4 – Regularly Assess Value in Step 8
Step 8 in the business analysis process involves assessing the value created by the solution. And here is where we as business analysts can start to fall in love with agile methodologies. In a more traditional, waterfall environment we might wait months or years to see our requirements implemented and the value intended by those requirements realized.
In an agile environment where production-ready code is delivered regularly, we might see slices of value realized within weeks. And that means we can also be assessing the value of those changes earlier, and communicating about the value already delivered by the project team before the team is even done with the project.
This kind of celebration and communication can create a lot of positive momentum inside our project teams and across our organizations. What’s more, as we see the initial changes deployed, we’ll often learn even more about what the next set of valuable functionality is, generating new ideas for new projects and backlog items, which will require regularly grooming the product backlog. Instead of staying stuck on what was originally in scope, it is important to leverage this learning and make adjustments.
An Agile Business Analyst is Still a Business Analyst
Although we might apply the business analysis process differently in agile, it’s just as important as ever to be a tried-and-true business analyst in an agile environment. In fact, if we try to skip over steps just because we are doing agile, we are likely to face more challenges inside our projects.
If you are a business analyst on an agile team, consider how you demonstrate leadership within your own domain of business analysis by applying these crucial strategies to increase your effectiveness.