So What Makes a Good Business Analyst?

Posted by LaxBrad / at 10:48 AM / / 0 comments

I have read many posts and blogs attempting to answer this question and while many have offered great insights and opinions, they have decidedly omitted describing what I think are key characteristics of a great BA.
When hiring a BA the first thing to ponder is why am I hiring this BA? What BA related role will they play in the organization? However, the top characteristics that I look for are:

1. Customer service skills
I believe that exemplary customer service skills are the most important trait that a candidate can possess. Incorporated into this skill set are the ability to communicate effectively at any level of an organization all the while ensuring that needs are being met. Providing good customer service means that the customer (client) feels that their needs are being met at every step of the process. That includes having their issues and problems understood and well defined prior to the design of the solution. Human nature dictates that we feel the most comfortable when we are certain that we are being heard and understood.
I look for individuals that have successfully held previous positions in the Hospitality Industry. Specifically in a fast food restaurant or food service capacity. The reason? Customers (Clients) can be the most demanding and assertive when they are hungry. Also, the volume of customers is also usually high, therefore the establishments usually has very well defined processes and procedures for the employees to follow. If the candidate was able to successfully ensure that the customer left happy repeatedly, then they usually will also be able to ensure that clients will repeatedly be satisfied. People that are drawn to these types of jobs are people that naturally enjoy satisfying other people's needs.

2. Ability to think strategically
The candidate must be able to think strategically. That is to say, they must be able to envision how the future could  look.  They also must be able to envision the path to be taken to get there. I liken this ability to a good croquet player. The croquet player thinks two three, even four shots in advance. So must the BA, they must think 3 or 4 tasks ahead of where they currently are and how that will affect the outcome of the process. The Senior level BA should be able to provide strategic thinking / planning at the enterprise level, while the Junior BA should be able to plan for a small Service offering (usually a single function / process), provided by a Program Area.

3. Breadth, not necessarily quantity of experience
Finally, I like candidates that have a broad range of experience. This applies to all levels of BA's, including Junior through to Senior. Obviously, a junior may not have any experience at all, but at least they may be able to demonstrate a range of experience through their first jobs (restaurant - retail). I look for BAs that have completed several different projects that have served a varied and diverse client base. I believe that it is better to have some knowledge of several lines of business than to be an expert in only one business area. That is not to say that you cannot be considered an expert in one area and still contain a broad range of experience.

I was once asked by a senior manager type who I thought made a better BA - A Technological Expert or a Business Domain expert? I surprised them with my answer: "I don't think either is any better than the other. It really depends on type of person they are and if the possess exemplary customer services skills. Technology and Business Domain knowledge can be taught, where the desire to satisfy another person's needs is more of an inherent characteristic".
Overall, I consider Customer Service Skills to be the number one attribute I look for, followed by Strategic Thinking and Breadth of Experience. Notice that I do not mention technological skills or knowledge. While I come from a systems development and software design background, I don't think that it is imperative skill set for a BA to possess.
What are your thoughts? let me know.....

Ready..... Set..... Launch?

Posted by LaxBrad / at 6:47 PM / / 1 comments

3 years ago we started with the requirements gathering session that included a brief overview of UML 2.0. The Working Group were an eager bunch and very passionate about their business. I thought this was going to be easy........

Having an engaged Working Group is the dream of any BA. These people were / are very detailed and thorough. I was in heaven. The requirements would literally write themselves. The users would do it all. My job was to ensure that the Junior BA captured the requirements as the users had described them. I soon learned that it was not going to be as easy as I thought. We soon got mired in the details of their operations that really offered no value to the project. My facilitation skills were pushed to the limits in trying to rein them in and focus everyone on the task at hand and then try to move on to more relevant topics.

The original schedule, which we knew was aggressive, was for a year from requirements to implementation. The requirements took the scheduled amount of time, approximately 6 months. The design proved to be more challenging and we decided to use an implementation of Oracle’s BPEL with a Java front-end. Design completed within 6 months and then it was time for the build.

AAhhhh the build. Yes, it was challenging to say the least. When we started, BPEL was new and unknown to our client’s IT department. Hell, it was new to our developers as well. But nonetheless, we soldiered on. It has taken 2 years to build the application but that includes interfaces to 5 external data partners (we go and get information from them) and 2 external requesting agencies, that automatically request information from our system. Essentially, we ended up building 8 applications for the price of one. The application is by no means perfect and defect free, but it blows the old application out of the water.

3 years in the making and we launched on October 15th. The development team couldn’t be more ecstatic, the client (sponsor) is very happy as well.

The users? Well, I guess they’re ok with it. It’s kinda anti-climactic when a state-of-the-art, amazing application that interacts with no less than 8 other distinct and very different systems (I wish I could give you the deets), is received with a yawn, maybe even a snarl, from the users. It’s not your regular user apathy, it seems like true distain.

On to the next fantastically unappreciated project.......

A couple of thoughts on Enterprise Architecture

Posted by LaxBrad / at 1:52 PM / / 5 comments

A couple of questions that has been nagging me for quite a while are: Does Enterprise Business Architecture encompass IT Architecture? Why are people confused by the term Enterprise Architect?

The struggle, it would seem, is all in the language. I first heard Enterprise Architecture while working in a technical support role and it was in reference to the IT Architecture for the entire enterprise. Along came the Enterprise Business Architects and suddenly there is a confusion of terms. Or is there? The way I see it, and this is just one person’s opinion, is that there needs to be standardization on the language used when describing IT and Business Architecture. Well duh, you say?

I have discussed this with some peers and colleagues and depending on their background training and current role, the answers fall into two buckets. The IT folks get confused when I say Enterprise Architecture includes IT Architecture, Information Architecture and Business Architecture. The Business folks usually respond with a simple “of course”, but don’t always agree that Business Architecture is governed by Enterprise Architecture. It is after all, one portion of the enterprise.
A very simple illustration of my view of EA:



By No means is this an exhaustive examination of the all that EA is supposed to be, but it does demonstrate why the language confusion exists. And yes, Information and Information Technology are different – the differences to be explained in another blog sometime later.
It may come down to the same problem that has existed for years – The business and IT folks must understand that their operations are only one part of the enterprise and they must work in conjunction with all parts of the organization for it to be an efficient, productive enterprise.