Business Analyst Blog

At a recent Atlanta IIBA meeting, Lisa Heiser was telling me about the frustration that her dad felt because he doesn’t understand what she does. He asked “How can you have worked for an airline, then a telecommunications company, and then the government? How do you know what to do in these different types of companies? What exactly do you do??” 

Lisa struggled to explain the BA role to her father and finally hit on an analogy with which he could relate. While they were eating dinner in a restaurant she said “Dad, think about the job of our waiter. She comes to us (the customer) and asks us what we want/need (requirements). Then she writes down our orders in a way the chef and kitchen staff will understand – she translates our order to the chef so he knows exactly what we want. Then she delivers our food to us from the kitchen and makes sure that we got what we asked for! She could work for an Italian pizzeria, a French bistro, or a Japanese steakhouse and she would still do basically the same job. Just like a BA!”

Be sure to check the IIBA web site, for the dates and locations of the 2007 IIBA Certification exams.  With locations in four countries on three continents in 12 different cities many BAs will have the opportunity to certify in the coming year.

 http://www.theiiba.org/content.asp?ContentId=558

If you are interested in taking the exam, I recommend that you start working on your application soon. The application is a critical step in the certification process because it is where you detail your BA work experience. It may take some time for you to describe your experience and get your references. You can apply even if you don't know which test date/location is best for you.

You will see that most of the exams are scheduled to coordinate with a BA conference. It is amazing how many BA conferences are planned.  2006 has been a great year for business analysis. 2007 promises to be even more exciting. Happy New Year to all.

Well, the results are in and 15 of us can now refer to ourselves as CBAPs!! Certified Business Analysis Professionals through the IIBA. I am proud to say that three of us here at B2T are in this first group: Jonathan "Kupe" Kupersmith, Kevin Quilliams, and myself, Barbara Carkenord. We are also proud to have one of our B2T certified students in the group: Stephanie Griffiths. Congratulations to all!

Now that the first group of people are through the process the IIBA will be spending next year streamlining the process. Thanks to all of the volunteers at the IIBA who worked so hard to make this happen.

There are many tools in my BA Toolbox, but there are a few I use more than the rest.  Think of the handyman that just did some work at your house or office.  They come with a truck full of tools, but it seems like their hammer is always by their side.  That is how I feel about the Requirements Work Plan (RWP).

Whether I am engaged in a 12 month project or a 2 week project I create a RWP.  The 12 month project requires a detailed RWP that is reviewed by other team members and key stakeholders.  The two week project RWP is usually documented on a cocktail napkin.  

It is not just me that finds requirements planning important.  The IIBA, http://www.theiiba.org/, has a knowledge area in the BA Body of Knowledge dedicated to requirements planning and management.  This is one of six knowledge areas, which indicates the industry feels requirements planning is important.

Some of the items to include in your RWP are as follows:

• Project Type 
• Project Scope
• Project stakeholders and their role on the project
• Requirements activities/tasks/deliverables and time and duration estimates for each
• Identify milestones in the above activities for development and delivery of requirements
• Requirements assumptions and risks

All of this information should fit into the project plan and schedule and will be updated as the project moves long.  Once the project is complete store the actual data to help plan for the next project.

One question we all get is "How long will it take to complete requirements?"  If you use this tool, you will begin to answer the question with confidence. 

I was talking with a business analyst at the Boston Business Analyst World conference. She asked if we offer any training on how BAs should navigate the politics in their organizations. She was facing a situation where the IT group disagreed with a business unit request but she was a paid consultant, hired by IT!

Although dealing with office politics is necessary for many professions, BAs face some unique challenges, often driven by where they officially “report” in the organization.

Many BAs “report to” or “reside in” IT. This means that they are paid out of the IT budget and evaluated by IT management. Promotions and assignments to plum projects are controlled by IT (you see where I am going with this!). As BUSINESS analysts we are tasked with representing the business to the IT group. We are supposed to be advocates for the business. But what happens when the business disagrees with an IT decision or direction? Guess who is stuck in the middle? The BA. All of our talk of being a bridge or a liaison can be destroyed by an organizational structure that makes the BA’s career progression at odds with the best interest of the business. Of course there are also issues when the BA “reports to” the business unit (I’ll save that for another day.) Ideally BAs would be an independent group and could truly act as liaisons. Analogous to the PMO (project management office), a Business Analyst Office or Center for Excellence may eventually help us with these conflicts. The recent Gartner report on business analysis placement also defines a hybrid model where there are BAs in IT and in the business units. 

In the meanwhile, a business analyst must represent all of his or her stakeholders as fully as possible and work to resolve conflicts through communication and consensus building. We may have to walk a fine line between representing business stakeholders while not alienating our management. Thank goodness that we are excellent communicators and listeners. Sometimes simply listening and asking questions help disparate groups to come to a common vision.

I am just getting back to work after sitting for the first IIBA Certification Exam! I wanted to share my experience with those of you who may be considering applying for this certification. The exam was given in Orlando, Florida to coincide with the World Congress for Business Analysis conference. 16 BAs were accepted to sit for the exam. As you can imagine, we were all very excited and a little nervous about being the first group to attempt certification.

The application process is spelled out in a candidate handbook, available on the IIBA web site www.theiiba.org. A candidate must have 5 years experience (7500 hours) in business analysis during the last 10 years. Each candidate must also provide two professional references and complete the application process.

While I cannot tell you anything specific about the exam questions (all testers must sign a confidentiality agreement), I can tell you about the experience and the rules around taking the exam (or "writing" the exam for those of you who are outside of the United States).

The exam is 150, multiple choice questions pertaining to the knowledge areas documented in the IIBA BA Body of Knowledge. Each question has four possible answers and the tester is to select the best answer. The questions were written by business analysis practitioners and approved by a professional psychometrician (a person who is an expert in testing). We were given 3 ½ hours to complete the exam and it was proctored by a professional examination company, Castle Learning.

The resources available to study for the exam are significant. In addition to the body of knowledge itself, there are over 80 books listed in the body of knowledge that contain business analysis task descriptions. Obviously, most of us will not have read all of these books, but I would recommend that you be familiar with at least a couple of them in each major topic area. There are also many study groups forming in the local IIBA chapters. My study group is great!

Questions are weighted by knowledge area as follows (based on a task survey conducted earlier this year): Enterprise Analysis - 22%, Requirements Planning and Management – 22.8%, Requirements Elicitation – 18%, Requirements Analysis and Documentation – 20%, Requirements Communication – 10%, Solution Assessment and Validation – 5.8%. Many of the questions are very challenging because as BAs our answer is often “it depends”! I drew on my knowledge and experience to evaluate each question and attempt to choose the correct answer. I will let you know how I did.

I recently joined the incredible fraternity of Crocs - the funky looking shoe made of rubber.  I had "The Crocs Experience."  That is what my new found brotherhood calls it.  As I now wear my Crocs every where, I thought of my journey to "The Crocs Experience" similar to project teams getting to "The BA Experience."

For over a year, I have been seeing thousands of people wearing Crocs and laughing under my breath thinking how can these people wear that ugly shoe.  I would ask them why they bought them, and their reply was always the same.  "They are so comfortable and durable…there is no better shoe."

Last week I found myself at a shoe store staring at a Crocs display, and a woman approached me.  She stares in my eyes and asks if I have a pair.  I reply no, and my new friend was in a state of shock.  She composed herself and with unbridled passion she began a 5 minute speech about how wonderful the shoe is and that she hardly ever takes hers off.  I was so moved that I decided to drink the Kool-Aid.  I bought a pair and WOW!…they are awesome!  Last night I wore mine to bed!

Now to my point.  "The Crocs Experience" is just like "The BA Experience." Even with all the studies showing that a high percentage of projects fail due to a lack of excellent requirements, I have seen project teams laughing under their breath and thinking we don't need to spend the effort of getting excellent requirements.  Those teams like to start on the solution first and begin coding as soon as possible.  But, once they try the approach of getting excellent requirements they have "The BA Experience."  And of course, they never look back. 

Have you had "The BA Experience?"

I did a little sniffing on the web to find out what the acronym stands for, exactly. Silly me. I actually expected a cogent, coherent, standards-based answer.

According to webopedia.com and Wikipedia , the acronym variously stands for "System Development Life Cycle" (or "System Design Life Cycle") in most cases, and "Systems Development Life Cycle" by the DOJ (why lawyers have any say in this, I don't know).

Note the singular "System" in most uses (Wikipedia has a re-direct to the plural from the singular, so I presume they are considered to be of equal validity for that reference). Most modern, rapid/agile/fast/whatever methodology references I could find (see here , here , here and here for examples) refer to it in the singular, although that's certainly not univerally true (hit the link to the last example above for a real quandary). There are a ton of other, software-focused sites that call it, predictably, the "Software Development Life Cycle."

I couldn't find the Yourdon book to verify his Delphinic definition of the acronym. OK, actually: I threw up my hands in dismay after so many un-attributed opinions. I will probably never really care whether Yourdon refers to it in the singular or plural. Based upon what I can find, my gut says that "System" is conversationally interchangeable with "Systems" in most general-purpose cases.

In other words, people call it what they want.

Wait! What about "PLC" (Project Life Cycle)? Isn't that valid, too? I mean, what if there is/are no "System(s)" involved? Or software? Don't BAs just care about the "Project?"

I think you get my drift.  To cut to the chase:  There's no substitute for a good glossary. No matter how many arguments other people are having about terms, if they are defined in your company's glossary for all to see, then you can do business.

Isn't that what it's all about? Correct me if I'm wrong…

One of the knowledge areas included in the IIBA BABOK is Enterprise Analysis. I have noticed that when BAs review this knowledge area for the first time, many exclaim "BAs don't do this!". Honestly I must say that I had the same reaction the first time that I looked at the detailed tasks outlined. The knowledge area includes things like Strategic Planning, Business Architecture development and Business Case development. For those of us who have worked at large companies, these tasks are usually owned by a separate group called Strategic Planning or Corporate Planning.

However, the more that we talk about these tasks, the more than I see BAs doing this kind of work every day. We don't do it formally and often do it unconsciously but we do it. Experienced analysts are always questioning why we are doing a particular project or task, we are always thinking about how to spend our time in the most effective way for our employer and we are always considering how does this work fit with other groups in the organization. If a business stakeholder asked for a technology change that would negatively impact another corporate group, we would discuss the ramifications and brainstorm for another solution!

I would encourage BAs to become more aware of how much you do think about strategic issues for your organization. When you talk with a business stakeholder about how to improve their process you are thinking strategically and you are doing informal business case or cost benefit analysis. Don't sell yourself short - BAs are very strategic and perform Enterprise Analysis all of the time.

There are a number of requirements management tools on the market that can help Business Analysts and project teams more efficiently document, communicate, and manage requirements.  Most have integration points with modeling, development, and testing tools allowing teams to trace requirements through the project lifecycle. 

I want to stress that these tools will help you increase your efficiency.  This implies that you have already implemented a requirements management process/methodology that teams are effectively using.  Requirements management tools will make you more efficient only if you have a methodology that everyone understands.  Here are some steps to take before you start looking to purchase a tool.

1. Create and document a requirements management methodology.  Know what your needs are before finding a technical solution.  The methodology should include what your requirements package looks like, how you categorize requirements, what attributes you track, how you trace requirements, and who does what and at what point in the project.
2. Implement this methodology using tools like Microsoft Word which mostly everyone has access to and knows how to use. 
3. Use this methodology on pilot projects, identify lessons learned, and make the necessary adjustments.
4. Establish a support structure where project teams can get assistance with using the methodology and provide feedback.  The support team should be responsible for making adjustments to the methodology and communicating the changes.
5. Roll out the methodology to all teams in your organization.
6. When the methodology (process) is in place and the people using the methodology are effectively implementing it, you can begin looking for a tool to increase your efficiency.
7. Use your requirements management methodology as your requirements for the tool. 

If you do the above successfully you have a great chance for a successful tool implementation.  The good news is that some of the tool vendors don’t shy away from the fact that you should have a methodology in place.

I would love to hear from others that have implemented or are planning to implement a requirements management tool.  Please share your thoughts and experiences.