Jonathan Kupersmith has a great article over at the Business Analysis Times, titled: Business Analysts are Set-up to Fail
In my experience working for (and in partnership with) global companies, analysis is often done by teams consisting exclusively or mostly of junior analysts. I believe this is because in many organisations, analysis is seen as little more than stenography, so they put the cheapest people on the job – usually graduate trainees.
Hardly any of those junior analysts ever get full systems lifecycle experience, so they never learn to appreciate the perspective of the developer or the tester (see It’s about the software and The customer isn’t the only consumer).
I'm senior because I've outlasted the rest.
Most of them stick around for years, getting no further mentoring or training and end up as senior analysts because of their “years of experience” rather than any serious ability.
I once worked with a senior BA, with twenty-five years’ experience, whose idea of eliciting, documenting and analysing requirements was to copy and paste a set of meeting notes under each requirement Id. The worst thing about that was everyone else on the project assumed the way he did it was just the way requirements analysis was done, so never questioned WHY it was so poor. Flaws due to a lack of any actual analysis were fixed during UAT and that was just accepted as normal.
When I came along and suggested such things as visual modelling of flows and use cases and business rules catalogues and message catalogues and (most bizarrely of all) a requirements traceability matrix, I was seen as an upstart (until I proved myself).
What is the result? The BA Experience (as Kupe calls it) is poor for those who have to consume the output of junior BAs (junior in ability, not years). I think this is why so many developers think they could do as good a job as the BAs. They probably could!
Kind regards,
Declan Chellar
Hi Declan;
Firstly, it is on my list of new year resolutions to visit your site more often; I find your blogs lucid, articulate, accurate and easy to relate to. I think I can definately learn a lot from your blog, and I thank you for writing it.
This post gets me wondering a few things… firstly, you immediately reminded me of this excellent post from Craig Reid/The Process Ninja: http://www.theprocessninja.com/process/2009/06/building-sandcastles-why-the-world-needs-process-analysts-not-business-analysts.html
He talks of a difference between a BA and a Process Analyst, and I think it’s a valid point.
Although, I do wonder if it’s less a distinct difference between the two roles, and more that the tech platforms that clients are migrating toward (and the business empowerment opportunities they provide) are ultimately demanding a more consildated skill-set with a focus on process.
Are you finding clients/companies are starting to become a little more “switched on” in terms of what they want and expect out of their Business/Process Analyst capability?
Thank you for your kind and encouraging words, Ryan.
I have had a look at Craig’s post and I commented. For your convenience, here is a copy of my comment:
“I agree with you that Process Analyst is a specialised skill and it is not the same as, say requirements analysis.
However, I have always thought of Business Analyst as a (poorly defined) umbrella term that covers many skills, including Process Analyst, Information Analyst, Business Strategist, Requirements Manager, and so on.
I don’t disagree with your point at all, however, and I have seen companies put BAs in place as process analysts because they have domain knowledge, but who do not know how to model a process.”
I don’t think a specific technology has much to do with modelling a business’s processes, at not at the pre-selection stage. How can a business select a technology unless the business can say to the vendors “Look, this is more or less what were are trying to achieve as a business”. However, a business might seek to take advantage of a technological concept in general, (e.g., smart phones) and take that into account in their model without picking a specific platform.
However, once a platform has been chosen, then a technology-gnostic view of the processes needs to be modelled, taking into account what the platform/software can add.
I actually don’t think companies are switched on at all as to what they want out of their BA (in its umbrella sense) capability.
Kind regards,
Declan