I see at least 7 distinct themes here, each of which deserves a separate article:
1. Inadequate or outdated HR job description of Business Analyst.
2. Problems with recruitment/consulting firms’ descriptions of open business analyst positions.
3. Industry definitions of "Business Analyst."
4. Organizational change management.
5. Boundaries between business analysts and Enterprise and Solution Architects.
6. New, as yet undefined positions that are being called “business analyst.”
7. Conflicting training methodologies and recommended tools.
8. The importance of online communities.
Here are some thoughts:
BUSINESS ANALYST HAS ALWAYS BEEN AN ALL-ENCOMPASSING TERM
In my own career, I have been hired for positions with the title, Business Analyst, where the actual job role was: • Data Analyst • Management Consultant • Process Consultant • Project Manager • QA Lead • QA Tester • System Analyst
In Britain the term Business Analyst may also refer to a Financial Analyst. This was also the case until quite recently in the US.
THE PROFESSION IS EVOLVING FASTER THAN THE JOB DEFINITION
It is not up to HR to understand what BAs do.
Any definition of business analysis must be expansive and able to adapt to change, rather than being restrictive and static.
The answer is not a more rigid definition, but a more fluid, flexible and dynamic one.
In a forthcoming article on Modern Analyst.com, I write, “Traditionally, business analysts have been forced to sit at the children’s table during Thanksgiving. They are not usually allowed to play in strategic spaces, or poke their sticky little fingers into senior leadership dilemmas. ”
Recently, our sticky little fingers have been poked in an increasing number of tasty organizational pies.
“COMPUTING MACHINERY” ITSELF IS EVOLUTIONARY
I highly recommend the esteemed and venerable organization The Association for Computing Machinery, (http://www.acm.org/) which was founded in 1947.
They are a reminder of the sheer breadth, scope, diversity, history and intellectual rigor behind our industry.
Methodology lags behind technology, just as technology (Techne) lags behind science and art (Poesis).
Sam Cherubin
Nathan: Just a note -- I think you inserted a typo that fundamentally changes the meaning of one of your statements:
"Independent organizations foundered in an attempt to support Business Analysts and provide understanding into the profession such as the IIBA are seeking to achieve a level of respect to fortify the profession, though as the world changes; the profession loses respect due to unqualified and under skilled professionals operating in this space."
It took me aback for a moment -- have organizations like IIBA really "foundered" in their efforts? I think the IIBA in particular has been extremely effective and is doing many, many things not only right, but very successfully. So I'm guessing you meant "founded", not "foundered". (I'm not trying to be picky, just wanted to help other readers not end up trying to read more into your statement than you intended!)
On the other hand, I was certainly cheering as I read your statement just before: "Moving forward, it is important to take the profession as business analysis as seriously as possible due to the nature of the role. A person operating in this profession can make or break an organization based on their ability to listen, understand, interpret and present facts in the form of requirements of both internal and external parties." Here here! Apparently Fidelity recently commissioned a study of what are the primary causes of software project failure TODAY; and they got essentially the same results as the Gartner Group got a decade ago -- bad requirements are still the main culprit!
Thanks for your analysis!
-- Larry Ackley (Senior Business Analyst & BA Mentor -- larryackley@verizon.net)
Hi Larry,
Thanks for the great feedback, and well spotted on the typo. This is definitely a typo as I hold IIBA in high regards for their work into our profession. They are a very respectable organisation and I hope that their momentum continues into the future.
I have sent a request for the editor to fix the typo as I do not want people to misunderstand my point in the article.
It is not surprising that bad requirements are still the main culprit for project failures, every day I see bad requirements and the impact they have on organisations. This would be a great subject to write about from a Business Analyst perspective and why bad requirements are often misunderstood as good requirements.
Thanks again
-- Nathan Fulton
Hi, Larry. I am an IT recruiter and trying to learn the BA/BSA field so as to create a focus on it...and so that I can do a better job both finding correct talent for my searches and also to help HR define exactly what they need. These articles/comments are extremely useful.
I attended this webinar last night:
BABOK® version 2.0 Release Party Presented by Kevin Brennan, CBAP, Vice President, Professional Development
In tha article, Kevin demonstrated in a pie chart exactly what you mention above. The dismal success rates of projects (especially software are due to poor requirements. 50% responsible....50% of the pie.
The interesting thing is this. There were several other much smaller slices. Two of those slices being "Lack of Qualified Resources" at 3% and "Poor Communiction" representing 14%.
Kevin's theory is that everything is in reverse. Lack of Qualified Resources and Poor Communication are actually the "causative roots" for the Poor Requirements Definition.
It sounds to me like this is a bit of a paradigm shift for the BA market. I think people have just accepted the Poor Requirements Definition model and not looked deeper into the problem...thus, self perpetuating. Is it one that we should embrace...or not?
=======================================
My other point that feeds into the "Poor Communication" vein is this. It seems to me that Communication and Leadership are tools that are the foundation for being a good BA/BSA or PM. One can be an absolute black belt in any methodology...or several, yet if they cannot communicate their ideas to an organzation in a way they they are adopted (leadership!!!), then these theories, methodologies and ideas are meaningless. How many times have you met with stakeholders who met you with closed arms and smirks on their faces. If you can't penetrate that, you are cooked.
My contention is that communication courses should be mandatory in the certification process in the BA/BSA/PM field. We must become as good at communication as process.
Case in point: I was at an AGILE (APLN) round table discussion just recently. A fellow sat next to me who made several public smart alex comments (the first one was funny, but #2 and then #3 became increasingly annoying), seemed quite introverted and closed off, and then proceeded to chew ice that I know the round table participants could hear. (we were only two rows back) My first thought was, "who in the hell is going to follow this guy in ANYTHING???!!!" He is rude, obnoxious, and inconsiderate. I could care less what he knows.
I would be interested to hear your thoughts.
- David
@David - A Good Communicator is first generous with their listening, very closely followed by generous with their ideas. I believe that if someone chews ice at a meeting and happens to to also have a great deal to offer to the project, then it is professional to control my thoughts, put aside my own pre-conceived judgements and make use of what he has to offer. As the relationship builds, then decide if it's a noise issue or your own issue and take it from there.
Only registered users may post comments.
|