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.
My client's project struggled for direction. The team spent 4 months trying to determine what to build. Then, most of the team quit. A new team formed with the imperative to "just get something in the hands of the end user." The team achieved this in 2 months, but now they realize the value, purpose, and priorities of the project are unknown. In discussing next steps, the Development Lead Manager asks:
Not that long ago, I received an email from someone in the Northwestern part of the US. They were thinking of moving to agile approaches and they wanted to pick my brain surrounding the logistics of “going Agile”. It was an introduction of sorts, but it was also an assessment.
Most people in the BA field know that the IIBA® has produced an important update to its definitive Business Analysis Body of Knowledge, the BABOK® Guide. Released in April 2015, the BABOK® Guide includes major upgrades, ranging from the BA Core Concept Model™ (BACCM), to changes to most Knowledge Areas, the addition of 16 new techniques, and the addition of an all-new section containing five perspectives on Business Analysis.
In past articles, I’ve spent lots of time asking you to find common ground between waterfall and agile. Not to discount either approach, but in realization, when done well, they have more in common than we often recognize. This call to find bridges between approaches comes from my experience with organizations working hard to manage a melting pot of methodologies, approaches, and leadership mandates. Organizations value adaptability, flexibility, and experimentation while hanging on to patterns that are traditional and comfortable, so teams (and their vendors) include pockets of traditional, hybrid, and agile approaches.
Originially Published 10/27/14
One of the key roles of Business Analysts in the solution implementation process is to assess the readiness of the organization to take full advantage of the new solution. This is the role in which the Business Analyst acts as a Change Agent in the organization. Whether this is a software enhancement, new system implementation, business architecture, business intelligence, data, business process, product change, or change implemented by a customer, supplier or regulator, effective communication of the upcoming change to all affected by the change is important to preparing the organization to capture the expected benefit of the change.
I give complete credit for this article to Bob “the BA” Prentiss. I had to privilege and pleasure of hearing his keynote address to the Southwest Ohio Business Analysis Regional Conference (SOBARC), hosted by Cincinnati IIBA Chapter. It was a very entertaining and thought provoking presentation. So I invite you to consider “What is your BA Brand?”
My brilliant readers know this piece of fun. Get credit in my next blog by offering more “C”s (and “D’s”) in the comments at bottom.
C: The letter C, as in the acronym CDCTCX. Also used in the acronyms CZSG and CSZG, among others.
Maybe it’s because they are so easy to write. Given a template and a few minutes of guidance, anyone can write a use case description. The problem is that everyone writes them differently, and from different perspectives. One person may describe what they want a solution to do, while another tries to describe the design of a set of screens, and another tries to explain how an existing system works. If they all try to collaborate on the same use case, chaos is likely, personalities will take over, and the result will only satisfy the requirements of some of the stakeholders. Usually the technical solution providers persevere and we lose sight of what the business users wanted. We end up with use cases like “Create”, “View”, “Modify” and “Browse” which represent the developers’ point of view, rather than the business point of view.
It seems like we have been talking about this for 10+ years! We probably will continue the discussion for another 10!
Titles cause confusion. As Kupe’s blog talked about last month, confusion still exists regarding the PM and BA roles in general. The industry works hard to clearly define these roles, but the real-life challenges of organizations make perfect alignment to industry role definitions impossible. And, more recently, agile roles have been added to the mix.
In my line of work, we have working sessions between Business system users and IT. In these sessions, the IT people demonstrate innovations that might add value to the business. I recently attended a session where a particular IT team had come up with a way to improve a business process through a system optimization. Due to my little appreciation of technical jargon I got the concept that they were selling and as you guessed, it was a TOTAL DISASTER!!! The business user community was hardly captivated, and they did not buy into the concept. It was tossed out.
By definition, agile development is a team sport. The emphasis is on teams working and delivering together. It’s not measured by how many user stories the development team produces, but by how many completed/done stories the team can produce.