Mastering Business Analysis

Mastering Business Analysis

During this workshop, James Robertson teaches you the craft of business analysis

10-11 October 2013 (10-18h)
Location: Golden Tulip Brussels Airport (Diegem)
Presented in English by
Price: 1450 EUR (excl. 21% VAT)
Register Now » AGENDA » SPEAKERS »

This event is history, please check out the NEXT SESSION

Check out our related open workshops:

Check out our related in-house workshops:

Full Programme:
9.30h - 10.00h
Registration, coffee/tea and croissants
Registration (only first day)
Start of each workshop day

This programme is spread over 2 days, from 10h00 till 18h00, with a buffet lunch around 13h00. Workshop leader James Robertson will already be present from 9h30 to answer your questions and talk about your specific business analysis, requirements and/or innovation problems if you want this.

Business Analysis - what are we trying to do ?

Business analysis is about improving your business. To do this, the business analyst studies the problem space, models it and establishes the difference between the business as it is, and as it should be (from as-is to to-be).

The business analyst employs systems thinking and abstraction to see past the technological bias of the current way of doing things, to see the essence of the business - what should be happening - and to deliver, in alignment with management's goals, a model of the desired future state of the business.

Project Inception

Inception sets the foundation for the project. It makes use of the Business Model Canvas (with acknowledgement to Alex Osterwalder and Yves Pigneur) to ensure that the project provides an improvement to the business, and contributes directly to the organisation’s goals.

The right result can only come if the project is solving the right problem. By defining the value proposition, how that value is to be delivered, the customer/user segments to whom it is to be delivered to, and several other factors, the Inception activity ensures that the project is worthwhile and will provide continuing value.

We also look at some of the more conventional project inception models such as SWOT, ALUo, and PESTLE.

Business Reconnaissance

Many projects suffer from scope problems. Either the scope is set too small in the beginning and the project suffers scope creep later, or it is an inappropriate scope and the project delivers the wrong product. Sometimes the scope is too large and resources are wasted. In this section we set down how to determine the scope of the work to be studied and improved.

The resulting context model defines the scope of the problem to be solved by defining the interfaces between the problem and the outside world. Once this problem space/business area has been defined, the business analysis study can proceed confident that it will solve the right problem.

Additionally, we demonstrate how this context model can be used to measure the size of the business area and estimate the necessary effort.

Modelling the Business

Modelling is the core of the business analysis activity. The business analyst uses a variety of modellingtools to arrive at a precise and agreed understanding of the business. Firstly, business events are used as the optimal way of partitioning the problem space. Business events are significant happenings outside the business to which the business responds. These are prioritised and the response to each event is modelled as an end-to-end process, giving the analyst the advantage of seeing the big picture, as well as finding more and better opportunities for process improvement.

We teach a variety of models (business analysts should be able to select whichever is most appropriate) to graphically represent the business processes. UML and BPMN models are prominent, but we also teach alternative ways of modelling, each having its own advantages. Data flow models and scenarios are "business friendly" ways to show a process. Data models show the information used by the business — by discovering the stored information, the business analyst uncovers more of the business policy.

Finding the Solution

The solution — the real solution — is not just a piece of software. Instead the real solution is the future state of the business. The software is only a part of the solution; the real (and beneficial) challenge is to transform the business into something better. We use several techniques:

  • Innovation means looking at the problem in a fresh way. The innovative business analyst finds better processes, systems, products and services that make the business function more effectively. Innovation is necessary — if there is no innovation, there is no advancement from the previous state of the business.
  • Systems thinking means looking at the business as a whole, not just one small part of it, or at one business user and his software system. The systemic-thinking analyst is concerned with finding a solution that suits the whole of the enterprise, and does not cause unexpected detrimental effects of any changes.
Getting Approval

Having the best solution is not enough — you have to convince others. In this section we show you how the persuasive business analyst communicates with the various stakeholders to ensure that everybody has a clear understanding and to win them over to the proposed solution.

Additionally, the business analyst frequently has to facilitate workshops, and to use communication skills to convince stakeholders of the real problem, and to bring sometimes disparate viewpoints to a consensus.

Ongoing Business Analysis

The role of the business analyst is evolving; it is moving away from the narrow role of a requirements writer to a wider range of responsibilities. Today’s business analyst must consider the enterprise as a whole, and whether his or her project is aligning with the rest of the projects in the enterprise, and whether the project is contributing to enterprise-wide goals.

The business analyst is the person best placed to maintain the cognitive thread of requirements as they affect various parts of the organisation. Knowledge gained by one project team must be distributed so that others can benefit, and knowledge from previous projects gathered to avoid duplication of functionality and systems.

We also briefly look at how the products of business analysis can be used as input to project management tasks. After all, if business knowledge and requirements are the foundation for the project, it stands to reason that a project manager should use the business analysis deliverables as the basis for management.

End of each workshop day

Questions about this ? Interested but you can't attend ? Send us an email !