Tag: Elicitation

A Checklist for Business Analysis Planning

Use the Universal Business Analysis Planning Checklist as You Plan Your Business Analysis Approach.

Every project is a unique, temporary endeavor.

The business process management, regulatory compliance and digital transformation projects that business analysts may play a role in all come with different goals, scopes, teams, timelines, budgets dependencies and risks.  Though many projects follow similar methodologies they are all tailored for project scope constraints and to take advantage of available resources, opportunities and lessons learned from prior work. 

Each business analyst also comes with a unique set of skills and experiences. Almost all business analysts have great communications skills and at least some experience-based business domain knowledge. That’s why they became business analysts in the first place. Every business analyst has uniquely acquired knowledge of business analysis techniques and business domains through personal study, practice and experience. Many have also been trained in elicitation, requirements management, modeling, measurement, analysis and documentation techniques. An ever-growing number have received professional certifications, such as the IIBA Certified Business Analysis Professional (CBAP) or the PMI Professional in Business Analysis (PMI-PBA).

What is Business Analysis Planning?

The most skilled business analysts are not only competent in many business analysis techniques but also consciously tailor their business analysis approach for each project that they engage in.  They have learned to consider key project dynamics along with their own competencies and to tailor their planned business activities and deliverables to suit each project’s unique dynamics. Regardless of your own level of business analysis experience, maturity, and whether you are formally trained, certified or not, you can still consciously assess each project’s dynamics and tailor your forthcoming business analysis work to get the most productivity and value out of your business analysis efforts in each project.

The most significant project dynamics include:

  • The methodology, or sequence of stages or major milestones, and the business analysis products or outcomes that are expected by the end of each stage/milestone (and before starting the next).
  • The budget and schedule, not only to meet them, but to take advantage of contingency or schedule slack opportunities, to increase the value, quality or to learn.
  • The key project stakeholders and relationships that are new and changed and forming, to take a proactive role in fostering and building relationships with and among that team.
  • The types and combinations of elicitation techniques that will be best suited for producing or validating business analysis deliverables. 
  • The business domain knowledge and experiences of the diverse key project stakeholders, including your own unique set of business analysis competencies.

The Universal Business Analysis Planning Checklist

You can be more effective in planning your business analysis approach if you follow a consistent, clear agenda that considers the common project dynamics.

The Universal Business Analysis Approach Planning Checklist covers the most common project dynamics. You can use this as an agenda to elicit and discover a comprehensive view of a project’s key dynamics, its opportunities and use what you discover to adapt/tailor your business analysis approach.

As an exercise, think of a project that you have recently worked on, you are currently working on, or will soon be working on.  Answer questions in the following checklist for yourself.

Project Life Cycle

  • What are the planned stages of this project?
  • What stage are we currently in?
  • What is the business analysis deliverable (or set of deliverables) that I am responsible for producing in this stage?
  • What is the intended use of my business analysis deliverable(s) and who will use it?

Schedule and Effort Budget

  • How much effort can I spend and by what target date am I expected to produce my business analysis deliverable(s)?
  • Is that about what I also estimate it will take?
  • Is either my effort or date estimate higher than the effort budget or target date? If so, how might I adapt my effort, scope, activities or configuration of my deliverable(s)?

Project Stakeholders and Relationships

    • What are the key roles is on the project team and who is in them?
      • Does this project have an executive sponsor, project owner or product owner, project manager, specialists and business subject matter experts?
      • What are the names and titles the persons in these project roles?
    • Are significantly new relationships being are created in this project?
      • Who’s new to each other on this team?
      • Are there local and who’s remote team members?
    • What are peoples’ responsibilities?
      • Who is responsible for producing, accepting or needs to be consulted or informed of each of the project’s key deliverables, particularly the business analysis deliverable(s)?


Elicitation Techniques

  • Which elicitation techniques are available to me use?
    • Documentation Reviews – What documentation or prior work products are available to review?
    • Interviews and Workshops – Who can I interview or include in a workshop, and what questions would I need to ask?
    • Observations – Where and what kinds of observations may be needed and how could I arrange for them?
    • System reviews – What system(s) are available to review and for what information?
    • Surveys – Who could I engage in a survey and using what types of questions?
  • What are my own business analysis competencies?
    • Considering this project’s stakeholders and relationships, the elicitation techniques available to me, and my own core competencies, which elicitation techniques are best suited gather and validate my business analysis information?

Organizational Assets

  • What specialized tools for elicitation, documentation and modeling are available to me?
    • Collaboration tools, facilities, survey tools?
    • Diagramming or modeling software?
  • What prior business analysis work (e.g., documents, models) that I can draw from?
  • Does my organization offer training in the subject business domain?

Competencies and Knowledge

  • Who on the project team has what expert business domain knowledge?
  • What is my own business domain knowledge?
  • What are my strongest core business analysis competencies?
  • Where can you take advantage the team’s diversity of knowledge and competencies?
  • Who are the best stakeholders in this project to engage in elicitation of content or validation of business analysis deliverables and what is or are the best elicitation techniques to use?

On reflection, are you able to answer these questions for yourself? When you go into your project workplace, who will you include in this conversation?


Business analysis planning is a recognized business analysis activity. The IIBA Body of Knowledge (BoK) includes the Plan Business Analysis Approach activity within its Business Analysis Planning and Management process. The BoK also lays out the scope of what should be covered by a Business Analysis Approach as “The set of processes, templates, and activities that will be used to perform business analysis in a specific context.”

The time and formality that you apply to business analysis planning is up to you. At the financial institution where I work as a project and program manager, our business analysts typically tailor and document a business analysis plan for each new project to which they are assigned. 

I think of business analysis planning as a form of insurance. Spend a little time upfront to assure that the bulk of the rest of your business analysis efforts will be as well spent and effective as possible. Expect the benefits of tailoring a business analysis plan for every project to be that:

  1. It will help you to align your own core business analysis competencies to each project, and
  2. You and the project will gain the most value from your business analysis efforts.

That’s a value-adding proposition.
You are welcome to contribute comments about project dynamics that impact business analysis plans or about the checklist presented through the Contact Us page at www.ProcessModelingAdvisor.com.

How to Figure the Detail of Process Models

I love that a fellow analyst asked me a question as they were having trouble being asked about putting “narrative on their process model.” 

We started with the first question – WHY?   Simple, yet seriously, we’re so good at OVER analyzing and getting into analysis paralysis that sometimes just trying to figure out what is going on can save others (but especially us!) LOTS of valuable time!

With the first question, the answer was easy – they want more information.  Okay, so then the next questions is then about what the PURPOSE of the model is?  What are you trying to accomplish with your process model?

Good foundational, IIBA® BABOK® Guide v3 (2015) states that the purpose of process modeling is to provide a “standardized graphical model…to show how work is carried out…as foundation for process analysis.”  So are we showing ONLY how work is carried out?  Or are your stakeholders asking for much more?

We have data models and stakeholder RACI matrices and other valuable tools because they’re great at what they’re used for!  They each have their own purpose!  So ask yourself if you’re ever having difficulty with your process model because you’re trying to do WAY more than model a process?


This is the analysis skill – identify what questions are being asked or needing to be answered and facilitate getting that information to the needed decision makers.  If people ask lots of questions about who is doing what on your process, then maybe we do need greater detail on the stakeholder ownership.  Perhaps there is no ownership?  Or don’t overanalyze and just add a new swim lane if it makes the users happy (and of course understand better!).  If people ask lots of questions that revolve around data, do we need a data dictionary and some data modeling or data flow diagrams?  This is common when you meet with stakeholders of different levels of focus.  Too often process steps, decision points, data elements, stakeholders and end products are thrown at the analyst.  Do not feel compelled to write everything on the process model.  Write PROCESS on the process model and make notes on the side.  Then look at your notes.  Are all the notes about data?  Then your own notes tell you that you need some data definition.  And don’t be afraid to acknowledge that there’s a mix of high-level overview requests mixed in with the “give me the technical details down to the line of code” demands.  Just then make your model flow so that each view or screen or page is only showing ONE level.  Then with technology today just link it to the page with the lower level of detail.  Don’t over complicate it trying to take a full course on modeling software or anything.  Simply list high level functions with overall business areas on your main page.  Then for each one of those functions, create a “clean page” with just that function’s information.  And then you can work WITH your stakeholders to define as much information as they at that deeper level, while keeping everyone on the same page at that higher level.  Even better, with this approach, you just created a strategic, overview perspective as well as tactical or operational details.  Now you’ve helped multiple groups from starting with a single model!

See what information comes up from the stakeholders on what is missing or needs to be added to make the process model USABLE.  You are creating a process model for OTHERS to use.  If the level of detail is high and you’re not sure it’ll work – ask!  Share it out and see if people have questions.  If they have none, then you’ve done what is needed to help others get things done!  Analysts process model to facilitate, not own.  The model is the stakeholders’, teams’ or client’s.  It’s for them to get their work done, complete projects and create great new products.  If they ask lots of questions, then help them get the answers.  And as you do, always think what is the most efficient and effective way I can get them the answers.  Just because they want all the information on the same visual, does not mean that it will help them answer their questions.  But to know what to capture appropriately on process models, means you need to know what everyone is trying to accomplish by using your process model.  Make it an actionable document.  Anything you produce should be reusable over and over again – from decision making to operations and troubleshooting – and by people other than you!  That’s the true value! 

So next time someone tells you that your process model is lacking lots of information or needs other data and elements added, ask why and get clarity on the stakeholder’s need and what they hope to accomplish WITH your model.  Then work with them to help develop a model that answers their questions and supports their decision making.

Design Thinking in a Waterfall World

As much as we like to think we are now in a dynamic and agile world, most delivery initiatives are still some shades of agile and all shades of waterfall.

These initiatives could have adopted an agile outlook and naming convention, but the businesses they support are often still predominantly waterfall – going from one clearly defined task to another until realizing value. Think for example, order to cash, just in time logistics etc.

We often have some outliers, mostly modern businesses without legacy overloads and whose core business is digital or relies heavily on digital who may have cracked the agility question.

Waterfall is seen by most agile advocates as a relic of a time that had been and that should be forgotten and buried.

Waterfall is expensive, time consuming and unforgiving of errors.

BATimes June24 2020 1

Design thinking, on the other hand may be equally as expensive especially for organizations with legacy burdens switching over to an agile way of work, has picking up errors early built right into its DNA and offers opportunities to succeed quickly or fail fast.

BATimes June24 2020 2

A variation of the plan-do-check management methodology – the decision is easy to reach if one strips down the elements of the methodology into its bare bones fundamentals –design thinking allows the business or the delivery team to involve the customer for whom a product or service is being designed early on in the delivery effort. Design thinking offers up an opportunity to build a product truly needed by the customer and not one that was assumed the customer needs.


The question one ponders then is whether an enterprise or delivery team can only be one or the other? Or be both?

An important point of departure is that agility is a mindset, a mindset written into an organisations’ DNA and not only those of its project delivery teams. Agility does not rest solely on the tools and techniques that an organisation or its teams chooses to work with, rather it relies heavily on the collective agreement between teams and individuals; the capacity to work quickly, to experiment all the time, to learn fast and to be honest with itself all the time.

That said, with an agile mindset, design thinking techniques can be applied within each phase of the waterfall methodology.

For example, in the requirements phase of a waterfall project, the elements of design thinking’s empathise, define and ideate can readily be adopted. A bold team may and should also prototype and test their assumptions and some of the features of their product/service with real customers. Done well, the requirements phase of a waterfall project doesn’t then just end with a signed off requirements specification, but also the knowledge of what the customer truly wants backed with empirical data. And potentially the design and implementation phases have a ton of knowledge of the market to go on with – in essence most of the work in these phases of waterfall delivery would have been completed during the define stage as done as described above.

BATimes June24 2020 3

The actual waterfall phases of design and implementation then just becomes opportunities for refinements of the work done in the requirement phase using design thinking, and for honouring the legacy requirements of phase gates.

BATimes June24 2020 4

The refinement efforts in each of the design and implementation phases could also leverage design thinking. For example, the design phase of waterfall could leverage prototyping and test multiple user experience approaches – building on the work started during requirements. And in the implementation phase will build based on the output from the design phase which has determined with a high degree of accuracy what the customer truly wants.

The test phase of the waterfall delivery effort, may end up being systems’ tests (regression and systems integration tests) and confirmatory usability tests – as actual usability tests would have been completed upfront during requirements and design phases where the team had brought in the real customers to empathise with, define and ideate with, prototype for and tested with.

One can then safely conclude that waterfall can co-exist with design thinking (and really most other agile techniques) if the organisation’s mindset focused on agility and not processes for the sake of processes.

Applying Maslow’s theory of Needs to Business Analysis

Having worked on multiple IT implementations and Transformation projects I have often found the evolution of user’s requirements follow the Maslow’s theory of needs.

Adoption of this theory in the requirement gathering process would turn out be fruitful for Business Analysts in efficient Requirement Elicitation from the Users.

Although most of us are aware about the Maslow’s Theory of needs, a quick memory refresh would be helpful:

Maslow’s hierarchy of needs displays the order of human needs in the form of a Pyramid with lowest levels made up of most basic needs moving on to the top of the pyramid with complex needs as depicted below.

BATimes June17 2020 1

Physiological Needs: The basic human requirements to survive would comprise the Physiological needs like Food, Water, warmth, and rest.

Security/Safety: Once the Physiological needs are satisfied, the need for security and safety arises. This comprises of financial, emotional, social security, and health and well-being.

Love/Belonging: These needs are driven by interpersonal relations like friendship, love, trust and acceptance among individuals.

Self-Esteem: The fourth level of needs arise out of the feelings of getting praised by others for self-accomplishments be it professional, academic, athletic, or personal.

Self-Actualization: The final level of needs reflects the realization of individuals to utilize the complete potential, so that they can do the best that they are capable of doing.

Now coming back to our original discussion on following the Maslow’s theory of needs for requirements elicitation, the below framework often works to elicit requirements from users starting from basic system requirements to the complex analytical requirements to explore the full potential of the system.

BATimes June17 2020 2

The 5 evolving stages of requirements are Data Capture, Data Security, System Integration, User Experience, and Analytical Capabilities. As we progress from bottom to top of the pyramid, the responsibility of BA to make recommendations to elicit the requirements from the users increases. Let us look at each of these stages by taking an example of a Salesforce CRM implementation

1. Data Capture:

The first stage is critical and forms the major portion of requirements as this serves as the foundation of the implementation just like the Physiological needs serve as the base for human survival.

In general, any IT implementation would start with a problem statement where the Business has an issue with missing data capture or users spending their valuable time on mundane repetitive tasks which could be automated. It is the responsibility of the Business Analyst to capture the basic needs from users in terms of data they would like to capture, and the level of automation required to perform their everyday job.

In our example of Salesforce implementation, the information that needs to be captured like Leads, Opportunities, Accounts, Contacts need to be captured at parameter level with respective UI forms for data capture along with validations. Also, the automations that govern the system functionality need to be captured. For example, updating a parameter in Accounts from the corresponding parameter on Contact. 


2. Data Security:

Once the basic requirements are established with respect to Data storage, User Interface and automations, the security of the data recorded in the system becomes critical just like need for Security in human life.

Different sets of users would need access to different data elements and the level of access in terms of Read/Write would differ as well. The BA needs to carefully gather the requirements of Data Security from users and work on profiling of these users.

In our example of Salesforce implementation, the Sales team would needs read/write access on Opportunity data whereas the Finance team would only need read access to Opportunities to perform forecasting and the Operations team might not need access to Opportunity data at all. There would also be scenario when one Sales Representative would not want other Sales Representative to access his Opportunity data. Hence, the Security of the data forms the next level of User needs in order to feel secure while using the application.

3. Data Integration:

Once the data is recorded in the system and is secure within the system, the next need is to have communication with other systems so that there is proper exchange of information between the systems to complete the end to end transactions. This is like the need for interpersonal relations like friendship between humans.

Different systems serve as the system of record for different data elements within an IT Architecture. Also, in most cases there is always a Master data system where all the critical data gets stored. As a BA it is important to identify the need for the required data for an application to work as expected and identify the downstream systems which would use the data from the application. This information may not be directly provided by the end users, but it is the responsibility of the BA to study the IT landscape and identify the different source and destinations of data.

In our case of Salesforce implementation, the Customer Account information would generally be recorded in the ERP, so Salesforce needs to integrate with the ERP to get the Account information. The Order information from Salesforce was used by downstream order fulfillment application, so Salesforce needs to integrate with this downstream application to complete the Order fulfilment process.

4. User Experience:

Once a working system is in place with the required basic functionalities to fulfill everyday job of the user, the user experience factor comes in which would further drive the requirements to make the system more user friendly and intuitive, hence leading to appreciation of the system by the users. This is like the self-esteem needs of human life.

Now that the basic functional requirements from the user are gathered, it is the responsibility of the BA to drive the requirements for better user experience. This would encompass aesthetic requirements like the look and feel of screens, user guidance while using the system, mobile usability etc. Although this type of requirements might not sound critical during the initial implementations, they turn out to be critical once the users start using the system, and there have been projects purely focusing on improving user experience.

In our case of Salesforce implementation, the choice between using Salesforce classic which is traditional user interface as compared to Salesforce Lightning which has an advanced User Interface would be critical in determining the user experience.

5. Analytical Capabilities:

Once the requirements for a fully functional and user friendly system are established, the insights that the data stored in the system could provide to the user becomes important, as it would enable the user to utilize the complete potential of the system and make business decisions. This is like the need for realization of individuals to utilize the complete potential so that they can do the best that they are capable of doing.

The Analytical requirements would be predominantly in the form of Reports and Dashboards that could be derived from the data stored in a system. With the advancement in Artificial Intelligence, the data could be used to provide suggestions to the user as well. Many a times, the user may not be directly able to give requirements with respect to Analytical capabilities, so the BA needs to determine the KPIs for the business users and recommend the suitable reports and dashboards around the same.

In our case of Salesforce implementation, once the Sales users have a well-functioning Opportunities module in Salesforce, it would be great if they are able to generate reports on the Opportunity pipeline and even better if they have a dashboard depicting the Opportunity Pipeline which would enable them to make quick decisions.

Requirement elicitation is often complex with users not being able to articulate the exact requirements in a proper order. Following the bottom-up approach from the Pyramid would help to a great extent in eliciting the requirements from users, starting from basic to the complex requirements.


1. https://www.simplypsychology.org/maslow.html

Are We Speaking the Same Language?

Business stakeholders and solution teams may use different terminology when it comes to requirements. 

Creating requirements tailored exclusively for one group or the other is likely to result in confusion and unfulfilled expectations.  There are some actions we can do as business analysts to help ensure stakeholders have a shared understanding of terminology which has downstream benefits.

Shared Terminology

Most organizations use terminology that span from its founding days up to the current day.  Terminology is added along the way which may replace terms but may have a different scope in meaning.  Depending on when solutions are created, each may adopt technical terms in vogue at the time. 

Some terminology is unique to an industry or even within the company.  Some terms can have different meanings depending on the department which causes confusion.  Mergers and acquisitions compound the situation.  The result is business and technical lexicons which vary across the organization.

Besides understanding the current terminology for your project, business analysts can work with business and solution team stakeholders to create a shared comprehension of what terminology will be used in the project.  This may come in the form of a dictionary, taxonomy or ontology.  I found it helpful to decide on one primary term and its definition, but also include:

  • Aliases (This can be the translation between stakeholder groups or previous terms)
  • Alias Differences (In case there are differences in meaning or relationships)
  • Relationships to other terms (Ontologies allow multiple structured relationships)
  • Allowed values (if appropriate)
  • Data Definition (Usually populated during later requirements elicitation)
  • Examples


Taking this approach while identifying high level requirements sets a foundation to build upon as more detailed requirements are elicited.  While stakeholders may resist doing this because “they want to get started”, this has payoffs for everyone.  Some of the benefits are:

  • More accurate requirements
  • Less time revisiting the same topics
  • Possible reduced development time
  • Improved QA testing (especially if Gherkin structured language is used)
  • Provides a foundation for data architecture
  • Better tracking and backlog visibility

Requirements Architecture

When you have a shared understanding of the terms and their meaning, this allows a business analyst to define the requirements architecture more efficiently and effectively.   Per the BABOK 3.0, the purpose of requirements architecture is to ensure the requirements collectively support one another to fully achieve the objectives. It is difficult to do this when terminology can be perceived differently.

Countless times I have tried to find a backlog item, but it contained terminology that was tailored to one person’s interpretation of the requirement.  When I create a requirement, I think about how someone would try to find it and recognize the contents.  If terminology is agreed upon early, I can name the requirement in a way that is identifiable by all stakeholders. 

Using the agreed upon terms also simplifies creating diagrams and models. It may reduce the number and complexity of the artifacts.  This makes requirement reviews and approval simpler.

A defined shared understanding helps with scope and expectations.  If the business is using a term that is broader in scope than the solution providers understand, this results in missed expectations and may not be discovered until User Acceptance Testing.  The opposite situation results in an unnecessary scope increase. 

Similarly, this also helps when breaking requirements into manageable backlog items.  Knowing the meaning of a term can prevent adding requirements which overlap or have gaps.  The potential for requirements reuse can be identified more easily because terms have been standardized.

 If I can’t get shared agreement, I use the most likely used term and include aliases.  When a requirement is business facing, I refrain from including technical terminology that would be confusing to business stakeholders. 

The preferred terminology may change during a project.  I have often wished requirements management tools would allow variable place holders that tie back to a dictionary, taxonomy, or ontology.  If the term or related information changed, I would only have to edit the change in one source.


During a project’s inception, the project team should determine the stakeholders and their responsibilities on the project.  They need to identify where requirements are stored, who needs access, and the attributes that need to be stored.  This leads to a plan for how business analysts share business analysis information. 

A shared terminology and a structured requirements architecture facilitate visibility into the scope of the project.  Stakeholders can identify where a specific requirement fits in by searching using the agreed terms.   It may reduce the need for meetings or extra communication for the business analyst.

This is helpful for the business because they can plan for feature releases, SME availability and UAT resources.  It helps the IT managers plan for personnel, hardware, security and other aspects.  If regulatory oversight is involved, the compliance team would need to be involved early on and would thus gain the benefits mentioned.


Since companies have a variety of lexicons, there are significant benefits to creating a shared understanding of terminology.  Business analysts can create requirements more accurately and efficiently.  Teams can benefit by not rehashing the same discussions.  Developers and Quality Analysts are more likely to build and test what the stakeholders intended.  A jointly determined lexicon is the foundation for creating a structured requirements architecture.  This promotes visibility to stakeholders so they can find requirements and plan for them.