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.
This blog was supposed to be on requirements elicitation techniques, but it ended up being an example of what peer review does. I finished my blog and handed it over to my colleague for feedback. He pointed out that I assumed people knew how to gather requirements for them to start using the techniques mentioned in the blog. In other words, the blog on techniques was a step ahead, and I should first explain the approach. Ouch! The bump on my head still hurts. So, here we go.
I have been reading and rereading Arthur Conan Doyle’s stories and novels about the brilliant detective Sherlock Holmes for years. With the possible exception of Edgar Allen Poe’s lesser known Auguste Dupin (see The Murders on the Rue Morgue), Holmes stands as the pre-eminent and archetypical critical thinker and detective of all time. Sherlock Holmes provides the model for all the genius eccentric crime solvers who occupy the books, airwaves, and movie theaters of today. Holmes has a lot to say about how to analyze information and evidence and deduce the best solution or the perpetrator of the crime.
In recent years, we’ve seen even the most conservative, tightly-structured organizations begin to experiment with agile and hybrid approaches. These organizations have a long and comfortable relationship with the traditional waterfall approach, but their curiosity leads them to dabble in agile. Where does this leave their well-defined and well-protected organizational templates, standards, and best practices?
A picture is worth a thousand words - somebody surely captured a lot in this saying. I am a Business Analyst and I write business requirements so where does this fit in? Well, it does fit in the context of all the diagrams that a BA can leverage to put forth business requirements in concise manner. In this article, let’s explore the world of data flow diagrams.
So, you don’t think you are an entrepreneur? You are not going to start a company or build a business from the ground up. You are not going to risk your livelihood or work crazy hours or wear multiple hats like an entrepreneur does. We suggest you think again.
Case Studies in Stakeholder Engagement and the Business Analyst Role
I am wondering how many people, after reading that title and my biography, think that I am going to suggest that business analysts should run the business. If you think that is the path that I will take here, you will be sadly disappointed. The Business Analyst’s task is to identify the business problem and get the group of involved stakeholders to collaborate on a solution to that problem. The business analyst is rarely the owner of the solution.
In my previous post I promised to list the skills a Business Analyst must have. While there are many qualities/skills required I list only those that are critical. After all, there is no “ideal” BA!! Before I do that let me briefly discuss the types of BA’s as the skills differ slightly for each.
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.