12 years ago when the IIBA began to form, many debates were had over what the project manager did on the team vs. the business analyst. I am sure the conversations were around before then. And I am shocked there is the same amount of discussions still going on today. It may be because I have a heightened awareness, but I dare to say there are more conversations happening today. Here are some examples of recent activities that sparked this blog.
Doesn’t it seem like we can hardly go a day without reading about how missed requirements are leading to incredible amounts of wasted time, energy, and money on information technology projects? I have been on enough projects to know that the statistics are most likely telling a realistic story about how projects get scoped, defined, and delivered, but that they are not necessarily giving a comprehensive account of the situation.
For those that aren’t in the know, a digital pen (also known as a smart pen) allows you to capture what you are writing in an electronic format.
This update is from the STP conference I’m attending in Denver the week of November 3, 2014. Software Test Professionals is a conference mostly focused towards testing, so the slant of all of the talks is that lens or perspective. That being said, the agile topics are by definition broader and more whole-team centered.
It’s a fantastic invention really.
It most likely was derived out of sheer necessity and in some cases desperation. In many varied situations you can pull from it a wide array of tools which will get the job done when you need it most. It’s a versatile, useful, multidimensional asset; a must have for those who dare to brave the unknown.
My brilliant readers know this piece of fun. Get credit in my next blog by offering more “B”s (and “C’s”) in the comments at bottom.
BA: See Business Analysis or Business Analyst.
Baseline: 1. A method of slowing progress to fit communal bandwidth; for example, the monthly rhythm of a change control board. 2. A clear, consistent, concise definition of feasible requirements suitable for: a) ruining with last minute executive confusion and “demand” deliverables; or b) for improving with carefully considered change management.
See Bob Prentiss Live in Washington May 4th - 6th at
Project Summit Business Analyst World Washington!
You want to make progress. You know that you are an innovator for your organization. You simply want people to listen to you, yet your voice and any challenge you put forth to do the right thing seems to go unheard or unrecognized. You need to ask yourself “why?” I get it, it can be very frustrating when you probably have the answer to a problem and are trying to prevent your company from settling for the status quo. So how can you get your voice heard? Let me ask you this: “Do you think you have been challenging appropriately?” Now “appropriately” sounds like I am just talking about being “nice”. It is actually much, much, more than that, which is why challenging appropriately is in fact, a challenge. For some of us, the answer is intelligent disobedience, but for some of us, it is learning how to challenge appropriately.
Process mapping is a group exercise in which teams of subject matter experts (SMEs) and/or process owners (POs) gather to determine how work gets done. Step-by-step diagrams are drawn to document the who, what, when and how a business task is performed. Teams utilize process mapping as a way of finding opportunities for improvement, increasing transparency between groups, and understanding the roles of systems in processes.
As Business Analysts we traditionally gather project requirements early in the process. We hold focus groups, we interview subject matter experts, we gather all we think we need for a project and then create the Business Requirements Documentation, get the green light, and hand it off to the developers.
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.