This event is history, please check out the list of upcoming seminars
|FREE BOOK for all participants:|
This programme is spread over 2 days, from 9h30 till 17h30, with a buffet lunch around 12h30. Workshop leader James Robertson will already be present from 9h00 to answer your questions and talk about your specific business analysis, requirements and/or innovation problems if you want this.
James Robertson is a consultant, teacher, author, project leader whose area of concern is the requirements for products, and the contribution that good requirements make to successful projects. His work in the area of business analysis and requirements gathering is valued by clients around the world. Along with his advice and experience, you get the "Business Analysis & Leadership" book free with your participation.
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.
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.
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 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.
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:
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.
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.