1. Bite sized training sessions: Scope of the Business Analyst Role

2. Objectives Review the scope of the BA role
Make a case for the importance of the BA role
Discuss whether a BA really is a BA…
Think about the “analyst” part the BA title
Review the scope of the BA role
An examination of what the scope needs to be in order for a BA to be able to do analysis of requirements. Assuming that there are such things as business requirements for change and that these need analysis in order to be defined, then there is certain information required which necessitates a BA either being involved in or having intimate knowledge of certain stages of a project.
Make a case for the importance of the BA role
What value do BAs add? Can this be specified? Can it be quantified? The issue is that most of the benefits that BAs deliver are invisible as they are concerned with the avoidance of foul-ups.
Discuss whether a BA really is a BA…
A deconstruction of the title “Business Analyst” – do they really do what they say on the tin?
Differentiate between Inductive and Deductive analysis
Analysis is not just talking, chatting or even asking questions. It is as precise and formal process as possible in order to maximise chances of discovering the right information to deliver maximum benefits in the minimum time. As BAs we should be aware of some of the basics and inductive logic and deductive logic are basics. 2

3. Putting the Business Analyst in context
Programme/Project Manager
“The sponsor will get it all,
now and for free”
Owner/sponsor
“I want it all
I want it now
I want it for free”
BUSINESS
ANALYST
The point of this slide is to mostly self explanatory except for the arrows – they show key interactions. Some of these do not involve the BA yet they materially affect the work that BAs do, and as such we need to be aware that they are going on.
Solutions developers
“Given all the other projects we are already doing for you, the best we can do is a bit, in 6 months and it will of course cost a bit”
Subject Matter Experts/Users
“We must have this
- and soon! -
or our business will fail”

4. ok, we have to plan…first off, SME’s, what do you need?
Sponsor:
We’re going to the moon!
Project Manager:
ok, we have to plan…first off, SME’s, what do you need?
SME:
We’ll need a spaceship and spacesuits! Business Analysts: Do we need anything else?
Business Analysts:
to answer your question I need to know…
Why are we going to the moon?
(Problem analysis)
How will we know it was a worthwhile trip?
(Objectives analysis)
Therefore - what will we need to ensure it is worthwhile?
(Requirements analysis)
Developer:
So we need to develop solutions for the following requirements…
Worked (mickey-mouse) example, hopefully self explanatory.
The point to stress is that it is not until we get to the BA section that there are questions on the specifics of what is being proposed, why and what istherefore necessary.
Give the developers that information and tell them they don’t have to worry about justifying whether it is really needed or not (the analysis of that has been done!) and they are ‘freed up’ to think creatively about best solutions.

5. 5 Made the case that BA is not a difficult thing to do in principle
It is difficult in practice because it demands provable ANALYSIS which means TIME AND THINKING – on projects these are often both in short supply
So long as the analysis is provable in your method/approach it doesn’t matter what method/approach you use
Beware the jargon – my current fav is Jidoka – add the human element to processes (from Lean)
When I am working as a BA my mantra is trust no-one, believe nothing, prove everything – and that should apply to how you do Business Analysis as well 5

6. An example of rocket science...?
Mars Climate Orbiter went in to orbit at 57km above Mars instead of 150km.
It was completely destroyed.
Cause: some navigation calculations performed in Imperial units (pound-seconds) and some in metric units (newton-seconds).
Most project failures are due to incomplete/inaccurate requirements
The fact that “Most project failures are due to incomplete/inaccurate requirements “ is substantiated on a subsequent slide.
Possible question for debate (referring back to the scope of the BA role)…is the specification of calculation units the realm of the BA or technical analyst/systems designer?
Answer: it depends on whether the business have specific requirements in this area – and those requirements are justified given the objectives of the piece of work. 6

7. What do you think are the other main causes of project failure?
Discussion
What do you think are the other main causes of project failure?

8. Why Projects Fail The Standish Group “Chaos Report” (1994)
The landmark study of project failure covering 365 executive managers and 8,380 applications in all major industry segments including: banking, retail and wholesale.
The Chaos Report is the first survey made by the Standish Group. This report is the landmark study of IT project failure. It is cited by everybody writing a paper or making a presentation were a reference is made of IT project failure.
It includes large, medium, and small companies across major industry segments : banking, securities, manufacturing, retail, wholesale, heath care, insurance, services, and local, state, and federal organizations. The total sample size was 365 respondents  representing 8,380 applications.
It is also hotly contested and disputed (as brief Google search will verify) – so do not accept this data as utterly without question true.
Some of the contents of this slide were taken from

9. More chaos stats, stats and …
The trends in the Chaos dataset are not encouraging…
Source:

10. How can BAs mitigate the main risks for project failure?
Discussion
How can BAs mitigate the main risks for project failure?
Incomplete/inaccurate requirements
Business Analysts own requirements. They may not always be the people who generate them, but if the signed-off requirements are not fit for purpose (that purpose being the development of all aspects of solutions, computerised or not) then it is the Business Analyst who should be held responsible. A good Business Analyst then should remove the risk of inaccurate requirements, and should significantly mitigate the risk of incomplete requirements. They cannot remove this risk as they will be dependant to an extent on the quality of the other people who are supplying requirements.
Lack of user involvement
To mitigate the risk of lack of user involvement, we need to know which users need to be involved, why and how.
A Business Analyst should be analysing and documenting the context and scope of the solution.
Context.
BAs need to define user groups that need to be engaged by the project in the course of defining the context in which the solution will operate.
They need to know the user and customer groups who interact with the solution.
The BA also needs to define who is to be engaged by the project and how in order to do the analysis the analyst needs to do.
Scope.
The BA must analyse the organisation units which are the user groups that are going to be changed by the solution (what they do, how they do it, how they are structured and so on).
These users need to be engaged to gather requirements.
The Business Analyst has the responsibility for ensuring that these context and scope definitions are full, complete and accurate.
This analysis should mitigate the risk of lack of user involvement. What the analysis does NOT do is analyse who the solution needs to be ‘sold to’ and how to ‘sell it’. Thus the Business Analyst can mitigate the risk of lack of user involvement but not remove it.
Unrealistic expectations
Unrealistic expectations can be caused by many reasons and the majority of them will not be directly attributable to the Business Analyst so they can not mitigate the risk. The area that Business Analysts can and must mitigate risk is the area of unrealistic expectations for the project deliverables. Logically, this can be traced back to the objectives for the project. Unless objectives are specific, measurable, achievable, directly relevant to what the project will deliver and fundamentally important to the business owners of the project, then they can be interpreted in any number of ways leading directly to unrealistic expectations about what the project will deliver.
For example, consider these two objectives:
a. become a centre of excellence for customer service
b. increase sales by 10%
Objective ‘a’ immediately raises the question of how the business will know it has become a centre of customer service. What measure will it use as a scale of customer service and what value on that scale means that the business has achieved being a centre of customer service? Define that and there is no doubt about what the project is setting out to achieve.
The Business Analyst owns responsibility for ensuring that the objectives are fit for purpose (that purpose being the development of requirements that – when implemented – will result in the objectives being achieved). Note that the Business Analyst does not have to do the work of defining the objectives (in the real world they are often done by Project Managers), they must simply make sure they are fit for purpose. If they are not, then the project runs the significant risk of failure due to unrealistic expectations caused by a poor definition of what the project will achieve.
Similar arguments can be made for functionality that is expected (BA defines functional requirements), scaleability and other non-functional requirements that the BA should be defining.
Lack of executive support
Surely the Business Analyst is not responsible for senior exec buy-in? Consider this: you are a Business Analyst working on a project and for some reason the people who can make the go/no-go decisions are always too busy to attend steering group meetings and so on. The question is why? There can be a multitude of reasons which are outside of the control of the Business Analyst and – indeed – the project.
However, one reason that is in control of the project (and may be in control of the Business Analyst themselves) is that the senior execs are not interested because they do not care about the deliverables of the project.
Suppose now you are a senior exec and you have 2 projects for which you hold ultimate authority. One project will deliver a solution that takes you some way to meeting your sales targets that you are responsible to the company board for achieving. The other project delivers a cultural change programme centred around the slogan of “becoming a centre of excellence for customer service”.
Which would you focus on?
By the way, both of these projects were projects in the real world – guess which one got completed and which failed due to lack of decisions by the senior execs?
Business Analysts can make sure that the objectives are directly relevant to what the project will deliver and fundamentally important to the business owners of the project. If they are not then the Business Analyst should raise the risk that the project will fail due to lack of senior exec support.
Changing requirements
Requirements can change because the business environment changes, the business users come to understand what they are asking for is not what they need or because of misunderstandings about what the requirement really is.
It is this last reason that the Business Analyst can mitigate against.
By building up a rigorous chain of inductive logic starting with the precise definition of what the project seeks to address (in terms of problems and/or opportunities) and following through to the full set of process and data requirements for the change, the Business Analyst can deliver a justified set of change of requirements that will not change because of misunderstandings. This ‘chain of reasoning’ is the covered in more detail in a subsequent training session.
Lack of planning
The Business Analyst is not a Project Manager (or vice-versa) – they are very different skills sets and (typically) the type of person who makes a good Business Analyst does not make a good Project Manager (and vice-versa).
Planning is owned by the Project Manager.
In the real world, most projects are planned by setting an implementation date and then the plan is constructed back from that date to try and fit everything in. This implementation date constraint is often outside of the control of the project team.
What the Business Analyst can and must do is define what they need to do, who and what they need to do it with and how much effort will be involved. At least that part of the plan will then have some rational justification.
Business Analysts must also analyse the risks of cutting back on the analysis – and in the real world the risk is (typically) project full or partial failure due to
1. Incomplete/inaccurate requirements
2. Lack of user involvement
3. Unrealistic expectations
4. Lack of executive support
5. Changing requirements
6. Lack of planning

11. Cost of analysis errors
The cost of correcting analysis errors rises almost exponentially the longer they remain undetected.
Relative cost of correcting error
Barry Boehm
Cost of correcting analysis errors rises almost exponentially through a project lifecycle because the longer an analysis error is left
The more places it is being used so…
The more work has to be un-done
The more work has to be re-done 11

12. How much poor analysis £costs
40-56% of bugs can be traced to requirement errors
Finding and fixing requirement errors consumes 70-85% of project rework costs
The average project exceeds its planned time schedule by 120%
52.7% of projects will cost 189% of their original estimate
Only 16.2% of projects will be completed on time & on budget
30% of projects are cancelled before completion.

13. Discussion
What do you think a business analyst does? Should PMs do what BAs do and vice-versa?

14. Scope of the Business Analyst role (I)
There is a chain of reasoning that leads from the statement of a problem to the implementation of solutions…
…it is documented in products…
BA product
application
Tech
Specs
Code &
Databases
UAT
specs
Extracted
data
Business
Procedures
Loaded
Data
Training
Drivers
Objectives
Scope
Business &
Functional &NF
Requirements
Processes &
Data
Models
BA products
TOR
These are products.
Although they are dependant on each other as the arrows show, they do not have to be developed sequentially. Typically, they will be developed concurrently with significant overlap. Certainly the process models can not be declared complete until at least the functional requirements are complete (because functional requirements result in at least 1 process model).
The skill is in recognising that a change to (say) functional requirements means a potential change to process models, and that a change to process models needs to be verified against functional requirements.
This ‘bouncing up and down’ the chain of products is typical in an iterative process of analysis. 14

15. Scope of the Business Analyst role (II)
There is a chain of reasoning that leads from the statement of a problem to the implementation of solutions…
…involving up to 10 groups of people…
Owners
defines measures of success and $targets
…Business Analysts confirm & document
$Money!
Strategists
determine the strategy to hit the targets
…Business Analysts help research, create strategy, challenge & document
Sponsors
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
Solution Builders
build solution
…Business Analysts protect requirements & document compromises
Solution Builders & Business
test solution
…Business Analysts ensure tested against requirements
Scope of the BA diagram narrative.
‘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.
Project managers
Implement solution
…Business Analysts help with
Process and data migration
Cutover planning
Rollout
Users
Accept solution
…Business Analysts help with
$MEASURING $BENEFITS $REALISATION
POST-IMPLEMENTATION
Business Analysts feed back to the Owner how well their measure of success has been achieved 15

16. Definition of terms for “Business Analysis”
Business: why “Business”?
…should it be Change Requirements???
Analysis: “the process of breaking a concept down into more simple parts, so that its logical structure is displayed” (OED) a : examination of a complex, its elements, and their relations b : a statement of such an analysis (Merriam Webster)
Summary: One definition that can be used: a Business Analyst is someone who analyses change requirements and produces a justifiable set of analysis deliverables that are used to design and implement the solution.
Justification: Did you know that there is no standard, definitive and agreed definition of what a Business Analyst is?
That means not only does the profession have no recognised industry standards or an agreed definition, there is also no binding definition of a set of qualifications or standards that all Business Analysts must adhere to.
And that means that Business Analysts:
can be all things to all people
can define their own role
should define their own role so that they have an answer for anyone who tries to dump unassigned tasks in to the remit of a Business Analyst in (for example) your organisation – i.e. you!
“Business Analyst” – let’s deconstruct (analyse!) the term.
1. “Business” – no, we are not going to define “business”, but we are going to challenge why Business Analysts are called Business Analysts. Apart from working in businesses, don’t Business Analysts also do their work in local and central government, charities, non-governmental organisations, and so on?
The term “Business” in “Business Analyst” may have come about in the 1980s when Systems Analysts (who pre-date Business Analysts) declared that they were starting to get engaged in activities not related to Systems Analysis. If they were not analysing systems, what were they analysing? Their answer was “Business”. However, a more descriptive answer would be "they analyse requirements for change".
Based on that the role would be more accurately described as “Change Requirements Analyst” but as the name “Business Analyst” has stuck we will continue with that title.
2. “Analyst” – someone who analyses. “Analysis” then is the important definition. Here's how three sources define "analysis"
Internet: an investigation of the component parts of a whole and their relations in making up the whole
Oxford English Dictionary:
a detailed examination of the elements or structure of something.
the separation of something into its constituent elements — ORIGIN Greek analysis, from analuein ‘unloose.’
Merriam-Webster dictionary:
separation of a whole into its component parts
a: the identification or separation of ingredients of a substance b: a statement of the constituents of a mixture
a: proof of a mathematical proposition by assuming the result and deducing a valid statement by a series of reversible steps b(1): a branch of mathematics concerned mainly with limits, continuity, and infinite series (2): calculus 1b
a: an examination of a complex, its elements, and their relations b: a statement of such an analysis
a: a method in philosophy of resolving complex expressions into simpler or more basic ones b: clarification of an expression by an elucidation of its use in discourse
the use of function words instead of inflectional forms as a characteristic device of a language
So analysis is all about breaking a problem down to its component parts to expose the logical inter-relationships between them. The ‘problem’ being analysed is the change requirements for a project. We ‘break the problem down’ so we can prove that all the components are actually required. We analyse change requirements (break them down to their component parts) and prove that each and every requirement is necessary in order to deliver the project.
And once armed with all these provable facts about the project, new requirements can be derived from the existing facts. This is where the business analyst really creates value for the project as they discover new requirements that no-one had ever thought of, or realised must exist, based on the current project definition.
Summary: Business Analyst = someone who analyses change requirements and produces a provable set of analysis deliverables that are used to design and implement the solution.
…and here are a few things Business Analysts are not (although none of these roles can function well without an effective Business Analyst producing high quality analysis deliverables!):
Project Managers
Systems Analysts
Designers
Coders
Testers
Implementers

17. Inductive VS Deductive Analysis
Induction:
a method of reasoning from a part to a whole, from particulars to generals, or from the individual to the universal.
Example: whenever I let go of a hammer, it falls to the ground. Therefore, every time I let go of a hammer it will fall to the ground.
Deduction:
a rigorous proof, or derivation, of one statement (the conclusion) from one or more statements (the premises)—i.e., a chain of statements, each of which is either a premise or a consequence of a statement occurring earlier in the proof.
Example: All fairies are pink. Tinkerbelle is a fairy. Therefore, Tinkerbelle is pink.
Which is better? That’s elementary, Watson.
Definitions from Encyclopaedia Britannica 2008
Although deductive analysis is always preferably but as analysts we need to recognise that the vast majority of the time we can only analyse inductively, hence the value in checking and verification of our analysis – inductive analysis is not as rigorous or reliable as deductive so it needs checking.

18. …and there’s more the BA needs to be thinking about…
Argumentation theory – how to discover the truth.
Philosophy – what is “truth” in a business context and how to do we prove it?
Rhetoric – persuasion and/or enquiry?
Opinions – they matter but are only one tool – not the only tool!
Communication theories – how to best communicate what to who?
We have barely scratched the surface of the shrink-wrap on the subject of business analysis.
In order to do some kind of analysis that gives a conclusion we can justify (at least!) or prove (rare but best!) then we need to be thinking about…
…argumentation theory: how the two sides of an argument are formed, how they can be resolved, the tools, techniques and challenges in conducting an argument (not the stand up row sort, but the logical, presenting cases sort).
…philosophy: what is this truth that we claim to have analysed for a project? What reality does it have? Are there limitations to it that can inform our analysis?
…rhetoric: is a convincing argument a matter of style, of substance, or both? Does the fact that rhetoric affects opinions matter?
…opinion: in the logical world of analysis what part could opinions play? Well, have a chat with you subject matter experts and you may find that they are summarising an awful lot of experience and knowledge in to opinions (not for nothing are there such things as medical opinions). Having recognised that, be aware that an opinion expressed by an expert on something they are not expert in may not be worth as much (good doctors are not necessarily good car mechanics!)
…communication theories: BAs have a wide group of disparate roles to communicate with…what methods, styles and techniques work best for which groups?
These subjects have fundamental impacts on projects that profoundly affect the ability of the BA to be successful in helping projects avoid the pitfalls that mean most end up failing.
…BAs are the analytical engine of a project…no-one else is accountable for doing it…we better do it well!

19. You are not alone… www.smart-BA.com Articles
Sample analysis documentation
Excellent BA community
Forums
Another excellent BA community
BA professional organisation
BA professional qualifications (CBAP)
BA professional qualifications (ISEB Diploma)

20. Questions?