« 22 Ways to Create Compelling Content When You Don’t Have a ClueFive around the web #14 »

BA Development Day 2011

I went to the NZ IIBA BA Development Day last week. It was worthwhile and I would recommend it to any business analyst in New Zealand wanting to further their career.

This one-day event was broken up into 3 streams: Equip, Evolve, Enable.

  • Equip: Foundation Skills for BAs
  • Evolve: Business Change for the Organisation
  • Enable: Take your Career Forward

I was late in registering and was unable to sign up for any of the workshops. Here is a summary of the presentations I saw.

Today’s Business Analyst: Learning, Adapting, Delivering Value

Mary Gorman was the keynote speaker. She spoke about how today’s business analysts need to be able to adapt to deliver value to the organisations they work for. Business analysts need to focus on the goal of the business rather than focusing on the role of business analysis.

From BA to BA Lead and Beyond

Deanna Hughes talked about how many business analysts do not take control of their career. Without knowing what they want to do how can they understand their own development needs? “It's too easy to work in an area of expertise and discover you're not an expert after five years.”

Presenting Better Business Cases

Helen Chesterman talked about how business cases are arguments, not documents.

Sponsors are emotional beings and sometimes make decisions that go against the recommendations in a business case. This can be because the sponsor’s values and the organisation’s values are often not included in a business case.

Business analysts often feel uneasy about being emotion into the workplace, but emotion brings value to the company. Business cases need to include, with the facts, ties to the company’s vision. This adds emotion to the case, making it easier for the sponsor to align the business case with their values.

A traditional business case is factually based, including the estimated cost of implementation, and there turn on investment, and the risks of delivering and of not delivering, and the recommendation. It's a logical argument. It is missing the elevator pitch.

The Enterprise Business Analyst is a must have for any progressive organisation

Bruce Anderson spoke about the value of a business analyst focusing on the enterprise provides to an organisation.


  • Constantly considers the organisation view.
  • Can communicate at all levels.
  • Are resourceful in information gathering. This is necessary to know what's really going on. Fact-finding is needed to get information from business unit leaders.
  • Challenge the current paradigm and understanding the impacts. For example, policy can change from pushing to market to allowing the market to pull.
  • Help drive change and instigates change based on understanding of the business needs.
  • Deliver an appropriate level of business modelling, using whatever is appropriate for the organisation. Detailed models may come later.
  • Understand the skill sets required to support the business processes.
  • Sit above, but feed into the detailed project level. They are not involved in single projects.
  • Are an important link into the Business Analysts. A BA needs the information at the organisation level from the enterprise BA. The enterprise BA needs to know from the BA what is happening at the “coalface”.
  • Has enough technical understanding to “be dangerous”. Architects handle the technology. The CEO wants to know about their business.

An enterprise BA makes the CEO look good by feeding the right information.

The Software Development Industrial Revolution and the Role of the Business Analyst - Return of the King

Craig McLean provided a demo of Aviarc DrawingBoard, a new software development tool to create working prototypes.

Business Rules and Data Requirements: Analysing in Tandem for Success

Mary Gorman talked about how understanding just the business rules or understanding the data is limiting.

Different types of rules:

  • Term rule - a glossary definition. These help constrain our understanding. These definitions are not casual definitions.
  • Fact rule - can be drawn as a relationship between two entities.
  • Data attributes - the fact rule may provide the information about the data.
  • Constraint rule - helps understand if there is some localisation of a rule, if it is specific to current focus. For example an expiration date on a gift card.
  • Derivation rule - a calculated rule derived by data. For example a card expiration date may depend on an activation date.
  • Data attribute rules – define how the data will be stored, its size, whether the attribute is optional, what values are permitted. Business analysts need to know early how these will be enforced because it will constrain the design.

Categorisation helps us see if we are missing some rules, and if they are balanced.

All rules are not equal. Analysts do not have time to model the world. Analysts need to understand which policies have the higher priority to prioritise work.

Moving from Requirements Analysis to Business Analysis

John Barris talked about how business analysis is all about understanding the business for the purpose of changing it. Requirements analysis is just a part of this. Analysts need to move from focusing on requirements to being business change specific.

The IIBA has educated BAs as to what a BA is. We need to be able to prove the value of BAs to others. Focusing on business instead of features is focusing on the overall outcome. To do this, BAs need to understand the business to understand the desired outcome.

We need to move from a requirements artefact/document focus to a business focused change. These artefacts can constrain the real requirements.
We need to change from writing documents to solving problems. Business-centric change is impact, risks, and results focused. A builder will talk about what the new kitchen will be like, not the specific requirements.

How to evolve your skills to be a business change advisor.

  • Never ask “what do you want?” unless you want to be a glorified minute taker.
  • Use business architecture.
  • Think business change enabled by IT, not IT change.
  • Assess your current state based on the outcomes required, not by assessing the entire work domain.
  • Become the business change specialist and advisor. Focusing on outcome instead of territory improves your reputation.
  • Up skill on business success.
  • Understand what a healthy business looks like.
By Brian Logan   Fri 18-Nov-2011

No feedback yet

Form is loading...