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.
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.