Main Content RSS FeedFeature Article

It’s Good to be a Business Analyst II »

Welcome! This site specializes in providing tips and tools for Business Analysts and systems development in general. If you're new here, you may want to subscribe to my RSS feed. If you'd prefer, you can also receive my posts directly to your e-mail. Thanks for visiting!

I’ve said it before, and I’ll say it again: It’s good to be a business analyst!

Not long ago, CIO.com ran an article entitled, Why Business Analysts Are So Important for IT and CIOs. The article has apparently piqued the interest of many business analysts as I’ve seen it mentioned in various blogs and discussion groups.

It is exciting that reliable research firms like Forrester are producing reports such as this that acknowledge the value of the BA role and provide such a positive outlook.

I wanted, first, to point out the article to those of you who may not yet have read it; second, to share some of my own commentary on passages that I found particularly interesting. So, here we go:

What is clear: The most successful business analysts are the ones who blend the temperament and communications savvy of a diplomat with the analytical skills of an intelligence officer. And business analysts are a hot commodity.

I found the comment on the mix of skills interesting - and hey, when is the last time you were told you were a “hot commodity?”

The best candidates are business-oriented business analysts who want more direct control over how business processes are automated, and IT-oriented business analysts who want to move from IT into the business.

I really like this passage because I’ve argued time and time again that the business analyst role is not just a software development and IT role. Corporate business units benefit from having a trusted adviser who understands how technology can be applied to solve business problems. The business and IT both benefit when an analyst can get engaged with decision makers early to help them define business problems and articulate their needs in the form of business objectives and requirements; not solutions.

To ensure that the business technology analyst role is coherent, supported and ultimately attractive, CIOs should establish a forum in which these folks can share best practices, such as a business technology analysis center of excellence.

Wow. I found this to be a very interesting idea. I can see consulting companies doing something like this, but I wonder how many typical companies with IT shops and BAs actually have such a center of excellence, or are moving in that direction? I’d be very interested to hear of them, and how it is working out.

Finally…

In the end, the more business technology analysts that are working in the business, the better off the CIO and IT function will be—no matter if the BT analysts are reporting into IT or the business side. That’s because those IT-savvy analysts, who will have a more in-depth understanding of and more expertise in technologies, will “ultimately help the business make better decisions when it comes to its interactions with IT,” contend the Forrester analysts. And, “CIOs have new allies in the business.”

What a fun and informative read. If you haven’t, go read the article. I’ve only touched on a few of many good points, and there is lots of other interesting insight in the comments section.

Hopefully this won’t be the last article of the kind, and I’m confident it won’t be. It really is good to be a business analyst.

  • Bookmark this page

    Post to del.icio.us Digg this!
  • Twitter Updates

    • Products & Services

    • Recent Visitors

    Main Content RSS FeedRecent Articles

    Documentation is No Substitute for Interaction »

    I’ve long been of the opinion that involving as many stakeholders in the project as early as possible is a key to successful business analysis, and, more importantly, to successful projects, and have said as much in a few of my posts on this site.

    Jim Highsmith, in the book Agile project management : creating innovative products, thinks that the reason projects tend to have so much documentation and so few results is that:

    More on User Stories »

    In my business analysis group, we identify user requirements through use cases, but we don’t use user stories. As I am not extremely well-versed when it comes to some of the agile methods, I thought I’d do some research to learn more about user stores and to determine how user stories are different from use cases and from traditional requirements.

    Weekly Digest - 8-17 »

    Here are some links to interesting articles and information I’ve found during the past week.
    If you’ve ever doubted the need for requirements elicitation for an ERP project, you need to read this. Apparently a company is suing an ERP software vendor because the software it was expecting to work in a promised date did not […]

    Weekly Digest - 08-16 »

    Here are some interesting items I’ve come across over the past week or so that I’d like to share.
    I read a though-provoking article the other day by Tony Lock on why IT is still not communicating well with its business counterparts. Per Lock:

    [F]ew organisations have formally established and monitored service levels reporting in terminology and […]

    New Tools - and Their Implications »

    On this blog we’ve talked about the imprecision of natural language and the problems it can present in drafting requirements. Forget requirements - what would you think of a tool that could turn natural language into software code? Sounds crazy, doesn’t it? Well, there is already such a tool in the works, although it’ll probably still be a while before they’ve ironed out all the wrinkles.

    Looking the Part »

    Ever heard the expression that you should dress for the job you want, and not the one you have? I read this interesting little passage a few weeks back and just thought I’d share.
    Today in business, “looking the part” has definitely resurfaced as a priority in the eyes of many decision-makers. Perhaps that’s why so […]