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

Linking Process and Data

by Vivek  Venkatraman,

Business Analysts Pty Ltd Consultant


I would like to discuss the importance of understanding the link between process and data while performing business analysis. Process and data are the fundamental elements of any business. It is critical to understand how they are linked to understand the product or service delivery because almost every business process has data linked to or flowing through it. Understanding the linkage helps gain better understanding of new domains and/or complex processes and helps to elicit requirements more effectively. It also helps uncover essential processes or links that may otherwise be overlooked. Insufficient understanding of the linkage between process and data might lead to incorrect and or incomplete requirements.


Identifying the linkage pattern can be quite useful when:

  • creating a new business process
  • analysing an existing process to understand the overall business process
  • understanding the terminologies of the existing business process
  • creating new data models from process flows
  • defining epics and user stories
  • writing effective acceptance criteria for user stories


There are a few steps which can be followed to help understand the linkage between process and data. Following steps can be followed for analysing existing business process to understand the business:

  • Begin with the process flow diagram to understand the sequence of tasks in a process.
  • Identify the data elements that passes through every task in a process.
  • Use these data elements to understand more about the data models and how it links back to different tasks in the process.
  • An in-depth understanding of the data model would help identify other processes that may relate to the current process.
  • Understanding the business processes that are related or linked to the current process would help gain a holistic view of the product/application.


Creating a new process to a level of detail requires an in-depth understanding of the process and data flows. This involves asking a lot of questions while charting out the business process flow diagrams and this is an iterative process. As we gain better understanding of the process and data, the quality of questions and the level of details would significantly improve.

  • From the initial elicitation information available, create a high-level process flow diagram.
  • Within each of the tasks, determine what data would flow through it.
  • From the identified data, create data models by liaising with the stakeholders.
  • This is an iterative process and as we gain better and better understanding of the data and process models, more questions would pop up till we are satisfied with the level of detail in the process flow diagram.

Later, I will discuss with examples on how the quality of questions would improve as we understand process and data together.

A few techniques can be used for this purpose:

  • The question that we need to ask to identify data when looking at the process flow is – “what data flows through this task and how does it relate to my process?”
  • From the data modelling, we can ask questions like “is this data used in any other task in the process and if so, how does is it used?”
  • For understanding the data and in turn the application as a whole, we can ask “what are the other processes this data is used in?”


Leveraging the English language

  • A well written process task is written in “Verb Adjective Noun” format.
  • The “Adjective Noun” in the process would help identify the data element which could then be used to understand the data.


I will discuss a couple of examples on how understanding data and process as a whole can help analyse or create better business processes.

An example of a customer order – Designing a new process to allow the user to create, edit and submit an order.  The system validates the order and confirms the order.


The process flow in the previous slide is quite simple but understanding the data might help understand the underlying business objective for writing better requirements. A few questions that would then help model the data are

  • What is the customer trying to order?
  • What are the attributes of a customer order?
  • Are the attributes linked to any other data source and what is the relationship?
  • If there is a relationship with other data elements, are those elements linked to the current process?

We can then create a data model once we have the above questions answered and relationships defined



A better understanding of process and data helps ask better questions which directly benefits in writing better requirements. It is by our understanding of process and data that we are able to ask the below questions:

  • Does the customer have a registered account and if not, does it have to be linked?
  • Does the asset exist and if so, do we have all the necessary details?
  • Has the validation for the asset and account been done already or does it have to be done as part of the order validation?

These are very valuables questions that help create the process flow in a detail that we need. Failing to get these questions answered may lead to missing details from the process flow diagrams. Understanding the process and data together thus helps writing better requirements, user stories and acceptance criteria.

Another example I would like to discuss is that of an Income process where we only have a high-level process flow.


The above high-level process doesn’t help understanding the entire business process. Let us try to use some techniques we discussed earlier to help understand the business process.

  • Looking at the process flow, let’s try to identify the data by using the “Verb Adjective Noun” technique.
  • Using this technique, “Income Announcement” will have to be the data for the first task.
  • Similarly, “Client Holdings” and “Customer Payment” should have to be the data for the subsequent tasks.

Let’s look at the data models to gain a better understanding



From the above diagram, it is evident that

  • For an “Announcement” to exist, there needs to be an “Asset”.
  • To gain better understanding of the “Capture Income Announcement” task, ask “how do we get the payable and record date information” and if there is a process for that, understand that process as well.
  • For a “Create Customer Payment” task, we can understand from the data that a Payment needs to have an announcement, Asset, Holding and Account.
  • Since we can see that Announcement is created from an Asset and Holding is created from Asset & Account, a payment can be created from the announcement and holding information which is in the previous two tasks.

This linkage between data and process thus helps understand what the business process is and what the outputs of the process are.


From the examples, we can conclude that linking data and process is essential for:

  • In-depth understanding of any business process
  • Understanding new domains quickly
  • Understanding the terminologies used in different domains
  • Developing better requirements
  • Improving quality of user stories and acceptance criteria


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

How do you become a Business Analyst?

by Justin Balina,

Business Analysts Pty Ltd Consultant

A couple of my colleagues have asked me this question and I couldn’t really give them a concrete answer. Later that day, I had time to reflect on the question – how does a person actually become a Business Analyst? Unlike teachers, doctors or architects, there isn’t really a degree in Australia that you can do specifically to become a BA. All the BA’s I’ve met in the past followed fairly different journeys. In this blog, I’ll share my journey to becoming a BA and some interesting stories from current/ex-colleagues too!


My BA journey

When I finished my IT degree, young me already knew that I did not want to be a full time tester. Maybe I was too impatient or just didn’t enjoy doing repetitive tasks. I thought about being a developer so added that to my shortlist. I also wanted to be a Database Admin so I added that too. I didn’t really want to be a Business Analyst as young me thought it wasn’t technical enough aka wasn’t ‘IT’ so I didn’t really apply for BA roles.

Fast forward a few weeks later, and after about 50 job applications – I’ve finally secured my first role as System Administrator! I was really excited as it was my first job out of university! There were heaps of technical systems, techniques and concepts that I needed to learn. It was a mix between a technical and business role and the thing that I really enjoyed was being the conduit between the business and IT. I felt like I was this translator that knew 2 separate languages! The other key thing that I liked in my role was a day was never the same! Every day of the week I had a different task to do! After speaking about it to my manager, he suggested that I consider being a BA as the things I enjoyed doing were in line with what BAs do!

After a year in my first IT job, I decided to move on and work as a Telecommunications Business Analyst for a financial institution. Yes it was tough. It was a learning curve for me but it helped me kick start my BA career!!


BA stories from colleagues

During my short career, I’ve met and worked with a lot of Business Analysts from different specialisations and backgrounds. I was quite surprised to figure out that everyone had a different journey than me.

I worked with a senior BA who finished chemical engineering in university and worked as a lab technician for 10 years before he became a BA. He was originally part of a project as a stakeholder and enjoyed the investigation/requirement activities with in business analysis, so he switched careers!

I’ve worked alongside a call centre representative who was in their role for 2 years working as an SME for a project I was part of. She really enjoyed the various project activities and challenges. For her, there was never a dull day when doing project work and we encouraged her to start her career as a BA. A year later and after doing a BA training course, the company decided to give her a promotion as a Junior BA to kick start her career!

I also had a colleague who, with 15 years of testing experience behind him, decided to move to become a BA. He said that BAs usually have multiple roles behind that job title. BAs can also be Project Managers, Testers, Data Analysts, Change Manager or even Network Engineers on some projects. It was that flexibility and ‘wearing many hats’ that attracted him to shift from the testing.


Some Guidance 

Some of the things I and my BA colleagues believe will help a person start a career in business analysis, or transition their career in this direction are:

  • Building a network – if you want to be a BA, talk to other BAs. Learn from them and build the chance of opportunities through this network.
  • Training – Business Analysis is not a cookie cutter role, but there are definitely some great courses that will get you well on your way. Business Analysts Pty Ltd provide amazing courses that have helped people transition into BA roles.
  • Become a part of the industry. The International Institute of Business Analysis (IIBA) provides a wealth of information, public events, and networks. If being a BA is what you want to do, connecting with an organisation focused on it is a great start.


To sum it up, everyone has different adventures they have to go through to become a BA. Being a BA doesn’t mean that you have a list of set tasks, but doing whatever is needed for the success of the project.

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

Bridging the Gap Between IT & OT Security

by Henry Elisher,

Business Analysts Pty Ltd Consultant


Many industrial organisations still view IT (Information Technology) and OT (Operational Technology) security as unique issues to be addressed in isolation. Even though IT & OT environments are foundationally and functionally different, the need for convergence between the two in the new world of increased and pervasive cyber risk can no longer be labelled as a consideration or option, convergence between the two spheres needs to be a mission critical objective.

A recent report by the World Economic Forum identified cyberattacks on critical infrastructure and strategic industrial assets as now being one of the top five global risks. Knowing that, it beckons reason that the typical view many industrial companies take when it comes to the security of their IT & OT spheres is that each still pose their own unique set of challenges which need to be handled in isolation. The reasoning being that the differing concerns and practices of each are justification enough to warrant a siloed approach to security.

Siloed approaches in themselves mean a disparate and non-cohesive structure. Gaps in the cyber defence of organisations as a result from the lack of cohesion are inevitable.

Attackers understand where the vulnerabilities lie and have the expertise to exploit the security gaps between IT & OT technologies. They understand full well that those responsible for organisational cyber defence can have different priorities and practices. Specifically, within the business there can be differing, functional requirements, different working cultures and risk appetites. It’s no surprise then that these environments also have the propensity to be dissimilar and divergent when it comes to their own security requirements.

In industrial organisations security has traditionally been divided across three silos, IT security, OT security and additionally, physical security (plant security and system integrity). This divide has made it difficult for operators to identify and respond to incidents when they’ve occurred. Coupled with the historical aspect of siloed priorities in terms of security requirements, with IT security focusing primarily on confidentiality and OT security on integrity and availability, modern day operations have been placed under immense pressure and scrutiny. New challenges have now arisen from the complexities formed out of elaborate IT and OT infrastructures, which typically include thousands of devices, all being connected via the IIoT (Industrial Internet of Things). These complexities have changed the game yet again, making it even more difficult to detect, investigate and remediate cyber security threats and incidents.

From the perspective of critical infrastructure providers, the potential societal consequences from a cyberattack requires that their operations take place in a certain manner. The priority of an operator, such as in the electricity market, is to ensure the safe and reliable delivery of that service, it’s their primary concern. Having this as their key responsibility in turn leads to other differences across areas, from component lifetimes and patching practices to audit timelines and additional functions. Reliability of service in the electricity sector is of utmost importance and becomes an overarching goal.

These security challenges are also often exacerbated by the communication barriers between the two groups & the fact that they quite likely have different reporting and governance structures.

This lack of coordination and communication becomes especially risky in times of emergency where the organisation has been the target of a cyber-attack and needs to formulate a cohesive, comprehensive response to, or in fact recover from, a cyber incident.

Protection of the various spheres in an organisation is obligatory. However, in order to protect a complex surface attack, the way many industrial organisations are acting recently has been to devise ways to converge their IT & OT working groups. A more than onerous task in itself as each group has a tendency to believe that security vulnerabilities are inheritedby them usually due the blatant ignorance of the other. This finger pointing tends to entrench an eternal battle that centres on each domain playing a defensive roll and devising mitigation strategies against risks posed by the other side. The issue is of course not internal. However, the area of conflict that exists between the two groups is just the space required for attackers to utilise and exploit it.

The difference in the IT & OT environments highlights one of two fundamental barriers that need to be overcome. IT environments are dynamic and IT systems are often patched, upgraded and replaced regularly. IT personnel have their concerns centred on the confidentiality of data, data integrity and availability. As knowledgeable as IT staff may be in their fields and as up to date they may be on trends & threats, their propensity to operate outside their sphere is limited. IT personnel are often lacklustre and typically unfamiliar with OT networks and control systems.


OT staff work in a world where stability, reliability and safety are the top priorities. Their remit is to maintain the stability of complex and sensitive environments, quiet often with legacy systems that have not been upgraded in decades.

This inherent environment difference due to business priorities and culture can be pervasive and quite often divisive without pointed remediation.

Also, the different technologies utilised within each domain has the propensity to cause unnecessary tension. Within the realm of IT, personnel are used to working with the latest hardware and software, including of course the very best security available to protect their network. Their time is spent patching, upgrading and replacing systems. Whilst IT has ownership of their ‘sphere’ the disparity between what they see as their world and the responsibility & accountability they should have is altogether different.

OT on the other hand has the propensity to function with legacy technologies, many of which pre-date the internet era. Common features of the IT environment are lost in the OT world, and the lack of basic security controls such as authentication and encryption are often disregarded in terms of importance to the ire of IT who in turn can be both incredulous and dismissive in their contempt.

C-level support is the primary step to being able to instigate IT/OT convergence, and ultimately, bring about the success of forming a harmonious unification of practices in IT & OT. In order to unify strategy, security thinking and practices, the objective of organisations is to create a culture of collaboration between the disciplines.

Despite the divide there are organisations that have successfully facilitated deep collaboration between IT & OT, the importance and driving factor of which rested within the remit of the C-suite and the support provided.

In order to facilitate convergence some organisations have created C-level roles to bridge the gap between the two. For example, it is not uncommon to known see a Chief Digital Officer whose role it is to be bridge the divide between IT & OT through the merging of culture, and by the establishment of incident management responsiveness that spans both groups.

To make this happen, more and more organisations are taking senior, experienced engineers from OT units, and assigning them to support incident response within the Security Operations Centre (SOC). This in itself helps to create an environment where people, knowledge, processes and technologies straddle and work to unify the IT/OT fence.

What consolidating IT & OT cybersecurity efforts achieves first and foremost is that it clarifies responsibilities, but more importantly, moves to eliminate security gaps. It also ensures that there is a consistency of security levels across the entire organisation and leads to reductions in the overall cyber risk. The key objectives set within this form of consolidation are therefore to entrench a shared responsibility for end-to-end cybersecurity, ensure global corporate governance of all cybersecurity policies, procedures, technologies and guidelines, and supports global visibility and management of all cyber assets, vulnerabilities and threats.

The elimination of the IT & OT silos is critical for the goal of reducing risk. The aim should be for the creation of a single digital security and risk management function/structure, with a direct report into IT but having a responsibility that spans all of the requirements for IT & OT security.

In order to be effective therefore, a converged IT-OT cybersecurity program needs to ensure a centralised oversight of the entire organisation’s cyber security efforts and additionally, have the authority invested in the group to be able to implement key objectives. Implementation of key objectives can be through formal organisational changes or via virtual teams that work in IT groups, OT groups, and security operation centres (SOC’s). The integration of third parties with specific capabilities should also be a consideration in order to address the ongoing shortages in cybersecurity professionals.

Any organisation going through changes will inevitably encounter varying degrees of resistance. Even though the benefits derived from the convergence of IT/OT cyber security strategies may seem to be obvious, the transition is likely to be arduous due to personnel implacability and the complexity of two stand-alone operating functions being subsumed into one cohesive structure.

Some of the initiatives that companies utilise to ease the transitions are:

  • Establish cross-trained site teams in order to handle routine security hygiene
  • Create a global support network within IT & OT experts in order to deal with more complex cyber issues such as malware intrusions and anomalous behaviour
  • Update key IT/OT cybersecurity processes from vulnerability management to incident management
  • Ensure compliance with corporate policies
  • Integrate cybersecurity technology to enable coordinated cybersecurity management

Also, there needs to be the understanding that whilst the tools required by IT & OT might need to be different, they do in themselves need to be compatible and fully integrated within key areas such as asset inventory, endpoint and network protection, security monitoring & reporting, and secure remote access.

Beyond the technical challenges, posed inherent cultural issues also need to be addressed. Quite commonly distrust between the two groups may be the biggest hurdle to overcome on its own. Methods that might aid in the easing of transition in this regard might include workshops to reconcile perspectives, and the cross-pollination of groups in order to build bridges and re-establish trust between the groups.

The challenges posed in bridging the gap between IT & OT security exist, are real, but, are not insurmountable. As both IT & OT infrastructures increase in complexity and their dependencies increase accordingly, ownership of cyber security issues cannot take place in isolation. A siloed approach will not work in environments of interdependency because aside from the internal disruption and inefficiencies of this viewpoint, the gaps and ‘grey’ area of ownership create the opportunity for attackers to take advantage.

Convergence of the IT & OT security realms needs to have C-level support and a framework set by which security for both resides in a single location under a single remit. Once a cohesive plan is in place and once collaboration occurs between both domains then effective strategies for mitigation in a holistic sense can be made possible.


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



Building Cyber Resilience – The New Challenge For Business Leaders

by Henry Elisher,

Business Analysts Pty Ltd Consultant


Cyber threats can and will affect all industries. The most current wave of digital transformation to hit the global economy has brought to us the IOT, (Internet of Things), which means now that nearly all organisations operate in a digitally interconnected ecosystem.  Cyber security can therefore no longer be regarded as an individualised problem that can be fought at the digital and physical frontier of a single organisation. The cyber security vulnerability of anyone you do business with can now also be your vulnerability also, you too can inherit the risk.  

Successful cyber-attacks on critical infrastructure have the potential to immediately threaten both national security and economic stability. The degree and nature of attacks now have the potential to cripple not just industries, but can also do untold damage to nations, as dependencies have risen through interconnectedness. One only needs to look at the NoTPetya cyber-attack on the Ukraine in 2017 to witness the ferocity, scale and damage of a cyber event with magnitude[i]. The scale and potential to create damage and harm is not lost on cyber threat actors either. Criminal groups, hacktivists with the aim of causing civil unrest, and even state-sponsored groups performing espionage activities, all understand the vulnerabilities of operating in an interconnected and interdependent environment where the consequences of a cyber-attack can easily cascade from one to many in an instant. The Ukrainian event will not be the last, and even though the degrees of attacks may vary it cannot be assumed that anyone is immune.

Combatting and managing this growing risk must now become the onus of business leaders. To understand, identify and build a robust and pervasive cyber resilience culture and further, ensure it is instilled within every person of an organisation means that actions and the activity of knowledge transfer, defence and culture needs to commence from the top down. Board members and chief executives are now obligated to take it upon themselves to proactively formulate strategies and ensure cyber resilience is interwoven into the fabric of their organisation.

The new interconnected world in which organisations operate necessitates leaders to fundamentally shift their mindset in two distinct ways[ii]:

  1. There needs to be the understanding that cyber-risk is a business and ecosystem-wide risk and not simply a component that fits within the remit of IT risk. Cyber risk management decisions must be integrated into all business decisions.
  2. Awareness that managing cyber-risk in an interconnected environment means that leaders need to look well beyond the boundaries of their own houses and understand their broader neighbourhoods of suppliers, customers, competitors, peers and regulators, amongst others[iii].


Knowing what needs to be protected is the first step in addressing the challenges of cyber resilience in a complex and interdependent operational universe.

Organisations usually have interdependent relationships with numerous stakeholders that can span multiple degrees of separation within an organisation. In order to ensure that cyber security and resilience are effectively adopted within the context of business strategy, leaders have the obligation to grasp both the breadth and depth of the connections within their operational sphere.

Being able to produce a logistical map of interconnected stakeholders is also of utmost importance. The identification has to start within the core value chain, specifically, identifying the connected infrastructure, and then, expanding that sphere of reference to the surrounding business ecosystem of suppliers, customers and peers. This then needs to be encapsulated and buttressed by a clear picture of what the extended ecosystemis.

The extended ecosystem is also known as the strategic layer and comprises policy makers, regulators, law enforcement, insurers and standards bodies.

As the digitisation increases so too does the complexity and interdependencies of the network layer, i.e., the computer systems[i] that interact with one another. Coming to an understanding of this layer early in the piece and getting ahead of the development will allow a better insight into obvious cyber vulnerabilities and will highlight how this layer can be utilised as a highway to propagate cyber-attacks, and further, how the effects can easily cascade across the ecosystem.

Understanding the network layer and also working both adeptly and with agility in the strategic layer is critical in becoming cyber resilient. Cyber security and resilience cannot be allowed to simply be regarded in isolation. Leaders must now take it upon themselves to recognise that a lack of security in their broader neighbourhood means that their own cyber integrity has the ability to be undermined. Cooperation is a key aspect to heightening cyber resilience. It is essential between members of a neighbourhood, from oversight bodies to suppliers, customers and employees, that cooperation through all operational spheres needs to take place in order to inform, identify and combat all perceived threats.


How to secure systems that will become increasingly more complex will inevitably be the ongoing challenge for any market. The ever-changing nature of technology and the shifting sands on which both the network layer and strategic layer are founded will mean collaborative and collective efforts will need to be sustained, indefinitely.    

In 2017, to help facilitate board oversight and action in support of organisational cyber resilience, the World Economic Forum (WEC)[i], in collaboration with leading academics, developed 10 overarching principles[ii] for organisational cyber governance. The principles were put in place to assist boards in promoting cyber resilience as a key component of their overall organisational strategy.

The key cyber resilience principles are restated below in this blog. These principles have been lifted exactly as stipulated by the WEC

Principle 1 – Responsibility for cyber resilience – The board as a whole need to take ultimate responsibility for the oversight of cyber risk and resilience. This primary oversight may be delegated to an existing committee or new, dedicated committee.

Principle 2 – Command of the subject – Board members need to receive cyber resilience training upon joining the board and are regularly updated on threats and trends – with advice from independent external experts when requested.

Principle 3 – Accountable Officer – The board ensures that one corporate office is accountable for reporting on the organisations capability to manage cyber resilience and progress in completing cyber resilience goals.

Principle 4 – Integration of cyber resilience – The board ensures that management integrates cyber resilience and cyber risk assessments into the overall business strategy as and enterprise wide risk management, as well as budgeting decisions and resource allocation.

Principle 5 – Risk appetite – The board annually defines and quantifies business risk tolerance relative to cyber resilience and ensures that it is consistent with corporate strategy and risk appetite.

Principle 6 – Risk assessment and reporting The board holds management accountable for reporting a quantified and understandable assessment of cyber risks, threats and events as a standing agenda item during its meetings.

Principle 7 – Resilience plans The board ensures that management supports the officer for cyber resilience by creation, implementation, testing and ongoing cyber resilience plans, which are harmonized across the business.

Principle 8 – Community The board encourages management to collaborate with stakeholders, as relevant and appropriate, in order to ensure systemic cyber resilience.

Principle 9 – Review The board ensures that a formal, independent cyber resilience review of the organisation is carried out annually.

Principle 10 – Effectiveness The board periodically reviews its own performance on implementation of these principles and seeks independent advice for continuous improvement.


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

[I]‘The untold story of NoTPetya, the most devastating cyberattack in history’,accessed 23 APR 2019,

[II]Boston Consulting Group, Whitepaper, accessed 12 APR 2019,’ Building cyberresilience into the electricity ecosystem’,


[III]World Economic Forum, Whitepaper, accessed 15 April 2019, ‘Cyber resilience in the electricity ecosystem: Principles and guidance for boards’,


Confessions of an Agile convert

by Nikesh Parbhoo,

Business Analysts Pty Ltd Consultant




Confessions of an Agile convert

Having to work in an agile environment for the first time can be a daunting challenge, particularly if you’ve done work in waterfall environments for most of your career. Agile is being adopted to a greater degree in IT delivery. You will find that each country, city, industry or client/employer will either be more mature or less mature at effectively applying Agile techniques. Ensure that you understand where you need to operate at in this maturity continuum.

What does it take to make that leap across the chasm into the world of agile?

Firstly, read up on agile as much as you can. The IIBA has the Agile extension to the BABOK which is useful.  Speak to as many professional agile practitioners as possible. Some cities have Agile meetup groups that you can leverage off.           

If you have a decision to make regarding accepting a piece of work in an Agile project, your preparation should give you the confidence to say yes. All your analysis skills developed in your Waterfall life is fully transferable in Agile. Agile is just a method of work – the skills associated with being a business analyst remain the same. Attention to detail, people skills, business acumen and all other good BA skillsets will be to your advantage in any Agile space.

Know your new tools and artefacts

Gant charts, Microsoft project, requirements specification documents and business process management tools/artefacts are some the assets of knowledge you would have built up during your waterfall career. Agile is less structured, and so you need to understand your new paradigm of working and the tools that go with it.

The Atlassian suite (Jira and Confluence) is widely used in agile IT implementation projects.  The good news is that using these tools are intuitive and nota mountain to overcome to become productive quickly.

‘Let go’ of your artefacts

Typical Waterfall BAs have a very close, sometimes emotional relationship with their artefacts, be it the requirements specification document, business process maps, etc. This ownership mentality is something that must loosen up in an Agile environment where the team owns the artefacts through co-creation and collaboration.

The BA takes primary accountability for an agile artefact (like a User Story), but it is ultimately a product of the greater team. Don’t feel like your space is being intruded upon when the product owner or the SMEs make a change to your User Story on Jira.

Agile is more human

Agile offers teams the ability to think and produce value like we do natively as human beings.  We naturally operate on a try-fail-try again basis as humans. Think babies or children and you soon realise that they essentially operate on an agile basis. They are never perfect, but they are constantly trying and eventually get it right. The frustrations that accompany the ‘throw it over the wall’ mentality of Waterfall evaporate quickly in a well-run Agile team. Remember: Fail fast to get to ‘goodenough’ quicker.

Information Crosshairs

For all its goodness, Agile also presents some challenges. Information flow is one of those that Agile cannot necessarily fix. Too much communication, too little absorption by all the relevant stakeholders can lead to rework, distractions and duplication. When important decisions are being made on the fly (which is a strength of agile), it is critical that these get communicated effectively to the team. Use the daily stand-ups to facilitate this.

Get everything into Jira & Confluence

Your agile project is probably using Jira/Confluence as its tool. Ensure that Jira (or any other tool of choice) is the one and only source of truth. A half-baked attempt at using Jira does not help the project move forward, and only serves to intensify the problems associated with information crosshairs.

Jira is great, but Kanban boards can be better 

Tools like Jira are fantastic to keep track of all your user stories. Physical Kanban boards where team members update their stories at daily stand-ups form part of powerful agile rituals that can congeal a team. There is something inherently primitive about having a tactile experience of moving a card to ‘feel’ progress. More so, a physical Kanban board is a prevailing communication tool to sponsors, program managers and similar management stakeholders that have a constant visual report they can access at any point in time.

Physical Kanban boards however, do not work very well when you have distributed teams located across the globe. In these circumstances, a Kanban board can work better for a localised team that is working on a stream within a larger project.

Getting the best people in the room

This concept is not unique to Agile. Having the best people in the room increases your chances of working in any environment. I have found that two key agile roles can have a huge positive effect on the life of a BA in an agile project are:

  • •          The Product Owner:  This person needs to be a strong advocate for the system and should be empowered to make substantial decisions on behalf of the business.  All team members (business analysts included) will turn to the product owner when making critical decisions about the solution.
  • •          The Scrum Master:  A good scrum master should be able to facilitate momentum on the project and clear any obstacles. A good scrum master connects the dots between all project disciplines and overlays this with his/her deep insights about agile practices.

Most importantly … play and have fun

Kids in a playground manufacture fun in a way that might be observed as chaos to an outsider.  An agile project has similar traits. Leave the shackles of your waterfall past behind and embrace a more collaborative (sometimes messy), but ultimately more energetic, adaptable and fun way of working.



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