There are fundamental components that must be included in any business analysis work:
1) Define the problem or opportunity being addressed through drivers and SMART objectives.
2) Determine the required scope of changes through high-level requirements to achieve the objectives.
3) Specify what process and data changes are needed within the scope to deliver the objectives.
2. Analyse the reasons why the fundamental components
of all Business Analysis tools and methods must be the
same
Examine fundamental components of Business Analysis
3. There is a chain of reasoning that leads from the statement of a problem to the implementation of solutions…
POST-IMPLEMENTATION
Business Analysts feed back to the Owner how well their
measure of success has been achieved
Owners
defines measures of success and $targets
…Business Analysts confirm & document
Strategists
determine the strategy to hit the targets
…Business Analysts help do market research, create strategy, challenge &
documentSponsors
establish a Programme that delivers the strategy
…Business Analysts document Programme TOR
and help build the Business Case
Programme Managers
Institute Projects that implement the programme
…Business Analysts document the Project TOR
Project Stakeholders
…Business Analysts specify requirements for
Projects (in the Business Model)
Design Analysts
design solution that satisfies the requirements
…Business Analysts write functional specifications, protect
requirements & document compromises
Project managers
Implement solution
…Business Analysts help with
-Process and data migration
-Cutover planning
-Rollout
Solution Builders & Business
test solution
…Business Analysts ensure tested against requirements
Solution Builders
build solution
…Business Analysts protect requirements & document compromises
Users
Accept solution
…Business Analysts help with
-$MEASURING $BENEFITS $REALISATION
Setting the scene: scope of the Business Analyst role
$Money!
…involving up to 10 groups of people…
4. Stakeholders
Drivers
Objectives Objectives Objectives Objectives Objectives
Drivers Drivers Drivers
Change
Requirements
Change
Requirements
Change
Requirements
Change
Requirements
Change
Requirements
Change Requirements must be assumed to be wrong until they are proved to be right
Stakeholders
5. Change requirements can be for (amongst others)
◦ Processes
◦ Organisation units
◦ Locations
◦ Channel
◦ Data
◦ Applications
◦ Technologies
◦ Non-functionals
…oh – and the valid intersections!!!
6. We need to change how we take orders (process)…
…by the tele-orders team (organisation unit)…
…at our Leeds contact centre (location)…
…by phone or email (channel)
…to capture alternate delivery addresses (data)…
…on the Chordiant system (application)…
…running on the intranet (technology)…
…and make it available 24/7/365 (non-functional).
7.
8. The problems / opportunities that
the business face
The measures and targets that
will enable us to declare the
change project has been
successful
Driver
Project
Objective
Change
Requirement
Business Rule
Addressed as
measured by
Delivered by
Enforces
Definitions of what changes are required
that will affect the measures of success
(objectives) sufficiently for the project to
be declared successful
What rules must be implemented
by the changes specified in the
requirements
Description
9. Problem / opportunity analysis
SMART objectives
Business…
Functional…
Non-functional…
…high level
…mid level
Process model
Process specification
Non-functional specifications
Data model
Attribute specification
…low level
Driver
Project
Objective
Change
Requirement
Business Rule
Addressed as
measured by
Delivered by
Enforces
Specific – there is a precise definition of the objective
Measurable – there are units that the objective will be measured in
Achievable – the measures can be achieved ‘in the real world’
Relevant –this project will actually affect this objective
To-die-for – the project has failed if it does not achieve the
objective
Analysis products
10. Driver
Project
Objective
Change
Requirement
Business Rule
Addressed as
measured by
Delivered by
Enforces
Problems
Opportunities
Threats
Constraints
Agile “product backlog”
7 types of ISEB requirements
6 types if IIBA requirements
Vision
Benefit
Target
Agile “product backlog”
More process and data modelling
than you can shake a stick at
AKA…
12. Problem / opportunity analysis
SMART objectives
EXAMPLE way of documenting…
Driver
Project
Objective
Addressed as
measured by
13. EXAMPLE way of documenting…
Problem / opportunity analysis
SMART objectives
Business…
Functional…
Non-functional…
…high level
…mid level
Driver
Project
Objective
Change
Requirement
Addressed as
measured by
Delivered by
14. EXAMPLE way of documenting…
Problem / opportunity analysis
SMART objectives
Business…
Functional…
Non-functional…
…high level
…mid level
Process model
Process specification
Non-functional specifications
Data model
Attribute specification
…low level
Driver
Project
Objective
Change
Requirement
Business Rule
Addressed as
measured by
Delivered by
Enforces
15. EXAMPLE PROCESS RULES
Conduct
Training
Time to start
Training course
Provide
BA support
Monitor
Analysis
quality
BA requests
support
Analysis Phase
Of Project
concludes
A BA can request one of 4 types of support:
1. Phone or email based query about a specific point
2. Informal review of a project deliverable
3. Formal review of full set of project deliverables
4. Facilitated workshop of how to apply analysis to a specific project
1. In the case of phone or email query about a specific point
the BA poses the question and the training provider will provide guidance for how the technicalities of Business Analysis apply
to the problem
Informal reviews of project deliverables will be done by email and will only discuss the technicalities of Business Analysis in relation
to the document
Formal reviews will involve the BA sending the full set of Analysis deliverables to the training provider who will critique them from a
technical perspective and then deliver the feedback in a one-to-one structured feedback session on the client site
Facilitated workshops will be initiated by the BA - the training provider will supply workshop agenda and prerequisites which the BA
will use to organise the workshop. The training provider will then facilitate the workshop for the project.
Process execution rules
Process dependency rules
1. Who is interacts with process
2. Where they are
3. Availability of process
4. Volumetrics
5. Performance of process
6. Security & Authorisation levels
Non-functional Rules
16. Course
Delegate
Analysis
Deliverable
Attends
Supplies
EXAMPLE DATA RULES
Support Type
Data relationship rules
receives
1. Who is allowed access to the data?
2. How long must this data be kept?
3. How many instances of it must be supported?
Non-Functional Rules
Attributes
1. Name
2. Start Date
3. Course duration
Attributes
1. Name
2. Contact details
Attributes
1. Name
2. Content
3. Review feedback
Attributes
1. Name
2. Description
Course.Start Date
Definition: the date/time the course is scheduled to start
Data type: Numeric
Size: 12
Domain: Datetime
Data rules:
• Format is DD/MM/YYYY HH:MM
• When created must be in the future
• Cannot be a Saturday or Sunday or Bank Holiday
Data content rules
17. There is a chain of reasoning that leads from the statement of a problem to
implemented solutions
It doesn’t matter how you get from problem to solution – what method or approach –
but you will HAVE to…
Define the problem being fixed (drivers)
Define how you will know they have been fixed (objectives)
Define what has to change to achieve objectives (high level requirements)
Define how big the changes have to be to achieve objectives (scope)
Define what process changes are required (process requirements)
Define what data changes are required (data requirements)
18. what factors caused this project to come in to being? Driver analysis
how will you know the project has been successful? smart Objectives
how big is the solution? scope
what applications and technologies will the solution
impact scope
what data will be migrated? scope
where will it be able to do it? scope
where will the solution impact? scope
who is impacted by the solution? scope
What changes will the project make that will deliver the
objectives? high level functional requirements
what processes does the solution cover?
scope & high level functional
requirements
what will the solution be able to do? high level functional requirements
19. what is the process sequence of the solution? process models
who is involved with each process
process models & process non-
functional
what are the rules that each process executes? process logic
what data does each process need to be able to
execute? process logic
how fast will each process be? process non-functional
how many transactions must each be able to perform? process non-functional
where will each process be used? process non-functional
who is allowed to use each process? process non-functional
how are all the different sets of data related to each
other? data model
what needs to be known about each set of data? data attributes
how long will data be kept? data non-functional
how much data will be kept? data non-functional
who can access what data? data non-functional
Editor's Notes
Remember this? We are interested in looking at what this “chain of reasoning” is that the business analyst follows…
There is a chain of reasoning that leads from the sufficient definition of the problem to the sufficient definition of the requirements for the solution.
Break any one link in the chain and the rest of the chain is unsupported: unprovable.
Scope of the BA diagram narrative (from Scope of The BA Role module).
‘Owners’ are those people who can enable a project to proceed or cancel it. They will include budget holders but almost certainly there will be other owners who may or may not be officially recognised as such but who can – if they desire – stop the project. For example, an IT Director might be one owner of a Business project involving a new system if there are IT standards which must be adhered to before a system can go live. These owners need to agree what the change project will accomplish and analysis is needed to define these objectives in terms of what the measures of success will be and – for each measure – the target value that equates to success.
‘Strategists’ will define an approach for achieving the objectives. Analysis is needed to ensure that the strategy is justifiable to the owners. Note that it is very common for an Owner to also be a Strategist! But not all Owners will be Strategists.
‘Sponsors’ will back a programme of change. A programme is defined as a collection of projects. Taken together these projects will deliver the strategy that has been agreed will achieve the objectives. Note that it is very common for an Owner to also be a Sponsor! But not all Owners will be Sponsors. Analysis will be needed to define the Terms of Reference (TOR) for the Programme: the Objectives, Scope and High Level Requirements as a bare minimum.
‘Programme Managers’ will initiate the projects that make up the programme. The same note for Programmes apply to Projects: it is very common for an Owner to also be a Programme Manager! But not all Owners will be Programme Managers. Analysis will be needed to define the Terms of Reference (TOR) for the Programme: the Objectives, Scope and High Level Requirements as a bare minimum.
‘Project stakeholders’ will generate and sign-off requirements for the project. Analysis is required to define the process, data and non-functional requirements.
‘Design analysts’ will take the products of analysis and propose the best solution to meet the requirements (‘best’ being defined as satisfies most requirements). Any compromises required will be mediated by the Business Analyst with all who need to accept the compromise. Note that Design Analysts can be IT analysts for IT components, HR analysts for people and organisation units, and others for other components.
‘Solution Builders’ take the design specifications and construct solutions. Note that these solutions are not constrained to IT components but must all work together to provide the whole solution.
‘Solution builders and Business’ test the solution. The requirements analysis should be used to construct the test plans – especially the user acceptance testing. Note that the Business Analyst should q/a that the UAT does test that the requirements have been met.
‘Project Manager’ will co-ordinate the whole project and implementing the solution, and the Business Analyst (being a subject matter expert on project Objectives, Scope, and Requirements) should be able to contribute significantly to the design of all implementation activity, all the while ensuring that requirements are being met.
In an ideal world, ‘post implementation’ how well the objectives have been met will be fed back to the Owners.
Stakeholders
The first link in the chain is the stakeholders. Identifying the relevant stakeholders is possibly the hardest thing to do in analysis. But they are the foundation of the whole project. They define what success is for the project and they have it in their power to halt the project. They decide at critical points whether a project should proceed or not.
So, identify the wrong group of stakeholders and we will have a project that is being controlled and assessed by the wrong people using the wrong measures.
Drivers
The next link in the chain is project drivers.
Drivers are one of 3 main types:
1. Problems that need fixing – for example a project driver might be to communicate with customer better.
2. Opportunities that can be exploited – for example a project driver might be to promote a new way of communicating with customers that has been developed with the company – using mobile phone text messages for example.
3. Constraints that must be adhered to – for example a project driver might be to make the changes required to keep the company legal in respect of laws about what messages can be sent in text messages.
Projects frequently have many drivers of mixed types. Your problem as a business analyst is to prove to the killer stakeholders’ and your satisfaction that the right set of drivers have been identified.
Drivers are often linked and where they are they belong together in the same project. For example, the opportunity to communicate with customers using text messages must comply with any laws about what is allowable content within text messages.
Sometimes, the drivers will not link together at all. You have to analyse then why they are in the same project. There must be a logical reason for having these drivers together otherwise you can end up developing and implementing essentially 2 different projects that have no connection with each other under 1 project heading and budget.
So our challenge as business analysts is to make sure that the right set of drivers is
identified.
Objectives.
The fact that the drivers have been addressed is proved by achieving the objectives.
The objectives simply measure that one or more drivers have been addressed.
What scale do the objectives have and what target value equates to success? We need that information if we are to prove that the drivers of the project have been successfully addressed.
The problem we face is that it is easy to identify the wrong objectives and - if we do - then everything that follows is wrong.
Requirements
Now we know what the project is trying to achieve, the next set of questions to be answered is how will it achieve the objectives? What will need to be there in order for the objectives to be realised?
There are many types and levels of requirements and these are the subject of several further modules.
For now, you just need to realise that without the right objectives we will analyse the wrong requirements.
And as there an infinite number of requirements that don’t support achieving project objectives and only a small set that do, requirements must always be assumed to wrong - in the sense they don’t help achieve objectives – until they can be proved to be right.
So, you now have set of justified change requirements…just how big is the change?
To answer this question we need to declare the units with which we will measure bigness. The problem is, what unit measure the size of change? The answer is there is isn’t one. There isn’t one unit, there are many.
It is not enough to ask how big the change is, we have to ask “how big is the change in terms of the number of processes it will affect?” and “how big is the change in terms of the number of users it will impact?” and “how big is the change in terms of where it will be used?”.
All these questions using this “…in terms of…” concept are declaring the unit of measure for bigness for that assessment.
There are many units of measure that can be used. The common ones are POLDAT:
Processes
Organisation Units
Locations
Data
Applications
Technology
…most of these will have some associated non-functional components as well.
A model of the different bits of information in the chain of reasoning and how they relate to one another.
Fundamental point: as a BA you will not proceed in an orderly fashion through these links: you will bounce up and down them as new information comes to light. What you have to do is constantly monitor the structural integrity of the chain: does a new piece of information change anything in other links up or down the chain? It has got be kept consistent.
These are products of analysis that document the links in the chain of reasoning.
The products that document the links in the chain (and the elements in the chain) have different names/jargon depending on method/approach being used.
As BAs we need to be able to identify the components not by name but by the job they do so that when working in any methodology under any approach we can identify what it really is and how we can analyse and document it.
The following set of slides show and example of how these products can be documented to show the type of information in each one.
Because analysis of change requirements means defining these components (in green) then it follows that any analysis method must encompass documenting these components, somewhere, somehow, under some name.
These are some typical questions that get asked during a project – specifically during work connected with the Terms of Reference although of course they can crop up any time. Just about every project will need to get answers to these questions as a minimum.
The important things are
Recognise that the question is being asked
Document an answer of sufficient quality in the relevant place
Again, these are the most common questions that any change project will need to get answers to, and the places to document the answers.