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.

Originally posted on JonathanBabcock.com as:

It’s Good to be a Business Analyst II

Some recent articles I’ve read and training that I’ve received has taught me how important a clearly defined business strategy is to meeting organizational goals. What’s more, it’s now plain to me how important the corporate strategy can be in helping to make business and technology decisions. Here’s a quick and (probably overly) simple example I made up to illustrate the point.

Strategy As a Point of Reference

An internet host has built a strong market presence as a low-price, highly reliable provider. In fact, the “quick and dirty” articulation of their strategy was that they would provide the highest rate of server uptime at the lowest price in the market. Their success was based on their ability to do just that.

They arrived at this strategy as a result of competitive analysis of the market that indicated that they had competitive advantages that could be leveraged to differentiate them from their competitors in the areas of price and reliability. As their clientele grew, they began to think of new ways that they could provide value for their customers to solidify and grow their position in the market.

One idea was that they could provide a service to build simple websites for subscribers that wanted it free of charge. By so doing, they could provide more value to their customers, and potentially tap a new market segment; that of customers that want to go “online” but are not computer savvy.

It seemed like a good enough idea, and many decision-makers were initially in favor. As they discussed further, though, they asked themselves how the idea aligned with their strategy as the low-cost, high-reliability provider. Providing a free service would cost the company man-hours, meaning that to maintain their margins they’d likely have to raise prices and risk their position as the low-cost provider. Providing Website services also did nothing to enhance their image of reliability.

Because the new service didn’t support their corporate strategy, they decided not to take it on.

What if they didn’t have a clear corporate strategy? May the decision have been different?

How is this important to the business analyst?

As a business analyst, it is important to know your company (or client’s) strategy so you can ensure that proposed solutions - IT or otherwise - align with where the company wants to be and how it wants to go about getting there. It’s not always enough that “the customer wants it” or to show potential for quick financial returns to justify a business case. While it would be nice to be able to be all things to all people, that just isn’t realistic in most cases. How does the proposed project support company strategy? Does it at all? If not, should we be doing it?

Those are powerful questions and are sometimes difficult to ask, especially of a Sr. Executive about his pet project that, according to him,is going to “solve world hunger.” As a business analyst, one of the ways we can add value is by asking these types of tough questions. An appeal to corporate strategy is an appeal to the overall company vision. While strategy evolves over time, it likely won’t change rapidly over a short period of time because it is usually structured around getting the most out of the company’s core competencies and differentiators.

As a Business Analyst, we may not necessarily be involved in defining strategy, but we do need to be aware of it, and use it as a reference point when helping business stakeholders make important decisions.

Originally posted on JonathanBabcock.com as:

Corporate Strategy and the Business Analyst

• There were between 50-60 attendees.
• At least a quarter of attendees were attending a chapter meeting for the first time.
• It was mentioned that there are approximately 100 members in the Atlanta chapter of the IIBA.

When asked for a show of hands,

• Approximately half of the group indicated that they currently use cases to expresss user and functional requirements.
• Approximately half of the group does UML modelling other than just for use cases (activity & sequence diagrams, etc.).
• Very few - I estimate less than a quarter - use a requirement management tool for traceability.
  Of the group, there were probably 6-8 CBAPS in attendance.

Originally posted on JonathanBabcock.com as:

Random Observations from the February Atlanta IIBA chapter meeting

First off, it was a good time. I went with a co-worker, and we arrived fairly early. Showing up early gave us an opportunity to meet and visit with chapter president Jonathan Kupersmith (aka “Kupe”) and a few other BA’s. I’m a longtime fan of his company’s business analyst blog, and it was nice to be able to discuss the business analysis and blogging for a few minutes with Kupe. After food (quite a bit, actually) we heard an interesting presentation by Keith Barrett of the Sky IT Group.

He presented a formula for accelerating the requirements lifecycle. The gist of the presentation was that for the past several years, companies have been focusing their resources on tools to aid in requirements management, with the promise that tools would improve requirement quality. In fact, while those tools have matured and become very good at what they’re designed to do - manage requirements - they have not done a great deal to improve requirement quality.

He anticipates that the next frontier in improving the requirements lifecyle will be to improve quality of articulating and and communicating requirements, and that to do so, focus will be turned to ways of visualizing and simulating requirements. All in all, it was an interesting presentation.

As it turns out, I understand that a related presentation will be made available via the web in what I presume will be sort of a “webinar” format. Thanks to Requirements.net for the info.

All in all, the meeting was a very positive experience and I’ll look forward to attending future meetings and events.

Speaking of Requirements.net, it was at the meeting that I initially heard of the website, so I rushed to check it out. In their own words,

Requirements.net is home of the industry consortium for business analysis. Through focus on requirements definition, visualization, and management, the companies behind Requirements.net are driven to share and sponsor best practices and technologies to improve industry requirements practices.

“Consortium” members appear to be HP Software, Blueprint, RQNG, Orasi, Sky IT, and CorTechs. Between the blog, the whitepapers, podcasts, presentations, etc., it looks like there will be something there for everyone. It will be interesting to see what types of problems they’ll tackle, and how they’ll go about doing it. In any case, go check them out. It looks like requirements.net may become another nice resource for business analysts.

Originally posted on JonathanBabcock.com as:

IIBA Atlanta Chapter Meeting & Requirements.net

I’ve noticed a recurring discussion around various business analysis-oriented websites of late concerning the relevance and value of the Business Analyst, especially in an agile environment. Some argue that with agile, “business analyst” responsibilities are carried out by software developers or technical architects, eliminating unneeded layers of communication (read; BA’s).

Karl Wiegers, one of my favorite reads on software methodology, addresses the topic briefly here.

One of the points he makes, and with which I agree is that we can “[t]hink of the analyst function as being a project role, not necessarily a job title. This role can be performed by various people on the project who have the skills, knowledge and temperament for it.”

That’s where I think the IIBA may find peace with certain agile evangelists (see the comments section - link requires registration). Depending on the environment, developers could certainly be called on to carry out some of the software related “business analyst” responsibilities. I don’t think that marginalizes the broader role of the Business Analyst, though. “Who does what” in a company is governed by any number of factors, including budget, headcount, and the available skill sets among the company’s pool of employees, to name just a few.

Wiegers goes on to warn that some developers may not be comfortable wearing the “analyst hat.” I can relate - in reverse fashion. A number of years ago as a new consulting analyst I was staffed on a project as a software developer. I like to think I did a fairly decent job, given my lack of experience and training, but I won’t even pretend that my performance would have matched someone with training, experience, and who enjoyed software development. Additionally, while I was willing to fill the role, I didn’t (and don’t) particularly enjoy coding software.

To that I’d add that even if the developer is great at analysis, sometimes business solutions just won’t involve software development. Who does the analysis for those projects? From my humble vantage point, business analysis is not at all limited to requirements for software development solutions. If a Business Analyst’s role is to identify stakeholder need, and then help identify the best solutions to meet those needs, then it seems perfectly reasonable that some solutions will not involve software development at all. This is where what the IIBA refers to as “enterprise analysis” comes into play.

Some solutions may involve tweaking business processes through personnel (staffing) changes, changes in sales or marketing approach, or myriad other ways that may not even require the first line of code. In these situations, I’m not sure how interested software developers are going to be in fulfilling the responsibilities of the business analyst.

For me, the bottom line is that there is a place for enterprise business analysis, and a place for software requirements analysis. Often, those roles will be filled by a business analyst, but they don’t have to be. Different methodologies work better in different environments. In some shops, agile is the way to go. In others, it’s a waterfall or some derivative of the waterfall method that makes the most sense. While the titles of who performs the work may differ, business analysis skills are critical in any methodology.

Originally posted on JonathanBabcock.com as:

On Business Analysis in an Agile Setting

This post is based on a quote I read and liked from the article, “When Requirements Go Bad: Part II” by Kurt Bittner. The article is available from Dr. Dobb’s Requirements Development e-zine (free subscription required). According to Bittner:

We need to banish the practice of writing requirements that we can “throw over the wall” to developers or testers and instead pursue a more open, communicative approach. What is important to realize is that requirements are what motivate discussions, but it is the discussion that matters most.

Well said. While I’ve taken an occasionally rocky path to get there, my experience as a BA has led me to the same conclusion.

Tough Lessons Learned

I’ve worked projects in the past in which we would spend 3-4 weeks of requirements analysis with various users and stakeholders and then bring what we considered to be, for all intents and purposes, a “finished product” to be signed off by the design, development and QA teams.

Needless to say, those sessions were often not the most enjoyable. The dialog that the teams needed to ensure that they understood what they were expected to deliver had not taken place, and they just didn’t have enough familiarity with the project to be comfortable signing what was, by all appearances, a blank check for their labor. Of course, we worked to resolve concerns and improve the specification, but this meant adding days, and sometimes weeks to the requirements phase of the project.

Here’s one solution..

One thing my team has done that has been working much better it to pull together a quick, unrefined, “skeleton” requirements document as quickly as possible, and then invite the project team for a requirements “working session.” Note, I am careful to not give the impression that it is a formal review session or that there is any expectation of the participants other than that they express their thoughts, questions and concerns. This helps to establish them as true stakeholders in the project and to assume a collaborative role and not just a reactionary one.

One thing that I think we, as business analysts, occasionally forget is that the downstream delivery teams are our customers, too - and in a very real way. We need to make sure that they have an opportunity to develop a true sense of ownership for the project early on and that they understand what the requirements are all about.

Now, regarding these working sessions - By default, I plan for 3 iterations of these before bringing a document before the team for approval. Obviously, we’ll hold more or fewer sessions as necessary.

Mitigating the “waterfall effect”

Another benefit of these iterative working sessions up front and earlier in the requirements analysis phase is that you mitigate the “waterfall effect”, or the notion that one phase be entirely complete before work begins on the following phase of the lifecycle. I think this is what Kurt Bittner was referring to with the “throwing requirements over the wall” comment.

What I’ve found is that, be it in theory or in fact, design doesn’t wait until the final review is over and documents are signed. After the first iteration, designers, developers and QA folks are able to start mulling ideas. Sometimes they’ll hold a whiteboard session right after the meeting. If not to design, to start thinking in terms of impacts to systems, and brainstorming design options. With each iteration the they have a clearer idea of what the project will require, the constraints they’ll be working under, and the technical challenges they’ll need to work through. By the time we’ve been through a few iterations, they have a pretty good idea of what the design will look like, even if it hasn’t been fully formalized and documented.

Another thing that has become easier with the notion of this more team-oriented approach to functional requirements is that the approval process is much, much easier. Document signatories don’t feel like they’re signing their lives away without understanding the fine print. They feel like they have ownership in the document, and they understand that their approval simply means that requirements are “complete” to the extent that design and development can proceed with a comfortable level of risk. If further changes or iterations are required, we’ll get back to the table and work it out through the change management process.

Anyway, this is something that has worked for my team. In our shop, we refer to our methodology as sort of a “modified waterfall”. We do identify and track to different phases, but we’ve also adopted some more agile practices in that our requirements and design processes are purposely both collaborative and iterative. You might say that if we have a “wall”, at least it has a nice, large, open door in the middle!

What types of things have worked for you to improve the lines of communication and collaboration in your requirements process? Please feel welcome to comment on this post, or contact me.

Originally posted on JonathanBabcock.com as:

With requirements, discussions matter most

The “Junto”

For some reason, last week I picked up and began reading from Benjamin Franklin’s autobiography. In it, he mentions a mutual improvement society that he and several of his acquaintances founded in colonial Philadelphia to compare ideas, to critique each other’s publications, and to gather sociably. They called it “Junto.” The idea behind Junto was that in gathering like-minded individuals with a common cause for civil discourse, all participants stood to benefit.

From Wikipedia:

Franklin organized a group of friends to provide a structured forum for discussion. The group, initially composed of twelve members, called itself the Junto (Latin for meeting). The members of the Junto were drawn from diverse occupations and backgrounds, but they all shared a spirit of inquiry and a desire to improve themselves, their community, and to help others.

That association drew me to think about our day, and about the field of business analysis. What a wealth of information is available and easily accessible to us today! Through blogs, e-zines, messages forums, professional publications and social and professional networking groups one can learn a great deal about business analysis and the broader use and implementation of technology to solve business problems.

I subscribe to and religiously read dozens of feeds and online articles each day to try to learn new tricks of the trade, make professional contacts, and to generally improve my skill and performance as a business analyst. With time, I’ve noticed that I often gain as much benefit from reading the work of normal, daily business analysis practitioners as I do from the established experts and renowned thought-leaders. For that reason I decided to begin this blog to contribute, perhaps in some small way, to that growing body of knowledge.

Anyway, I’ll wrap up my philosophical interlude now and get to the point of this post.

Add your voice

There are lots of good reasons to add your “voice” to mine and the many others that blog on business analysis, and other related topics. If you’ve learned some hard lessons, have some opinions on what works and what doesn’t, have some tips on how to do things better or more efficiently, etc., etc., then why not share them?

Forgive the following allusion, but I did major in marketing…. As the sample size of ideas on industry best (and worst) practices increases, we all gain a clearer picture of what those practices are. The IIBA is doing a great job of formalizing standards and methods in the business analysis body of knowledge. That said, the BABOK can’t and shouldn’t be expected to address all the aspects of any scenario that a business analyst may face. As I see it (and I’m of the impression that IIBA leadership would agree), industry best practices are not invented by governing bodies, but are proposed, tested and refined through practice and constructive discourse by everyday workers in the field - like myself and many readers of this and similar blogs.

As a single case in point, if you look around on the leading BA community web sites and blogs, you’ll find that a common topic is that of defining what exactly the business analyst is, and what exactly a business analyst does. There are lots of valid and interesting ideas floating around to which I’ve added some of my own. That’s where our modern BA “Junto” comprised of dialogs carried out via blogs, mesage boards, and networking groups comes into play. In my mind, we all have an opportunity to contribute in defining and shaping the role of the business analyst.

I’m not saying we should all go out and buy domains and webspace to set up our own blogs, but that we all find some way to participate. There are lots of resources available. If starting your own blog is not your cup of tea - and it isn’t for everyone - then you can add comments to others’ blog posts. Additionally, there are some great message forums and networking communities and websites in which you can participate and share what you know. See the blogrolls on the sidebar of my front page for just a few ideas.

If you have a new blog or have found a useful site dealing with business analysis or a related field (software development methodology, project management, communication, organizational skills, professionalism, leadership, etc.), and would like folks to know about it, please comment here to add the name of your blog and a brief description. The reach of my blog isn’t yet as espansive as many, but it is growing. I’d also be curious to know about you myself.

Anyway, I don’t anticipate a mass-movement as a result of this one simple (although admittedly long-winded) blog post, but hopefully a few of you will get off the fence and join in the collaborative, online BA community. Here’s to discovering many more valuable business analysis resources and contacts!

Originally posted on JonathanBabcock.com as:

A Call to Participate!

Thanks to Scott Sehlhorst for first bringing Kelly’s blog to my attention.

Originally posted on JonathanBabcock.com as:

All About Agile

There must be some blind spot that computer engineers have which prevents them from seeing that (1) most people are not computer engineers, (2) there is no point making simple things complicated, and (3) not everyone is looking for a zillion features to have to wade through to do simple things.

Let’s start at square one. What is the first thing you want to do with any computerized product? Turn it on.

Why should that be a problem when people were turning things off and on for generations before there were personal computers?Yet computer engineers seem determined to avoid the very words “off” and “on.”

Apparently they feel a need to coin new terms for everything, no matter how simple or well-known those things may be. For computers, the word is “start,” which you have to go to for either turning the computer off or on.

With our microwave oven, the word is “power.” For my car radio and cell phone, there is no word at all.

For other things, there is the same coining of new words for things people already understand by old words. Printers can be set for “landscape” or “portrait,” as if people had never heard of horizontal and vertical.

When I had to have a new radio put into my old car, I told the man who installed it, “I didn’t go to M.I.T” and wanted the simplest radio to use that he had.

Yet even the simplest radio he had in stock came with over 100 pages of instructions — and nothing on the radio that said “on” or “off.” In fact, none of the buttons on the front of the radio had anything to indicate what they were for.

What struck me about this article was the fact that I had never struggled much with the issues Dr. Sowell points out. I think there definitely is a generation gap when it comes to using electronic appliances and gadgets. Dr. Sowell, I am pretty sure, is in his mid-70’s, and he has a point in that usability for septuagenarians probably isn’t the first consideration for designers as they architect the latest and greatest in consumer electronics.

I’m no expert in the field, but I wonder if that isn’t a mistake. My grandma loves to write letters and I’ve been wanting to her on a computer for the longest time so she could discover the wonders of e-mail and instant messaging. She won’t have it, though, because it all just confuses her. I wonder how many of the millions of elderly folks in the world wouldn’t adopt new technology if it were just a little simpler and a little more user friendly. Nintendo seems to have hit the jackpot with the Wii. I’ve heard lots of stories of retirees in complexes for the elderly heaping the Wii with rave reviews for bowling and other games that are fun, but simple.

As business analysts, we often get knocked - and rightfully so - for not giving sufficient consideration to the end-user in general, and ease-of-use in particular when designing new systems and applications. Usability requirements are sometimes hard to articulate, but capturing and implementing them is very, very important to the a product’s success. Dr. Sowell mentions ease of use, lack of intuitive labeling and use of obscure terminology as a couple of his gripes. Let’s make sure to take these and other things into consideration as we participate in creating products that not only provide functions the business needs, but also provide the ease of use and features that the end-user requires.

Originally posted on JonathanBabcock.com as:

Economist Sowell on… Usability!

Successful business analysts have an ability to draw ideas to their logical conclusions. An analyst’s work typically requires assessment of concepts following a progression from the general to the specific, and other times from specific to general.

Progression from the general to the specific is what Business Analysts are most known for. This is where we take a high-level business problem and objectives and decompose them into requirements that represent functions and attributes of a system or solution. Nearly every job posting you’ll see for a Business Analyst will mention this need to be able to elicit requirements and produce the accompanying documentation.

Less widely acknowledged - although equally important, in my opinion - is the progression of rolling up symptoms and side effects of business problems into higher-level root causes and problem statements.

Here’s a simple illustration of a logical thought progression during business analysis:

And the point is..?

It’s not rare that I hear about a business owner who has heard about a problem or defect or two and, based on a few scraps of information, is ready to dive head-first into solution details. More often than not, this approach will lead to a solution that addresses symptoms while leaving the larger, fundamental problem undiagnosed and unfixed.

Organizations seem to have a tendency to skimp on root cause analysis. It can be a wearisome job requiring time and intensive research. However, if we haven’t done due diligence to identify and solidify root causes of business problems, how can we have a level of confidence that our solutions are fixing them? I think this is where the BA can really add value outside the traditional “writing up specs” role.

If a BA can get involved with the business decision makers early enough and help ensure that symptoms are traced to their true causes (which, incidentally, often turn out to be the causes of multiple other symptoms) and the business problem is succinctly defined, then a project has a much better chance of successfully solving the business problem.

Summary & Conclusion

• Business Analysts are skilled in tracing problems and ideas to their logical conclusions; from specific to general and from general to specific.
• Business stakeholders often mistake symptoms for business problems because they don’t do sufficient root cause analysis.
• Business Analysis skills can and should be leveraged to help define business problems.
• Projects are more effective when they address real business problems and not just symptoms.

Wouldn’t we all rather be involved in projects that we know will effectively solve business problems?

Alright, thinking about thought is tiresome, so I’m going to put down the virtual pen for now. What are your thoughts on the topic?

Originally posted on JonathanBabcock.com as:

Thought, Problems, and Business Analysts