Business Analyst Blog

What should you do first? Would you define your requirements scope before you start to identify and analyze your stakeholders or vice versa? Would you receive the same answer if you asked 10 Business Analysts? I would bet not. Many might answer that they identify scope first before they can identify requirements stakeholders. Others would start with the people whom they know are impacted by the project.

 Does it matter which is done first? Probably not and I will tell you why. Typically you want to start with what you know most about the project. As a Business Analyst I continually ask myself two questions: what do I already know and what is most important to know next? Most project activities do not happen sequentially, especially during the planning process. It really doesn't matter which activity you do first as long as you focus on defining what you need to know most at the appropriate time on the project. In the beginning of the project you will want to understand the breadth of the project based on some key elements such as the scope and the stakeholders-and it really does not matter where you begin.

The Atlanta IIBA Chapter meeting this week focused on Enterprise Analysis, specifically business cases. Pamela Robinson of Financial Voyages (http://www.teamfv.com/), gave a great presentation on business case development. Her organization has developed a Business Case Development Framework to help organizations improve their business case development process. It was great to hear another successful professional talk about business cases in the same way that we do.

Pamela listed several characteristics of a business case. These characteristics were good reminders for those of us writing business cases, whether for large projects or small. One of the most important characteristics is the description of why the business case was developed.  In other words, what triggered or caused us to write the business case. Just as in everything that BAs do, the WHY is always critical. Not only do we need to articulate why the change should be made, we need to build a case for why the change should be made now.

She also reminded us that business cases are time sensitive.  A minute after a business case is finished, a factor in the environment can change and make the business case obsolete. This is why it is important that we work to get a go/no go decision as soon as possible after the case is developed. It also reminds us that we should not get too bogged down into detailed requirements. The business case is high level, detailed requirements will be gathered once the project is approved and initiated. The author of the business case is also a salesperson. We need to sell the idea to our decision makers but clearly describe the benefits and convince them that time is of the essence!

 Pamela's presentation will be posted on the Atlanta IIBA web site http://tech.groups.yahoo.com/group/iibaatlanta

“How do I get a junior level BA position?”  This question is one I get often from individuals looking to become Business Analysts.  Unfortunately, there is no magic pill and the path may be different for everyone. Here is the advice I have for those looking to become Business Analysts. 

• Network: You need to start meeting BAs or people that hire BAs.  Join your local IIBA chapter.  Being part of a BA professional organization lets people know you are passionate about the role. Talk to recruiters that place BAs.  Let everyone who will listen know that you want to be a BA.  You’ll begin to understand what companies are looking for in a Business Analyst.  You’ll also see which companies are dedicated to the role. Those are the ones you want to pursue. 
• Rework your resume:  I can almost guarantee that even if you have never had the title of a Business Analyst, or something close, you have performed tasks and used techniques required of a BA.  Highlight the BA type skills you have on your resume. 
• Get educated:  There are many ways to accomplish this.  You can read books, find a BA mentor, attend IIBA meetings, or find a training provider that will meet your needs.
• Look at your current company first: A great way to make a transition into a BA role is within your current company.  Let your manager know that you are interested in making a move and hopefully your manager will work with you to get the right opportunities.  This is how I broke into the role.  I was a SME for years before I became a Business Analyst.

I would love to hear how you broke into the role and any advice you may have for others.

I have just returned from the 2007 DAMA Conference in Boston. It was an intense conference with over 750 attendees. Topics ranged from Metadata Management to data modeling challenges to developing your enterprise data strategy.

I sat in several worthwhile sessions and came away with one excellent suggestion that BAs can begin to incorporate right away. It comes from one of the many sessions on Data Quality. With organizations amassing more and more data of various types, the quality of the data stored in databases is often questionable. Many of our applications contain redundant data. We have thousands of null or missing data values and much of our data is old and obsolete. Inaccurate data really causes problems when a business stakeholder asks for a new report or query from our databases. When we are assigned to a new project that involves the use of existing data, one of our first questions should be how accurate is the data? Business stakeholders may not be aware of the number of errors that exist in production databases. In our company we are always amazed at how many bad email addresses that we have when we try to send out a notification. Many of our contacts do not notify us when they get a new email address so when we send out messages, we gets lots of errors.

If we go forward with projects, utilizing existing data and the data is not accurate, then the time spent on the project has been wasted. As an excellent Business Analyst, we can add value at the beginning of projects by asking and researching the quality of existing data. If we find that the data quality is poor, we should recommend a clean up project first, before designing new reports and queries. These “data cleansing” projects can be expensive but improving the quality of our data, which is a corporate asset, increases our ability to make good business decisions that rely on the data.

How many times have you heard this statement (or something like it)? Sometimes it seems so much easier to buy a software package than to spend the time thinking about what we need and how we want it to work. “There must be a package out there somewhere that we could use.” In many cases this is just wishful thinking. Although there are thousands of software packages for sale, more every day, the chances that a package will support your true business needs without customization is low. Of course, there are applications that follow standard processes like many accounting/bookkeeping applications. Those are great opportunities to use something that is already written. But even in those cases, we still need requirements.

I know that I am preaching to the choir when I tell Business Analysts that we still need to analyze and document requirements, even when we know that we are going to buy a package. How can we help others see the value? How can we convince our business stakeholders and management that they should give us some time to do some research, document requirements and find the package with the best fit for our organization? My answer is with questions. BAs are excellent at posing questions that help their stakeholders realize the importance of analysis. How well does the XYZ package support your underlying business function? How many users will it support? How much data can it hold? Are the reports useful? Easy to generate? Will our procedures/organizational structure have to change to use the new software? How much training will be required for users?

You know the drill, develop lots of questions and keep asking. When you see hesitation on the face of your executive sponsor or manager, quickly jump in and offer to help. “How about if I put together some ideas and try to answer some of these questions before we start the contracting process?” We continue to help our organizations understand the value of requirements analysis (and the value of Business Analysts!) when we ask good questions and then offer to help find answers.

I receive several emails a week from BAs asking about the differences between B2T Training's certification and the IIBA or which one to get. The short answer, like most in the business analysis world, is "It depends." Here are my thoughts to help you  make that decision.

Many training companies and universities offer certificate or certification programs for business analysis. They are primarily a way for the organization to recognize that an individual has completed a course of study. Similar to obtaining a degree in computer science and then completing a certification program in a particular programming language, these are both important, but they offer different levels of recognition. The degree proves that you satisfactorily completed a proven curriculum and demonstrated your knowledge through exams, case studies, and possibly a work-study program. A certification is an independent expert verification of your knowledge and possibly skills related to a narrower subject.

There are currently three types of certification programs in the market place for business analysts: certificate programs, certification programs, and the IIBA certification program. Let's start with the IIBA certification program. The IIBA is the industry organization that has defined the body of knowledge for the business analysis profession, BABOK. The IIBA's certification is an exam that measures your knowledge of the BABOK and would be extremely difficult to pass without business analysis experience. In order to sit for the exam, you must have a minimum of 5 years experience.

The other certificate and certification programs are administered by training companies and universities. Most of them are certificate programs that recognize you attended training and may have a small amount of testing related to the topics covered in class. B2T Training's certification program requires testing of business analysis topics and completion of portions of a requirements package. It is more of a performance-based certification, rather than a certificate of completion.

So which one do you need or which one is going to benefit you the most? It depends on why you want the certification and what you are going to do with it. Proof that you have attended business analysis training and/or have knowledge of the BABOK shows that you are aware of industry terminology and techniques. It will always be considered positively by employers and will make your transition into new environments easier. From an employer's perspective, evidence that a BA possess not only business analysis knowledge, but the ability to apply that knowledge in a day-to-day, real-world business analysis environment is invaluable. Consider your current situation and where you want to be in three or five years when making this decision. BAs may choose to earn multiple levels of recognition based on their personal needs.

By "personal" I don't mean that you need to keep your requirements planning to yourself.  No secret diary should be used requiring your project manager to snoop around your desk late at night to discover when you will be done with your requirements tasks.  Your requirements plan needs to be shared with the project team and all stakeholders involved in the project.  What I mean is that no two Business Analysts will have an identical plan and that is OK.  There are a variety of skills you need to be an excellent BA and every BA has different strengths and weaknesses.  Estimating the tasks to complete should be similar from BA to BA, but the time to complete each task is personal. 

Consider this analogy.  The requirements tasks are like a person's hand and the BA's time estimate is like a person's finger print.  For the most part, we all have the same basic hand structure, but no one has the same finger prints.

BAs work on projects that have many variables impacting the decision of which requirements tasks should be included and determining time estimates for those tasks.  They include the type of project, the business and project risks, the time frame allotted for the project, the stakeholders involved, the number of integration points with other systems, etc.  Over time a Business Analyst can look over all of those factors and confidently determine the tasks needed to be accomplished for a project.  Planning the right tasks can be done with little regard to the BA resource working on the project.  The individual Business Analyst needs to be considered to determine the most accurate time estimates.

As an excellent BA you need to track the actual time it takes to complete each requirement task for your projects.  The more history you accumulate the better you will be able to estimate how long each task will take to complete.  When you are planning the next project refer back to the actual data to better estimate your time.   

The January meeting of the Atlanta IIBA was excellent. We had about 40 attendees and a great presentation. The presenter was Ryan English from SpiDynamics http://www.spidynamics.com/

Ryan spoke about web application security vulnerabilities and pointed out that requirements documents should always include security requirements. These requirements are part of the category called Quality of Service requirements in the BABOK™. Ryan quoted a couple of interesting statistics: 64% of developers are not confident in their ability to write secure applications and 70% of security violations are in the application level. I believe both of these statistics can be improved with more awareness and training. As BAs we should ask our developers if they are familiar with the most common security risks. We should encourage them to get training and learn more about how they can prevent common vulnerabilities. We should encourage our managers to send developers to training. And we need to educate ourselves about the risks and how we can prevent them by writing excellent requirements. We don't need to be experts on security risks, many of us work for large organizations which have a security officer in the IT division. If you have access to an internal resource like this, take him out to lunch!!  Read the white papers that are available on SpiDynamics web page. Search the web for information about security for your industry. With an experienced BA, a little knowledge goes a long way. We don't need to become security experts because we know how to ask good questions and interview the people who have the knowledge. We just need to be aware of the issues.

Here's one for ya':

What, exactly, is a "model?" I'm not talking about this or this . I mean, when BAs are discussing "models" ("logical data models," "process models"), what exactly do they mean?

Is it graphical? How many times have you been referred to a "modeling tool" to create a representation of data?

Is it textual? I've never heard of anybody referring to MS Word as a modeling tool…

Here's an example of the impact of my private quandary:

When somebody is required to deliver a "model" of the data related to a project, do they have any basic idea what that should look like if it were placed in a lineup? Would they panic, not knowing what to deliver? Are they afraid, very afraid???

Surely there must be some consensus somewhere… 

I know! I'll look!!

(Sometime later:)

I looked here; I looked there; I looked everywhere. Sigh. No clear, unambiguous consensus.

But I found a couple of clues. First of all is the use of the word "abstract" in so many of the definitions.  I think that the use of the word "abstract" is useful. I've noticed something interesting about data: you can't really "see" it. You can see representations of it (like reports, a GUI displaying it, or even a table listing), but you can't really see it, unless of course you elect to try direct examination of the storage media via a scanning electron microscope, which I don't recommend for BA standard practice. It's way too distracting from the goal.

Which leads me to my second observation:

The use of the word "representation" in some of the definitions.

After thinking about it for a bit, it appeared to me that a great definition for the word "model," at least as used by BAs in the performance of their jobs, could be:

"Any visual representation of an abstract concept that is useful for communicating the realities of the project related to the representation."

This definition would prescribe, then, the use of either graphical, textual or both methods for this purpose. But, note also, the use of the word "communicate." This is at the core of the need. If the delivery method is not right for the audience, then the "model" fails the test of the definition.

No matter how cool the picture, if the target audience doesn't grasp the reality of the subject, then it's worthless. 

No? Feel free to correct me.

How much time do you spend deciding who to reply, forward, and cc on each email message? Do you find yourself sending lots of follow up/clarification emails because you forget to say something important or your original message is not clear? If you spend very little time thinking before you hit the "Send" button, I want to challenge you to change your habits. Every task, even one that seems as simple as replying to an email should be done with some thoughtfulness. I am not suggesting that you spend a large amount of time but I am recommending that before you do each task you think about what you are doing, why you are doing it, and who will be impacted. This thinking ahead (dare I say planning), improves your productivity and those with whom you communicate. These are the core skills that make an excellent Business Analyst.

It is always easiest to support a recommendation with examples of what happens if you don't take it. For example: What happens if you reply to an email which is discussing a project and you forget to CC the Project Manager? It may cause the PM to be out of the loop and he or she may make other decisions without full knowledge. What happens when you send an email to a group of people asking for a response and no one replys because everyone hopes that someone else will do it?

In addition to whom you are communicating with, you must be very clear about the reason for the message and your expectations for a response. If you are just providing information, make it clear that no response is required. Who wants to get email messages that just say "Thanks for the info?" If you need a response be clear about 1) what you need, 2) who you expect to respond, and 3) when you need the response. You will find that being clear about expectations makes your life easier. So the few moments that you spend "thinking before you send" will payoff with much greater time savings when you are getting your messages the next day.

And of course, be polite and be concise. As many times as we say it, no one wants to read long email messages. If you need to have a conversation with someone, schedule a time. There are many communications that don't work well via email.