Business Analyst Blog

I saw a great article in the PM Network magazine this month. www.pmi.org It really applies to everyone, not just PMs or BAs.

The article was written by Bud Baker, PH. D. one of the contributing editors to the magazine and he was referencing the very well read book, The 7 Habits of Highly Effective People by Stephen Covey, PH.D. We often spend time responding to urgent matters without thinking about whether or not they are important. Often our most important work is longer term and requires us to manage our time in such a way that each day we work a little towards a bigger goal. Urgent matters come up every day and distract us from our longer term work. It is important for all business professionals, and specifically Business Analysts to constantly ask themselves: Am I spending my time on the most important tasks on my list? Good risk analysis tells us that we need to elicit, analyze, and document the high risk requirements first. These are the most important even though other things may seem more urgent.

We don't have enough time to do all of the things that we would like to do in our jobs. We have to make decisions every day about where we will spend our time. Although it is difficult to say no to some tasks, or put them off - we owe it to our business stakeholders to stay focused on our most important tasks every day.

Continued from BA Considerations when Working with Global Teams - Part 1

1) Selecting and using common (familiar) processes, tools, templates, techniques and standards. We should try to select development processes, tools, techniques and templates for which the team has experience. For the BA the key deliverable is the requirements package. Using a standard template for requirements really helps save time and energy in managing everyone's expectations about what will be delivered. It is still important that the BA communicate which components (like a process decomposition diagram, a logical data model, etc.) their package will include, and how each component will be presented for validation (text, structured text, tables, models, workflow diagrams, prototypes, etc). The team should agree which techniques, notations, and standards to follow when creating models and diagrams. Training may be needed by some team members (see #2). Text should be kept to a minimum because words have so many different meanings (especially across cultures) and add more risk. Models, diagrams, and tables are preferred. Identifying company-wide standards such as legal considerations, security standards, and technical standards i.e., coding languages, platforms, and architecture framework, increases the development team's understanding about the project technical constraints.

2) Acquiring training as needed for the team - specifically regarding requirements elicitation, analysis, and validation techniques or templates. If the project incorporates anything new from the previous item training may needed to provide a common baseline for the team.

3) Scheduling more frequent structured meetings and formal communications. A conference call schedule for when requirements will be elicited, analyzed, and reviewed, who will be involved, and what techniques and tools will be used to develop the requirements. When scheduling meetings for disparate teams try to alternate the time of the meeting regularly so that the same stakeholders are not always inconvenienced by the time zone differences. A clear work session agenda should specify purpose, topics with time boxes, and roles and responsibilities such as identifying who is facilitating the discussion, and what participation is expected from each attendee, what outcome is expected, as well as what collaborative tools will be used. Try to keep discussions focused and short to keep remote participants engaged. Have more frequent shorter meetings rather than broad discussions that can be difficult over the telephone.

4) Adherence to a well-understood and formal change control process. Developers should not be adding in any functionality that was not part of the agreed requirements. Business stakeholders should not be directly communicating with the developers to request additional functionality. Change requests need to be documented and assessed before they can be added to the project scope.

5) Using collaboration tools, wikis, and Internet/intranet project repositories where information can be centralized and shared regardless of the person's location. Certain web-based tools are needed to view and update information by the project team whether they are inside or outside the company's firewall. The team should be able to access the project documents like the requirements package as they need it. Additionally collaboration tools can be used by the development team to show/build prototypes and share details with the rest of the team.

6) Maintaining a secure infrastructure for role-based access to information. This includes maintaining proper security access to view sensitive requirements documentation, any other protected intellectual property such as, internal business processes or other assets such as, customer or account information. This may include determining which team members have "view" privilege and which have "update" privileges to specific project documents.

Having people from different time zones and diverse cultures adds another layer of complexity on your global project to delivering clear requirements, but this risk can be managed successfully. Your comments about working on global teams are welcomed.

Working with remote stakeholders without face-to-face contact is never easy. If we cannot walk down the hall to ask a question or to look over someone’s shoulder to sneak a peek at their progress – we gain little insight into the detailed work and sometimes we don’t know until too late that we are off track. When we cannot read the body language and we don’t understand some of the conversation on a conference call – we may miss much of the intended message. We really increase the risk and complexity of our projects when we are assigned on global teams with people from different time zones, different cultures and with different business norms.

As business analysts we often function as the liaison between two major groups of stakeholders. Not only do we communicate with the business stakeholders to elicit, analyze, document, and validate the business needs but we need to clearly communicate the properly detailed requirements to the development team in a format that they understand and can use to build the appropriate software solution. Communicating well and translating needs is difficult on any IT project.  When our development team is in another country, we need to become much more formal in our processes and communication or we can really have a disaster on our hands. Of course all good projects begin with a shared understanding of the project purpose, scope, and roles and responsibilities. Beyond that, I have learned some key factors which improved my success on global projects. Some items mentioned below are the sole responsibility of the business analyst, such as scheduling requirements work sessions with stakeholders. Others may be owned or shared by the PM, BA or other team members such as acquiring training for the team. The items for consideration include:

1)      Selecting and using common (familiar) processes, tools, templates, techniques and standards.

2)      Acquiring training as needed for the team – specifically regarding requirements elicitation, analysis, and validation techniques.

3)      Scheduling more frequent structured meetings and formal communications.

4)      Adherence to a well-understood and formal change control process.

5)      Using collaboration tools, wikis, and internet/intranet project repositories where information can be centralized and shared regardless of the person’s location.

6)      Maintaining a secure infrastructure for role-based access to information.

Next week’s blog will include more details about each recommendation.

Your comments and recommendations with global teams are welcomed. 

As I talk to folks about anything and everything related to the world of a BA there seems to be different point of views about requirements and solution sign-off.  I often hear that SME's don't want to "sign-off" on the requirements because they may change their mind.  Sign-off has become this dreaded milestone.  In many instances, sign-off is not the problem, but the symptom of something much worse.  The business and the IT solution team are not in sync.  Much of this is due to poor requirements management.  In my opinion, to help resolve the issue you need sign-off. 

When I think of "sign-off" I do not only think of a physical signature on a large requirements package.  Depending on the project and the milestone, sign-off can be a thumbs up, an email, a physical or electronic signature on a document, and everything in between. 

There is a critical reason for sign-offs throughout the project lifecycle.  At different stages of a project you need to take the opportunity to ensure you are headed in the right direction.  As an excellent Business Analyst you should constantly be verifying with your stakeholders that you understand the scope, business requirements, functional requirements, etc.  In addition, you need to make certain the solution team has enough information to deliver the best solution.

To be successful, you need to facilitate the process of delivering a quality solution to your customer.  Getting sign-offs of any flavor will help.   

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.