Business Analyst Blog

Many BAs have experienced analysis paralysis at least once in their career. This phrase describes the situation when you keep thinking/analyzing a problem, doing more research, documenting what you have learned, and then repeating the activities. Think, research, document. Think, research, document. It is the BA's equivalent of an infinite loop in programming. We get stuck in this cycle and can't seem to get out. There are many reasons that this phenomenon occurs. But how do we stop ourselves and get out of the infinite loop? Post your comments and suggestions and let's help each other.

Sometimes Business analysts tease Project Managers, we joke that we are more important than they are. In a meeting with a group of BAs last week I was reminded of how much we need PMs!!

Analysis paralysis! We joke about it but it is a real problem. Most BAs can get stuck in details whether they like to admit it or not. We love to analyze and we get into so much detail that we forget that we have to actually get something done. I am reminded of a Calculus professor in college - the absent minded professor who would forget that our class hour was over because he was so enjoying calculating derivatives on the blackboard. We model and we define terms and we "what if" and we get completely lost in our fascinating world of ideas. We need someone to pull us back up out of the weeds and force us to take that first step in the direction of the finish line.

Not only do we get lost in details, we can't stay within scope. Everyone always blames the business people for scope creep but let's be honest, BAs wander outside the scope of the project as much as anyone. We start thinking about how we could help fix another business area or we get an idea for how we could help the business sell more products or offer a new product or  . . . . Where does it end?? It ends when our Project Manager reminds us that we need to stay focused on the requirements inside our scope and we should get just the details that we absolutely need to move forward. We tend to be perfectionists but we usually don't have time to get every single requirement perfectly so we need to prioritize, get the most important details and move forward. Get something done.

So I say to all of you Project Managers - thank you and keep doing what you do best: keep us on track and focused, reminding us that although we can't do everything perfectly, we are doing a very good job!

The international BA is not as glamorous as the International Man of Mystery, Austin Powers, but it is exciting.  For a number of reasons, many BAs are interacting with customers and team members across the globe. One of the keys to success is to understand and sometimes embrace the culture of the people with whom you are interacting.  I want to share a short story of how I was able to break the ice with some clients in Argentina.

I spent some time in Buenos Aires, Argentina implementing an inventory management system.  My first trip was dedicated to eliciting requirements.  Prior to my trip I spoke with some of the key stakeholders to get to know them.  I was hoping this would make my elicitation easier, but my first day in the office was not an easy one.  Although everyone was extremely friendly, I did not really connect with many people.  My elicitation was not going as well as I had hoped.  Later that afternoon, I was thinking about how I could improve. I was looking out in the hallway and noticed something.  When people greeted each other they gave a kiss on the cheek.  I remembered that when I introduced myself to everyone that morning, I had the outstretched arm with a firm handshake.  I made sure to keep a good amount of personal space. 

With no other great ideas, I decided in the morning I was going in for the kiss.  I am a hugger, but not necessarily a kisser when it comes to hello's.  I was definitely going to be out of my comfort zone, but I had to do something.  So, in I came the next morning and turned into the kissing bandit! The first few were uncomfortable, but I got used to it quickly.  And, it worked! There was this transformation from Kupe the outsider, to Kupe is one of us trying to help.  The trip was very successful as were all my future interactions with this customer base.  

Embrace the opportunity to meet new people and experience new cultures.   

So, that was my story let's hear your story. 

If you haven’t seen it yet, check out CIO magazine article written recently by Katherine Walsh about the Hot Job of a Business Analyst:

http://www.cio.com/article/120154/Hot_Jobs_Business_Analyst

Ms. Walsh describes the role of the BA consistently with the IIBA definition and has some good things to say about our Business Analyst role and why it’s hot right now. What I found most interesting was a comment that a CIO wrote in response about hiring good BAs. This CIO prefers to work with Business Analysts who are originally from the business (not IT) yet also technically savvy. Can you guess the reason for her prejudice? Technical people tend to want to solve every problem with software before they understand the business process, the environment and the objectives. Not that I agree with this generalization of every person with an IT background, but we all know people who have this habit. I can remember many elicitation sessions where an architect or a developer who was invited to listen in and hear the business requirements and then he or she would immediately try to tell us how they would design a software solution.  

This issue of jumping into the solution too quickly is exactly the thing that we at B2T Training try to instill throughout our BA curriculum – you really need to understand the business problem and the business area before you start designing a software solution. Even though technology is integrally tied to most business solutions, software is not the right answer to every business problem. I repeat, software does not fix every business problem. Many people still don’t get it. Some technical folks think they know better than the business people how the business can run more efficiently even when they don’t have a clue about the critical business processes and what the business people need to accomplish their goals. That is why an excellent BA is one who tries in every project to understand the fundamental business needs before identifying functional requirements to the IT staff or picking out software packages to purchase. Everyone wants to finish projects faster but who are we kidding? There is no silver bullet, other than thorough investigation to learn the details or else we run a high risk that the project will fail.

One more note about the salary ranges mentioned by Ms. Walsh - I think that senior BAs can command more than she listed as the top of the salary and this is why. I think whenever a company finds Business Analysts who truly get the business, are technically savvy, are great problem solvers, are organized, good negotiators, are very detailed yet see the big picture, and have good communication skills across the organization; they will always command competitive salaries. And if the BA also possesses leadership skills and an MBA, they will most likely be groomed for management positions with greater and greater responsibilities. 

Coincidentally in the Wall Street journal I also read another article recently that said how important it was for CIOs to be business savvy. It reminded readers that the days of being only a great technical manager are over. CIOs need to help develop the business strategy with the other C-level management. They can’t just think about technology for the sake of technology. They need to help develop and support the business strategy. Hmm – I think this is a role that a senior BA could aspire to perform.

The main program at July's Greater Atlanta IIBA chapter meeting was about User Flow Diagrams.  The presenter was Carol Kilpatrick, modeling and design specialist, from Delta Technology.  She gave a great presentation on how she documents work flow diagrams to focus on user actions.  There were two points Carol made that apply to all documents we produce as Business Analysts.

1) Use a consistent format.  By using a consistent format the readers of the deliverables become familiar with the document.  This allows the reader to focus on the message of the document and not the format.  When there are multiple BAs working with the same project team and business stakeholders it is even more important.  You want the reader to focus on what is being communicated, not how you are communicating.

2) Produce drafts quickly and have them reviewed.  By having your documents reviewed early and often you get instant feedback on the accuracy and completeness of your document.  There is a risk here.  You can be viewed as presenting incomplete documents.  Make sure your reader is aware it is an early draft to make sure you are on the right track. 

The main reason for consistency and reviews is to help ensure we have elicited and documented clear and complete requirements.  Please share your tips on how we can get to clear and complete requirements!

I am really excited about the proposed upcoming changes to the IIBAs BABOK. Kevin Brennan, VP of the Body of Knowledge has posted a diagram on his blog http://www.bainsight.com/ and on the new online community Catalyze http://www.mycatalyze.com/ so take a look. Three of the knowledge areas will be renamed and some of the content will be moved. I really like two of the proposed new names: Business Analysis Planning and Elicitation. I like Business Analysis Planning because we have been having trouble clarifying the differences between what a BA does during planning from what a Project Manager does during planning. This name makes it clear that the business analysis work must be planned. We are not trying to do the PM work, we need to plan our own work. I also like removing the word Requirements from the Elicitation chapter. The techniques that are discussed in this chapter can be used for more than just eliciting requirements. They can be used for design, for scoping, for brainstorming, etc.

The third major change is to separate the requirements planning and management topics. Planning becomes Business Analysis Planning as mentioned above. Requirements management gets combined with Requirements Communication. Although this combination is not as natural, these are two topic areas that are related and are small, so from a practical standpoint it makes sense for us to put them in the same chapter.

We would love to hear what BAs think about these ideas. Reply here or at the sites listed above with your thoughts.

For years developers have had online communities where they can keep up with the thoughts and insights from the gurus of their discipline.  This has been a phenomenal resource for developers giving them access to unlimited knowledge helping them build better applications.  Now Business Analysts have an online community called Catalyze.    

I attended  the BusinessAnalystWorld Symposium in Atlanta last week. One of the speakers whom I enjoyed was Keith Barrett from ProcessExchange Inc. http://www.process-exchange.com/

Keith spoke about Reuse Based Requirements Development & Management (RBRDM). I was very glad to hear someone at the symposium talking about requirements reuse because it is an area that I think we should be talking about a lot more. In defining his terms Keith defined Requirements Development as all of the work that is done to elicit, analyze, and document the requirements. He acknowledged that many requirements are still written in text and that textual requirements are difficult for software developers to use and difficult to manage for reuse.

He defined Requirements Management as the ongoing management of requirements from the point that they are created throughout the project and after implementation continuing on for the life of the business or the system that they describe. Only if the requirements are managed on an ongoing basis are they available for reuse on later projects.

A couple of other key points that Keith emphasized: requirements are valuable corporate assets and as such should be treated with care and respect. They should be developed carefully using standard approaches and common formats and they should be stored in a common repository. Also, Keith's experience with reusability in the development world taught him that reusability is best leveraged when components are grouped into "families" of related components so that they can easily be found and understood when needed.

In discussing the currently available Requirements Management tools in the marketplace Keith and the audience agreed that none of them have all of the feature/characteristics that we would like to help us manage requirements. We look forward to these tools becoming more sophisticated in the coming years.

We tackled a complex analysis problem yesterday and I was reminded how great it is to have a developer available to help with brainstorming during requirements elicitation.

A manager at one of our clients has a very complex algorithm for optimizing revenue in a boutique division of their organization. This division has been so successful that the senior managers want to share the success with the rest of the organization. They asked us to automate the algorithm so that it could be used by other managers and other divisions. The reason that the algorithm is so successful is that it was developed by a brilliant human brain and has been refined over several years of practical use.

Our initial interviews had indicated that the algorithm is a set of intuitively applied business rules with a lot of exceptions. Before our session yesterday we weren't really sure that this thinking process could be automated. But we brought together the key business stakeholders, a developer and the BA team to see what we could do. As we painfully extracted intuition, assumptions, experiential knowledge and gut feel business rules from the SME, our developer was jotting notes and adding his own questions. As we began to understand the basic steps in the process we tried to write them/document them in a format that would lead to some kind of repeatable process. As BAs we could "see" the pattern but we couldn't imagine how to make a machine understand it or repeat it. But our developer could. He saw an approach that would allow all of the rules to be applied appropriately.

This was a great reminder that business rules used by business people are often very complex and are difficult to document. Our SME would tell you that it was difficult for him to explain this complex thinking process, even though he "invented" it. Everyone in the room learned a tremendous amount about the process and the business. We just have the start of our design but at least we have a start. Without our developer there, we may have left the room deciding that software support was not possible for this complex process.

In May 2007 I attended the Project Summit/BusinessAnalystWorld conference in Washington, DC.  I sat in on a presentation called “Can the BA Save the World?”, presented by a fellow CBAP, Marcos Ferrer.  Marcos is a facilitator, planner & system implementer with over 30 years experience in computing and over 22 years experience in business analysis. 

When I saw the title of the presentation I did not know what to expect, but I had to attend.  Marcos covered a lot in this presentation, but he made a point that really stuck with me.  He sees the Business Analyst profession making its way into our national, state, and local governments.  He discussed that when bills are brought to congress, or the President makes decisions there is no BA present.  I have to agree with him.  Is analysis done before decisions are made?  I am going to be optimistic and say yes, but is the analysis that we do as excellent BAs done consistently?  I don't think so. 

As excellent Business Analysts we work hard to understand the true business need and work with solution teams to present and recommend unbiased solution options.  Is this what happens on Capitol Hill or in the White House?  Marcos stressed that there is no unbiased third party like a Business Analyst there to help.

This is one way Marcos felt that we as BAs can save the world.  "Save the world" may be an extreme, but I believe we can definitely help companies in public and private industry and our government make better decisions. 

I would love to hear you comments.