Skip to main content

Tag: Training

BATimes_Apr20_2023

Read All About It – Why Reading is a Critical Skill in BA

I love reading.

It is to the point of compulsion where I log into my Amazon.com account and sneak in a couple titles
of varying degrees, regardless of what my original intention was. I always mutter a friendly curse
towards the algorithms that market new, old, debut and longstanding authors of novels, novella, and
fantastical stories each time I log in. It is not just limited to online…oh, no, not at all. Traveling, locally,
domestic, or internationally? Same problem. I make it a significant point to dop into any local
bookstore with self-guaranty that I will walk out with, at minimum, one book, genre notwithstanding.

Reading, however, has become so much more than just “getting lost in the story” or falling in love with
characters whom we can only dream to meet, mirror ourselves against or become attached to. It is not
a hobby, it is not just a compulsion, it is not habit. It is something else, something more: a skill. A
critical skill, at that. A skill that, like anything, any one can become proficient, an expert on, but
requires the same thing: practice, practice, practice. While I could spend the time writing this piece on
the top ten books a business analyst should read (and was the original idea for this article) …instead, I
make a proclamation. A quasi-Magna Carta, if you would: all business analysts must take the time in
their schedules to make room for improving this critical and formidable skill.

 

Today, there are rumors of studies finding that young adults after their high school (post-secondary)
education will never read a book again. It is flabbergasting on one hand, but to lose a critical skill like
reading that is sharpened when you open the cover-to-cover bound print matter (or e-book for you
digital readers), it is breathtaking. We, as business analysts, whether we realize it or not, are
consistently reading. Reading our e-mails, reading our business analyst documentation, reading
requirements. You are reading right now, are you not? That is pending that you continue to read my
piece on this subject matter. We are, in and out of varying intervals and degrees, reading! Some read
faster than others, some take the time to deeply understand and analyze what is on the paper, or page
before us. Aside from this, you are inherently practicing a critical skill in which will only make you
better, as a business analyst.

 

Advertisement

 

Google search any reason as to why human beings should read and the results are countless: whether
it be for stress relief, for better memory retention, to prevent disease, it is all relevant. However,
relevancy aside, it becomes relevant to our work. Reading requires us to think, to analyze, to ask
ourselves questions. Is that not what we do now? Think, analyze, ask questions? Of course, overlooking
that I am oversimplifying the business analysis method, reading leads us to business analyzing!

Reading only stands to benefit you to improve in these areas; reading helps establish connections, to
understand concepts. Who does not like conversing in the language of titles, authors and favorite quotes
from that series or book that came out last week, month, year? There once was a video game I played
as a young adult and in the conversation of movies, they spoke about how movies during their time
(when movies/cinema were in their Golden Age), help people out of a bind or jam that they do not
understand. Take out movies/cinema and replace with books/reading, and there you got it.

So, read all about it! And I do not mean that slogan about the latest newspaper (although a reliable
source for information), I truly mean…read all about it. Being able to become a fount of knowledge
and to be able to translate that knowledge into performance as a BA should be your guiding light. As
a business analyst: think about it, analyze it, ask questions about it. Understand it…you will thank
yourself someday

BATimes_Mar15_2023

Your Next Process Model’s Degree of Abstraction

Any process model is so much more than a flowchart. It is an abstraction of current or future real-world operations.

Process modeling is one of the core competencies of any capable business analyst. Both the International Institute of Business Analysis (IIBA) Business Analysis Standard[1], and the Project Management Institute (PMI) Guide to Business Analysis[2] call for certified business analysts to be capable of preparing and using process models.

Business analysts and process improvement analysts may prepare process models at key points of business process management, information technology, and regulatory compliance project methodologies. They may specify current or future functional, organizational, and information systems architectures, functional requirements, workflow designs, and even automated operations. What any process model needs to communicate will vary from one project to the next.  The highest quality process model examples provide clear, accurate process information of direct interest to their readers.

Informed business analysts know that one of the secrets to producing a high-quality process model is to establish a clear mission for each model. To be successful, you should mindfully establish the mission of your next process model within the business process management, information technology, or regulatory compliance project that the model will serve.  You will then tailor your elicitations of the model’s content and configuration to meet project needs. Part of your process model mission-setting elicitation agenda will include asking and answering this important question:

What is this model’s required degree of abstraction?[3]

There are three generally accepted degrees of abstraction to consider: conceptual, logical, and configuration.

 

A Conceptual Process Model  

A conceptual process model graphically presents the defining structure of what a process is.

Business analysts, project sponsors, project managers, domain subject matter experts, regulators, and other process stakeholders use conceptual process models, for the following purposes:

  • To make process governance and scoping decisions;
  • To gain agreement about and communicate the process’s defined scope and structure, unequivocally distinguishing that process from all others in their business;
  • To design enterprise architecture, to define technology solution architectures,
  • To be the sound foundation on which forthcoming detailed problem analysis or detailed process definition is scoped out or planned;
  • To support project management decisions (e.g. budgeting, scoping).
  • To further elicit and fit logical process details upon its sound contextual and structural foundation.

 

Some business analysts and systems analysts might interpret the term conceptual to mean “high level”. That would be an oversimplification and a mistake. To serve its purpose, a conceptual process model should unequivocally define the sound, stable structure of the process. Despite being the highest degree of abstraction, a high-quality conceptual process model is still precise.  It can clearly and graphically communicate all of these process-defining information:

  • The process’s name.
  • The process’s initiating event(s) that causes the process to be performed.
  • The process’s activities and their expected sequence of execution.
  • The process’s expected outcome(s).
  • The process’s customer(s).

 

Advertisement

 

A Logical Process Model

A logical process model elaborates contextually relevant details about how a process is required to operate, is designed to operate, or currently operates.

A high-quality logical process model could graphically, answer any of these types of how-elaborating questions:

  • The decomposition or summary of some of the process’s activities.
  • The rule-driven or decision-driven conditional work that may be performed.
  • The assigned responsibilities for performing the process’s activities.
  • The data or information required to be used and/or produced.
  • The causes of the process to be delayed or interrupted.
  • The processing errors that may occur while the process is executing, and how they will be resolved.
  • The process’s related performance or measurement data, and text-based operating procedures, documents, or other specifications.

There is a spectrum of uses for logical process models. Process owners and analysts use logical process models to determine what and where to measure an existing process’s performance or to design and communicate proposed process improvements. They also define requirements for, or the design of manual or automated procedures, or describe the design of workflows.

Competent business analysts and process analysts can anticipate, elicit and document a range of logical refinement types, using clear agendas and reusable modeling patterns[4]. They also know that no two logical process models need to communicate all of the same types of logical refinements. So they will consider the model’s mission within each project and tailor their modeling efforts to focus on eliciting and documenting the types of logical refinements that suit each model’s intended use within its project’s methodology.

 

A Process Configuration Model

A process configuration model communicates concrete implementation mechanisms such as software operations and user procedures or workflows.

A process configuration model is the lowest degree of abstraction. Business analysts and systems analysts typically prepare process configuration models in low-code and no-code software platforms. The platform consumes the process configuration model along with detailed process-related roles, security, forms, system interface, and data specifications to generate operating software, on top of an already well-rounded software product architecture. There is otherwise no or very little programmer intervention in translating the model into working software. When updates to requirements or defects emerge, the analyst revises the configuration model, and the platform regenerates and redeploys the software.

You must adopt and adhere exactly to a chosen low-code or no-code platform’s process modeling syntax. You can learn that by taking the training offered by the low-code or no-code platform’s vendor. Along with a process configuration model, you would specify, in detail:

  • System users, their assigned roles, and their responsibilities to perform the configured process flow.
  • The sequence of execution of configurable functional components, of an automated end-to-end workflow.
  • The configurable functional components involved in the process flow configuration. These are typically the user interfaces (e.g. forms, reports) system integrations (e.g. APIs), and the data attributes used in an automated process workflow.

Since process configuration models are precisely translated into operating software and business operations, any errors or omissions in the modeling become errors or omissions in the generated software and business operations.  It stands to reason that to be a successful business analyst or systems analyst in a low-code or no-code environment, you must design process configuration models based on sufficiently detailed logical requirements, that you have elicited and understood.

 

How to Choose Your Next Process Model’s Degree of Abstraction

Follow these guidelines to choose what the required degree of abstraction of your next process model will be:

Use conceptual process models to get agreement about and communicate what the process is. What is the scope? What causes it to be performed? What are the activities and their expected sequence? What is or are the expected outcome(s)? Use conceptual process models for planning, scoping, and architecture definition.

Use logical process models to get agreement and communicate how a process works or is required to work. Be prepared to elicit and document the answers to logical details such as: What are the detailed or summary activities? Who is responsible for what? What happens if? What happens when? What decisions will be made? What information is produced or used? Remember to elicit and include the details that are relevant to your model’s intended audience: those who participate in the lifecycle of your business process management or information technology project. Keep your model’s intended audience in mind when eliciting and documenting details. Use appropriately detailed logical process models for detailed functional requirements or design.

Use process configuration models to specify the configuration of concrete software modules, physical devices, and/or manual operating procedures that implement a process.

You typically use process configuration models in no-code or low-code software generation. To gain the benefits, you must specify very precise and accurate process implementation details, and exactly follow the process configuration modeling syntax.

 

Conclusion

A process model is not just a flowchart. It communicates what are, or will be, real-world operations. It may play a crucial role in the success or failure of your next business process management, information technology, or regulatory compliance project.

The most competent business analysts and process analysts clarify what their model’s required degree of abstraction will be, at the start of their analysis. They then focus their own and their project stakeholders’ efforts and time on the types of model content and format that will best suit each project’s unique needs.

You are welcome to learn more or share your comments and experiences about Your Next Process Model’s Degree of Abstraction via the Contact Us page at www.ProcessModelingAdvisor.com.

Copyright 2023, Edmund Metera
[1] The Business Analysis Standard (IIBA, November, 2022)
[2] PMI Guide to Business Analysis (PMI Inc, 2017)
[3] The Universal Process Modeling Procedure: The Practical Guide to High-Quality Business Process Models (Metera, 2018, 2022)
[4] The Universal Process Modeling Procedure: The Practical Guide To High-Quality Business Process Models Using BPMN (Metera, 2022)
BATimes_Nov17_2022

Important Techniques for CBAP Certification Examination

This again is a very frequent question that we receive from our CBAP participants. BABoK V3 has 50 techniques and obviously, all techniques would not be of equal importance for all three certifications. Some techniques are more important to junior business analysts and some techniques are used more by the Senior Business Analysts.

In this article, we are going to categorize the techniques into three categories based on their complexity levels. Low complexity techniques are more useful for ECBA aspirants. Medium and high complex ones are more important for CBAP examination aspirants. High complexity techniques would require CBAP practitioners more time and effort to understand and be comfortable with.

You must be wondering how did we come up with this list?

It’s primarily based on inputs from many of our past CBAP participants regarding what kind of techniques challenged them more during the CBAP certification examination. Secondly, most business analysts start their careers as requirements analysts and as part of requirement analysis work, they use some techniques more extensively than others. Techniques that typically belong to strategy analysis planning and solution evaluation are the techniques where usually many have a lesser comfort level and obviously, they need to pay more attention to those techniques. Three specific areas that we would advise CBAP participants to pay attention are the techniques related to Financial Analysis, Decision Analysis, and UML.

Here are a few blogs and videos that we published which will help CBAP aspirants:

Estimation

https://www.adaptiveus.com/business-analysis-estimation-technique/

Metrics and KPI

https://www.adaptiveus.com/business-analysis-world-indicators/

Data and Concept model

https://www.adaptiveus.com/concept-model-vs-data-model/

https://www.youtube.com/watch?v=YdvgaxqTkmE&feature=youtu.be

Process analysis

https://www.adaptiveus.com/process-modeling-vs-process-analysis/

Business model canvas

https://www.adaptiveus.com/balanced-scorecard-vs-business-model-canvas/

Non-functional requirements

https://www.adaptiveus.com/blog/non-functional-requirements

 

Advertisement

 

Stakeholder list, map, and personas

Here is a summary of important techniques for CBAP certification:

Author: L N Mishra, Co-Founder, Adaptive US

 

L N Mishra co-founded Adaptive US, a business analysis skill development organization, working with professionals from 80+ countries in skyrocketing their BA career and staying ahead of the game. He has helped 5000+ BA professionals to achieve better salary and role in their BA career. He is the ONLY trainer who holds all 7 certifications from IIBA (ECBA, CCBA, CBAP, CCA, AAC, CBDA, and CPOA).

LN has authored 12 best-selling books on business analysis. He is also a Versatile trainer, coach and speaker on all IIBA Certifications.

Grab a copy of best-selling eBook –  FREE 50 CBAP Exam Mock Questions Plus Comprehensive CBAP Exam Information utilized by 1000s of BA professionals to ace their IIBA exam.

 

LN is also a member of IIBA Question Setting Committee, mentored 100+ global clients and 3000+ Bas. He has 24+ years of working experience as a Business Analyst and conducted 1000+ workshops in business analysis, requirements engineering and agile, project management, requirements engineering and different BA Skilled webinars.

Please write to LN if your thoughts are in sync with his or if they spark a thought in you.

BATimes_OCT12_2022

How Does Agile Analysis Certification (IIBA(r)-AAC) Fit?

Agile is here to stay!

 

Being a capable business analyst in an agile environment is no longer a specialization. Every competent BA must be comfortable working in an agile environment, and that should be reflected in the certifications offered by the IIBA.

 

Version 3 of the Guide to the Business Analysis Body of Knowledge (BABOK) was released in 2015. This version identified agile analysis as one of five sample perspectives that “provide focus to tasks and techniques specific to the context of the initiative”. Other perspectives included business intelligence, information technology, business architecture, and business process management. The expressed intent was that these perspectives represented common views of business analysis, and that they should be applied as appropriate in any project context to provide ways to approach business analysis work.

 

At the time, there were ongoing “debates” in the community regarding the need for or value derived from including business analysts on agile teams. Indeed, the identification of roles in the Scrum Guide: scrum master, product owner, developer, motivated many (misguided?) teams to specifically reject the notion of business analysts as necessary or desirable members of a Scrum team. This premise became common throughout the industry.

 

Advertisement

 

Parenthetically, I have always found it interesting that no one seemed to question the inclusion of testers as a specialized role on Scrum teams.

 

Why overlook business analysts? The question could generate an article unto itself.

 

As agile methods became more widely accepted, it was clear the business analysis domain needed to address this oversight. The IIBA partnered with the Agile Alliance to create and release version 2 of the Agile Extension to the BABOK Guide in 2017. The Extension was intended to demonstrate the need for business analysis in an agile context and to clarify the application of solid business analysis, independent of project context or development paradigm. The Guide “demonstrates how an Agile mindset can be applied to all domains and how any BABOK® Guide task can be performed in an agile context”[i].

 

In 2018, the IIBA introduced the Agile Analysis Certification (IIBA®-AAC). This was the first of their “specialty” certifications, expanding on the core certifications: Entry Certificate in Business AnalysisTM (ECBATM), Certification of Competency in Business AnalysisTM (CCBA®), Certified Business Analysis Professional (CBAP®). The certification was designed to be methodology-agnostic, focusing on the business analysis principles necessary to support iterative, adaptive development, independent of the domain. Some new techniques were introduced, but by and large, the focus was on how good business analysis practices described in the BABOK® should be applied in an agile context.

 

No one should argue that doing business analysis in an agile, change-driven context is the same as traditional, plan-driven analysis. The differences, however, focus largely on the timing and the level of detail in the application of standard BA practices. The same practices generally apply regardless of the team’s development approach.

 

Fast forward several years, and the agile paradigm is dominant in the software industry. Many organizations are extending, transitioning, or having transitioned to agile frameworks and methodologies. At the same time, those frameworks, methodologies, and teams have recognized that business analysis is not antithetical to agility. Indeed, business analysts or those project team members having strong business analysis capabilities are now seen as vital to successful initiatives.

 

Where does that leave the AAC? As of August 2022, the IIBA Certification Registry lists 1,474 registered holders of the IIBA®-AAC. This may not represent the entire total, as holders can choose to exclude their names from the directory. Compared with the other core and specialty certifications the numbers tell an interesting story:

  • ECBATM – 7,359
  • CCBA® – 2,743
  • CBAP® – 16,331
  • IIBA®-CBDA (Business Data Analytics Certification) – 338
  • IIBA®-CCA (Cybersecurity Analysis Certification) – 253
  • IIBA®-CPOA (Product Ownership Analysis Certification) – 634

 

Clearly, the core certifications are more popular than the specialty certifications. This is particularly true of CBAP®, which has been around for a longer time, requires verifiable work experience, and has more recognition in the marketplace. There is more interest in AAC than any of the other specializations, but that may be a result of the length of time AAC has been available in comparison to the other specialty certs.

 

What I find most interesting, however, is the integration of agile principles with the other specialty certifications. The IIBA emphasizes that the specialty certifications, particularly CBDA and CPOA, which is really an Agile certification, include the application of agile techniques along with an expectation of the application of techniques and practices from the BABOK®.

 

People preparing for certifications have a duty to understand more than just “what’s in the book”. To be an effective BA, the practitioner needs to be able to apply techniques and practices from any perspective that will support the initiative. In providing training for aspiring BAs and certification candidates, I often refer to information not only from the BABOK®, but also from the Agile Extension and a variety of other agile frameworks and methodologies.

 

Going forward, I can easily see the AAC being rolled into the core certifications, particularly at the ECBATM level. While that would eliminate one outlet for my services (AAC certification courses), I think it would ultimately serve the domain and result in better BAs.

[i] IIBA and Agile Alliance Release Version 2 of The Agile Extension to the BABOK Guide (https://www.agilealliance.org/the-alliance/news-press/iiba-and-agile-alliance-release-version-2-of-the-agile-extension-to-the-babok-guide/#:~:text=The%20Agile%20Extension%20to%20the%20BABOK%C2%AE%20Guide%20will,be%20available%20for%20enterprise%20licensing%20in%20September%202017)

 

BATimes_July20_2022

Books To Bank On For Your Business: Five Top Reads For Avid Business Analysts

In the fast-paced world of business analysis, you live and learn from minute to minute. Keeping up with cutting-edge industry developments can be a Herculean task for even the most dedicated of business professionals.

So, when it comes to studying, ensure that you are expending your time wisely on quality learning from the best. Here to broaden your knowledge base, expand your vocabulary, and share insider experience, we have collated a small but perfectly formed reading list to equip anybody from post-graduate all the way up to leadership levels with the information needed to succeed. Rather than wasting your time wading your way through reams of useless information to garner a few insightful gems of wisdom when you could already be one step ahead in applying your newfound knowledge to your latest project, use our guide to the top five reads of the moment to help you cut straight to the chase.

 

1: ‘How To Lead In Product Management: Practices To Align Stakeholders, Guide Development Teams, And Create Value Together’ By Roman Pichle

Author of no less than four books and creator of his own blog alongside an educational product management podcast, Roman Pichler is your go-to consultant when it comes to leading in product management. Within the pages of Roman’s latest offering, you’ll find out how to guide your team successfully and to foster positive relationships with your stakeholders. While technical skills and knowledge of your industry are vital elements of leadership, Pichler lends his wisdom on the more nuanced aspects of the interpersonal relationships that must be cultivated as a good leader. This includes invaluable advice on building trust with your team, creating common goals, resolving challenging situations and maintaining your own wellbeing in this high-stakes environment.

 

2: ‘Seven Steps To Mastering Business Analysis (Business Analysis Professional Development)’ By Jamie Champagne

Written by Jamie Champagne, the first ever Hawaiian to become a Certified Business Analysis Professional, this book is a simple yet thorough guide to the complex world of business analysis. An insightful read for beginners and experts alike, Jamie uses her font of experience as founder of her own successful company, Champagne Collaborations, to provide seven clearly structured steps to business success. Champagne generously provides explanations of all key terms and concepts, alongside proven techniques that are coupled with real-life examples for ease of learning. A great resource for those studying for exams in the field, or for anybody looking to understand and  increase the value of their work or to broaden their professional horizon.

 

Advertisement

 

3: ‘Agile And Business Analysis’ By Debra Paul And Lynda Girvan

With 55 years of experience in the industry between the two of them, the brains behind Assist Knowledge Development Debra Paul and Linda Girvan have applied their expertise to an in-depth exploration into the use of Agile as an approach in business in this book. Paul and Girvan delve into what Agile means as a business analysis methodology, outlining their thoughts on it’s role in all of the most important aspects of business such as the understanding of customer requirements, the engagement of key stakeholders in the company or product, and the accurate measurement of how successfully the company is achieving its targets in relation to these.

 

4: ‘Agile Software Requirements: Lean Requirements Practices For Teams, Programs, And The Enterprise’ By Dean Leffingwell

With 30 years of experience in the software industry, Dean Leffingwell is an absolute authority in his field. Leffingwell generously shares his experience as the founding CEO of Requisite, Inc., and as Vice President of IBM’s Rational Software in a revolutionary compilation of his recommended best practices. No matter what your company structure of developmental process in the Agile business environment, Leffingwell has likely devised a business model to suit it. His application of the latest in Agile methodology, combined with his expertise in traditional management practices and lean product development creates an all-encompassing bible for anybody interested in getting the best from their business in terms of software requirements.

 

5: ‘Mastering The Requirements Process: Getting Requirements Right’ By Suzanne Robertson And James Robertson

Suzanne and James Robertson’s goal in writing this definitive guide to the requirements process was to teach business analysts how to identify requirements accurately, therefore ensuring an efficient and successful development process free from time and resource-wasting hiccups. Such has been the success of this detailed volume that it is now in it’s third edition, with constantly updated strategies that include information on how to apply it’s lessons to both traditional and to Agile business models. In this latest publication, the Robertsons have provided additional information on the Volere Knowledge Model and Requirements Process, the Brown Cow Model, as well as further chapters on specification templates, formality guides and story cards.

You can find more information about the writer at UKWritingsAcademized and State Of Writing