Tag: BABOK

Best of BATimes: The Quest for Good Requirements

Written by Martin Schedlbauer on January 19, 2023. Posted in Articles.

The main responsibility of the analyst is the discovery, analysis, documentation, and communication of requirements. A requirement is simply a feature that a product or service must have in order to be useful to its stakeholders. For example, two requirements for a customer relationship management system might be to allow users to update the payment terms for an account and to add new customers.

In this article, we will look at the different aspects of the requirements management process and the lifecycle of requirements.

Definition of a Requirement

A more precise definition is provided by the IEEE Glossary of Software Engineering Terminology and the Business Analysis Body of Knowledge® (BABOK®). Both define a requirement as a

condition or capability needed by a user to solve a problem or achieve an objective.
condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
documented representation of a condition or capability in (1) or (2).

Not all requirements are at the same level. Some might be high level requirements expressed by the business sponsor (e.g., reduce the cost of invoicing customers), others might be very specific requirements that describe a function needed by a particular user (e.g., allow me to click on a customer name and then display that customer’s account history).

The BABOK® defines the following requirements types: business, user (stakeholder), functional (solution), non-functional (quality of service), constraint, and implementation (transition).

Note that these terms are overloaded and often have different definitions within some organizations. For example, a user requirement is referred to as a business requirement in some organizations and a business requirement is sometimes called a business goal or project objective. Functional requirements are also often called technical requirements, detailed requirements, or system requirements. So, it is important to understand the semantics of the terms being used. If in doubt, ask, but don’t assume. In fact, publish a glossary of terms to clarify the meaning of terms that are used by the project team.

Examples of Different Types of Requirements

To clarify the different kinds of requirements types, let’s take a look at some examples for each type.

Table 1. Requirements Examples

Scope

The scope of a project refers to the agreed upon set of features that the final product will contain. Scope creep is a common occurrence and it describes the propensity of scope to expand as stakeholders add requirements during the project without regard to its impact on budget, schedule, and deliverables. The project manager must work with the stakeholders to get agreement on the scope.

Stakeholders

The stakeholders are the main source of requirements. They have specific needs that the analyst must identify. This is easier said than done: often stakeholders are not quite sure what they need and they often don’t know how to express what they need. It is the analyst’s job to help uncover the requirements of the stakeholders.

A stakeholder is anyone who has an interest in the successful outcome of the project, including project sponsors, users, business executives, managers, developers, clients, customers, vendors, and government or regulatory agencies.

Eliciting requirements is surprisingly hard work. Stakeholders often do not know exactly what they need and eliciting the requirements can be quite challenging. As Fred Brooks has stated so poignantly in his seminal essay “No Silver Bullet: Essence and Accidents of Software Engineering”

“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirement, including all the interfaces to people, machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”

He goes on to say that in a systems development project there are two kinds of complexities that must be managed: accidental and essential (or inherent).

Much of software engineering is focused on reducing accidental complexity, which is the complexity that we add to a project by way of the tools and programming languages that we use. For example, writing code in C is much harder than Java and writing code in Java is much harder than doing a “mashup” with web components.

While it is good to focus on reducing accidental complexity, much of the complexity of a project is rooted in essential (or inherent) complexity. Essential complexity is the difficulty of the problem itself: launching a rocket into orbit is hard no matter what programming language you use. The techniques studied in this book are about managing essential complexity.

Brooks also argues that systems are best developed incrementally. Start with something small that you understand and improve and expand it rather than building the penultimate version at the outset. This approach is the foundation for iterative and agile methods.

Requirements Management

Requirements management is the process of defining and maintaining the requirements that form the agreement between the project team and the stakeholders. A requirements management plan (RMP) is a document that defines the process, procedures, and standards for eliciting, documenting, storing, and updating the requirements. The typical requirement management activities include the following:

Figure 1. Requirements Management Activities

Requirements Management Activities

Requirements management is generally supported by the use of requirements tracking or requirements management tools. There are numerous commercial, free, and open source tools that can be used.

Requirements Process

The process of requirements specification can be broken down into discovery (elicitation), analysis, modeling and documentation, communication, and validation (see Figure 2.) As part of the process, the project team must also negotiate the relative importance of each requirement, so that an appropriate prioritization can be established. The requirements that are considered to be implementable within the allocated time and budget are called the project scope or simply scope.

The project team generally implements the requirements in order of priority, starting with the most important ones. The reason is simple: most projects have limited time and budget and commonly not all requirements can be addressed. By the time we run out of time and money the stakeholders would want the most important requirements taken care of. While this sounds simple, establishing and negotiating the priorities of requirements can often be very difficult and politically challenging. Stakeholders don’t want to prioritize for fear of not getting what they want; the project team does not want an unlimited scope as they know that they likely cannot accomplish everything with the allotted resources.

Figure 2. Requirements Management Process

Stakeholder Obligations

For an IT project to be successful, the stakeholders have certain responsibilities:

they must spend the time with the analyst and educate them about their business and help them understand their objectives
they need to allocate the time necessary to provide clear requirements and validate the requirements in a timely fashion
they must precisely describe their requirement; vaguely stated requirements are not implementable and documenting them is a waste of time
they must provide feedback when needed
they must provide additional information in a timely fashion
they must prioritize the requirements
they must respect the estimates for time and budget provided by the project team and resist the urge to “negotiate”
they must inform the project team of changes to requirements as soon as they occur

The analyst must continually remind (in subtle ways, of course) the stakeholders of their responsibilities. If the stakeholders don’t live up to them, then that introduces project risks which must be made known to the projects manager and included in the project’s risk catalog.

Requirements Elicitation and Discovery

To discover requirements, the analyst applies a variety of techniques. The steps in requirements elicitation are generally as follows:

Plan the requirements elicitation process and how the team will document and validate the requirements. This plan is referred to as the Requirements Management Plan (RMP) and is considered a key document for project planning.
Write a Project Charter or Project Mission Statement containing the business requirements and the overall scope of the project. Often a Context Diagram is provided to clarify the scope of the system development effort. All stakeholders must agree to the vision for the project. Some organizations refer to this document as the Business Requirements Document (BRD). Use brainstorming and interviewing to arrive at the key business requirements.
Identify the key users and their usage characteristics and select a proxy for each user that can present the requirements for that class of users. These “user representatives” will be consulted throughout the requirements elicitation effort.
Collaborate with the user representatives to identify use cases and then analyze those use cases to derive the detailed functional requirements for the product.
Analyze any events to which the system must respond, such as input from hardware devices or messages from other systems.
Identify any other stakeholders who might provide requirements or constraints.
Convene requirements workshops in which users work together for a few days to explore user needs and to agree on the requirements. Requirements workshops are a way to reduce the amount of time it takes to find all the requirements by getting everyone together at the same time. Joint Requirements Planning (JRP) and Joint Application Development (JAD) are examples of facilitated requirements workshops.
Shadow users as they perform job tasks and use the results of the observations to identify needs and to understand business processes. Document these insights in flow charts or UML Activity Diagrams.
Hold feedback sessions during which users can provide feedback on issues or problems with the current system. The results can be used to formulate requirements on how to enhance the system. Looking at problem reports from the help desk can be particularly insightful.
Build a prototype that demonstrates the requirements and provides realistic feedback to the users.
Identify, document, and address any risks that might have a negative impact on the project, i.e., that might cause a delay in delivery, an increase in budget, or a reduction in scope.
Validate the requirements through walkthroughs and other formal or informal meetings with stakeholder to assure that the right requirements have been discovered.

Requirements Analysis

As soon as requirements have been identified, they must be analyzed to ensure that they are correct, not in conflict with each other, and that they are precisely understood by all stakeholders. During analysis, the requirements must be decomposed into sufficient detail so that the project team can accurately estimate effort for implementation and assure that the requirements are indeed feasible.

Analysis Artifacts

During analysis, the analyst constructs a number of textual, digital and visual artifacts, including:

context diagrams
use case model
conceptual data models and data dictionary
user interface model
business process models
prioritized requirements catalog
business rule catalog
prototypes (horizontal discovery as well as vertical feasibility prototypes)

Requirements Documentation

To communicate the requirements to the stakeholders for validation and to provide the development team with a thorough understanding of what must be done, the analyst must write a requirements specification. This is simply called the requirements package as there are no industry standards for the format of that specification. Every organization has adopted a different document template. It is important, however, that an organization has a standard document template. The template must be flexible as no single structure will fit all projects.

The successful analyst knows how to select the right documentation techniques and does not limit himself to just one documentation approach, such as wireframes, use cases, or narrative requirements. He blends the different approaches to specify all requirements clearly, unambiguously, and concisely.

While writing documentation is generally not a value-added activity from the user’s perspective, it is a necessary mechanism to mitigate certain project risks. The amount of necessary documentation is dependent on the specific risks that are present, particularly when projects are implemented by outsourcing partners, distributed teams, or when access to stakeholders is limited or sporadic.

Requirements Validation

Requirements must be validated prior to implementation to assure that they are correctly understood and still valid lest the team wastes precious resources implementing functionality that is not needed. Validation is achieved through several means, including:

Formal and informal inspection: In this approach, the project team meets and walks through the requirements package, including any visual and executable models.
Stakeholder reviews: Present the requirements, models, and prototypes to the stakeholders for review and validation. At the conclusion of the review, the stakeholders “sign-off” on the requirements to indicate their approval.
Acceptance criteria definition: For each user requirement (generally expressed as a use case), define post conditions so that tests can be constructed that verify that the requirements have been met.

Writing Effective Requirements

Documenting requirements is an essential part of the requirements process. Over the years, many approaches to documenting requirements have been developed. Among the more prominent recommendations is IEEE Standard 830, which contains the recommended practices for writing software requirements specifications (SRS).

Requirements that are useful, exhibit several important characteristics:

complete: the requirement must contain all the information necessary to allow the project team to fulfill the requirement
accurate: the requirement must be correct; validation is generally done through reviews with stakeholders; an accurate requirement cannot be in conflict with another requirement
testable: the requirement can be verified through a test
feasible: the requirement can be implemented; there is no technical or other impediment that make the requirement undoable
necessary: the requirement must describe a feature that the stakeholders actually need; it must relate to a business objective
unambiguous: the requirement must be described in a simple and concise manner that guarantees that there are no differing interpretations of what the requirement means
prioritized: the requirement’s degree of necessity relative to other requirements has been established through stakeholder consultation

Documentation Formats

Requirements are commonly written as simple narrative statements. User requirements are best expressed as more elaborate documents. A common format for documenting user requirements are use cases. In addition, constructing visual models simplifies communication of complex requirements. A visual model, such as a UML diagram, can more precisely describe requirements than a written paragraph. It is also easier to discover mistakes in a diagram than a lengthy narrative. A requirements specification typically includes a combination of narratives, use cases, and visual models.

Requirements Identification

All requirements must be labeled so that it is easy to refer to them through a unique handle rather than its description. The following conventions are often used:

User Requirements are expressed as use cases and use the prefix UC, e.g., UC1.
Functional Requirements use the prefixes R or FR, e.g., R92, FR876
Business Requirements use the prefix O (for objective), e.g., O2
Business Rules use the prefix BR, e.g., BR12
Non-Functional (or Quality of Service) Requirements also use the prefix R, although some prefer to use NFR, e.g., R14 or NFR23

Requirements Traceability

Requirements must be traceable. That means for any requirement, one must be able to ascertain its source and its realization, i.e., a reason why the requirement exists and a guarantee that the requirement has actually been implemented. Generally, analysts construct a matrix that traces each requirement to implementation, test cases, and sources. The source of a requirement is generally some stakeholder but might also be a regulation or mandate.

Requirements Approval

Many organizations have a formal process of “sign-off” or approval where the customer or project sponsor formally agrees to the requirements that have been captured. While it is somewhat formal, sign-off must be viewed as a project milestone rather than a formal contract. Requirements very likely will still change after sign-off. After all, the business does not remain static; things change constantly in the business world. Project teams must adopt a requirements change procedure that stakeholders can fall back on when a requirement does indeed change. Naturally, the project manager must explain to the stakeholders that a change to the requirements (either by adding, modifying, or removing a requirement from the specification) likely will have an impact on the project’s schedule, budget, and delivery milestones.

While it is desirable for the project team that requirements are eventually “frozen” it is not realistic. The project team should be prepared to continually manage the requirements scope: scope is not static, it is dynamic and the development lifecycle must accommodate the dynamic nature of requirements. Because of that inherent dynamic, agile methods have become more appealing to many organizations. Agile methods acknowledge that requirements change and therefore they do not force a formal “sign-off” and “freezing” of the requirements. Scope is managed much more flexibly and informally in agile projects.

Conclusion

In this article, we summarized the important aspects of gathering, analyzing, documenting, communicating, and validating requirements. The techniques provided should serve as a foundation for your own best requirements management practices.

Published: 01/25/2011

Dr. Martin Schedlbauer, consultant and instructor for the Corporate Education Group, is an accomplished business analysis subject matter expert, and has been leading and authoring seminars and workshops in business analysis, software engineering, and project management for over twenty years. Beyond that, he coaches his clients in business analysis practices, process modeling, and lean project management. When he is not working with his clients or delivering workshops for CEG, he lectures at Northeastern University in Boston in his capacity as Clinical Professor.

[1] Brooks, F., “No Silver Bullet: Essence and Accidents of Software Engineering”. IEEE Computer, 20 (4), April 1987, pp. 10 – 19.

[2] A mashup is a re-combination of available web components to provide powerful new functionality using simple visual editors and little programming. As examples, see Yahoo pipes and Google mashups.

A 3-D View to Understanding the BABOK

Written by Glenn Brûlé on June 28, 2018. Posted in Articles. 91 Comments on 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.

Do not read the BABOK from front to back or put another way, do not read it in a linear fashion!
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.

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.

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!

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.

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

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

Written by Yaaqub (Yamo) Mohamed on May 28, 2018. Posted in Articles.

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

Written by Angela Wick on August 18, 2016. Posted in Articles.

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!

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.

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

Written by Yaaqub (Yamo) Mohamed on March 29, 2016. Posted in Articles. 1 Comment on 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:

(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:

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:

The form and shape in which you do this task currently – introspective or retrospective curiosity.
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.