Sometimes I get questions from BAs and PMs, and when I can’t answer them, I pass them on to CBAP 007. With an IIBA license to drill, no business analysis issue is too big or too small for this experienced professional. Here is one from July 2015:
We’re addicted to the search for THE answer to our problems. Good answers aren’t good enough. We want THE answer that will solve a particular problem in every situation. A suite of solutions that can solve the problem most of the time is judged as grossly inadequate.
As a Business Analyst, your work is generally concerned with developing an understanding of an organization, and then communicating that understanding in ways that are efficient and actionable. Use this simple technique, outlined below, to quickly understand the aspects of an organization that are typically of interest to a BA.
In my classes and consulting work I get the same complaints when I ask teams about the biggest roadblocks in requirements work:
- “My stakeholders keep adding features.”
- “My stakeholders keep changing the requirements.”
- “My stakeholders don't know what they want.”
C. K. Chesterton penned a quote that I’m especially fond of, “It isn't that they can't see the solution. It's that they can't see the problem.” It’s one that constantly reminds me that there is always, without fail, an opportunity lying around somewhere. I just need to find a way to find it.
Requirements gathering is the cornerstone to the success of any Agile project. There is no denying the fact that stakeholders often struggle in providing the functions and features that they expect from a system but rather provide the details and system behaviour. The key to achieving clarity is progressive elaboration. Interviews and workshops with stakeholders conducted by the business analyst can achieve this progressive elaboration.
What must we do to bring about a Change initiative as smoothly as possible? Communicate! Communicate! Communicate!
How much, and for how long do we do this? Until we get sick and tired of the sound of our own voice – then we take a deep breath and a drink of water, and we start all over again.
Communication isn’t something that stops and starts; it’s a constant activity before, during and after any Change initiative.
Have you ever wanted to be a spy?
We may not be qualified to be the gun-wielding, smooth-talking James Bond, but maybe a savvy CIA analyst might be more up our street. There are, of course, parallels in many types of analysis work and while our projects may be a little less glamorous than counter-terrorism, there are things we can learn from the world of Intelligence Analysts.
In the first part of this post we began to explore the Project Management quadrant of my 4-Quadrants of Product Ownership model. When I introduced the 4-Quadrants in this post or blog post, I introduced four areas where I thought a skilled and well-balanced Scrum Product Owner had to have skill and focus:
No. That isn't a question about your personal life, it's a question about your work life. Are you still engaged? Or has the passion for your work worn off? More to the point? Are our staff still engaged? Do they look forward to arriving at the office, or are they regularly having to buy new alarm clocks because the old ones don't hold up to the Monday morning mauling to shut them up?
The issue of 'employee engagement' has become a bit of a trend lately. Head to Google Trends (www.google.com/trends) and type in 'Employee Engagement' for a visual representation of that trend based on Google searches. (Compare it to how my specialty of 'Change Management' is trending. Oops. Do I need to change my topic?)
It’s probably safe to say that many organizations that perform software development are either using some form of Agile methodology or are in the process of implementing Agile. Management in these organizations very likely believes that Agile will deliver numerous benefits to the organization thereby allowing them to receive numerous accolades, applause, and recognition for their incredible foresight. Unfortunately, these lofty expectations are often wildly out of line and potentially detrimental to their organization. Frustration and disappointment are the typical reality in organizations adopting Agile for the first time. Understanding the root causes of this frustration will help avoid disappointment and the disruption to productivity in your project teams.
The short answer: Because you want a project delivered on time, meets your specifications, and works for the end customers.
The long answer: The following project is a real example to illustrate the missing pieces and how a business analyst could have made a huge impact. Do you see similarities with a project you have?
A team member (let’s call him Guy) worked with the client managing multiple Excel spreadsheets. Guy saw a pain point and realized he could do something about it. He suggested building a web application with relational databases to help the team. The client liked this idea because they realized this new tool would impact forecasting and reporting – affecting the bottom line.
Being a successful Business Analyst means you have to have a variety of different skills and be adaptable to a changing environment. Every Business Analyst will bring their unique blend of skills and experience to the role, of course, but I’ve highlighted below what I think are the most common skills that a good BA will need. Feel free to add in the comments any other skills that you have found helpful in your BA career.
|Traceability matrix||Slavishly make this|
|Functional decomposition||Dump on free thinking positions|
|Balanced scorecards||Biased scarecrows|
|Verify requirements||Vilify requirements|
|Active listening||Passively missing meeting|
|Clarity, completeness, coherence, concision||Confusion, carveouts, crazy, carrying on & on &…|
|Enterprise architecture||Architect renter prizes|
|Decision analysis||Revision paralysis|
|Agile methodology||Methodological fragility|
|Measured outcomes||Declarations of victory|
|You found the error||You didn’t find the error|
On the surface, this statement appears as if I’ve lost my mind. For one thing, a traditional view of Product Owners is as a Product Manager or a customer/business stakeholder-facing role, and the traditional Project Manager is more a planning and execution focused role. The two are quite far apart and seem to have little synergy.
Process mapping is often the first step in business process improvement. It is a necessary activity that provides a baseline from which improvements can be measured and is the key to identifying and localizing opportunities for improvement. Therefore, it is important that facilitators capture the right information to help steer process improvement initiatives in the right direction.
In my opinion, a project without a business analyst is doomed to fail. I may be exaggerating a bit and probably even underrating my ability to fill both roles, but I was a bit spoiled in my last W2 project manager position. I had very skilled business analysts assigned to every project I was leading. I helped them with requirements and functional design documents, but they did the real work. They made it all make sense to the developers. The tech lead knew who to go to with questions in terms of requirements and scope. I could do it – but the BA already had the walking around knowledge so he was the go-to person on design issues for the tech lead if he was around.
While it may seem to many that the benefits of business analysis are obvious, the truth is that many businesses don’t completely understand how analysis can help their business. In actuality, business analysis can be the glue that holds a business together.
In most organizations, the days of multi-year, single release, all-or-nothing waterfall projects have come to an end. Instead, teams (agile, waterfall and everything in between) are trending toward smaller, shorter iterations. They hope smaller iterations will reduce cost, shrink time-to-market and improve quality.
BABOK Version 3 vs. Version 2 - Taming the new Guide - Part 3: BA CORE CONCEPT MODEL (BACCM) and PerspectivesWritten by Elizabeth Larson & Richard Larson
In our continuing series on BABOK version 3 vs. version 2, we conclude with the two major additions made by IIBA: the BA Core Concept Model™ (BACCM) and an all-new section containing five perspectives on Business Analysis. This article provides a summary of the new BACCM, a practical definition of the six core concepts, and an example of each. This article also describes the new Perspectives and provides examples of the common elements in all the Perspectives.
Business analysis is a relatively new profession. Some say it is not really a profession, but more of a line of work or collection of activities. Others say it is a discipline, a business practice that has been woefully absent in the complex world of business. The International Institute of Business Analysis defines business analysis as follows:
Attention all stakeholders of the solar federation. My personal life has recently tuned me into pain in a way that makes me realize that the BA’s professional life offers great pain. “NO!”, you say, yet here is a list of hurts you may well have inflicted on a BA if you think about it carefully.
In Part 1 we started our comparison of BABOK version 3 and its predecessor, version 2. We outlined the Knowledge Area and Tasks that are changing with the new release and showed where the major changes are occurring. Our view is there were substantive, but not necessarily shocking changes in the versions pertaining to the KAs and Tasks. Now we turn our attention to the updates of the General Techniques in the latest BABOK version.