Skip to main content

Tag: Elicitation

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.



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.  

Requirements in Context 2020 – The Trips-R-You Case Study (and Benchmark?)

The objective of my 2016 Requirements in Context series was to help business analysts elicit requirements

through an improved understanding of the difference between high-level requirements (HLRs) and detailed requirements (DTRs).

The Trips-R-You case study is an addendum to that series, offering end-to-end examples of requirements documented using spreadsheet-based templates.

In IIBA® BABOK® V3 terminology, end-to-end means from Business Requirements to Stakeholder Requirements to Solution and Transition Requirements. Both the original series and the case study use the more traditional business terms Goal, HLR, and DTR. Also both only address functional requirements within the context of a project chartered to deliver an IT-based solution.

NOTE: A business may choose to organize their IT solution-delivery resources following Agile principles. But if the delivery of those solutions are managed by a project manager, or the Agile teams do not include a ‘real’ product owner – able and available to prioritize and refine user stories, then requirements still need to be documented and managed.

The Case Study

The case study involves a fictitious organisation — the Trips-R-You Travel Agency. It deals primarily with the requirements phase of an equally fictitious project, established to deliver a web-based customer self-service flight booking capability — commonly referred to as an Airline Reservation System.

The case study is divided into three sections, based on the three levels of requirements. The first section introduces the organization and a problem it faces. A goal is set that is intended to eliminate the problem, and a business case is commissioned to examine potential solutions.

The second section sees a project initiated to deliver the solution recommended by the business case. That project’s scope is shown, and how it leads to high-level requirements for the project.

The third section takes five HLRs to the detail level – one HLR involving each of the primary capability types a business information system is able to support:

  • User Interface (UI)
  • Report
  • Data Import
  • Data Export
  • Automated Function

To support capturing the details involved in each of the above capability types, type-specific spreadsheet-based templates are utilized.

The third section also discusses and uses a Data Dictionary template. As the detail for a given HLR is discussed, the data-specific business needs involved are captured using this template. Once captured, those data-specific details are available for referencing in the other templates when those needs come up again, as they will, during discussions involving other HLRs.

NOTE: The Data Dictionary template incorporates the concepts presented in my 2018 “Well-defined Data” series.

Detailed Requirements vs Detailed Requirement Statements

It’s natural (and correct) to assume that for every HLR, there will be some number of DTRs. But what, exactly, should a detailed requirement look like? A formal requirement statement is expected to be a single sentence that includes the word ‘shall’ (rather than a term implying a priority such as ‘must’ or ‘should’). More typically, to accommodate detail, a textual requirement statement involves a number of sentences or paragraphs.

Requirement documentation techniques that make use of ‘fully dressed’ UML use cases describe an Actor interacting with ‘the system’ performing a given business activity. That description includes the individual steps within the activity, organized into different flows — one main flow and any number of alternate and/or exception flows. The step description includes names of individual fields and ‘controls’ (e.g. buttons) involved. The requirements documentation technique may treat each flow or each step within the use case as an individual DTR, or treat the entire use case as a single DTR.

The spreadsheet-based templates used by the Trips-R-You case study uniquely identify individual rows, each representing a detailed requirement (but not in ‘statement’ form). Three separate worksheets (tabs) are used to capture different categories of detailed requirement. Those three categories address:

  • The capability’s operation – E.g. who needs it, when.
  • An Individual element – E.g. a field, control, or step within an automated function.
  • An Element Grouping – E.g. an area on a screen or report (see mock-up below), a record being imported or exported.


Tabular format allows for separate columns to represent different types of detail (i.e. characteristics) applicable to a given item. E.g. for an individual field element within a report area, characteristics identifying the font to be used and whether the field is to be justified left, right, or centered. The templates also support visual representations of the detailed requirements, such as screen or report mock-ups (see example below).

Because all of the details for a ‘unit of delivery’ (a specific UI, report, etc.) are captured in an individual spreadsheet file, those DTRs can be represented by a single ‘formal’ DTR statement (similar to a whole use case being treated as a single DTR). The following is an example from the case study of one of the HLR statements for a report, and its corresponding single formal DTR statement representing the template-based DTRs for that report:

REQ008 (HLR) – A customer shall be able to access and print the booking confirmation details.

REQ015 (DTR) – The system shall be able to produce a Booking Confirmation report for a specific Booking – as specified in DR015 – Self-service Booking Confirmation Report v1.0.

The template-based DTRs for this report consisted of the following:


# of Rows





Report Areas


The spreadsheet file also included the following mock-up, visually representing the six Report Areas and the Elements contained in each:

BATimes APR29 1 2020

Individual Statements, Templates, or a Requirements Management Tool?

Requirements have a reputation for taking too long to document. They have probably earned that reputation from projects where: Requirements were ‘hand-crafted’ requirement statements; HLR statements were allowed to include too much detail; And DLR textual statements were written that included varying combinations of details about fields and/or field characteristics.

Keeping HLRs to the capability type-specific level (i.e. specific UI, report, etc.) is intended to avoid time wasted at this stage of requirements elicitation. Using capability type-specific templates is intended to save time by representing and providing space for capturing values for the specific types of details that need to be addressed for each capability type and category.

NOTE: The templates used in the Trips-R-You case study represent an amalgamation of detailed requirement types and characteristics based on my years of experience as a business analyst working in project teams delivering IT-based solutions. That experience included working for software package vendors, for organizations acquiring software packages, and for organizations outsourcing parts of a solution.

Better than spreadsheet-based templates, where affordable, would be a commercially-available requirements management (RM) or application lifecycle management (ALM) tool that supports the requirements-related concepts presented in the Trips-R-You case study.

The Trips-R-You Case Study as a Tool Benchmark

In addition to being an aid to understanding concepts related to HLRs and DTRs, it was hoped that the Trips-R-You case study would serve as a benchmark utilized by RM and ALM tool vendors. While their tools would not be expected to support all of the concepts out of the box, most tools currently on the market offer some degree of configuration. Any organization looking to acquire a commercially-available tool to support the requirements phase of IT-based projects might ask their candidate tool vendors to demonstrate their tool’s ability to support this case study.

NOTE: Any tool vendor that believes their tool to be capable of supporting the “Requirements in Context” concepts represented in the Trips-R-You case study is welcome to contact me for assistance with the benchmarking exercise.

5 Business Process Modeling Tips for Digital Transformation

Business analysts should bring more than an ad-hoc or experience-based business process modeling competence to digital transformation projects. This article will explain why and practically, how.

Many enterprises are on digital transformation journeys.

They are optimizing operating costs, improving capacity, security, scalability, and availability by moving their existing applications onto private or public cloud infrastructures. They are adopting best practices and gaining operational efficiencies by adopting best-of-breed enterprise applications in the cloud. They are integrating technologies like mobility, the internet of things, data analytics and machine learning, robotic process automation, biometrics and more. All in the cloud. This is commonly referred to as digital transformation.

Digital transformation projects differ from process management and regulatory compliance projects. They aim to disrupt by creating new business processes and services rather than improving what exists. They aim to get to market quickly by adopting and integrating existing technologies, systems and services, along with their processes, rather than inventing them. Their business processes are enabled by systems and services that are off-premise, in the cloud.

Disruption – Digital transformation projects typically seek to achieve leapfrog operational improvements rather than incremental ones. They achieve efficiencies and standardization objectives by adopting the processes of already proven, best-of-breed business systems and services. For example, adopting a human resource management system in the cloud will disrupt by altogether abandoning current processes and adopting and standardizing on the best-of-breed processes of the cloud solution.

Pace – Many digital transformation projects have aggressive timelines to deploy their technologies, to keep pace with business competitors or to gain market share. Already-invented and proven software services hosted in the cloud can be subscribed to and deployed relatively quickly. The time and effort spent on deploying business applications may be shortened. The effort shifts to tailoring, integrating, testing integrated components software and adopting change within business operations.

Technology – Technologies such as virtual machines, software as a service, mobile devices, the Internet of Things, biometrics, machine learning and the internet itself are all part of the digital transformation landscape. Virtual servers in the cloud are highly scalable and cost-effective. The range of existing, proven systems and services ready to be subscribed to, adopted and integrated in the cloud continues to grow. The cloud’s systems and services collaborate as a network of event-triggered and outcome-oriented services.

As with other information technology projects, digital transformation projects come with delivery and operational risks. They can have heightened vendor risk, people risk, change management risk, and ultimately business process failure risk. They rely on external vendors’ consultants, or third party consultants who are temporary and outside the direct control of the organization who owns the transformation. The organization’s people who will maintain the newly transformed services when a digital transformation project ends may be left with a knowledge gap in their capability to support the new product or service. The people whose day-to-day operations are affected might not initially be well-enough prepared to use the digitally transformed systems and processes. These can ultimately contribute to business process failure risk. The risk of failure to achieve the expected operational benefits due to poorly designed or executed business processes.

This is why any digital transformation project’s lifecycle may call for a business analyst to prepare conceptual or logical business process models. The models will be used for the same reasons that process models are used in process improvement or regulatory compliance projects: to communicate among the processes’ stakeholders. By communicating the required or designed processes among the digital transformation project’s owners, its suppliers and to people in the organization whose processes are changing

So What?

According to the IIBA, process modeling is one of a business analysts’ competencies. Although most business analysts are good enough communicators and have a well-rounded knowledge of their enterprises’ operations, they only have an ad-hoc or repeatable degree of business process modeling competence. They prepare business process models very infrequently. Some can recollect and repeat the process modeling techniques of their previous process improvement, regulatory compliance or IT projects. If they do, they are used to perceiving business processes as sequential procedures of tasks. There is generally room for improvement.

A business analyst should be able to confidently and efficiently elicit, perceive, model and communicate how a business process or activity is or will be implemented by a digital transformation project. Among their elicitation, subject matter and communication skills, a business analyst should be capable of perceiving any business process or activity as it is or will be implemented in the cloud, as a network of event and message triggered collaborating services.

5 Business Process Modeling Tips for Digital Transformation:

Here are 5 ways to improve your business process modeling competence and become better prepared for producing high-quality business process models that serve digital transformation projects.

1. Come Prepared
2. Get Event and Outcome Oriented
3. Know Your Mission
4. Have Agendas
5. Take Advantage of BPMN


Come Prepared.

Have a defined and proven process modeling competence and tailor it for each digital transformation project.

Start with a defined level of business process modeling competence instead of taking an ad-hoc approach or simply relying on past process improvement or regulatory compliance project experiences. Be able to clearly describe what steps and activities you will take to elicit and document the business process model. Have established elicitation techniques, agendas and modeling patterns that you can use to elicit and model basic business process flows. Be able to predict what modeling steps you will take in developing the business process model. Also, be able to predict what elicitation techniques work well for you. Have clear, concise elicitation agendas. Be prepared to intentionally tailor your approach, elicitation techniques, elicitation agendas and model configuration to the needs of each digital transformation project’s methodology.

Get Event and Outcome Oriented.

Perceive, normalize and define all business processes or activities as event-driven and outcome-oriented services.

Initiating events and expected outcomes are critical to the way that business processes and services collaborate in the cloud. Any business process or activity is a repeatable collection of work activities, initiated by a business event that achieves an expected outcome, for a customer.

Observe and recognize how business events and expected outcomes are implemented as cloud services. For example, you know that whenever you’ve made a credit card purchase online, the credit card authorization service started by receiving a request from an online business process in which you made your purchase. This was its initiating event. Once initiated by that event, the credit card authorization service completed related work tasks, like negotiating with the credit company and a bank. It achieved its expected outcome by sending a response that the payment was accepted or declined. That was the expected outcome and that outcome was consumed by its customer: the site that made the credit card authorization request in the first place.

Use this framework to conceptually and logically frame any business process that you model in a digital transformation project, before spending valuable time and effort eliciting all the other process information that may come up: e.g. who owns it, how it is or will be implemented, what is its service level, how efficient it is, etc.. Not much of all the other logical details matter if the basic framework of the digitized business process or service itself is not well framed: To you, it must have an initiating event and one or more related activities that lead to its expected outcome, for a customer.

Know Your Mission.

Determine the purpose of a business process model in each digital transformation project’s lifecycle.

The scopes, objectives and delivery methodologies of digital transformation projects vary widely. Get clear about what the business process model will be used for, and know who will use it. Determine the tense and the required degree of abstraction that will best suit the model’s intended use. Establish these mission parameters at the start of your elicitation and modeling efforts so that you focus the forthcoming time and modeling efforts on the right types of conceptual or logical refinements for that project and you are in alignment with the mission parameters when you validate your model’s quality.

Have Agendas. It’s not nearly as important to ask a lot of questions as it is to ask the right questions.

Have clear, concise elicitation agendas to elicit basic business process flow and each of the most common logical business process flow refinements. These are the few but key questions you will doggedly elicit the answers to as you are eliciting your process model’s content. Understand why you need to ask and answer those questions. Prepare and communicate your elicitation agenda in advance of engaging key stakeholders in elicitation events like workshops or interviews.

Take Advantage of BPMN.

Take advantage of BPMN to illustrate event and outcome-oriented business process structures and modeling patterns.

Use BPMN’s icons that are specifically intended to illustrate event-driven, outcome-oriented process flows and logical refinements. Use modeling patterns that employ BPMN start events, message flows, intermediate events, and end events, to illustrate modeling patterns such as basic business process flow, external stakeholder interactions, interruptions, delays and exceptions, and expected outcomes.

Know the conceptual and logical process elements and patterns that are relevant to systems in the cloud. Have elicitation agendas and modeling patterns (using BPMN) that you will use to elicit, model and communicate them. Be able to elicit and model the events that start, interrupt, and finish processes and services. Use messages to illustrate collaborations among business processes and services

Establish or Improve Your Process Modeling Competence for Digital Transformation

The Universal Process Modeling Procedure is a step-by-step guide for producing a business process model that will meet its project’s intended purpose. It guides a business analyst or process analyst to establish a clear mission for every process model. It provides you clear elicitation agendas so that you can be asking the right questions at the right times in your model’s development. It tells you what to look for and how to accurately and unambiguously identify, normalise and define any business process and or activity. It includes a validation step with comprehensive and tailorable process model quality criteria. It informs you about key process model stakeholders and how to engage them in the model’s development. It also includes reusable BPMN modeling patterns for the most common types of process model refinements.

Learn more …

About business process modeling competence at

Find the book Universal Process Modeling Procedure – The Practical Guide to High Quality Business Process Models Using BPMN at Amazon Books.