Tag: BABOK

A 3-D View to Understanding the BABOK

As a business analyst practitioner and facilitator, I often find myself cautioning those individuals who are embarking on certification to pay particular attention to 2 key things when studying for either the CCBA Exam or the CBAP Exam.

  1. Do not read the BABOK from front to back or put another way, do not read it in a linear fashion!
  2. Rely heavily on your experiences and pragmatic approach to business analysis.

Here is how I start off the conversation with BA Certification candidates;

“If you had to choose a Knowledge Area or Task outlined in the BABOK, which one would you start with?”

As you can imagine responses are wide and varied some respond with Strategy Analysis, others with Elicitation and Collaboration while others are adamat that all business analysis activities must start with Planning and Monitoring.

brule 06272018a

The truth is ALL business analysis activities must start with a business need. All business needs must consider validity to the business and feasibility.

The sixty four million dollar question now becomes how do we go about doing this?

The answer quite frankly is not an easy one, and this is where the 3-D approach comes into play.


Advertisement

Consider This Business Analysis Exam Study Tip

In order to understand the business need it is likely we are going to want to engage with stakeholders, this means we would need to a. identify stakeholders and b. conduct some sort of elicitation activity to do so. In order o identify stakeholders we may have to undertake some sort of current state analysis by modeling out the organization or developing a context diagram.

And there you have it! To simply understand the business need we have evoked activities from the Planning and Monitoring Knowledge Area, Eliciation and Collaboration, Strategy Analysis and Requirements Analysis and Design Definition, all these activities have collided together for the sake of on task – understanding the business need, and we have yet to begin to understand what the solution may look like, if in fact it is feasible!

sullivan 06272018b

CONCLUSION:

For exam preparation I would strongly suggest that you consider reviewing the input and output diagrams as this will paint the 3D story of how knowledge areas and tasks are closely inter-related here’s a classic example.

brule 06272018c

Note all tasks that use the output from task 3.1 Plan the Business Analsyis Approach

brule 06272018d

There certainly are a great deal of tasks dependent on the output for task 6.2 Define the future state!

Would you like a copy of a comprehensive map that demonstrates all the relationships between knowledge areas?

Check this Out >>> The New IIBA Business Analysis Core Standard

IIBA Podcast Episode 1: Global BA Core Standard and Future of Business Analysis

Episode 1: Global BA Core Standard and Future of Business Analysis with Kevin Brennan

Key learning points:

  • Learn all about IIBA’s Global Business Analysis core standard.
  • How to make the standard useful in your practice as a business analysis practitioner.
  • High-level walkthrough of the different sections of the standard
  • Discover the importance of using a common language for anyone working in business analysis regardless of their role or industry.
  • The future of business analysis

Listen here:
{source}

{/source}

Bios:

Kevin Brennan has spent the last decade transforming the profession of business analysis, leading the development of multiple editions of the BABOK® Guide and driving the adoption of agile and architecture practices. As a senior executive in the social enterprise space, he has managed a product portfolio through rapid growth and built fully digital and virtual organizations. Kevin is known for his ability to deliver practical, effective and focused solutions to complex strategic problems and lead teams through periods of significant organizational and market changes. He has been a keynote speaker at conferences around the world and frequent author on topics including digital transformation, strategy, and leadership.

Yaaqub Mohamed a.k.a Yamo, is a passionate and practicing business analysis leader, author, keynote speaker and consultant from Toronto, Canada. He has worked in diverse domains such as: Government, Retail, Auto, Property, and Life Insurance, Mutual Funds, Banking, Sales and Marketing, CRM, Cloud Computing, Mobile App Development and the Non-profit sector. Yamo believes in adding relentless value to the BA community and advancing the practice. He’s the founder of BACoach.com blog and hosts the #1 ranked BA podcast on iTunes to help business analysts throughout the world, do analysis better, by providing educational, relevant, and inspiring content.

From the Archives: Diving Into Unofficial Roles & Responsibilities of the Business Analyst

Why are we the psychologists and the babysitters?  

Often on airplanes I get asked, “So, what do you do?” 

 I am sure if you travel you get this one as well!  Do any of you answer with “I am a therapist?”

Well, I do, and it works really well! I am a therapist that helps business teams and technology teams work together and create meaningful products, services, and systems.  

  • I help them agree on changes and create a shared understanding.
  • I create a process and platform to communicate.
  • I make them both feel like they are the ones who came up with the ideas.
  • I make conflict seem like a non-issue and create win/wins.
  • I present options and alternatives and work through, with the pros and cons.
  • And, they pay me an hourly rate to do this!

You rarely see “therapist” on a list of required BA skills, but a comparison of BA job descriptions across industries, across nations or even across a single organization, yields an amazing variety of responsibilities and required skill sets. Even the industry leading IIBA BABOK (embedded link: http://www.iiba.org/babok-guide.aspx) highlights more than 20 underlying competencies that support the professional practice of business analysis.

Related Article: Your Next Business Analyst Will be a Robot

Lengthy BA skill lists that include creative thinking, technical skills, adaptability, listening, solution knowledge, teaching, testing, leadership, facilitation, etc., confirm our reality that BAs are expected to be the Swiss Army Knife of the project, product, IT, or operations world. It’s no wonder that most BAs claim to “wear many different hats.” 

Despite the wide variety of accepted roles and responsibilities, BAs are often asked to wear strange hats—to take on unofficial duties that don’t really fit the wide range of normal. I get asked in my classes on a regular basis: “Is it the BA’s role to ___________?”  Students fill in the blank with common things like testing, coding, and project management, but hostage negotiator, spy and therapist have also landed at the end of their question!

Here are a few true stories I’ve collected over the years, with names changed to protect those who might be embarrassed by their big, floppy, gaudy, leopard-print hats:

Undercover Agent

  • BA Becky was a well-respected senior BA in her organization. The BACoE leader recognized her accomplishments by asking her to mentor a struggling team. The odd part of the assignment—BA Becky was asked to be an undercover mentor—she was not allowed to tell the team she was mentoring them. 
  • BA Barry was on a project team that needed to create a pricing strategy for the organization’s products. The strategy included several assumptions about their competitor’s pricing. The team leader asked BA Barry to “secret shop” the competitor to validate the assumptions.  

Ghost Writer

  • BA Beth asked her stakeholders from California, Texas and Arizona to travel to Minnesota for a full-day face-to-face requirements review meeting. The day before the big meeting, the project manager realized that BA Beth’s requirements were a huge mess. The requirements review would be a disaster. So, the PM asked BA Bart to stay late, re-do BA Beth’s requirements, and bring the new and improved requirements document into BA Beth’s meeting.  

Translator

  • BA Brody was fluent in Spanish, so it makes sense that he was asked to review, translate, and validate a 6-months old, 300-page requirements document written in—Portuguese! The business sponsor asked, “Since you are fluent in Spanish it won’t be too hard to translate, right?”

Scapegoat/Peace Negotiator/Psychologist

  • A crafty project manager tossed BA Ben under the bus when she asked Ben to present a feasibility analysis to an erratic, f-bomb-wielding business owner. The business owner had great vision, but cost and feasibility did not meet his expectations, and the PM did not want to be in the line of fire. 
  • BA Belinda got along well with everyone on her project team. So, naturally, the project manager asked BA Belinda to “figure out” a way to get a notoriously mean and stubborn database engineer to cooperate with the team. 
  • Late one afternoon in mid-October, BA Betty found out she would be laid off at the end of the month. That same day, BA Bill was asked build a relationship with Betty to get the information he needed to take over Betty’s requirements work for a few projects.  Obviously, laid-off BA Betty was NOT excited to do the knowledge transfer!

Babysitter

  • BA Brent was very smart but quite odd. His analysis work was solid, but his social skills were suspect. The team leader asked BA Betsy to help Brent stay focused, to monitor his interactions with the business SMEs and to step in when needed to ensure deadlines were met.

After Hours Snooper

  • BA Bill worked in a business unit where employees processed checks. Employees were required to secure the checks when they left the office each night. To validate compliance with check procedures, BA Bill was asked to stay late one night to search employee cubicles for unsecured checks. 
  • Important documents were missing from several client files in BA Brenda’s organization. Brenda’s team leader asked her to return to the office after hours and search processing analysts’ desks for the missing documents.

Data Detective

  • A third-party software vendor refused to provide their data model to their customer. The customer needed the data model to develop requirements and meet the needs of their business. BA Barb, a member of the customer project team, was asked to reverse engineer the vendor data model. 

What is it about the BA role that makes us prime targets for these odd assignments? I don’t see project managers or testers or developers wearing these odd hats. 

The majority of these unofficial roles rely on our ability to build and maintain relationships with a wide variety of people. Maybe, these odd assignments are a compliment? Perhaps people skills are the primary strength of effective BAs, and these unofficial roles are just a side-effect of our success.

Have you ever taken on one of these odd roles or do you have another unofficial BA role to add to my list? Share your story in the comments below!

Note: This article was originally published on batimes.com on September 14, 2015

Well, I do, and it works really well! I am a therapist that helps business teams and technology teams work together and create meaningful products, services, and systems. 

·        I help them agree on changes and create a shared understanding.

·        I create a process and platform to communicate.

·        I make them both feel like they are the ones who came up with the ideas.

·        I make conflict seem like a non-issue and create win/wins.

·        I present options and alternatives and work through, with the pros and cons.

·        And, they pay me an hourly rate to do this!

You rarely see “therapist” on a list of required BA skills, but a comparison of BA job descriptions across industries, across nations or even across a single organization, yields an amazing variety of responsibilities and required skill sets. Even the industry leading IIBA BABOK (embedded link: http://www.iiba.org/babok-guide.aspx) highlights more than 20 underlying competencies that support the professional practice of business analysis.

Lengthy BA skill lists that include creative thinking, technical skills, adaptability, listening, solution knowledge, teaching, testing, leadership, facilitation, etc., confirm our reality that BAs are expected to be the Swiss Army Knife of the project, product, IT, or operations world. It’s no wonder that most BAs claim to “wear many different hats.”

Despite the wide variety of accepted roles and responsibilities, BAs are often asked to wear strange hats—to take on unofficial duties that don’t really fit the wide range of normal. I get asked in my classes on a regular basis: “Is it the BA’s role to ___________?”  Students fill in the blank with common things like testing, coding, and project management, but hostage negotiator, spy and therapist have also landed at the end of their question!

Here are a few true stories I’ve collected over the years, with names changed to protect those who might be embarrassed by their big, floppy, gaudy, leopard-print hats:

Undercover Agent

·        BA Becky was a well-respected senior BA in her organization. The BACoE leader recognized her accomplishments by asking her to mentor a struggling team. The odd part of the assignment—BA Becky was asked to be an undercover mentor—she was not allowed to tell the team she was mentoring them.

·        BA Barry was on a project team that needed to create a pricing strategy for the organization’s products. The strategy included several assumptions about their competitor’s pricing. The team leader asked BA Barry to “secret shop” the competitor to validate the assumptions. 

Ghost Writer

·        BA Beth asked her stakeholders from California, Texas and Arizona to travel to Minnesota for a full-day face-to-face requirements review meeting. The day before the big meeting, the project manager realized that BA Beth’s requirements were a huge mess. The requirements review would be a disaster. So, the PM asked BA Bart to stay late, re-do BA Beth’s requirements, and bring the new and improved requirements document into BA Beth’s meeting. 

Translator

·        BA Brody was fluent in Spanish, so it makes sense that he was asked to review, translate, and validate a 6-months old, 300-page requirements document written in—Portuguese! The business sponsor asked, “Since you are fluent in Spanish it won’t be too hard to translate, right?”

Scapegoat/Peace Negotiator/Psychologist

·        A crafty project manager tossed BA Ben under the bus when she asked Ben to present a feasibility analysis to an erratic, f-bomb-wielding business owner. The business owner had great vision, but cost and feasibility did not meet his expectations, and the PM did not want to be in the line of fire.

·        BA Belinda got along well with everyone on her project team. So, naturally, the project manager asked BA Belinda to “figure out” a way to get a notoriously mean and stubborn database engineer to cooperate with the team.

·        Late one afternoon in mid-October, BA Betty found out she would be laid off at the end of the month. That same day, BA Bill was asked build a relationship with Betty to get the information he needed to take over Betty’s requirements work for a few projects.  Obviously, laid-off BA Betty was NOT excited to do the knowledge transfer!

Babysitter

·        BA Brent was very smart but quite odd. His analysis work was solid, but his social skills were suspect. The team leader asked BA Betsy to help Brent stay focused, to monitor his interactions with the business SMEs and to step in when needed to ensure deadlines were met.

After Hours Snooper

·        BA Bill worked in a business unit where employees processed checks. Employees were required to secure the checks when they left the office each night. To validate compliance with check procedures, BA Bill was asked to stay late one night to search employee cubicles for unsecured checks.

·        Important documents were missing from several client files in BA Brenda’s organization. Brenda’s team leader asked her to return to the office after hours and search processing analysts’ desks for the missing documents.

Data Detective

·        A third-party software vendor refused to provide their data model to their customer. The customer needed the data model to develop requirements and meet the needs of their business. BA Barb, a member of the customer project team, was asked to reverse engineer the vendor data model.

What is it about the BA role that makes us prime targets for these odd assignments? I don’t see project managers or testers or developers wearing these odd hats.

The majority of these unofficial roles rely on our ability to build and maintain relationships with a wide variety of people. Maybe, these odd assignments are a compliment? Perhaps people skills are the primary strength of effective BAs, and these unofficial roles are just a side-effect of our success.

Have you ever taken on one of these odd roles or do you have another unofficial BA role to add to my list? Share your story in the comments below!

5 Easy Ways to Make the BABOK® an Irresistible Read

“Are you kidding me, Yamo?”  If that was one of the first thoughts that came to your mind when you saw this post, I wouldn’t be surprised.

A few business analysts think that the BABOK® is a dry read. It may be for various reasons, and we will explore a few of them and what to do about it by diving into five ways to make the BOK talk to you. The latest edition of the BABOK® is version 3 and adds new elements to how you could leverage it as a practitioner.

After all, BABOK® is about showcasing a disciplined approach and framework to help businesses change effectively. And anything that entails discipline is not necessarily a gripping Star Wars trilogy that will get you hooked from the first word to the last.

So, why do you think BABOK® comes about as a dry read?

There are a few aspects of BABOK® that make the readers miss a few essential elements. For example, not being able to relate to a few tasks, detailed explanations of a few tasks that you “think” that you never did, or just the overwhelming feeling that you have to remember too much.

Reading and getting hooked to the BOK is an acquired taste. If you have ever had the experience of trying sushi for the first time (you know the very thought of eating raw or semi-cooked fish can be a big turnoff) and transitioning from anxiety to eagerly looking forward to eating it – you will know exactly what I mean.

In this post, I would like to share five ways in which you can make the BABOK® really interesting to read as a practitioner.

1. Understand how the Knowledge Areas, Underlying Competencies and Perspectives Are interrelated

One of the most useful ways to understand the different knowledge areas is the WHW practitioners’ narrative. Whenever I am teaching a prep course or speaking to practitioners on how to apply the BABOK®, I make sure to illustrate this. This essentially translates to understanding how each of the knowledge areas aligns with what we do as business analysis
Practitioners, in conjunction with underlying competencies and perspectives. According to BABOK V3.0, a Knowledge Area can be defined as:

… areas of specific business analysis expertise that encompass several tasks

and it’s also important to emphasize that:

Knowledge areas are not intended to represent phases in a project.

So, what is the “WHW Narrative“?

When you look at the diagram below from the BABOK®, you realize that there is an interrelationship between the different knowledge areas:

yamomarch1

(Source: BABOK® V3 – used with permission from IIBA®)

The WHW Narrative looks at the relationship between knowledge areas, underlying competencies, and perspectives. It does this by asking the following three questions and grouping the Knowledge Areas (KAs) under them:

W – What Does a BA Do? – These are the innermost KAs. The tasks that are part of these knowledge areas are “What” we do as business analysis practitioners (at the core of it).

H – How Does a BA Work? – These are the KAs surrounding the inner KAs. The tasks that are part of these knowledge areas are “How” we go about doing business analysis.

W – Who is An Effective BA? – The ‘Who’ encompasses the Underlying Competencies, BA core concept model and perspectives. Treat this as skills, knowledge, and personal traits of an effective practitioner as well as the ability to understand how to apply business analysis tasks in different contexts and project types. So, this defines “Who” is an effective BA.

So, if we were visualize this, our diagram above would look like as shown below:

yamomarch2

In Conclusion: Use this narrative to relate back a task to your practice. As you go through the different tasks in these knowledge areas, use the WHW practitioner’s narrative to help you see the trees and also the forest.

[Hat tip to one of my friends, Jonathan Nituch to introduce a part of this to me]

2. Open the Doors of Curiosity – The Secret to do it

When you read the BABOK®, how can you create curiosity?

George Loewenstein, a professor at Carnegie Melon University, came up with what’s called “the information gap theory of curiosity” and it’s, hands-down, one of the best ways to create curiosity on demand.

Quite simply, curiosity, as defined by Loewenstein, is an innate human behavior that’s triggered when people feel there is a gap between what they know and what they want to know. (Source – The Itch of Curiosity).

Loewenstein then goes on to explain how this gap influences people to take action (such as reading more, using information in BABOK®, or performing better business analysis).

But the question remains: How can you do it?

Here is how: When you are reading the BABOK®, try and do the following two things to help propel your curiosity:

  1. The form and shape in which you do this task currently – introspective or retrospective curiosity.
  2. How can you do this task better – prospective curiosity.

3. Use a Real-World Case Study (Past or Current)

Some of us learn better by using examples and by using something that we can relate to. If you have used wireframes or screenshots as part of your requirements package or even provided a written example of a formula for a mortgage loan or amortization calculator, you will know what I mean. Examples standout and help with greater understanding and make the study material more relatable.

Sometimes your brain responds better to something that is more tangible. For example, if I use the following formula to tell you that force increases as mass and acceleration increases – it may not make immediate sense.

F = m*a

[Force = (mass) times (acceleration) ]

However, if I tell you that a 100 kg ball falling from a height of 10 meters will create more damage than a 10 kg ball falling from a height of 1 meter (or same height) – you will be able to visualize the impact.

So, when you read the BABOK®and when you are going through the different tasks, create your own “fictitious” case study to relate the tasks to. You could also pick your current project (or one from the past), to relate the tasks to.

4. Turn Headlines to Questions

The tasks and techniques in the BABOK® have a standard repeating structure. It is useful to convert these repeating elements into a set of questions that can help you better understand the material. Questions, by their very nature, help develop your comprehension.

For example:

Techniques – could be “How to conduct stakeholder analysis?”

Stakeholders – could be “Who all could be potentially involved in this task?”

Elements (Slightly different) – could be “What are the key considerations to keep in mind?” and a self-directed question for every element:

Type of project or initiative – could be “What kind of project am I working on?”

Communication formality – could be “How formal should my communication be?”

5. Plan to take CCBA or CBAP Exam

After you’ve gone through and rationalized the “Why Should I do CCBA or CBAP?” question, you should consider prepping for the exam. One way to make the BABOK® “irresistible” is to use the “fear of failure”.

So, when you have set your eyes on taking up the exam, you will be forced to study the BOK, and you will hopefully apply the first four ways of this post to make it an interesting read.

Which of these five would be your favorite way to make the BOK irresistible? Do you have any tips of your own to share?

Please use the comment space below to provide your comments, questions and feedback.

Getting the Project Client to Focus on Requirements

Having trouble extracting project requirements from your customer? Does your project client think they have already handed you all of their requirements and is asking why you aren’t starting to design the solution yet? Are they worried about eating up the project budget with useless planning when you could be starting the “real” work on the project?

I know starting the real work on the project is tempting. It may even be possible – if it’s a two day or two-week project. But if your project is of any length and dollar amount to speak of, then you must – repeat MUST – have genuine project requirements. These requirements must be detailed enough to design and build a solution, and complete and complex enough for you to avoid making wrong assumptions that result in expensive and time-consuming rework later on in the engagement.

You can’t please everyone all of the time

For me, it’s about asking the right questions. For the business analyst who is likely leading much of the requirements definition effort and functional design document work, it has to be about asking the right questions as well. What the customer thinks are the requirements usually aren’t the real requirements. Often, as many have found, and the rest will soon discover, what the customer thinks is the problem is probably only a symptom of the real issue. The actual project may be a few layers down – and that’s the problem, need or issue you need to address. Otherwise, you’ll end up delivering something that doesn’t solve the end users’ real needs.

You may have followed the customer’s perceived requirements perfectly and gotten paid handsomely at the end of the engagement (and during). But 30 days later you find out that your customer is not very happy because what you delivered – while spot on with requirements – is not what they needed. And you now have a dissatisfied client and one who will likely point the finger at you while going somewhere else to get it fixed, and their overlooking you for their next project. Ouch. No, let’s get it right the first time. Here’s how you get there.

The key questions for the client

Related Article: Process Approach to Requirements Gathering

What are you current business processes as they pertain to this project?

The key here is to understand how the business operates now. It will help you understand their need or the perceived need. It will help you see the layers you may need to dig through to get to the “real” need if it isn’t the one the customer is currently presenting. It will help you see who else you may need to include in the discussion. What other key areas of the business are tied into this process? You should find that out here.

What do you want the new solution to be?

This one goes hand in hand with the question above and will give you even more insight into what the customer is thinking and if the real need is the one they have identified. Knowing the “as is” and the “to be” environment is critical to connecting the dots to get the client there. The “as is” situation tells you where they are coming from, and the “to be” will tell you a lot about what they are hoping to accomplish. It may help you better define the questioning process from this point forward.

What specific problems are your end users experiencing?

This is where you find out how tied into the process the end users are or have been up to this point. Maybe they originated the project request. Or maybe they know nothing about it. You need to know the answer to this question, and you need to draw them into the process. They are key.

Do you have specific technology needs or wants in mind?

There may be some underlying desire for a specific technology. I’ve gotten to this point a couple of times only to find out that a new technology – no real urgent need – is the only reason for the project. That’s not a bad thing – just a good thing to know up front. It may (or may not) change how you manage the project or the urgency of it. Just ask, you won’t be sorry.

Is this project supported by the executives?

Finally, make sure there is support for the project by the higher ups. It may not be appropriate to ask of an outside client. But if this is an internal project, it is definitely a question to ask. Why? Because lots of project “phishing” happens before any real funding or project approval has happened when you’re dealing with projects that are internal to your own company. They tend to skirt the formal process and may end up wasting a lot of your time and PMO time when there is no project out there. And how do you approach this on an external project? Well, carefully. But a skilled PM or BA can figure out a way to ask if the customer’s leadership is behind the effort. If you see this as a “weak” project or one that may not really be necessary, it’s a good question to ask no matter how you may go about it.

Summary

There really aren’t any magic questions that will that will draw out everything you need to know to deliver the right solution. No magic question that will make everyone happy and make all those potentially costly change orders completely unnecessary. Stuff happens, change orders happen, requirements change and sometimes they are foggy no matter how hard you try. They key is to try hard up front – put the effort into it. Good PM and good BA oversight and investigative questioning of the project client will get you 90% of the way there. The other 10% will be experience, skill, interpretation and a little luck.

How about our readers?  What do you “ask” or “demand” to get you through the muck to the real customer need and true customer requirements?  Please share your thoughts and expertise (and failures if you don’t mind).