I hate windows 8!!!

Why oh why oh why windows 8? What's wrong with windows 7? I just got used to it and it is great...ok not as brill as XP sp2 but less resource hungry and beats 10 kinds of sh*t out of Vista...actually, remember windows ME? Awful...Windows 98 mind you was perhaps THE classic...but then of course what was wrong with windows 3.1?

Perhaps we should form a conservation movement: protect Windows 7!!! Well, ok, protect Windows 98!! Or 3.1. Bugger it: save MS-DOS! Preserve the natural (technological) habitat of MS-DOS! Ooh yeah and let's not forget the internet: bring back Alta-Vista as THE search engine! In fact - get rid of the internet! Preserve the technological purity that was pre-internet....

Ridiculous? Why of course! I mean...windows 7 is better than MS-DOS for me...but do I want more change with windows 8? Yes; of course. I want change for the better if it is better (and not another Windows Vista). Ok, but how do we know it is better? Er...well we could do the analysis of drivers, objectives and requirements?

Welcome to business analysis!

So far so smug...but "what about red squirrels?" I hear you ask.

Yes, they are under threat from grey squirrels in the UK. There are only a few places left you can find them. So some people are trying preserve red squirrels. And why would they do that? Because red squirrels are better than grey? Like MS-DOS is better than Windows 7? If red squirrels were better than grey then grey squirrels would be under threat or would never have made any inroads against red...

Besides, where do you stop? Red squirrels have competed against other animals...actually of course, mammals replaced dinosaurs...what do we want - a return to dinosaurs? Or should we go back to single celled organisms?

And let's not forget the racialism of "native species" - people trying to get rid of rhododendrons because they are not "native" to Britain...and when would that have been then? In a hundred years will they be native if they are still here? If you substitute the word rhododendrons with "Indian nationals" you get a pretty scary statement...conservation or fascism?

So - why fear change? Change is inevitable and unstoppable and is the only constant in the universe. Right now today is not some golden point in time when everything is just right and nothing should change from here on in...and things will change...the planet will get warmer/cooler/whatever...species will go extinct (by the way: so many conservationists tell us about the numbers that are "threatened" or have gone extinct...what about the number of species coming in to being - and they are! Change happens...). Humans will go the way of the dinosaurs and what do conservationists want to do - preserve the primal soup? Good luck with that one!

So is all change good? No of course not: look at nuclear waste and the like...very dumb. But how will we know what changes we can make/are making are changes for the better? Er...well we could do the analysis of driver, objectives and requirements and then see if the changes are delivering those requirements?

Welcome to world of business analysis: saving the universe!

Bad Business Analysis

Just finished "Bad Science" by Ben Goldacre - great fun and pretty amazing. The scary bit was when he was banging on about Nutritionists...how they have jargonised and over-complicated a simple field (nutrition) in order to sell a pig in a poke and make a fast buck...scary because that's happened to Business Analysis with all the "methods" and "approaches" - Agile, Lean, Six Sigma, UML, RAD/JAD and the "accreditation" that goes with them: diplomas in this and CBAPs in that.

Fantastic.

Of course, you can hold all the certificates in all of the methods and approaches and still just not get that there is no way round actually doing the simple (but difficult!) analysis.

If you want it doing right first time, do what people who can't afford to fail do: analyse. Don't just keep throwing money at the miracle-cures peddled by the modern day equivalents of the mid-western medicine-men!

I mean, just a little bit of analysis about business analysis will tell you that you don't need to study a trade-marked load of marketing jargon in order to do analysis!

Over complicated and over-expensive methods and goobleydegook speak - who needs it?

NEW: Bite Sized Training for learning the best bits of business analysis one tasty morsel at a time!

NEW: Bite Sized Training for learning the best bits of business analysis one tasty morsel at a time!
These modules alsmost all have explanatory notes in (except the data modelling one - but there is plenty of explanantion of that in the article "Business Data Modelling - Why and How" also on the website). There is also a case study to download with it.

Feel free to download these files and edit using standard PC software such as OpenOffice or Powerpoint, Word, and Excel. The only request we have is tell them where you got it - go on, give us a plug!

ISEB Diploma in Business Analysis Oral questions

Here is a list of questions that were asked in a real oral exam undertaken by a BA taking the ISEB Oral exam to get the ISEB Diploma in Business Analysis...gives an idea of the style and what to expect. The questions asked in each exam will not all be the same of course!!!

The Guild of Business Analysts

This article proposes how BAs could regulate and certificate themselves and the benefits this gives to BAs, training organisations and employers!

This article is only a proposition - the start of an idea. Anyone who is interested should take it, expand it, and use it. Smart-BA would love to be a part of it, but we don't have to be...the main thing is to get BAs thinking about taking control of their own certification.
.

2 new articles - Data Modelling and Non-Functional Requirements

...an article on the neglected skill of data modelling - why do it, how to do it and some useful advanced techniques. One of the most powerful, succinct and rigorous ways of analysing business requirements gets a JFDI treatment.

...and an article on non-functional requirements: is it me or is it rather ironic that BAs who are meant to analyse and define EVERYTHING have a subject area that is only defined by what it isn't...non-functional requirements are requirements that are not - er - functional. So I guess then that data requirements are non-functional requirements? Clearly rubbish, so this article attempts to scope, define and manage this nebulous area of analysis.

Both available at www.smart-BA.com

Hope they help!

If I had one hour to save the world, I would spend fifty-five minutes defining the problem and only five minutes finding the solution. – Albert Einstein

Seems Albert wasn't an Agilist either.

Nuff said.

New self study manual on Strategic Business Analysis released!

Strategic Business Analysis is a self study manual covering an holistic approach to the investigation and improvement of business situations with a view to developing effective, feasible business solutions.

The manual is a JEEP (Just Enough Essential Points) manual containing all you need to get you through an exam! This is a "no waffle" manual that tells you what you need to know and no more. For open book exams such as the BCS/ISEB Business Analysis Essentials exam, you can even take this manual in with you!

The manual also has exam style questions with model answers and a full mock exam and marking scheme.

Hope it helps!

Let me know...
Guy

New articles on BA certification and non-functional requirements

There are 2 new articles on the smart-BA site: one on business analysis certification and one on just what non-functional requirements are (quite a trick for something whose name only tells you what it is not!).

Suggestions for further articles welcomed.

New versions of the manuals for passing exams like the ISEB Certificates available

BCS/ISEB have demanded that the manuals I wrote to help students pass the ISEB Certificate in Requirements Engineering and the ISEB Certificate in Modelling Business Processes be removed as they infringed the ISEB trade mark. All rather petty in my opinion.

So I have now re-written these manuals so that they do not reference the ISEB Certificates except as reference points for the types of exams available in these subject areas.

These manuals are now available FREE at http://www.smart-ba.com/

As always, hope this helps!

Guy

...and another thing...

I can't believe the hype around climate change...like it was ever fixed in the first place! It is a chaotic system and we stand about as much chance of making a predictable difference to sea levels as Canute did (smart man: he was just trying to prove to his followers that he was only mortal and could NOT turn the sea back: our 'leaders' seem to have lost the plot on that one...).

Let's cut pollution and population (before one does the other) but lets not delude ourselves with the global warming hogwash and offer 'sacrifices to the gods' in the form of whimsical carbon cuts.

Here endeth the rant.

Business Analysis - what it is and its main threat...

See first that the design is wise and just: that ascertained, pursue it resolutely do not for one repulse forego the purpose that you resolved to effect.
William Shakespeare

A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
Douglas Adams

An example of wasting time...?

There seems to be a lot of time invested in verbal examples.

Almost without exception every discussion I have with fellow analysts, users, managers, desgners, developers, testers, trainers and project managers involves the following pattern:
"I think this is the case and the reason is - well, suppose, for example..." and there follows an often lengthy, ususally contested (by someone else in the meeting) example of something to support the original statement.

The issue I have is that the example usually adds nothing but time: the meeting participants usually know the context of the example and understand the point being made that the example is supposed to support. Where this is not true and the example does aid eductation of meeting partcipants, fair enough. However, this is rare in my experience.

The net effect is to just add time to the meeting.

Why would people do this? The people I meet with are not stupid, and they are all aware of the time pressures, so why would they consume time with these (quite literally) pointless examples?

I have noticed that there are categories of people who don't tend to do this:
1. senior project sponsors will quite often simply lay down their requirements (or quite often solution and not requirements - but that is another issue)
2. true subject matter experts talking about the subject they are expert in
3. shy people (who just don't like talking!)

If these categories are correct, the profile of a typical example procastinator is middle management and below, not expert in the subject under dicsussuion who likes the sound of their own voice!

If this is true then it is in my interests to shut the examples down so that more progress can be made. I have the objective (reduce wasted time in meetings) and a requirement (shut down pointless examples): the question of the design of the solution now arises and - being a business analyst - I know I need to canvass experts in the 'technology' that can achieve this: interpersonal skills.

So anyone out there with a solution for my requirement (or an explanation of why my requirement won't contribute to achieving my objective), please do let me know!

Thanks!

ISEB Certificate in Modelling Business Processes Self Study Manual

I have written a self study pack for those Business Analysts looking to pass the ISEB Certificate In Modelling Business Processes.

This self study pack is for Business Analysts who want to pass the ISEB Certificate In Modelling Business Processes and contains exam style revision questions, a full mock exam and model answers.

The pack aims to give you only what you need to know to pass the ISEB Certificate in Modelling Business Processes together with exam style revision questions and a mock exam. This pack has been written by a Business Analyst for Business Analysts who already know how to do the job and now they want to pass the exam.

The pack is presented in sections reflecting the order of the syllabus for the ISEB certificate.

Each section of the pack comprises:

- key points as an aide-memoire

- details that expand on the key points

- exam style revision question

- model answer

The last section is about maximising your exam marks and is followed by a full mock exam with model answers. As the actual exam you is an 'open book' exam you can take this book in with you.

Hope this helps and all feedback welcomed.

Sometimes they die...

The line is from a TV series called ER: one doctor is talking to another who thought they could save every accident victim. This doctor has spent many hours and much angst on a patient who in the end he can't save. The older, wiser doctor says "well, sometimes they die." And so they do.

I was on a project once that was for some high-up sponsor (can't remember their job title exactly, but I'm sure it had "infallible" in there somewhere!) called Hal - this is not their real name, but the name of the super-computer in 2001 A Space Odyssey who is so super it tries to sabotage the whole mission. Hal did not have enough work to do so compensated by micro-managing everything and thereby looked busy but allowed enough time for Hal's hobby of putting their staff under immense pressure. Hal was a small-time bully.

Hal - of course - was not only supreme manager of everything (or whatever the title was), Hal also thought Hal was an expert project manager and business analyst. When I started work on the project Hal gave me objectives but no time - Hal said that Hal was NOT going to work with business analysts as Hal was far too busy for that. Not only that, but Hal did not want me to do analysis at all: Hal just wanted me to document some rules in isolation. So I did the work and then Hal kicked me out on the grounds that the project wasn't achieving what Hal wanted (Hal's real objectives - it turned out - were about a quick and dirty solution that would end up generating another project to fix the mess in a year, or perhaps 2, but failure was to built in in the form of non-compliance with legislation. Job creation was definitely part of Hal's real objectives).

The lesson I took from this is that sometimes projects do die - the project analysis I was kicked off was already over 1 year late when I started. I suspect this lateness was because of the conflict between what Hal should want to help the organisation succeed and what Hal really wanted to help Hal stay in a job - and Hal needed time to find a way of getting what Hal really wanted. If I had been allowed to work as a business analyst then maybe it could have been turned around but Hal had other objectives that meant turning it around would be a failure for Hal so - sometimes - projects die, taking some workers with them!

Post mortems seldom cure the victim, but what they can do is inform our work on the next project. This one was a great learning experience for me in humility: you can have all the fancy-pants analysis tools and mind-sets in the world but sometimes the project will die anyway. Live and learn...

Great BA fallacies in action?

A colleague of mine recently attended a Kaizen workshop and remarked drily afterwards that perhaps Toyota is not the best example of success to quote for this approach. Toyota has methods and approaches such as Lean and Kaizen and Toyota was successful so the thinking had been "adopt these things and you will be as successful as Toyota." Now that Toyota is struggling, is the converse true?

The post I made "Great BA Fallacies #4 - Non-Sequiturs: it does not follow" proposes that until a causal relationship between these facts is established, then neither is true. These things may work or they may not. We need to define exactly and specifically and measurably what we mean by "work" and then analysis the cause and effects on these measures to see if these things do - in fact - work.

Trouble is the people promoting these approaches often make this logical mistake. And if they are respected people then we can make the logical mistake of believing them - Great BA Fallacies #1 argue from authority. They will also often quote anecdotal evidence such as "I have been involved in [insert a large but hopefully believable number here] projects and they were all brilliant so therefore this must be a good approach/method". Not until the causal link is proved objectively it ain't!

It is especially hard if these authorites use Great BA Fallacies #1 Proof By Verbosity to establish their case. Like I'm doing in this post... :-)

So really, it all comes back to this: use analysis skills, trust no-one, believe nothing - PROVE everything - in other words develop a BA'd attitude...And apply it to anyone who tries to tell you anything - and to this post...and to all methods and approaches that we see come and go in Business Analysis: just cos its fashionable doesn't make it good: Prove it!

ISEB Certificate in Requirements Engineering Self Study Manual

I have written a self study pack for those Business Analysts looking to pass the ISEB Certificate In Requirements Engineering.

This self study pack is for Business Analysts who want to pass the ISEB Certificate In Requirements Engineering and contains exam style revision questions, a full mock exam and model answers.

The pack aims to give you only what you need to know to pass the ISEB Certificate in Requirements Engineering together with exam style revision questions and a mock exam. This pack has been written by a Business Analyst for Business Analysts who already know how to do the job and now they want to pass the exam.

The pack is presented in sections reflecting the order of the syllabus for the ISEB certificate.

Each section of the pack comprises:

- key points as an aide-memoire

- details that expand on the key points

- exam style revision question

- model answer

The last section is about maximising your exam marks and is followed by a full mock exam with model answers. As the actual exam you is an 'open book' exam you can take this book in with you.

Hope this helps and all feedback welcomed.

Great BA Fallacies #5 - Accidents

Anyone who breaks in to another person's house is a criminal. Fireman break in to people's houses therefore firemen are criminals. Well obviously that is wrong and any idiot can see that. Is it always so obvious?

Functional requirement: Only a customer can withdraw money from their accounts. Is this ok? What about if they die? Alright, change it then: Only the customer or the executor of a their will can withdraw money from a customer's account. But suppose the customer is a criminal using the account to launder money?

The fallacy of accident is the fallacy of making a generalisation that disregards exceptions - applying general rules that allow no exceptions to circumstances that need to cater for exceptions.

Given these exceptions, a Business Analyst might be tempted then to restate the functional requirement as "Anyone can withdraw money from any customer's account". What the BA has done is commit the reverse of the accident fallacy by making a general rule based on exceptions - in effect by reasoning that since anyone MIGHT need to withdraw money from a customer's account then everyone CAN withdraw money from a customer's account.

So how to avoid these fallacies? Specify what the requirements actually are as definitively as possible:
1. A customer must be able to withdraw money from their account.
2. The executor of a customer's will must be able to withdraw money from that customer's account.
3. Anyone who provides evidence of their legal right to withdraw money from a customer's account can withdraw money from that customer's account.

Hopefully you can start to see how the three process models that would implement these three functional requirements might start to look and how they would involve different validation procedures. Perhaps these requirements need further refinements (for example combining requirements 2 & 3?) - doing these requirements is detailed, tricky work where fallacies are always waiting to trip us up...accidents happen...

Great BA Fallacies #4 - Non-Sequiturs: it does not follow

Here's a crazy idea: drive with a gorilla in the back of your car because it is safer - how do I know? Have you EVER heard of a car accident where there was a gorilla in the back of one of the cars?

So why is this crazy? Because no causality has been established between the two premises to justify the conclusion - namely: the number of car accidents and the number of car accidents with gorillas in the back on one car to justify the recommendation to drive with a gorilla in the back of the car. Of course no-one would ever justify anything on two or more unrelated premises would they?

Summary of real news item: being rich makes you intelligent - a study has shown a positive correlation between academic achievement and a family's income.

Advertising of course is littered with these Non-sequiturs to try and dupe the unwary.

What relevance has this to Business Analysis? Heard the one about the project that was initiated because of low staff achievement levels and had an objective to increase sales per employee hour worked and a functional requirement to record employee time and attendance? Here is the non-sequitur: "our staff are not achieving what we want and what we want is increased sales per employee hour worked and therefore we will monitor staff time and attendance".

As a BA I am always on the lookout for non-sequiturs and until I have a demonstrated causal link verified by the subject matter experts between the premises and conclusion (and there may be one!) then I have to be wondering just why anyone would think that knowing how much staff are in attendance at work will increase sales per employee hour worked...I'm not saying it won't, I'm just saying that until the causal link is defined and agreed we are hoping and guessing instead of predicting...

Non-sequiturs hide. They lurk in such things as Great BA Fallacy #2 Proof By Verbosity and statistics and when said with authority by A Named Authority they often go unchallenged. The best way to identify them is to make them stand out by stating as plainly and simply as possible the premises and the conclusions - and they best way to do that is to do Analysis: break down a project's changes requirements in to their component parts so the logical inter-relationships can be examined. The component parts are Drivers, Objectives, Scope, Functional Requirements, Process and Data models and specifications.

If you do that and avoid all the other Great BA Fallacies then you will be richer.

Whoops - that may be a non-sequitur...

Great BA fallacies #3 - Begging the question

This fallacy creeps in just when you don't expect it - and I should know: I've been right about every other fallacy so I'm right about this one!

And there is the fallacy: I assume that because I've been right every time before (please remember that this is a made up example before reminding me of all my mistakes!) that I will be right in the future.

It's like saying that because I have flipped a coin 3 times and it has come up heads each time that the next time must be tails. No - each time I flip it there is a 50:50 chance of it being heads regardless of what happened on the last 3 or 5 or 100 flips.

Past performance is no indicator of future performance. Such reasoning that assumes an outcome in order to justify the outcome is begging the question.

Here's a classic BA example of it: "we tried that before and it didn't work". The inference is that because we tried it before and it didn't work if we try it again it won't work. The truth of the outcome will be determined by why it didn't work before and whether those factors still apply.

This fallacy ties in nicely with fallacy #1 - argument from authority - just because some 'authority' says something does not make it true: don't just believe someone because they have a reputation for being right or knowing a lot about something, that would beg the question of whether they are right in this case as well. You may want to use the person's track record as evidence that their opinion is worth considering - but it is NOT evidence that they are right.

Sometimes I get asked about how to Project Manage a project I am doing the analysis on: "you're doing a good job on the analysis so how should we restructure the project plan". I don't know! Project Management is a separate skill set I don't possess - asking me on the basis I am doing well with the analysis maybe flattering but would still result in (very probbaly) the wrong answer, so it is in both our interests for me to declare that.

Begging the question - assuming that we know the answer before asking the question and basing our answer on that false assumption - it gets everywhere and it always has caused trouble so it always will!

Whoops...

Great BA fallacies #2 - proof by verbosity

We've all been here: someone just talks and talks and uses more facts and figures than you can shake a stick at offering a wealth of supporting material (that you can't inspect during the 'discussion') - this is proof by verbosity otherwise known as "wearing down", "grinding in to submission" or "doorstep sales".

A favourite with politicians (of political parties or office politics). Also 'consultants' who wear red braces, draw lots of boxs with arrows on flip charts but don't actually write down anything that means anything. And lets not forget project sponsors!

What it relies on to succeed is the inability of the human brain to hold all the relevant facts in your head, correlate them and find the logical mistakes in the reasoning.

So, before considering how to survive this kind of onslaught, consider this: why did the person/people choose this method to 'prove' their position? One of 2 (or possibly both) reasons:
1. they have a scatter-gun mind and move off at random tangents anyway - that's what they are like
2. they are aware they have a weak case and are hoping to carry the day using voluminous distractions

So - how to survive? Firtsly and most importantly, remain focused on what questions you need answered and do not get distracted by all the information on offer.

If you have the time, let them finish every last drop of the verbal diarrhoea. Then ignore it all and refocus the conversation on what you were debating anyway - example: "That's interesting, but before coming on to your points can we just resolve this question...".

If you don't have the time, cut in with some stalling tactic like "You have some excellent points there but we need to resolve this question now and we only have half an hour so lets pick your points up off-line".

Of course, this is unlikely to work with someone senior to you. In this case, I try to show them the consequences of what position they want to take without considering their verbosity at all: "Ok, so we are going to complete the analysis of this project in 3 days - now you told me the scope is nationwide, so lets see...I need to visit 16 regional offices and pull together all the different requirements in 3 days - is that right?"

And one final point: of course they may be right or at least have some good points! Just because they are using this tactic does not mean they are wrong. Get all the information you can from them, pick up on the referenced material, review and consider it. You never know...and don't forget ABC of Great BA Fallacy #1: so you do want to check it out if you can!

Great BA fallacies #1

A fallacy is a component of a justification which is logically flawed and so makes the whole justification invalid.

This first fallacy I want to draw attention to is called "argument from authority" and is the argument that goes "it must be true because so-and-so said so". Because some one - or loads of people for that matter - or everyone - says something is true does not by itself make it true.

The use of this fallacy is staggeringly common - I've lost count of the JFDI requirements given to me because a Director of Something wants it and therefore it must be right. And then there is that Subject Matter Expert Who Knows Everything (or does he?)...even Einstien is often brought in to a discussion to try and prove a point.

ABC - ask, believe nothing and no-one, check: that's what a user told me this week. So beautifully put!

The bit that is relevant for this Great BA Fallacy is "believe no-one" - that doesn't mean everyone is a liar, it just means don't accept anything on face value, without checking and proving to your satisfaction that it is - actually - true.

The point is that it should not matter who's saying what, what matters is whether it is true. I mean, Einstien seemed to know his stuff about relativity but not (apparently) when it came to quantum mechanics: this illustrates no-one is infallible (well no-one I have ever heard of or met). In every day living this is not as important but as a Business Analyst analysing change requirements it is vital that I can prove that every change requirement I define is actually required - so unless I understand the logical reasoning that justifies a change requirement I will not accept what someone says just because it is them saying it.

I apply that principle even when it is another Business Analyst telling me something. Or a BA guru...in fact especially a BA guru! Unless I can understand the chain of reasoning and can not fault it, I should not (rationally) agree with it.

ABC.

100% Proof BA

How can Business Analysts prove anything when ultimately all their information comes from other people's opinions? Science can prove stuff - why not us?

Let's contrast how science and Business Analysis proceed:

Science has an objective to uncover more new knowledge. Science proceeds from observations on reality - these are then explained using 'hypotheses' and tested experimentally: if the hypothesis is true/false and we do such-and-such then this should happen. Those hypotheses that survive testing become theories. Theories are what pass for 'facts' in science on the basis that even though you have proved experimentally 10,000,000 every time you drop the hammer it falls, the 10,000,001st time it may not invalidating the theory of gravity that explained the falling hammer.

Business Analysis has an objective to uncover more new change requirements: Our 'facts'. But Business Analysis does not have reality as a starting point like science does.

Luckily (maybe) there is a form of reality that can be defined for Business Analysis but it can change - it is not as fixed as the reality that science has the luxury of: our BA reality is the decisions made by a group of people who have the recognised authority (formally or not) to sanction our project to proceed or kill it. Crucially, they must agree a joint definition of what needs to change and by how much in order for the project to be considered successful (smart Objectives).

These 'killer stakeholders' are not always who you would expect: sure, the budget holder is there. But what about the guys in charge of the IT standards and procedures? Try implementing without their agreement and you will rapidly experience the effect of killer stakeholders. Their objective: this project must maintain compliance with IT standards and procedures.

Once we have these smart objectives we can proceed to define what has to change in order for these objectives to be met (change requirements). Once we have that we can define how the changes will be made (design a solution) that will deliver these objectives. Then we can build, test and roll out.

Almost all change projects will have killer stakeholders we may not have expected: who is accountable for compliance with the Data Protection Act? Who is responsible for validating the business case? What about John Smith the main user because if he won't use it no-one will? And so on.

BA reality is built from people (mostly) who can leave their jobs, get promoted, and just change their minds! All our analysis is built using logic that rests on the premise that the smart objectives are right - and that premise depends on the agreement of all the killer stakeholders.

And scientists thinks they have it tough?!?!?!?
.

BA'd Attitude

.

Analysis: There seems to be one thing that can't be taught and that is the analytical attitude. Maybe this is the wrong name - perhaps willingness is a better term, or professionalism - don't know.

But without an analytical attitude you are going to struggle. That attitude can be summed up as
"Trust nothing, believe no-one, prove everything".

"Trust nothing" = things aren't always what they seem. Don't assume because a report is headed "profit report" that it is reporting profit. Define what profit is to that organisation, examine the input to the report, the process it goes through to calculate profit and prove that it is what it says it is.

"believe no-one" = just because a Director or subject matter expert tells you something is so does not make it true. Get it corroborated. Validate it against other information. Prove the correctness to your satisfaction.

And this applies to Business Analysis and our methods as well! Just because some BA guru tells you something does not make it true if it is only based only on the status of that guru.

"prove everything" = "trust nothing" + "believe no-one" + build your conclusions based on facts that have been proved.

This attitude cannot be learnt - it has to be part of the character of the individual.

The analytical attitude: good for all kinds of investigative work such as business analysis, crime investigations, scientific discovery - anywhere in fact that new information needs to be uncovered.

Is there one true method or approach for doing this? No. There are hundreds of valid approaches. But if you don't have the attitude you will be following the method without knowing why (why would you trust the method - you don't trust anything!).

The attitude is one thing, the skillset that maximises on the attitude is another and there are any number of training courses out there (check out my business analyst training offering).

.

Speed Business Analysis

.
I am doing some analysis consultancy at the moment for a huge organisation - you know the sort: a decision can't be made without having a working party determine if a workshop is needed to consider the possibility of putting "make a decision" on the agenda of the next "if all else fails have a meeting" sub-committee plenary session.

What is great is that having my own specific analysis framework to work to (regardless of the "method" or "approach" they take: bring on Agile UML with Lean JAD workshops!) means I just get on with getting the information I need to do the analysis.

And it's fun!

They get to do all the organsiational protocol stuff and I get to do the analysis. Ok, so early days yet and it could all go pear-shaped, but this kind of experience reminds me that the fundamentals of Business Analysis (when applied) cuts through the crap and gets to point far quicker than anything else.

Yup, Business Analysis speeds things up - not the usual perception for the profession!

.

Why won't BAs BA themselves?

As a profession we just seem to resist turning our analytical tools on ourselves with the result that we don't know what our objectives, functional and non-functional requirements, and business rules are.

Why won't we do that?

I have already posted on the fact that humans don't seem to like actually doing analysis and the reasons why and perhaps this explains the phenomenon but it does not excuse it.

What smart objectives for the profession does certification contribute to?

In order to meet the functional requirement "to be able to analyse change requirements" in what way does a jargonised method implement it?

The facts are that a significant proportion of BAs embrace jargonised methods and demand certification - and no-one else does!

I think we are trying to dress up in fancy uniforms and claim to be 'professionals' (whatever that actually means) whereas the reality of it is that we are far more like unregulated tradesmen.

Consider a gas fitter and a builder. The gas fitter (in the uk) is regulated and has to (by law) be CORGI accredited and work done on gas installations by non-accredited CORGI workmen is not permitted.

There's a driver here to try and prevent accidents due to faulty installation of gas appliances and the smart objective for gas fitters is to maintain their CORGI compliance and so maintain their ability to trade.

The builder doesn't have to be accredited by anyone to do anything.

Likewise there is no legal (or other recognised) imperative for Business Analysts. Hence we are the builders not the gas fitters, like it or not. That being the case the objective "maintain IIBA/ISEB/whatever certification" does not address any recognised drivers.

.

BA certification - what are the benefits?

As a Business Analyst I have wondered what are the benefits of BA certification and who is benefiting? To try and work that out I thought about the reasons why BAs should be certified.

Is it to measure the ability of the BA to do the job? Is it to try and get some consistency in the quality of analysis that is being done? Is to to increase the status of the profession?

Then I look at the 2 certification schemes available to BAs: the ISEB Diploma in Business Analysis from BCS and CBAP from IIBA and here is the thing: I have yet to see a job that has a mandatory requirement to hold either of these and yet if certification was proving the ability of the holder to do the job and ensuring consistency in quality of deliverables surely the employers would be demanding their employees have the certification?

Now I look at various functional requirements that exist for these certificates and I find (amongst others):
1. both require passing exams
2. both require money to be paid to the accreditation organisations for the exams.

Let's take the subject of exams first. I have a mathematics 'O' level I got 30 years ago that I am pretty sure I could not pass now. What does that mean? It means that 30 years ago I knew enough to be able to pass a mathematics 'O' level and not much more. Worse still: suppose I had an accident and became brain dead on a ventilator: I would still be more eligible academically than the brightest but unqualified candidate for a job that demands a mathematics 'O' level. This illustrates the absurdity of exams.

Now exam fees. I can see why exam fees are needed: someone has to pay for the provision of the administration of these exams.

But no jobs demand these particular exams and anyway exams (agruably) prove very little and may rule out otherwise excellent candidates!

So to summarise: someone has to pay for the provision of something no jobs demand and which prove very little anyway.

As a Business Analyst if this was a project I was analysing requirements for I would raise the issue that there does not appear to be any inherent benefit for the expense - unless I was working on the project for BCS or IIBA!!! :-)

I would be extremely interested to know the justification for exams and the current certification programmes - has anyone any views on that?
.

Do BAs need a way to do analysis emotionally?

Analysis communicates with the rational side of people who want to be rational. As BAs we have all kinds of methods and structures and approaches for doing that. Too many.

However, the question remains: how do BAs communicate with those operating at the emotional level (cos they have abstracted what they think they need to know already)? We don't have a framework for doing that: we have the emotional intelligence people and all kinds of "take a swim in lake you" gurus, what we don't have (or I am not aware of) is a framework for doing analysis using emotions rather than logic! And - of course - it is not black and white: people do not operate either rationally or emotionally - it is a mixture...

Doing analysis by emotions rather than logic?!? How does that work? It would be the only genuinely new approach I have seen to BA over the last 20 years... It has set me thinking...

.

Why humans don't like to analyse

.
Humans have evolved because they survived. They survived by exploiting their key advantage over competitors: the ability to use rationality to solve problems (such as how do I get away from the sabre tooth tiger?).

This rationality is expensive in terms of time and effort. It takes time and mental effort to reason: "I have observed and have also been told that sabre tooth tigers eat people so really I should ensure that I am not at risk of being attacked by one".

Far more efficient to just react with fear at the sight of the tiger and run away, making rational choices about which way to run perhaps.

So that fear came from somewhere. Sure: it came from the abstraction of the rational knowledge about sabre tooth tigers. The abstraction (i.e. the emotion of fear) is far less expensive to process than rationality. It is quicker and easier.

The problem is this: the abstraction does not admit new knowledge. If the sabre tooth tiger said "Hi, did you know I am now a vegetarian?" we would already be too far away to hear it and we would have no evidence that our fear reaction strategy had not worked yet again.

So people trust their emotions (abstracted rationality) as as they think they are quick, easy and reliable.

Now the nasty bit for us business analysts: we come along and try to get people to formalise their rationality in to analysis of their requirements. Perversely, they have already abstracted the knowledge that this analysis business is expensive and hard in to the emotion "dislike". What they do like are emotional reactions (quick and easy). So they don't like doing analysis and they worked out why rationally and that reasoning has been dropped as now they only need to know they don't like it.

Rationally they will agree (if they hang around long enough to discuss it with us) that analysis is necessary but that doesn't mean they have to like it and (usually) they don't.
.

Friday's rant

If one more person tells me that the key skill of a BA is to be able to communicate at all levels blah blah blah I will have to (censored) them.

This is equivalent to saying the key role of a systems designer is to communicate when actually the key skill is probably in knowing the technicalities of doing systems design. Its a technical job!

The key skill of a Business Analyst is the ability to analyse! Check out the name of the role! D'oh! This is also a technical job: doing analysis is very technical involving a high degree of applied logic, consistent and rigorous application of technical terms and concepts and the production of technical documentation defining the requirements. Not describing them or outlining them but defining them.

This is a hard, technical job.

If you want some technical support in this role, visit smart-BA where we put the analysis in to analysis!
.

Put the ANALYSIS (back?) into Business Analysis

Analysis.

Easy to say, hard to do.

Easy to say "I analysed the situation" but just what did the analyst do? HOW did they do the analysis. Do they even know what 'analysis' means?

In a nutshell, analysis is the process of breaking a problem or situation down to expose the logical inter-relationships (cause and effect, dependencies, etc) that exist between the component parts.

There are 2 main types of analysis: deductive and inductive.

Deductive:
Fact 1: All fairies are pink.
Fact 2: Tinkerbelle is a fairy.
Deduced fact 3: Tinkerbelle is pink.
If fact 1 and 2 are true there is simply no alternative to the fact that was deduced.
The process was break down the situation in to 2 empirical facts and then combine them deductively.

Inductive:
Fact 1: Whenever I have let go of the hammer it falls to the ground.
Induced fact 2: Every time I let go of the hammer it will fall to the ground.
The process was to break the situation down to 1 empirical fact and then try to establish a truth by generalising it. The principle here was to induce that because in the past every time I let the hammer go it fell to the ground that every time past, present and future I let go of the hammer it will fall to the ground.

What - even if there is a table in the way?

Induced conclusions are not as robust as deduced conclusions.

Meanwhile, back in the real world, it is interesting to note that most of our analysis (whether we recognise it or not) is done inductively.

It would make sense to make our conclusions as robust as possible.

Perhaps we should exercise a good deal of care in breaking down the situation or problem in to its component parts? Perhaps we should try and demonstrate the relationships between those parts so that they can be verified and tested?

Now we are talking business analysis!

Want to know more? Want to try it out in the real world on your project?

Now you need to visit www.smart-ba.com!
.

The 'law' of diminishing impact?

Get the project objectives wrong and you might just as well pack up and go home. I mean just forget the whole project: it will be delivering the wrong change as the objectives define what measures have to change and by how much in order to be considered a success.

Get the size required for a comments attribute on a minor entity wrong and - even if someone notices and cares - it won't matter significantly in achieving project success.

In between these two polar extremes of project analysis deliverables lies a hierarchy of deliverables that (as you progress down the hierarchy) the impact of getting wrong diminishes (in most but not all cases: miss out the order no attribute on a sales ordering solution and you probably can't achieve project objectives!).

At smart-BA we understand this stuff and the practical application of it. That's what makes our online training programme different: you get mentored by people who know it, live it, breath business analysis.

Project Manager Vs Project driver conflict?

Accountability for the delivery of project lies with the Project Manager.

The success of the project is defined by the how well the benefits are realised.

Therefore accountability for benefits realisation lies with the Project Manager.

It is worth noting that a lot of project managers are judged on project delivery on time and to budget. The project itself will be judged on benefits realisation. This can be unfortunate as what actions a project manager should take to deliver a project on time and to budget are not always the same actions they should take to realise the benefits of the project deliverables.

What a bummer.
.

Business Analysis jargon

Here is a secret - I think business analysis is crammed full of jargonised overcomplicated psuedo-I.T.speak.

The basic principle of business analysis is analysis. Analysis is a simple method. Science manages to uncover new knowledge with just one method. Ok, business analysis has a different objective to science (business analysis is there to define requirements for change) but it has hundreds of methods! Does it really need so many? And then each method can be implemented with loads of different approaches!

Why not have a new BA jargon generator: you start by selecting your approach and method (say Agile Six Sigma - I'll call this new BA system ASS) and then for each of the standard components for analysis (drivers, objectives, requirements, processes, data etc) you generate new jargon (ASS-drivers, etc) - a powerful quick start-up piece of jargon for ASS is kick-ASS: I'll make up what 'kick' starts for later or you could suggest some for me???

For that matter, generate some new jargon for ASS yourself and add it here - this can be the birth-place of (yet another) new and different piece of jargonised rubbish peddling the same old piss in a different shaped bottle!

If - on the other hand - you want a refreshingly straightforward approach to Business Analysis pop over to smart-BA - we aim to focus on just the analysis: why not? It's crazy enough to work!

P.s. although we might now consider launching smart-ASS...

a different way of learning about Business Analysis

Instead of classroom based learning with a contrived case study, why not learn about business analysis in the real world on a project you are working on? If only you could have access to a highly experienced mentor and follow a structured modular programme nothing could be simpler.

Well that was the concept behind www.smart-ba.com - progress your own work, learn in detail about business analysis and complete a project you are working on.