Access Requests and Entitlements

by Martin Klein,
Business Analysts Pty Ltd Consultant

When my youngest daughter Tams turned 18, she was ready to hit the clubs in the city. This had been a long time coming and she wasn’t going to miss what had become a rite of passage when the opportunity presented itself. On the night of her birthday she presented herself to the well-known clubs in the valley. Needless to say, as a father I had to hold my tongue and pray that she made it home without too much trouble. She was well aware that she would need some ID showing her age to allow her to enter the pubs and bars of the streets. But Queensland had created the lockout laws only the previous year introducing strict new rules with regards to patrons accessing the popular clubs with the intent of reducing alcohol induced crime in the areas. Clubs were now required to bar entry after 1 am and alcohol was to be served only until 3am.

Turning 18 had provided Tams the right to access the clubs. This entitlement was granted automatically when she turned 18 and had been the case for as long as we can remember. However, the lockout laws highlight the privilege that this entitlement provides to us and one that we have to date taken for granted.

In Identity Management terms, the definition of an entitlement is: the amount to which a person has a right.” Google Dictionary (2020). The example I provide here indicates that the general public in Brisbane at least have a right to access the clubs so long as they can prove they are over 18 years of age, but that there are constraints to this right introduced by legislation that will restrict the rights we have

In this blog, I want to introduce entitlements, granting a user an entitlement through a request for access and authorisation within an entitlement.

As with the entitlement granted to 18-year olds access to clubs in Brisbane, in organisations where an Identity and Access Management system exists, entitlements may be granted automatically based on specific attributes of the identity.


If we look at a process mapping the assignment of the entitlement to enter the clubs at 18 we have something not too different from the process above. We just identify the age as one of the attributes checked and permit access based on that attribute.


Access and authorisation are terms often considered the same thing and used interchangeably. But these are different features in Identity and Access Management. In each case they provide access for the identity to an entitlement, however while an identity may have access to a resource, they may not have the authorisation to access all the data or application that the resource hosts. As an example, a user may have access to a file server or cloud storage. But the ACL’s dictate what authorisation the user has access to on that data store.

Business policies and business rules define what access and authorisation is provided to the identity automatically.

In the event that the user / identity requires access to an additional resource, or that a higher level of authorisation is required, the identity will typically request access to the resource / application with the required authorisation level. This entitlement request requires approval before being assigned. In this particular instance approval is required from two separate approvers.



The following use case supports this access request process.


The process may be as simple as that pictured, or as complex as is portrayed in the Use Case. Needless to say, the functional and non-functional requirements will include levels of self-service capability, workflow development, triggers to re-route requests, assign approvers and send notifications.

Providing access to a resource or application is a business decision. The questions of who, why, when and what access is provided are largely determined by the business and implemented as rules within the IAM system to automatically assign the entitlement to the identity, just as the entitlement to access the clubs and bars of Brisbane are automatically given once specific determinants are fulfilled and in compliance with the laws of the State. In this case the age has exceeded 18 years.

Fortunately, IAM systems can use a broad set of attributes to determine access, but none of these relate to our human side while security staff need to make the decision on proof of age.

Like with the rest of us, this won’t last too long. 😉


Identity Lifecycle Management

by Martin Klein,
Business Analysts Pty Ltd Consultant


“At Facebook, we build tools to help people connect with the people they want and share what they want, and by doing this we are extending people’s capacity to build and maintain relationships.”

Mark Zuckerberg

In the first part of this series we talked about how my partner has lacked the confidence to re-enable her Facebook account. For her, Facebook became a scary beast that allowed others to stalk and peruse her personal life. There were few if any controls to allow her to restrict the access for unknown people and provide the security that she needed to have to use the application. This is still the case by the way, although Mark Zuckerberg seems to think otherwise in the quote we have cited at the head of this entry. But the quote does provide a great segue into what this blog entry wants to cover. In this entry I want to move on from the initial account registration to start managing the identity and the identity lifecycle.

This becomes the core of identity management with individual components such as the identity vault and integration connections providing the means to capture, consolidate and distribute / provision accounts across the company’s IT landscape.

We have said this before, but I will say it again. Gartner defines Identity Management as the set of processes required to provide the right access for the right people to the right applications at the right time and for the right reasons. The Identity Lifecycle takes this from cradle to grave. We don’t see too many digital identities entering the grave, and we have already covered off in our previous blog entry how the stork delivers the new identity. This blog will take us through the identity lifecycle journey with the aim of identifying the core processes involved in setting up an identity management system to introduce, manage and remove an identity within an organisations environment.

Let’s put this into context. The two following diagrams provide high level views of the IAM processes and integration.

The primary processes of the Identity lifecycle include:

  • Provisioning
  • Changes / Updates
  • De-provisioning

Figure 1 – Identity Lifecycle Processes

Figure 2 – Identity Integration Context Diagram


This simple diagram shows:

  • The Source of Truth (SoT)
  • The Identity Vault (Vault)
  • The Active Directory (target)
  • A cloud and on-premise application.

For the record I have added in how we can assign access based on attributes, position or roles. Each application or target system is considered an entitlement, although an application may have multiple entitlements with each one having a different level of access for a user to operate at different profile levels.

Traditional methods of achieving this were performed manually. The IT Service Desk would usually be requested to create, modify or remove an account for a staff member, visitor or other identity type (which I put into a general label of Person of interest or POI).

Figure 3 – Identity Lifecycle BPMN High Level Process


There are a few key aspects of identity management that are needed to make the lifecycle management processes work. The process map above outlines at a high level the Identity lifecycle journey.

It starts with the Source of Truth or Authoritative Source for the identity. Typically, this might be the HR or HCM (Human Capital Management system, the registration system which might be extended to allow updates to an identity, or some other system that has the ultimate truth with respect to the identity attributes. IAM synchronises identity data from an authoritative source to each connected / provisioned application. Provisioning involves a number of steps.

Firstly, the identity information is consolidated from the source of truth to the identity vault. The vault stores all identity information for the individual. This is where the person becomes is represented as a digital identity.

Secondly, whether the identity should be provisioned to the application is determined by the IAM system based on specific preconfigured business rules that assess the attributes of the identity such as position, location and/or department against a prescribed set of requirements.

Thirdly, once the IAM system has determined that the identity is to be provisioned to the application, a subset of the identity data from the vault is used to automatically create the account and assign specific access rights to the application for the identity.

The following process diagram outlines these steps to provision an account to an entitlement.

Figure 4 – Identity Provisioning


But people are not static entities. They may change their name, address, phone number, position, location or department or any one of a large number of attributes that define us as individuals in a corporate environment. Managing the Identity Lifecycle involves ensuring these changes are replicated from the Source of Truth to all target systems. Despite what people might think, Active Directory is NOT the authority on personal identity data. To change identity information, we need to change the data in the Source of Truth for the identity. IAM will synchronise the attributes changed to each connected system the identity is provisioned to, overwriting any data that is in each application for the identity attribute being changed.

By way of example, I could use a hypothetical situation where my daughter might find a partner that she wants to be with and, after the appropriate courting period, they agree to be wed.

At a digital level this simply changes a few attributes such as last name and title. These would be modified at the source of truth and synchronised via the IAM system to the vault and downstream applications.

This may seem a little impersonal, but it could be argued that IAM provides greater personal control over your information than has previously been allowed.

Ultimately, we move on to the termination. Rarely do we need to remove all traces of an identity from our systems. IAM provides much greater security in a more-timely manner than would otherwise be available through manual or semi-automated processes. In IAM terms, we consider that the terminated identity “will be back”. Perhaps they will return as a client or visiting consultant, or perhaps as a staff member in a different position. In any case, most IAM systems will disable accounts in the target systems but will retain the identity information in the identity vault and the source systems.

IAM automates the provisioning, change and de-provisioning processes. Business rules dictate what access is provided on which the IAM system acts and ensures that each provisioned application is provided only what data is required to enable the right access for the individual.

Facebook may be providing the tools that enable people to connect with others, but this is a limited version of what IAM provides in an organisation. Within the company’s environment IAM ensures that security of company and personal identity data is maintained, access is provided to data and applications across the organisation and the relationship that is required between people, applications and resources is established and maintained automatically by simple changes to our personal data.

Identity Management is extending far beyond the boundary of the organisation. Today we can use Facebook accounts to login to online and corporate sites, but what if we could turn that around and control our own identity data to permit parts of it to be consumed in creating accounts in Facebook, Google, Yahoo and other corporate and online sites.

I think at that point even my partner might be happy to venture into the sphere of the internet again.

Registering a New Account

by Martin Klein,
Business Analysts Pty Ltd Consultant

Recently my partner’s daughter (Lucy) said she had an invitation to a gender reveal party. Unfortunately, I come from a day long gone when gender reveal parties didn’t actually occur. Instead it was a surprise when the baby was born, and we took what came enjoying or commiserating with our friends and families. After much conversation and deliberation, I was informed that a gender reveal party is simply an excuse to celebrate the new baby before it was born instead of having to wait until the day. If only we could have so much fun in the digital world?

In the digital world we are all gender neutral and there are no “surprises”. Just think that we never have to guess what colour baby clothes or colour laptop covers we would need to buy.

However, on reflection that isn’t quite true. It is not unusual that we provide gender information when registering a new account online or within an organisation, and certainly the HR department are aware and identify our gender. This leads me to introduce the process for registering a new account because it is here that we inform the company of our specific details for access.

Before we can do anything with an identity, we need to capture the information required to create a digital representation of ourselves. Identity Management builds the relationship we have with specific applications by using our personal details. Items such as the position held, our location and even gender (yay it’s a girl!) matter in determining whether access is provided to specific applications and the level of authorisation that is provided. It’s not just about providing access to barbie dolls for girls or matchbox cars to boys although it could be if the business rules were to be that specific.

Identity Management builds the relationships we need with applications by associating specific attributes of the identity to the application. These associations are defined through business rules. For example, one business rule may dictate that an identity with a position attribute of manager may be provisioned with access to the finance system as a manager profile allowing the user to approve expense claims and authorise purchase orders to a specific value.

These details are captured in the registration process. Almost all environments, including Facebook, Google or Yahoo, will follow this process in creating a new account. I call this the registration process (for customers) keeping in mind that in a company, a new staff member will be created by the HR department.

The data captured in the registration process establishes the identity. The business rules consume the identity data to determine the access to applications and resources that require provisioning.

In corporate organisations, the initial account is created by HR as the department responsible for all staff and temporary personnel. The registration process is typically one that is used by consumers in registering an account to access specific applications or services.

The following BPMN diagram outlines a typical registration process.

The registration form should be kept short and capture the minimal information required to service the customers initial provisioning requirements. Once the registration is complete, the business rules may require that further information is provided to access additional data or applications. I tend to request simple fields be completed so that an account can be created and a password set by the customer through a verification email or SMS.

These fields may include:

  • Given Name (use given name rather than first name as many nationalities use the given name as the last name)
  • Family Name (once again using family name instead of surname as some nationalities are confused with surname.)
  • Date of Birth. (using the date of birth along with given and family name attributes will allow checking whether the account already exists. Typically these three fields will have a 95% success rate of identifying the individual. i.e. typically there is a 95% chance that a match of given name, family name and date of birth will be the same person as previously registered.)
  • Personal email address (This will be required to send the verification email to verify the account.
  • Phone number (This is optional but I put it in as an alternative to sending a verification email this may be used to verify the account via SMS.)
  • Country (It is good to capture location somehow. Depending on the business type this is more or less relevant. If operating as a regional council this location may be a post code rather than country.)

Optional fields may be added including:

  • A drop down box to select an application or resource required. (This allows immediate provisioning once the account is verified.)
  • Opt in / opt out for email newsletters etc.
  • Start date / End date. (I use a start and end date fields for short term temporary accounts only. Providing this to customers would not be relevant as the customer would simply set it for 50 years or so.)
  • In some instances, it may be suitable to have a short questionnaire as this may be used to provision certain interest groups for newsletter notifications.
  • Line Manager. This field would also be used in creating a temporary personnel account for a company. Setting the line manager identifies the approver who would approve the account creation. This would be in lieu of sending a verification email for the password as the new identity can set the password on first use of the account. A temporary password may be set or Multi factor authentication be setup to ensure security is maintained.
  • and gender.


The following form is an example I created on Microsoft forms.


Once the identity data is captured, the IAM system would confirm that the account with these details does not already exist. Typically the IAM system will use the given name, family name and date of birth to check for duplicate accounts. If this is a new account the IAM system will create it using the details provided. If an account with these details already exists it may present this to the customer asking whether the existing account is the same person and typically sending an email to the registered email address to verify the new details and connect this account.

Once the account name is established, an email with a verification button may be sent to the personal email address. This usually involves the customer clicking on the link / button in the email and setting the initial password for the account.

The following image provides the use case I have used to register a new student account.






Registering a new account correctly is critical for organisations. It is imperative that the registration process is simple and concise yet captures the data the company requires to provide opportunities for marketing and to deliver the services requested by the customer. In many cases, organisations are registering new accounts by allowing customers to use their social media accounts such as Facebook or Google, Yahoo or any others. However, many customers are reluctant to provide their details using social media as the protocol (OAUTH) used to do this allows the web site to capture a lot more than just name, gender and date of birth. As such, privacy issues become a major concern with customers. The Privacy act of 1988 (Australia) and GDPR (EU 2016) places the risk on the company to protect personal data with heavy fines and compensation (Google was fined EU$50 million in 2018 for breaching GDPR rules) if private data is accessed and released by unauthorised people

In the Identity environment there is such a thing as “too much information”. But providing the right access to applications and resources requires the right amount of information to be captured. It’s a fine line between minimising the information requested and ensuring individual access is provided. Maybe we do need to consider the gender in the registration process which may see us celebrating each new account as a boy or girl yet. At least this would make Lucy happy.


Introduction to the IAM Processes

by Martin Klein,
Business Analysts Pty Ltd Consultant


There seems to be a lot of attention on Identity information and in particular identity theft recently. With the increasing rate of data

breaches targeting Personal Identity Information (PII), more of us risk losing our identity in the digital age than we ever have before. The explosive growth of online shopping, social media and the Internet of Things has required us all to create online accounts across an ever-growing number of sites.

I for one, have not seen the necessity to limit the number of versions of my digital self. I live in a false belief that an old account I no longer use will somehow be deleted and removed from the site, while only the new accounts and sites I am using remain relevant. My partner, on the other hand, doesn’t believe in online shopping, nor is she enamoured in the need to share every meal, holiday snap or daily event with all her family and friends online. For her, a person who has deleted her Facebook account and removed any other online presence save that required for work, she sees the Internet as presenting too high a risk to personal privacy.

Many of us try to make the job easier by leveraging our social media account to login to a new shopping site we simply must have access to or establishing an account in a new organisation through work. We believe, falsely, that the use of social media as an authentication mechanism provides a more secure “digital presence”, limiting the number of passwords we need to remember and thereby reducing the security risks. Sure, it does this, but security is only provided in that we can use the same credentials to login rather than creating a whole new username / password combination. The new site will still create a digital version of us, a copy that might add more or less information than we have already provided elsewhere.

Our data is exposed to the world and secured through the company’s security systems. Alas sometimes these are less than effective, and at other times, despite their best efforts in ensuring the data is safe, inevitably we hear more stories of identity data being “stolen” by state actors or “unknown hackers”.

At times we can’t even trust those organisations to which we have enlisted our online presence. Some of these organisations sing to a different agenda, chasing increasing revenues through selling identity information, or allowing analysts to evaluate our online patterns to form advertising or direct manipulation of our actions through suggestive media placement.

The need for greater security measures is clear. Regulation is required to ensure that companies that do not take reasonable measures to secure the identity data, are held responsible for the potential loss in personal safety and the security of PII including credit card information, phone numbers and address data. To meet this requirement the European Union has released the General Data Protection Regulation. While this doesn’t prevent a breach, it does put the onus on companies to ensure strong security measures are implemented to avoid the fines resulting in the data breach and the loss of personal identity information from the company’s clients.

Whatever security you may have felt when enrolling with the corporate site has been lost. We are left to search “have I been pwned” ( to see if our email address and account information used to login to this site has been compromised.

Corporates need to establish stronger policies and security around Identity Management to ensure that our identity data remains safe. They need to ensure that each person is provided a single Digital Identity to access every application and every resource we may need to access for the tasks, work or services we are required to perform. Whether as an employee accessing corporate information, a student accessing university data and resources, or as a temporary visitor to a firm or customer accessing an online site, providing access and managing the Digital Identity information correctly ensures that access to the required applications is provided and data security is maintained.

Establishing a single Identity store, ensuring only minimal information is placed in each application and managing the identity lifecycle through access to applications, disabling or removing access when it is no longer required and removing the account completely when  requested, are some of the fundamental steps that Identity Management performs automatically in delivering the security of Identity data across the organisations environment.

 “I think it’s pretty clear that the Internet as a whole has not had a strong notion of identity. And identity means, ‘Who am I?’.” (Eric Schmidt. CEO Alphabet)

With the broad adoption of Cloud based applications, mobile devices and the Internet of Things (IoT), evolution is occurring not just in how consumers are accessing company data, but where the company data is located and how access is managed. Traditional manual methods are simply unable to provide access to individual identities. Identity and Access Management provides the silver bullet to this challenge, ensuring that identities are provided the right access but without compromising the security of company data or personal identity information.

This series of blog entries will help you becomes familiar with the processes used in managing the identity lifecycle. The series includes:

  • Registering a new identity, the process involved in capturing identity data and establishing the attributes of an identity, augmenting identity data from multiple sources and establishing a login name.
  • Developing the relationship the identity has with each application and resource through automated provisioning, understanding the role of the source of truth and establishing access through attributes. We will also look at the triggers involved in de-provisioning and removing access.
  • Governance – Requesting Access, workflow approvals for access, notifications and ensuring compliance is supported to prevent conflicts of interest and separation of duties.
  • Login – Authenticating and verifying identity through the login process including a look at the Single Sign On process to login to multiple applications.
  • Authorisation – Ensuring that the identity is provided access to an application at the authorised level.
  • Audit – Finally we will look at the reporting and audit processes involved with ensuring identity activity is tracked and reported on, and forensic reviews of identity access can be performed.

It is foreseeable that we can all live in a safe online environment.  It is also foreseeable that my partner will re-establish her Facebook account and join the rest of us in sharing our daily lives online. But then, should we really be keeping up with the Jones’ through social media, or should we just get on with our lives and enjoy each meal, each holiday moment and each event as they occur keeping the memories for the times we actually meet face to face with our friends and families.

CRM and Scrum

by Himanshu Bhasin,
Business Analysts Pty Ltd Consultant


The transition to Agile for Dynamics 365 or CRM methods is revolutionising enterprise software projects. Agile projects offer faster deployments, reduced costs, higher quality, more satisfied users and stakeholders, and more fun for the project teams involved compared to traditional, waterfall methods.

But how would one use this methodology for CRM projects? Let me help you with my experience as a BA in the implementation of CRM projects using Agile.  First and foremost is to understand what functionality of the CRM needs to be implemented to meet business needs and processes. For instance, a few of the services Microsoft Dynamics CRM provides functionality for are:

 Image courtesy of:


So, which of these are relevant to addressing the business need(s)?

Once we understand the CRM functionality to be used, the next steps are understanding the data, business processes and entities to be used in the CRM. Let us take an example of a standard Salesforce Automation (SFA) project as a guide. With SFA projects, the typical user constituencies include inside sales, outside sales, sales assistants and management. The standard CRM entities to implement would include Accounts, Contacts, Opportunities, and Activities as a minimum. In addition to the entity development, there are often workflows, data migration tasks and reporting requirements as well. Let’s see some of the activities of a BA working in an Agile environment on this type of project.

CRM Pre-planning and Sprint 0

To build the product backlog, the BA, along with the project team, could interview each user group to gather their requirements. This is a similar approach to the analysis phase of the waterfall methodology. The requirements should be documented as user stories with acceptance criteria. The user stories would include requirements relating to data entry, searching, data conversion, integrations, workflows and reporting. At the end of Sprint 0, the project team along with the business owner would prioritise the user stories into future sprints. Sprint 0 is the perfect sprint for configuring the servers, installing the software and setting the base security rules. All these tasks must be accomplished before the project team can move into development.

Sprint 1

Since Accounts are one of the fundamental CRM Entities and we have completed some of the server and security work in Sprint 0, we will start Accounts in Sprint 1. The user stories for accounts would include stories that would translate into tasks for storing data, creating forms, creating views, data migrations, reports and workflows. For example, the user story might say, “As a sales rep, I would like to save information about companies I am selling to inside CRM”. The user story would detail the fields such as account name, account number, physical addresses, billing address, phone numbers, etc. A second story would describe any data integration or importing requirements. For example, “As a sales rep, I would like to convert my existing accounts, so I can view them in the CRM”. It is important to remember that you wouldn’t be able to include stories about contacts until those entities are created in future sprints. So, if we included contacts in Sprint 2, we could include a user story that establishes the relationship between the account and contact in sprint 1 or future sprints. For example, “As a sales rep, I would like to associate a person with the company they work for and store this information in the CRM”. I have found ER diagrams very useful to depict the relationship between the entities.

For data migration tasks, the activities would be limited to the fields identified in the user stories for Accounts only. At the end of Sprint 1, you would demonstrate full Account functionality or even deploy Accounts to your users. Another important role of a BA in each sprint is firming. The idea behind firming sprints is to catch up on issues, bugs or refined requirements that the project team encounters during current or previous sprints.

Sprint 2 – 4 Contacts, Activities and Opportunities.

Each subsequent sprint would handle another CRM entity. In Sprint 2, we will move to Contacts, Sprint 3 would be Activities and Sprint 4 would be Opportunities. Each sprint builds on the code written in previous sprints. A BA keeps grooming the stories for next sprints and plans showcases for each sprint to get the feedback from the business.

Sprint 5 – Deployment

If the project team did not deploy at the completion of individual sprints, you can always add a deployment Sprint as part of your initial release.


The benefits of Agile (Scrum) development for CRM implementations are the iterative nature of short sprint cycles. Changes in business processes or new requirements can be quickly implemented by the project team without the need to wait for the “next” release. In addition, the short development cycles also tend to expose risks and issues earlier in the project as opposed to later development phases.

Navigating the Amusement Park

by Abraham Magalong,
Business Analysts Pty Ltd Consultant

Working as a BAPL Business Analyst Consultant is both character building and rewarding. I liken it to episode thirteen of season four of The Simpsons, named Selma’s Choice. Our profession of business analysis can sometimes be difficult. However, BAPL makes it easier by helping Consultants navigate the Duff Gardens amusement park equivalent of information technology (IT) projects. To illustrate how, I will provide direct comparisons between Selma’s Choice and the day in the life of a BAPL Consultant.

The story or IT project often begins by a directive. The Simpsons, along with Patty and Selma, drive to Littleneck Falls to attend the funeral of Great Aunt Gladys, and the review of her will. On the video will, Great Aunt Gladys advises Patty and Selma not to die alone, as she did. Selma hears the ticking of her biological clock, and decides she wants a child. This opening scene is similar to how projects are often started. Either a senior executive direction or the fear of not actioning and not being compliant. How BAPL use and capture this direction is by developing a scoping document. This living document allows both consultants and clients a mechanism to understand the business problem, impacts and the benefits of undertaking the project.

The next few scenes in this episode follows Selma on her journey in dating life. First she tries, video dating, but gets rejected by Groundskeeper Willie. She then goes to a psychic who tries to sell her a love potion. The psychic ingests it, blurts out the innocuous ingredients and discovers that she accidentally drank a truth serum. Selma dates Hans Moleman after revoking his license at the DMV. All goes well until Hans tries to kiss her goodnight; Selma envisions herself as the mother of several mini-Hans, and kicks him out of the car to prevent that future from happening. I liken this scene to the process business analysts go through when evaluating whether a solution meets business requirements. To avoid the turmoils of procuring the Hans Moleman equivalent of an IT solution, BAPL has quality control mechanisms across the practice to help consultants. Some of these control measures are:


BAPL ensures a level of due diligence is performed to ensure that all requirements have been documented. One of the means of doing this is ensuring that a level of current state analysis and requirement traceability, particularly process analysis, has been undertaken by the consultant.

Peer review

Before deliverables are submitted to clients or vendors, they are peer reviewed within the practice by a Senior BAPL Manager. This quality assurance step ensures that deliverables are fit for purpose and that all options have been appropriately considered.

Leveraging the practice knowledge

Consultants at BAPL have over 500 years’ cumulative experience in business analysis. This allows consultants to reach out to the practice and validate whether an analysis approach is appropriate or if they have had previous experience with the same problem. Our centre of excellence underpins this.

The concluding scenes are of Selma looking after Bart and Lisa at the Duff Gardens after Homer falls ill from food poisoning. After Bart and Lisa repeatedly annoy each other with pranks at the Little Land of Duff ride, Selma intervenes (mindlessly reacts), shouting at Bart to quit making noises and ordering Lisa to drink the water from the ride. When Lisa takes a sip, she hallucinates and wanders away from the ride, becoming mesmerised by the amusement parks lights and is later found swimming in the fermentarian. Lisa eventually is returned to Selma by park staff as she proclaims, “I am the Lizard Queen!” Bart typically creates mischief himself as he gets on a roller coaster called The Barrel Roll and ends up having to be rescued after the car stops in the centre of one of the inversions

Matt Groening

These unfortunate, albeit humorous series of events is similar to how frantic, chaotic and exhausting IT project delivery can be at times. Business Analysts fulfil their roles as well as others within the project team. This is because we share similar knowledge areas with many other disciplines like solution architecture, data analysis and project management. The concluding scenes justify how without a structured analysis approach, supportive culture and defined responsibilities, projects can quickly become over spent and delayed. To help consultants with situations like this, BAPL provides the following services:

Service Delivery Manager 1-2-1’s

Every person needs someone to depend on. Consultants at BAPL have a Service Delivery Manager who regularly ensures the consultant has all they need to confidently achieve their scope of work but also the client is happy with efforts and understands expectations.

Practice Manager guidance

Driving our practices collective knowledge and upskilling our consultants is the Practice Manager. Consultants can contact the Practice Manager for any advice, template guidance and support. Peer reviews from the Practice Manager also ensures a level of quality assurance for project deliverables.

Leveraging the practice knowledge

This point is worth repeating as it is a strength within our practice. No single consultant has all the answers. Every one of our consultants brings a variety of skills, years’ worth of knowledge and experience, and a plethora of lessons learnt. All of which can be leveraged by any consultant. A consultant can reach out to our practice to ask for advice on an analysis approach, template and sanity checking.

The episode concludes with Bart and Lisa returning home with Selma deciding she can live without children for now and adopts Jub-Jub, Gladys’ pet iguana. The role of a consultant is to provide value adding advice. This may be acknowledging that doing nothing, or something different, may be the best approach for a client. To ensure consultants are confident to provide advice like this, BAPL provides support, whether it be training, peer reviewing and guidance.

Working at BAPL is character building and rewarding. You will never feel like the ‘Lizard Queen’ when you have the backing of the whole practice behind you.

Habits of a Successful Digital Business Analyst

by Sohail Chatha,
Business Analysts Pty Ltd Consultant

As we enter the fourth industrial revolution, we can see that the product and services are transforming rapidly. The speed, breadth and depth of this revolution are forcing enterprises to rethink how products develop and how organisations create value. Sensing the need, many organisations are moving to adopt the new ways i.e. digitisation. Most of organisations need to re-invent their business and operating models in pursuit of digitisation to stay relevant and competitive.

A Business Analyst is looked upon to facilitate and manage this digital transformation journey. Being a conduit between business and technology stakeholders, a BA’s role is significant to achieving success in digital transformation projects. This blog identifies 7 key habits of a digital BA practice which are necessary to achieve success in the digital context.1. Business Goal Centric

Business goals are strategic imperatives that the organisation is looking to achieve. Business goals map to the organisation’s needs (opportunity or problem). A digital business analyst creates and promotes a shared understanding of the business vision/goals and outcomes expected from the digital initiative. All the analysis effort is directed towards achieving the defined business goals, shunning noise. Business acumen is shown when constantly inspecting and refining these goals after considering new information, market changes and values.

A digital Business Analyst flags the conflicting goals and works with stakeholders to create consistency. Additionally, digital analyst works with stakeholders to set realistic timelines for achieving these goals.

2. Customer Empathy (Voice of Customer)

The digital market is changing rapidly, customer needs evolve, their liking and disliking changes continuously. Understanding the customer needs has become a matter of survival for organisations. The sole purpose of the digital initiative is to align with the customer experience and improve customer journey (internal or external customer). A digital business analyst helps organisations in the timely and correct interpretation of the user needs, wants and expectations using data to produce better outcomes.

A digital business analyst thinks as a customer and during the digital initiative ensures that all digital processes, technology and governance will result in better user experience. As digital initiatives often involve complexity, maintaining the focus on customer is a necessity for a digital BA.

 3. Process Optimisation

The real opportunity in digital initiative is to look beyond technology and optimise processes in a way to positively impact the organisation. Digital transformations create processes which are more inclusive, human-centred and futuristic. The focus of digital initiative is to uplift or improve processes so that the “inside-out” strategy is challenged. Since the customer has become the centre piece for all the activities in a digital initiative, a digital Business Analyst constantly assess the process orientation towards the “outside-in” approach.

Technology is only a contributing factor in a Digital Transformation. The business analyst works with stakeholders and cross-functional teams to create processes which are leveraged to realise the complete potential for technology.

Figure 1: Organisation’s Digital Capabilities

4. Advocating an Agile Mindset

Around 70% of IT projects are delivered using Agile approaches. Additionally, Agile has found its application beyond the software development as Agility is now being adopted at the culture, communication, operational and delivery level. A digital Business Analyst is an Agile Advocate; they see the opportunity in,

  1. People and interaction over processes and tools
  2. Working “technology” over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan.

A digital Business Analyst challenges the status-quo, avoids waste, focuses on the high priority items first and delivers iteratively and incrementally. Transformations are complex and digital transformations even tougher. An Agile Business Analyst will always break the work into small, manageable pieces and deliver value rapidly and consistently. This Agility allows change which is easy to manage and control.

Feedback is sought at the delivery of each digital initiative’s stage. This feedback is fed into next iteration for improvement. A digital Business Analyst always facilitates resource allocation to high value analysis work first and is open to ideas with a focus on causes rather than output. These activities create a collaborative and Agile culture which helps technology to support the enterprise’s operation seamlessly.

5. Influence with Data

According to IBM, 90% of data has been created in the last 2 years and this ‘data overload’ is not going to stop as digitisation becomes the norm, and the Internet of Things integrates with our lives. Loads of data is available, getting to the ‘correct information’ is the challenge.

Six characteristics of good information are1:

  • Clear (Precise and unambiguous)
  • Relevant (appropriate to the concern)
  • Economical (available at reasonable cost)
  • Adequate (provides sufficient basis for assessment)
  • Quantifiable (can be independently validated)
  • Trustworthy and Credible

For digital initiatives, the Business Analyst needs to be a ‘power user’ than a data scientist. A digital Business Analyst works with Data Scientists/Data Analysts to get the ‘correct and relevant’ data and transforms it for meaningful presentation for stakeholders. A digital BA always considers the business context in the use of data and ignores the non-contextual information as ‘data pollution’.

A digital BA considers which source of data is more viable and reliable and interrogates the data to find rules and requirements to assist in developing digital solutions.

The presentation of data to influence the digital transformation path is managed by understanding the communication needs of stakeholders e.g. some stakeholders may be more data centric than others. A digital BA considers all these constraints to visually present data suitable to different the communication needs of stakeholders, which aids in creating the shared understanding of value.

6. Understand Technology and Governance

A digital business analyst adapts to technology trends and understands how technology solutions map to the business needs. Understanding the of technology helps a digital BA in the analysis work on:

  • Security and access management
  • Integration of Platforms (current or future)
  • Future proofing
  • Information Flow &
  • Business Architecture

Cyber security is coming into the public eye (e.g. 5G) and a digital BA usually works under strict privacy and/or legislative regulations. Governance of a digital initiative is critical for an enterprise to operate in the presence of regulators and government scrutiny. Developing a consistent and up-to-date governance structure helps a digital BA in the analysis work on:

  • Service Quality
  • Privacy Regulations
  • Information Management
  • Content Optimisation
  • Compliance and Licensing
  • Legislative changes

A governance mechanism in digital organisations will save them from penalties and increase user trust.

7. Collaboration and Communication

As per McKinsey, the success rate for digital transformations was less than 30% in 2018. An organisation transforms for the stakeholders, customers (internal/external) and market factors. If collaboration is not achieved right from start, the moving pieces of a digital transformation make it challenging to achieve synchronisation.

A digital BA makes collaboration with all relevant stakeholders a key task in digital initiatives. A Digital BA uses their soft skills to facilitate cross-functional teams to collaborate.

A digital BA ensures bi-directional communication and that stakeholders are involved throughout as per their impact level. A digital BA is trustworthy and transparent. A collaborative environment will result in involved stakeholders, free flow of information and innovation.



1 IIBA’s BABOK v3.0


The Zen of Agile – Personal Philosophies for Practical Agile Adoption

by Derek Lynch,

Business Analysts Pty Ltd Consultant


I’ve somehow managed to eke out a career staggering through the murky world between data science and business analysis. My 25 years of gainful employment (other than a brief but glorious stint as a directory enquiries call centre operator in my early twenties) has involved data analysis of some description but I’m yet to write a single line of SQL code. I don’t possess either the Wizard Robes of Genius of the data scientist or the Designer Suit of Knowledge that good Business Analysts wear, but I get by.

I consider myself very blessed to have worked across multiple sectors and disciplines – having progressed from media sentiment and sports sponsorship analysis through FMCG market research, creating financial and operational business intelligence systems, redesigning government digital service offerings using human-centred design methods. Currently I am working with clients to help them realise the value of quality data and integrated insights which has exposed me to a plethora of management styles, tools and methods, all of which have shaped my own personal work philosophy and approach.

About 4 years ago now I was asked to attend agile training in preparation for joining a team of digital developers as a Data SME working on State Government digital service offerings. My instant reaction was one of panic. 25 years of data analysis is a pretty sedentary career path which has left me with all the physical agility of a wombat but, once I was assured that there would be no assault courses or climbing walls to negotiate, I went along for the ride and what a ride it has turned out to be.   Pretty much my entire career for the last 4 years has involved working on agile-managed data projects, or as a Data SME as part of an agile software delivery team. As a result, the spectrum of maturity and success of agile delivery has varied spectacularly but every day brings a new insight or learning – hopefully some of what follows will benefit you or your organisations’ own path through agile delivery.

Look before you leap – agile isn’t for every organisation, agile isn’t for every project

“Look before you leap for as you sow, ye are like to reap” – Samuel Butler

The mistake a lot of organisations or individuals make is to approach agile as Agile – the Capitalized Methodology. Agile isn’t a methodology and treating it as such confuses process with philosophy and culture. Make sure you have a clear understanding of agile principles (the Agile Manifesto is the best place to start) and that you pay close attention to understanding the implications of adopting agile principles for your organisation or project and whether or not they fit with your culture and strategic intent. It should also be remembered that agile is an umbrella term for a multitude of different project management styles and approaches (Scrum, Lean, Kanban etc.) and that understanding the nuances of these approaches is critical to choosing the approach that best suits your needs.

It’s important to remember that agile was originally created as a software development delivery approach – nothing less, nothing more. While it has successfully crossed the chasm to other types of business change it will not be a catch-all fix to all business problems. In short, do your research before committing to something that will take a lot of effort to unravel if it fails.

People make agile work – agile doesn’t make people work

“He who masters the power formed by a group of people working together has within his grasp one of the greatest powers known to man.” – Idowu Koyenikan

I was in a meeting once where our program director went around the room asking us if we preferred the agile or waterfall project approach. When she asked one of my colleagues, a much valued, highly respected and somewhat grumpy team member responded “I don’t care – I just like getting s@%t done”. While it seemed a flippant and mildly offensive response it also resonated deeply with me – and is exactly the right way to approach agile.

Adopting agile principles requires step change and in many cases a leap of faith and making sure you have the right people filling the right roles on an agile team is absolutely critical to a project’s success. Agile will NOT magically fix a toxic team culture or boost the productivity of demotivated resources, quite the opposite in fact. Adopting agile principles can sometimes feel like the grieving process in that people exposed to agile for the first time often move through the stages of denial, anger, bargaining and depression before finally accepting and adopting agile principles – different people and groups will embrace the change at different pace and it’s important that this is factored in when considering adopting agile principles.

Understand the difference between “being” and “doing” Agile

“Glory lies in the attempt to reach one’s goal and not in reaching it” – Mahatma Ghandi

Agile is a mindset, an attitude. If the company you work for focuses on doing agile rather than being agile then there’s a pretty good chance that they’re on the wrong path. Being agile is about embracing the philosophy and applying the principles of agile to your business, the doing is simply a by-product of this. Many organisations fall into the traps of:

  • Following a mandated “one-size-fits-all” standardised agile model across all teams and projects. There is no standard approach to agile, it’s very nature is dynamic through constant adaptation and improvement.
  • Paying more attention to the ceremonies and adherence to the agile “process” rather than the end goal, which is incremental delivery. Run a mile from any organisation which tries to build agile parameters into your individual KPIs!

Agile isn’t a contest or a race

“Try not to become a man of success but a man of value.” – Albert Einstein

One of the primary agile benefits for me is the focus on planning, sizing and prioritizing increments of work and the tools like story pointing and velocity measurement are critical to how agile works.

But they are also a double-edged sword.

By assigning point values as a measure of level of effort required to complete a task you are able to estimate the level of effort required to complete tasks in relation to each other, but it should be remembered that they are neither a delivery promise or a goal. Story points and estimation have no intrinsic meaning beyond providing an informal understanding of project complexity and effort and a specific team’s capability to deliver. Comparing velocities between teams or individuals in teams is both worthless and unnecessary – success is value delivered, not accuracy of estimation or compliance to a plan. Beware the project that has the mysterious ability to meet their velocity targets without actually delivering value (trust me, I’ve worked on a few of these).

Agile is Iterative, so iterate your approach to adopting agile

“To improve is to change, so to be perfect is to change often” – Winston Churchill

One of the guiding principles of agile is to incrementally respond to change as opposed to following a rigid plan so don’t be afraid to use this as a mantra for adopting agile principles. Organisations who try to implement agile too quickly and rigidly run a high risk of agile implementation failure. They often overlook the fact that adopting agile is a massive cultural change that should not be made overnight. Agile can also lead to a significant investment in terms of training and/or recruiting resources and the talent management strategy is too often considered an afterthought in adopting agile principles.

Careful consideration should be made to scaling agile adoption in terms of organisational readiness, resource constraints and leadership bandwidth. The larger and more complex the business, the longer it will take to scale successfully.

Beware the agile zealots

“The mind can make a heaven out of hell or a hell out of heaven.” – John Milton

For some reason people can become somewhat zealous in their approach to agile and insist on strict interpretation of agile principles, which in itself directly contradicts the core principles of the Agile Manifesto. The whole point of agile is to deliver value to customers faster, but this is not mandated by any prescriptive process.

Employing agile coaches is a great way to train your team and a good agile coach who considers your business needs and tailors their coaching accordingly is gold. A bad agile coach who insists on following a rigid agile methodology and preaches the gospel of “Agile Process and Methodology” can be very damaging when it comes to building maturity in an inexperienced agile team.

So should you choose to adopt agile principles for your project or organisation? I can’t answer that for you, but what I can tell you is this:

The dictionary defines agile as:

1) being able to move quickly and easily


2) Relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans

If you approach agile in the spirit of the first definition, I believe your chances of success are much higher.

Soft Skills Pay the Bills

 by Gareth Jones,
Business Analysts Pty Ltd Practice Manager


At a recent IIBA Professional Day event, a former colleague and respected business analyst and I were talking about the various topics to be presented. Some of his colleagues were only interested in the sessions that catered for the more tangible BA activities, i.e. data modelling, process elicitation and so on, whilst he was focusing more on the mindfulness and soft skill techniques. We both agreed, that whilst the tangible techniques are necessary for all BAs to learn, it is the underlying competencies that will differentiate between success and failure.

Much like the tangible BA techniques, there are a raft of underlying competencies to get our heads around. Each of which require their own individual focus and continuous improvement approach. To give each budding or even seasoned BA a bit of a leg up, I thought I would share some of the key underlying competencies, or soft skills, that I feel are necessary for all BAs to focus on.

 Analytical Thinking: OK, so a no brainer with this one… or is it. “BAs use analytical thinking by rapidly assimilating various types of information (for example diagrams, stakeholder concerns, customer feedback, schematics, user guides, and spreadsheets), and identifying which are relevant” IIBA BABVOK v3. We are presented a topic, problem, or statement (see one liner here), and from this we collaborate with a number of people to determine the most adequate solution to address a business need. Without structuring our thought, applying traceability to our analysis, and interacting with people with various perspectives, we would struggle to form any trustworthy insight. To do this effectively we must learn new concepts, think outside of the face value of the problem drawing from past experiences and our own research, consider people, process and technology impacts, trace symptoms to root causes to problem solve, and reiterate this to various stakeholder groups in a level that is relevant to their interests. Simples!

Trustworthiness: Transparency breeds trust! The aim for every BA should be to become a trusted advisor. By this I mean, those that the BA works with and supports will take the information presented by the BA with an increasing level trust, to a point where it is accepted as verbatim (trusted). This requires the BA to be extremely diligent in the analysis they do and the perspectives they consider, it is hard work. But the flip side is that it provides a great platform for the BA to display the leadership often necessary to keep projects and initiatives on the right path.

In addition to this level of trustworthiness, BAs are often in a position where they are eliciting information from stakeholders that they may not want shared or linked back to them. In these cases, the BA must develop a strong level of trust with the individual stakeholder to elicit the correct information, and then be able to present this to other stakeholders in an objective manor that enables informed business decision making without having to disclose the source.

 Adaptability: Change is a constant. It is no coincidence that the IIBA speaks of both individual adaptability and adaptive project approaches. As organisations embrace adaptive or agile delivery models, changing requirements and priorities, as well as competing initiatives, will mean the BA will often needs to pick up a new requirement and drop one which they may have applied a good deal of thought to. Additionally, as agile uncovers information in an iterative process, what we think we ‘know’ may not turn out to be what we deliver in the end. Finally, each team and each initiative are unique, so what may work for one may not work for another. All of the above adds a little extra pressure on the BA to be across the change and prepared enough to help drive it and, in some situations, comfortable with not knowing all the detail.

The requirements we specify will be open to scrutiny, regarding feasibility, level of detail and granularity etc. This is only to achieve the right outcome, and we should never personalize this. Given each of our outputs as BAs are typically another’s inputs, we need to adapt our approach to suit the team and the level of detail they need for delivery. Requirements were never owned by the BA, we were only ever a temporary custodian of them. We need to maintain that focus to ensure the best requirement is delivered for the team, not just the one that we worked on.

 Facilitation: Don’t imagine them naked, I am not sure if that has ever worked. And forget ‘Practice Makes Perfect’, perfection doesn’t exist. ‘Persistence Beats Resistance’, this is something you can apply as it works both internally and externally. Cast your minds back to school where you had to deliver a presentation to your classmates. The majority of people were so nervous, their hands were shaking, and their voice would quiver. Those that did nail it were often met with congratulations rather than jeering as regardless of whether you were cool, a dweeb, or otherwise, everyone knows how scary those presentations were.

Well, if you’re a BA or want to be, standing up in front of people and guiding discussions and teams is ‘Par for the Course’. So if internally, this scares you, the go out and do it anyway. Persist. Look at programs like Toastmasters to get comfortable with the notion of public speaking. Lead a discussion at your next BA Forum. Write a blog for industry and present the information in a public setting. You need to persist to overcome your internal resistance!

This also gives you a platform to work on your communication skills, both verbal and non-verbal. Building the comfort in standing in front of people will give you the head space to focus on voice projection, body language, and so on.

 Leadership and Influencing: We play a pivotal role in business improvement, own it! Whilst we down own the requirements, and never have, we do guide stakeholders through the analytical process to ensure they have the right level of understanding to aid in key decision making. This may involve motivating stakeholders to take ownership in their part of the initiative by ensuring they understand their role and are provided with the necessary support to fulfill it successfully. This goes from the end user right up to the C Level execs. If we take pride in the delivery of successful outcomes, then we must focus attention on the key stakeholders necessary for the delivery of said outcomes. Whether you stand at the front and direct, or at the back and guide, will be determined by the environment and situation. But if the outcomes are at risk, we must take a level of responsibility in ensuring each stakeholder is aware, have traceability in our analysis to identify this and clarify this risk objectively, and detail what can be done to address this.

Teamwork: If they can’t work with you, they won’t work with you. This does tie back to adaptability in some way as how we accept changes will impact how others will approach us in future. But it is more than putting on a smile in the face of change or ambiguity. Business, and particularly IT is the most diverse industry in the world. We work with people from all over, with varying levels of experience. And as BAs, we play a pivotal role in how productively that team works together. Working collaboratively, being open to different points of view, being considerate when providing feedback, remaining objective in our analysis and depersonalizing the requirements. All of these will assist us in working with the different stakeholders on a day to day basis. But when the pressure builds, the deadlines approach, and the change is still constant, we must remember that our reactions can have a positive or detrimental impact on the team. Although work is very important to us, it is just that, work. We are delivering business improvements. We are not in the business of saving lives; we are in the business of saving or generating money. That isn’t to diminish the importance of what we do, but we must remain objective, take challenges it in our stride, keep calm and carry on.

The Gentle Art of Facilitation

by Gareth Jones,

Business Analysts Pty Ltd Consultant


Having been a BA for well over 10 years now, and having facilitated session in various situations, I feel that one of my strengths is facilitation. Whether this be workshops, training sessions, interviews, ‘negotiations’, I feel accomplished in most if not all of these facets. As so, on a recent need to facilitate a large group I approached it in my usual way expecting the usual result…Enter complacency.


On this particular occasion, I had in the room a number of brilliant people. Brilliant not just in the sense of personality but most definitely in capability. At the same time, I had a number of people in the room that were fresh to business analysis and as so, in the very early part of their learning journey.


My room was prepped. The materials were out. Everything was going according to plan. And so, after getting to know some of the early participants as they entered, I thought it best to get my presentation up and ready prior to the scheduled doors open. Enter problem number one, the projector was broken. I quickly asked facilities for assistance to which they informed me that they are aware of the problem and have left a spare projector under the table. Problem #2 – the backup projector was also broken. As I fluffed around trying to get this to work to no avail and was informed that the main projector would be broken for the first half of the day, I decided to push on minus the projection as I had printed copies the material for all participants (always have a backup!). This was not ideal but was sufficient enough to enable me to commence and for them to follow. However, we had lost some time already, and this was a slower process to follow.


The discussions were broad in view and varied in depth. I love to let discussions continue as this is where the interesting perspectives come from, and it also distracted the participants from some of the technical difficulties. Just after lunch the technical difficulties were finally resolved and we continued the day all be it a little behind. I was conscious of this but had 3 other days to catch up. I adjusted lunch time lengths slightly to cater for this.

 Day 2: More great discussions, more strong personalities, exercises that enabled team members to collaborate (yay), but the time lost on day 1 was creeping in to day 2. The agenda was out so I had to rearrange the exercises so larger exercises were not being started at the end of the day.


Day 3: I knew I was in a bit of trouble. However, we were also at the most important part of the session, so I couldn’t ‘rush’ through any of this. We finished the day 3 a number of key components behind and with one day to go (this was going to be tight, yikes!).


Day 4: Make or break. I had never been this behind. I had to adapt, and I needed a plan. We had agreed on day 3 to start earlier and finish slightly later if needs be (though some participants needed to leave at the previously specified time).









I got in very early to ensure the room had been re-set to reduce and lag time between exercise suggestion and commencement. All materials were in front of the participants, we had sweets (the important part of course) water etc. I had set a new agenda and communicated this out to the group at the start of the day. It included topics, exercises and then scheduled breaks. I allocated specific question time for the group to ensure questions were not being asked about information yet to be covered. Session by session we moved back on track. The group was more focused, more engaged, and got more out of the day. We made it!


Why am I sharing this? Facilitation is not a set and forget activity. And through everyday activity and a little complacency, I was reminded of this. So, as the last point below will attest, I wanted to learn from it and by sharing, maybe help someone avoid this situation. For me facilitation comes down to 6 main points. The T’s and C’s if you will.


Time Management vs outcomes: This is where facilitation can difficult. If you have a multitude of things to cover in your agenda, and a constrained amount of time you can ensure you meet all the items, but it may come at the cost of the quality of the session. Facilitation is about enabling and guiding a discussion, not lecturing or dictating. Don’t overload your agenda!


Communication: Communicating at the start of each session what needs to be covered, why we are covering it, and what we are then to do once it is finished. I.E. this morning we will focus on Customer Journey Mapping after which time we will break for morning tea.  Ensuring the participants know what needs to be covered, the time allocated to doing so, and the benefit for staying focused works brilliantly.


Control: Control is much like the accelerator pedal. You like to maintain a constant gentle approach, but sometimes it is safer to back off whilst other times it is necessary to power through. Control is very much linked to Time Management vs Outcomes. If you are not going to meet your agenda and must cover those items, you will need to implement stronger control measures. In my case it was more strict timeboxed activities, halting questions until allocated times, and achieving outcomes before scheduled breaks. If I ran the entire session this way, we would have finished early, the participants would have had low satisfaction, and the outcomes of learning would not have been achieved. If I had adjusted my control measures early, but with less severity, we would have maintained a constant pace throughout.


Confidence: Confidence in facilitation is key. If you are uncomfortable with leading groups and presenting, facilitating discussions will always be difficult. You build confidence through practice and preparation. Preparation eases the mind and gives you a plan, practice makes perfect. So always nominate for opportunities to stand-up in front of groups. The reward outweighs the nerves – back yourself!


Continuous Improvement: Always take the time to reflect, adjust and improve. There will  be times where something hits you out of left field, but learning from those times so you can react better the next time, is where the value lies in it for the facilitator.


To find out more about what’s happening in the world of Business Analysis follow us on LinkedIn