Business Relationships - What's your Mantra?

In one of the previous posts I wrote about the role and the responsibilities of a BA. One of the responsibilities was to be liaison between the business and the technical teams, which also happens to be the most commonly understood and agreed upon responsibility of a BA. This also entails developing good relationships with both of the groups. As the size of the corporation or the team grows this starts gaining even more significance. Good relationships can get things done faster than usual and usually people go out of their way to get things done for you and help you out. Although, I haven't ever tried to measure the size of the group beyond which communications starts to go down in efficiency and tasks start to take unusually long because of dependencies, I have a rough idea like everyone else. And then there are aspects of human behavior that start to project in all sorts of odd fashions. A Business Analyst also has to be careful of those and start managing the related issues. If the Development and the Analysis teams belong to the same company as the Business then the performance and delivery criteria are usually more relaxed. However, if Analysis and Development is being handled by a consulting partner from outside, both the criteria to evaluate the performance and parameters of measuring the effectiveness and pace of delivery get a little more narrow. Good and effective consulting groups usually try to eliminate chances of this happening by managing the relationships right from the beginning. Also, the key is that each and every consultant from the team is aware of the importance of building right relationships. It's a responsibility of each and every consultant and not just one specific role on the team. This is infact one of the first few things that are recommended to a consultant. Relationship building and management is right on the top of the list of essential consulting skills. Here's what once a very senior executive said to me, "You are the top of the heap, but you need to learn to build relationships with the Business to not only succeed at this task but to also to grow". So here's what my mantra became from that point on. In any consulting gig the relationship between the Business and I should be like Batman and Robin. And this is what I strive to achieve and dedicate time and energy to in parallel of doing the other very essential tasks that I have to.

Distinguish between Business Rules and Validations

A good set of requirements should always specify the Business Rules clearly. Business rules are a very crucial thing to understand. What are the Business Rules? These are some of the statements or questions that IT professionals get to hear very often. I can't agree more with the first and the second statement. Business Rules can make or break the effectiveness of a software application. That's how important they are. However, the definition and look and feel of business rules is probably still not clear to many Business Analysts. Or so it seems when I read a lot of requirements. Ocassionally, I have also seen that there's a lot of confusion between business rules and validations. Let's take an example for context. Let's say as a BA you want to understand and document the requirements of a device to measure the concentration of gases that flow through a medical systems device. Here's a few statements:

1. If the unit value is selected as '%', the value for the gas should be between 0 and 100. If the unit value is PPM (parts per million), the value for the gas should be between 0 and 10000.
2. If the gas flowing in the system is oxygen then the precision of the value should be to one decimal place. If the gas flowing in the system in not oxygen then the precision should be to two decimal places.

What's the nature of the statements above? Are they Business Rules? No, as much as they seem to be, they are actually not. These are simply validations that have to be performed. These are a level deeper in the granularity than the business rules. Validations have business rules as their origin. Business Rules are constraints that influences and regulates a process. Validations are how these business rules manifest themselves. For the examples above the business rules can be written down as:

1. Gas flow concentration is measured in Percent or PPM.
2. Precision of measurement is different for oxygen and other (non-oxygen) gases.

This by no means mean that the details are being omitted here. It just means that the details are being deffered to the validations or the acceptance criteria section of the requirements document.

Why is this difference so important to understand? Well, as a Business Analyst one of the pitfalls is getting into details too soon or getting too technical. In the interest of time with the client or keeping the communication restricted to plain and simple English it is very important to understand the process in as simple terms as possible. This also increases the chances of the business representative to actually read the requirement and comment on its correctness.

The Person and The Role

One of the surprising things that I come across during my interaction with professionals is the confusion between a person and a role. It's sometime also not as much a point of confusion as it is about not realizing the importance of distinguishing between them. Abstraction is the Key For an analyst the importance of making a clear distinction between a person and a role is never more important than while studying an organization's processes, both As-Is and the To-Be. This, in my opinion should be one of the first few things that a BA should find out about their client(s). I am not arguing that it is not important to know the person and the people involved for very obvious reasons, including relationship building, etc. But, as an Analyst, it is the Role that is of more interest and not a specific Person. It's the role that a processes is designed after, mostly, and not the person. If it's not, then that's how it should be. How many times have you heard statements like these?

• That's not my job.
• I don't have the bandwidth for this.
• There's only so much I can do.
• The bottleneck is that right now it's just me handling all this.

One thing that is common across all these statements is that each of the speakers is describing the problem visualizing either themselves of a specific person. And this is why a lot of times a lot of processes at a lot of places never get fixed. Talk Roles To counter such things, the first things that a BA should do is to get a Person to Role lookup ready for any organization. All the process diagrams and workflows that are produced as deliverables by a BA should have the roles and not the names of the people. While reviewing one of the process models of a client, I noticed that the BA role was missing from one of the key meetings. As expected I raised a flag and was told that it is because they don't have a BA. Again, as I said earlier, this was a statement that reflected confusion between a person and a role. This brings me to one of the other relationship aspect between a person and a role. A relationship between these two is many to many. A person can have many roles and a role can be played by a group of people. In other words, John Doe can be a PM and a BA and the role of Production Support can be played by a group 0f 3-4 individuals. Although this is a very trivial thing to write about, I find it worthwhile to express my views on it. Making this distinction clear upfront and keeping focus on it:

1. Brings out more information related to processes and the pain points. People feel comfortable in discussing the responsibilities of roles rather then a person or themselves.
2. Makes decision making more objective. Tasks are approached and analyzed in an impartial manner.
3. Communication becomes more effective.

One of the biggest advantages of getting to roles right from the beginning is that this prepares the client/customer for user modeling (personas and scenarios), which is yet another essential step towards designing and developing effective processes and tools.

Business Process Requirements - It's not a Trade-Off Triangle

For a Business Analyst it is not uncommon to spend most of his/her time concentrating on Requirements and Processes. I always hear it from people that a BA gathers and identifies/captures system requirements. Actually, very few go beyond the assumption, saying it out loud, that a BA also understands the process part of the problem. Business Analysts are typically seen as the people who will take care of the nitty-gritty when the goals have been identified and a decision has been made about what is to be developed. It's just the how part that a BA is thought to be responsible to figure out. And this is where the problem begins. Projects get executed, money is spent and yet sometimes the goal is not achieved. Either the system does not deliver the business value or even if does sometimes it's an overkill for the benefits it brings about. The overall picture, sometime, is that that there's a big disconnect between what the business objectives were and what's created as a solution to meet those objectives. This is a risk that is so often realized nowadays that technologists have become callous to missed deadlines, cost overruns, and even complete failure to meet the business objectives, which is otherwise also know as project failure. Dissection So why does this happen so often that projects fail; either they miss the targets or they end up delivering something that has very little ROI? Is it because the PM don't evaluate the business plan or is it because the SMEs (Subject Matter Experts) are really not SMEs? And let's not even drag the BA into the discussion here because (s)he just did what was asked to do. That's the mindset that is prevalent in the industry. None of the roles - PM, QA, BA, etc. encompass any responsibility to forcast and evaluate the ROI. And just in case this team happens to represent a consulting firm they could care less. They would just manage, understand, develop, and support what they are asked to deliver. That's the perception in the industry, at least from what I have been hearing. Solution So how can we ensure that this doesn't happen the next time on our next projects. I'd say, get the BA and let them do what their title cries out loud; let them be the business analysts. A BA should first tackle and understand the business and then the process and requirements parts of the problem. A BA should be very clear of the challenges that the business is facing for which they want a solution. Specifically a BA should ask the following questions:

• What's the business this client is in?
• How do they provide value to their customers or how do they make money?
• What's bothering them?
• What are they good at?
• What do they want to do?
• How do they know if what they want to do is what would help alleviate their problems?
• How would they know if what they did is helping them when their proposed solution is implemented?
• What are the priorities in the solution space?

This list of questions is much larger than what's written above. The idea is that a BA should be introduced in the process right from the beginning and should concentrate on understanding the state of the union (as one of my colleague calls it) and the goals and objectives of the project. It is the responsibility of a BA to make sure that they stay on top of the business priorities. Process analysis and requirement analysis by a BA without getting involved in business analysis will expose the team to a huge risk.

The quintessential BA

The quintessential BA

The following are some actual job descriptions I have come across over the years on the job boards related to Business Analyst positions.

--- 5+ years of experience with equity and annuities.

--- Must have solid 7+ years with Healthcare specifically claims, provider and insurance.

--- Should have worked for a minimum Ten years in a telecom or communications field.

The question is

“Is there such a thing as a generic BA who can function across industries?”

In other words

“Is it necessary to posses a specific domain knowledge to perform as a Senior BA”

For starters lets look at our fictional Generic BA, Joe.

Joe has worked for many years with a software product and/or services company. He started as a junior BA straight out of school and learned everything on this job. He has mastered the art of people skills. He knows all about requirements gathering, cost estimation, functional and non functional specifications and spends his days storyboarding, brainstorming, building use cases and working with activity and sequence diagrams. He accompanies select sales force to capture client requirements and grievances. He easily translates requirements into technical specifications and can fluently talk GeekSpeak and ClientLingo. He organizes meetings, facilitates discussions and consolidates notes. In a nutshell he is the perfect BA for his company.

But Joe has hit a ceiling with his company and is tired of his boss. Joe wants a change. Joe wants to move to NYC from SFC and work for an Asset Management company as a Senior BA. Joe applies for a position that matches everything on his resume except the dreadful 5+ years in Finance or Investment Banking domain. Would it be wiser for the bank to hire our stellar BA, Joe over an average BA who hasn’t shown much potential except the requisite experience?

Tough call. Depends on the situation. Whatever the job requires. Yada yada yada…

Joe is pissed. He should be. Or should he not?

Well it really, really depends. You can learn the terms of trade on the job and master the lingo. You can pick up threads and find your way through the nitty-gritty’s of the business. As long as you know the basics and techniques you can adapt to pretty much any new environment.

But sometimes; scratch that, most of the times the incumbent is expected to jump-start and contribute from day 1 and knowing the domain helps, helps big time. It shouldn’t supercede the inherent talent and caliber. Therefore the employers have to ask themselves, “Is this person the quintessential BA I am looking for?”

This decision, as always, is not an easy one.

Card Wall - It's not Reversion

A few weeks ago I was with a big client coaching and helping them transform their analysis and development activities so as to be able to respond faster to the market and outpace the competition. After the first few days one of the client Project Managers came up to me and expressed his surprise and lack of faith in the style of working and the practices that I was demonstrating and recommending to them. To take a step back, in the last couple of years I have become a big fan of using paper, pens, tables, and walls for as much as possible. I have seen business goals and processes being spanned over the walls using a simple marker and lots of cards of different colors. Having done it myself, now on multiple projects, the effectiveness and the participatory style of this elicitation technique has proven its power and reliability so much that I take a lot of pride in demonstrating the technique to solve real-life problems. One particular thing that can be done with this technique is to set up a status wall of tasks for any team. This wall can have a simple 3 column layout with the columns being Backlog, In-Progress, and Done from left to right. Each task that each team member is supposed to do in a given timeperiod (a week or two or may be even a month) is added to the Backlog and as they are picked up by the indvidual team members these cards are moved into the In-Progress column and subsequently to the Done column when they are completed. This is one of the simplest ways you can track the progress of a team that is also very visible to anyone and everyone. It can also be accompanied by any flavor of a graphical progress report that can also be hanged alongside or in the vicinity. This particular client had already spent a few days with me using almost similar techniques to talk about the vision of the team/products, roles and responsibilities of the team members, etc। And then we embarked on the actual transformation process। This is when the client project manager said something like,

I just don't understand why, in this day and age when we have all these electronic means and tools to track projects, somebody would use a style that not only antiquated but also inefficient. This is a place where we gets things done; nobody has time to do this

This left me thinking and wondering if there were people on the earlier teams that I had worked with who did not express their astonishment। But most important of all, this led me to write about it today so that the power of putting pen to paper (as we used to do earlier) is not lost and underestimated. Here's a few reason why I think this technique works:

1. It's simple and fast - all you need is a few markers and index cards and a dry wall. Moving things around is very simple.
2. It's highly collaborative- everybody can participate and see their ideas/tasks make to the wall.
3. It's visible to everyone - team member don't have to log in to any system to see the progress.
4. It's collectively owned - no one person owns the card wall. Everyone updates with their progress.
5. It's current - the chances are that the next time the team meets somewhere close to the card wall, they'll update it right there and then. This keeps the card wall better updated than any other electronic tool that I have seen and used.

This leades to an enviroment where critical data is always posted in big bright format. The idea that usage of pen and paper rules out utilizing the electronic tracking tools is a misconception. These are complementary to each other. Card walls just make the process of processing, managing, and displaying the vital information to all the consumers very easy and effective.

Scope Vs. Scale

Scope is probably one of the most overused words in the lingo of a Business Analyst and a Project Manager. Scale on the other hand gets used very little. So little that the difference between scope and scale is not very clearly understood by many. The way I see it is that scope is about variety and scale is about numbers. So what do I mean by that? Let's take an example of building an airport. Some of the main components of an airport are the runway, tarmac, terminal building, and jetways. These diffrent types of facilities add variety to the structures required to be built. On the other hand the number and size of runways, terminal buildings, and jetways determine the scale - bigger the number larger the scale. So, if I were to add a light rail system to the airport, I am increasing the scope. If I double the size of the terminal, I am adding to the scale. Why does this difference matter? A clear distinction between scope and scale enables better decision making. Let's take the example of a jetway. The justification of a jetway is to enable the passengers (un)board the plane from the terminal building. This can probably be achieved using a jetway with one door, which is not only cheaper but also simpler. However, if the requirement now suddenly changes to enable customers (un)boarding from two doors of an aircraft it will increase the scale of the problem. The scope is still the same. I have seen many a debates and back and forths between the clients and development teams over issues that are perceived to be an increase of 'scope', when they actually are an increase of 'scale'. Scalar enhancements are often easier to tackle because it is often easier for the client to understand that given the usage they may be spending more time and money than the return, at the moment. In such situations rescale the problem, don't descope it; says so Jeff Patton in his write-up titled Finish on Time by Managing Scale that is available at: http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=10330 Amongst the many advantages the prominent two of this approach are better client relationship and a more useful product. This is of course given the assumption that the business value of the feature is identified correctly beforehand.

Stand-Up Meetings: Progress of Team Vs. Status of an Individual

One of the most powerful tools and techniques, amongst many more, that I have come across over the last few years has been the Stand-Up meetings. Stand-up meetings are literally held standing up; each and every team member stands up and the team forms a big circle looking towards each other. There's three questions that each team member is supposed to answer:

1. What did I do since we last met yesterday
2. What am I planning on doing between now and until we meet tomorrow
3. What obstacles need to be removed to accomplish this task, if any

An ideal stand-up should last no more than 15 mins. And the goals of the meeting is not status update to an individual as it often is believed to be. The goals of this meeting is to let your team know of the progress, share your obstacles with the team, and get your day and tasks committed to and publically timeboxed. So, why am I picky about the Progress Vs. Status mindset? The answer in short is that it influences the attitude of the team members. When it's about Status, individual team members say their part and sort of zone out right after that. But when it's about Progress everyone is curious to know what it is and how they can benefit from it. There's a good write-up on stand-ups by Jason Yip available at http://www.thoughtworks.com/PatternsDailyStandupJason%20Yip.pdf Jason has the pros and cons of having these meetings in mornings and evenings. I have been involved in both morning and late afternoon meetings. As such there is not a prescribed time for a stand-up, but I find the morning ones more effective for the following few reasons:

1. It's a good start for a day, much more disciplined. I get to work on time to ensure that I don't miss the meeting.
2. I look at the day ahead with 8-10 hours and hence I am more focused.
3. With afternoon stand-ups the rush to finish work is, usually, during the late mornings and that distorts the spread of work load; it becomes more uneven.

What is a Business Analyst?

The role of a Business Analyst is often the most underestimated in the IT industry. If not that, it is not uncommon to come across so many different definitions of the role that the BA's often find themselves in a quagmire of responsibilities. What makes the problem a little serious is that, in an typical IT shop, almost everyone else thinks that they can do what a BA does. At the face value, it is not untrue. But then there's a counter to that, who can not do anything that others do. But the questions remain; do they have the time and the passion to do it, and the most important of all, are they good at it? So what does a BA do anyway? Kathleen B. Hass of Management Concepts, Inc. in her paper titled The Business Analyst: The Pivotal IT Role of the Future wrote that the role of the business analyst is emerging as the central IT competency of the future. And she also writes that the business analyst also serves as a liaison between the business community and the technical solutions provider. Doesn't seem too difficult to do and is thought of as the only job of a business analyst. There's so much ignorance around the importance of the role in the business solutions lifecycle that they are often referred to as glorified secretaries. There's much to a BA than just being a notes taker and a meeting organizer. A BA ensures that the team understands what the business wants to achieve and how the value will be delivered. Documenting the requirements just happens to be a process to capture this piece of information for the team to understand and refer to. It just so happens that the prevalent form of documentation in the industry is outdated, one which lays stress on producing tons of paper with fancy names like the Business Requirements Specifications, and the Functional Requirements Specifications. A typical BA spends so much time in writing these documents that no wonder they seem like secretaries. In my opinion the the primary responsibility of a Business Analyst is to understand the business needs of their clients and how the client delivers value to their customers. It is usually an activity that requires high energy, excellent time management and organization skills, and an ability to learn new business and domains quickly, especially if the BA is also happens to be a consultant. As the business environment around us is changing and the competition is becoming cut throat, a typical business solution lifecycle has become very short than what it was a decade ago. Today, companies need to provide added value to its customers more than just once a year. Typically, a BA is also the person who makes an objective evaluation along with the customer about what is a priority and why. This person has to be able to understand the risks and rewards of the business and what determines their play. And this is also the person who understands the power and limitation of the tools and technology available to help the customer achieve their goals with the associated costs. It is just not the project manager who should worry about these. It is the responsiblity of a BA to provide the data required to assess those costs to the Project Manager. These tasks take more than just writing the requirements and being a channel of communication. It takes an attitude of problem solving and being an agent of change, it takes a sense of ownership of the problem, and a desire to make the processes and people around you more productive. Kathleen Hass's paper is a good read that answers a lot of questions about the role and responsiblities of a BA and it can be found here. Update I found a job posting for a BA on Southwest Airlines' website, which by far is the best description of responsibilities of a BA that I have seen. This job posting can be accessed at: http://www.southwest.com/careers/6655sy.html In case this link is not working please click on the image on the right to see a screenshot.

Why at all and why now?

There are numerous blogs out there that deal with the art of software development. And around this art are other blogs that look at it from the perspective of project management. But none so far, that I know of, ever have the perspective of a Business Analyst. This blog shares my views on the definition and the importance of the role of a Business Analyst and the best practices.