In previous blog posts, we compared how people who work in business analysis have many parallels with entrepreneurs. Much of the similarity rests with the products that BA practitioners help create and the solutions they bring to organizations. There are also many, many personal traits and skills that the two have in common.
Often I come across situations where a BA is unprepared or under-prepared in approaching the requirements elicitation process. This leads to irritated business users, incomplete requirements, significant delays, reworks, and poor opinion about BA's in general. I decided to put together a list of pre-requisities that a BA must complete before commencing requirements elicitation process.
Having worked in financial services, with insurance companies and a number of software companies, while being very active on social media in my free time, I noticed several interesting trends that I would like to share.
Deliverables and artifacts were a focal point of BA work during the early part of my career. If I look back, it seemed the primary purpose of a BA was to generate paper—lots of paper—usually in the form of a giant BRD (business requirements document), and other related artifacts to support the Software Development Lifecycle and Project Management Process. As I grew in my career I realized my role as a BA was much more, and continued to evovle and struggle with the role of the template and paper.
Business Architecture: from Chaos to Processes
Large corporations try to make sense from chaos that surrounds them by understanding their environments, finding rules of thumb, implementing robust, repeatable, replicable processes and ultimately optimize their profits. This reality gets to be more complicated with large corporations. It involves numerous professionals within the corporation that do not naturally communicate with each other often creating duplicated efforts or even worse confrontational efforts. Furthermore, new unresolved business challenges emerge frequently for which a corporation has yet to find valid rules of thumb and that can even make their current rules of thumb obsolete. This is where the business architecture discipline comes into play in result oriented corporations.
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.
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.
Who’d of thunk it? The Pope’s New Year speech offers insight into issues that affect MANY organizations. This courageous leader gave a list of fifteen sicknesses inflicting the Vatican organization.
I have had the opportunity to be a developer before becoming a business analyst. Why do I say opportunity? Well in truth, the word was carefully picked. I can honestly say that I found out what not to do as a BA as opposed to what to be as a BA whilst I was a developer.
Last month we talked about adding value. In truth, delivering value is everyone’s job. We are all here to add value. Some of us do that through thinking up new things, some through helping a customer over the phone. Some add value by selling things in a physical store and others by writing code. In the exchange between a company and an individual you deliver some value to the company and in exchange you receive value, such as vacation time, retirement savings, and maybe insurance.
As a Badass Business Analyst, I am keenly aware that there are always going to be difficult conversations to be had, opportunities to be seized, monumental influencing efforts to undertake, and times where I simply need to go against the grain or broach a difficult topic. I might just have to disobey normal conventions. We are about to have one of those “moments”. Have you intelligently disobeyed your leader or your organization lately? One can argue that if you are not actively and intelligently disobeying on a regular basis you are not progressing, evolving, and helping out your organization.
The Entrepreneurial BA Practitioner Part 2: Entrepreneurial Traits of Business Analysis PractitionersWritten by Richard Larson & Elizabeth Larson
In our previous article, What do Business Analysis and Entrepreneurship Have in Common?, we outlined some high-level similarities between business analysis and entrepreneurship. Now let’s explore some detailed parallels between the two.
In January we wrote an article like we do every year about the upcoming trends in business analysis and project management. In this article we want to discuss what these trends mean for practitioners of business analysis. Below are the seven trends we discussed in last month’s article and a short description of each.
It’s project kick-off time! February, more than any other month, tends to be the time when organizations transition from planning to action. New initiatives have been prioritized, dollars have been allocated and teams are being formed—everyone is ready to get to work.
Many financial organizations find that it’s easier to just keep patching old technology rather than to make the kind of major changes to their core systems needed to become the business they really want to be. So, they keep pushing major transformations off, until one day the risks of maintaining the status quo become overwhelming.
Far too often, implementation of business analysis (BA) as a valued discipline within organizations is elusive. Business analysts (BAs) struggle to form BA communities, share knowledge and best practices, and improve competencies and outcomes of their efforts. These improvements will only reap limited benefits. What is needed to respond to 21st century challenges is a disciplined, value-creating BA Practice. However, we often falter when attempting to implement a formal BA discipline withing companies and non-profit agencies. It is an arduous task, a cultural change, a complex endeavor.
Todd Olson was the VP of Products at Rally Software for a few years. I met Todd when he was the co-founder of 6th Sense Analytics here in the Raleigh-Durham area. Todd’s background is mostly as a software engineer, but after Rally acquired 6th Sense, he developed a wonderful sense for product evolution and management as well.
A healthy respect for the magnitude of what we don’t know
Every time I start to believe I’m building an expertise in something or starting to mature into an experienced “adult”, life has a way of smacking me in the head and reminding me that “I don’t know jack.”
In the old days, business analysts used to gather or collect or capture requirements, but all that changed in 2009 with the second edition of the BABOK® Guide. Now we elicit requirements and other business analysis information, and the term elicit was defined in the BABOK® Guide as meaning “to call forth, or draw out”.
It seems that the good folks at the IIBA didn’t tell us the whole story. However they were on to something when they said the term means trying to uncover unstated and implied needs, not just what the subject matter experts (SME’s) tell you they want. This proves that you can’t just accept what your SME’s tell you, you have to work at it to discover what they aren’t telling you.
…IF you can tell what the prize really is. Let’s consider a list of potential “prizes” and the meaning of each for developing requirements.
THE Prize (by definition): Meeting Organizational Goals and Objectives
This ought to be the gold standard for developing requirements. Is it the standard at your organization? Try carrying the organizational mission, goals and objectives with you to share at requirements meetings. Whenever a debate erupts about some requirement, pull the goals out. Ask the group if the existing goals offer direction to resolve the debate. If so, the organization is practicing “BA behavior”.
Last year I had the opportunity to attend a course by Penny Pullan called Creative Facilitation. It was a course with heaps of practical tips around how to add creativity to the way you facilitate and present information. It was during this course that I had one of the those light bulb moments; adding creativity to how I facilitated meetings was great, but it was the idea that I could also apply this creativity to other business analysis tasks that got me really excited.
Have you noticed lately that there are a lot of industry “buzz words” and “phrases” that seem to be driving your corporation’s strategy and your every day approach to work? “Agile”, “agility-minded”, “progress over perfection”, “fail faster”, “do more with less”, and “get stuff done” are a few of the common ones these days. These are all challenges that are being issued on a daily basis. You know what? I don’t disagree with those challenges. I think it is a natural decision for leaders to make as they strive to make the bottom line or find creative ways to increase profits, but is it doable?