Business Analyst Blog

Recently MARTA, Atlanta’s mass transit system, installed a fancy new fare system which takes “smart” cards instead of tokens.  Things were a little bumpy at first but overall the new system seemed to be working well until the unexpected happened. Yesterday an article in the Atlanta Journal-Constitution talked about how MARTA took a heavy economic hit when the new fare system suddenly crashed during a maintenance upgrade and was down for about a day. About 115,000 people ride the MARTA daily. During the system downtime none of the cards would swipe, the Marta smart card vending machines quit working, more clerks were required than usual at each of the 38 stations affected, confused riders could not get through the blocked turn-styles, and others were inconvenienced to find cash to ride the bus. One of the outcomes is that MARTA is considering suing the outsourced software provider for damages.

Even though I do not know the details, clearly thorough testing was not performed during the upgrade process and based on the “free riders” snafu an acceptable disaster recovery plan was not in place. Like Jet Blue’s recent software fiasco that left travelers stranded, the MARTA system crash is another example of the potential financial impact an organization can suffer when technology suddenly goes awry. The lessons learned for these organizations may be more attention to plan for higher quality systems and also to have plans in place when the unexpected happens.  One of my recommendations would be to hire and utilize skilled and thorough Business Analysts who will define excellent requirements and who will be proactive in finding problems early before the defects can be coded in the software.

The MARTA system upgrade should have been a normal maintenance activity. MARTA could/should have involved a BA to review the upgrade changes and validate that sufficient testing would be performed for the upgrade. Based on the money that was lost the temporary workarounds were not effective. No matter how stable a system seems to be, planning for disaster recovery is vital for any critical software system. A BA has skills to elicit and document an acceptable disaster recovery plan to reduce the business exposure in the event that something drastic happens. Disaster recovery planning can be started early in the project when BAs identify potential risks and assess their impact to the business. The plan can be finalized once a solution has been defined. Lastly, MARTA could/should have a skilled BA facilitate and document a root-cause analysis about what happened and communicate the results to the impacted stakeholders.  This analysis would establish why the crash occurred and would hopefully lead to process improvements for future software changes. I think MARTA (and Jet Blue) should either hire or make better use of Business Analysts.

Applying for the CBAP (IIBA BA certification) is a bit daunting. The application process requires that you show that you really do have more than 5 years business analysis experience. This is very important because we, as a profession, want the certification to be meaningful and strong. We know that simply memorizing a bunch of BA terms and techniques does not make a person a Business Analyst. It is our experience that makes us what we are.

So, be aware that the application itself is more important than the CBAP exam in determining your eligibility for certification. Below are some hints for developing an application that accurately describes your experience.

1. Be careful documenting your PM work. Although many of us have done PM work, that work does not count towards your BA experience. Be sure to describe planning activities that you have done as requirements planning, stakeholder analysis, scoping the area of study, or scoping the requirements elicitation process.

2. Be careful documenting your QA work. Although many of us have done QA work, that work does not count towards your BA experience. Be sure to describe testing activities that you have done as identifying test cases that assess business requirements met, tracing test cases back to business requirements, reviewing QA test plans, cases, scripts for adherence to business requirements, reviewing test results for adherence to business requirements.

3. Don't forget about usability work. Many of our organizations have just started using the word usability but most of us have been doing it for years. Whenever you have helped your team design a screen that is more intuitive for its users you are designing usability.

4. Don't be afraid of Enterprise Analysis. You have probably done more Enterprise Analysis than you realize. If you have discussed possible project ideas with your business stakeholders and helped them determine if the project was a good idea (feasibility, alignment with business goals and architecture), you have experience in Enterprise Analysis.

5. Don't detail descriptions of specific projects. Although fascinating to you and your project team, the IIBA application reviewers don't need to know details about the application that you worked on. Describe projects with short, clear names that an outside reviewer would understand. For example: instead of saying: "The DEFSSC project interfaced the INCC system with the EFT outlink." Say something like: "The project involved linking the existing customer purchase system with an outside credit card processing service."

6. Do give specific examples of the types of requirements that you have elicited, analyzed, documented, communicated, and helped to implement. This should be the core of your application. Example: I developed a detailed business model of the payroll processing area by: interviewing 10 business stakeholders; developing a workflow model including over 15 diagrams; presenting the workflow model to the stakeholders; revising the model based on feedback; and obtaining approval of the recommended workflow changes.

7. Do document all of the work you have done in the last 10 years. Showing more than the required 7500 hours allows for a few items to be rejected but your application to be accepted. Document everything that you can.

8. Do enjoy the writing! How often do you get to brag about your accomplishments? Don't dread the writing, enjoy it! Good Luck, Barb

We are often asked by managers if we have a list of suggested interview questions for BA candidates. We do have a few and are happy to share them. As I was thinking about effective ways of evaluating BA candidates I was reminded of an interview that I had many years ago. After the traditional "talk" with the manager and HR, they gave me a written test. One of the questions presented a diagram of a system (a combination of an ANSI flowchart and a system architecture diagram) and asked me to consider the strengths and weaknesses of the system design. This was an essay question and I had one page for an answer. I really enjoyed this question because I immediately saw lots of flaws in the design presented (redundant data stores, overly complex interfaces, etc.). I actually filled up the page and continued on the back of the sheet. This was an excellent way for the hiring manager to evaluate my analysis skills along with my writing skills. Was my essay coherent? Did I find the same flaws that they expected me to find? Did I uncover anything that they hadn't thought of? How did my analysis compare to the other candidates?

I recommend that you ask analysis tests/questions like this when you are interviewing BAs. It can really give you a different assessment of their capabilities than the conversational part of the interview.

Oh, did I get the job? Yes I did, and on my first day I was told that the system I had evaluated during my interview was an old system that my team would be responsible for maintaining!! I should have known what I was getting myself into.

**Our Assessment for Business Analyst Candidates provides the suggested interview questions referenced above.**

This month the Atlanta SPIN (software process improvement network) hosted Kevin Shaan from Borland Software. Kevin talked about requirements development and management. Kevin spent several years as an appraiser for CMM and SEI assessments. He shared his observations about major weaknesses in the organizations that he assessed. Not surprising, poor requirements management was common. He affirmed the importance of having people (whether they are called Business Analysts or Requirements Analysts or developers) trained in requirements elicitation and analysis. He saw the requirements elicitation as a real weakness in many organizations. Problems included participation from the wrong stakeholders, lack of understanding of end users ("user constituency"), and lack of a communication plan. He recommended building the requirements elicitation and management skill set. In addition he walked through the requirements components of CMMI and explained why each is so important.

It is always good to hear more confirmation on the importance of business analysis. Kevin did a great job of explaining why each CMMI component is important and that one of the most effective ways of improving our development process is to have skilled business analysis professionals.

In the next few years I think we are going to see more and more Business Analysts move into executive level positions in both business and IT organizations. Many individuals holding these positions currently have strong business analysis backgrounds (whether or not they ever had that job title). The progression of a Business Analyst into executive management is very logical and smart from a CEO's perspective. BAs understand the core business and understand how to solve business problems. We are very good at looking at business areas from a strategic perspective and recommending forward thinking solutions. Because we understand what technology can do, we can see possibilities for future growth in our organizations and can see a path to get there.

My confidence in our ability to move up the ranks was reinforced when I was reviewing the results of a new survey of CIOs. The survey was conducted by Ziff Davis CIO Insight magazine entitled The Role of the CIO. http://www.cioinsight.com/ One of the questions was Top IT Exec's Most Important Personal Attributes. The top answers were leadership ability (50%), strategic thinking (39.9%), business understanding (39.5%), and communication skills (31.6%). 

While most of the CIOs prior responsibilities were IT management (82.3%), many have consulting backgrounds (51.2%) and business management (38.1%). When asked what prior tasks/experiences were most helpful in their current positions they consistently listed work like strategic planning, negotiation, consulting experience, along with financial experience.

Technical work was further down the list indicating that even though CIOs are responsible for the technology group, they report that their current most important responsibilities are working with other executives on contributing to their company's strategic direction. So if you are interested in moving up the corporate ladder, becoming an excellent BA is a great step.

B2T Training Tip

If you made it through the application process then you are half way home.  There is no need to get overly anxious about the exam.  But, since you are probably like me, you are still very anxious.  I hope the Q & A below helps relieve some of that anxiety.   

Q & A

Question: How many questions are on the exam and what is the format; multiple choice, true false, etc.?

Answer:  The exam consists of 150 questions and they are all multiple choice with four possible answers.  Only one answer is the correct answer and there are no multiple correct choices, i.e. one of the answers is not 'A and C.'

Q: How long are you given to take the exam?

A: You have 3.5 hours to complete the exam.  It took each of us at B2T Training between 2.5 and 3 hours to complete the exam.

Q: What version of the BABOK is the exam based on?

A: The exam is and will be based on version 1.6 of the BABOK until further notice.  As of 5/1/07 the IIBA does not plan on updating the exam until version 3.0 is released.

Q: Are all the questions taken directly from the content in the BABOK?

A: The short answer is no.  The test writers used the BABOK and the references listed in the BABOK to write the questions. 

Q: What question types were used?

A: The test writers used Bloom's Taxonomy as a basis to have varying levels of question difficulty. An overview of Bloom's Taxonomy can be found at http://www.coun.uvic.ca/learn/program/hndouts/bloom.html.

Q: Were the questions tricky?

A: I would not say tricky, but a large percent of the questions had good distractors.  This means that two answers appeared to be correct.  You have to take your time reading each question to ensure you understand what the question is asking and that you select the best answer.

B2T Tip 

We created a CBAP study group to discuss the BABOK in our organization. Here's how we structured it and what we learned:

• Assign each Knowledge Area to one or two BAs - they will facilitate the session on their KA
• Schedule 1 1/2 hours per session
• Schedule dates/KAs ahead to give everyone time to prepare
• Require participants to read the Knowledge Area before the session
• Present BABOK tasks and ask for questions/issues
• Presenter(s) shares his or her experience with each task and technique

Since everyone in our group knows each other we are aware other's experiences. Our facilitators specifically pointed out ideas in the BABOK that were different than our experience.

Q & A

Q: What materials are used for the study group sessions?

A: We built PowerPoint slides with highlights of each task/technique. The Atlanta chapter has been sharing slides so we did not have to start from scratch. My advice is don't just copy text from the BABOK onto a slide. Paraphrase and summarize the concepts.

Q: How often should a study group meet?

A: Our group met every two weeks. The schedule should be geared towards when participants plan to take the exam.

Q: Is anyone "in charge?"

A: Yes. One person must be the coordinator. He or she makes sure that facilitators are ready for each session, reserves the conference room or conference bridge, and monitors the meeting time.

Q: Who decides how topics are covered?

A: We just started at the beginning of the BABOK and went through sequentially. Don't forget Chapter 1 - it has important foundational information.

Let us know if you have any questions about starting your own study group.

 Hot News

The IIBA has extended the application deadline for the Atlanta, Houston, and Minneapolis exams.  The new dates are:

• Atlanta - April 27, 2007
• Houston - May 7, 2007
• Minneapolis - May 7, 2007

B2T Tip

The application process may seem like a daunting task, but you can do it.  Break it down into small chunks and take it one step at a time.  The most challenging part will be documenting your work history.  Dedicate some uninterrupted time to try and tackle this task.  Don't go overboard with details.  Make sure to highlight the tasks you performed and the deliverables you created for each project.

Q & A

Question: What are the requirements to sit for the CBAP exam?

Answer:  You must have

• 5 years (7500 hrs) of business analysis work experience in the last ten years
• documented experience and expertise in at least four of the six knowledge areas of the BABOK
• a high school or equivalent education
• 21 hours of professional development in the last four years directly related to business analysis or the underlying fundamentals

Q: What information is required on the application?

A: There are six main categories on the application.

• Personal Information: Name, contact info, IIBA Member data
• Company Information: The name, size and primary business activity
• Work Experience: Project dates and description, contact information of someone who can verify the project and your work, organizational info, your total hours on the project, your total business analysis hours on the project, and a description of your business analysis activities (tasks and deliverables).
• Knowledge Area Expertise: Complete a task survey related for 4 of the 6 knowledge areas and underlying fundamentals covered in the BABOK.
• Education history
• Professional Development:  Information related to training meeting the necessary 21 hours of professional development. 

Q: How long does it take to complete the application?

A: Give yourself between 6 and 10 hrs to complete the application.  The number of projects you need to document is the key variable in the amount of time needed to complete the application.

Q: I am having a hard time finding contact information for a manager on a project.  What should I do?

A: You can list a project team member, project sponsor, or SME that can vouch for the project and your business analysis tasks and deliverables.

Q: Did the IIBA scrutinize the applicants?  Were any audited?

A: The application is a major part of your certification.  The IIBA ensures that qualified individuals sit for the exam.  I was asked to supply more information after I submitted my application.  I know of one person whose application was audited and the IIBA announced that some applicants were not approved for the first exam.

If you have any questions related to the IIBA CBAP exam application process please add a comment to this blog entry. 

Three of the sixteen Certified Business Analysis Professionals are B2T Training staff: Barbara Carkenord, Kevin Quilliams, and Kupe.  We are frequently asked about  our exam experience. And many people ask us a number of questions related to the IIBA CBAP exam and application process. Many of you may have similar questions and we thought it would be helpful to dedicate a series of blog entries to answer these questions and provide our expertise. 

There will be an entry covering each of the topics below:

• Application process
• Exam format 
• Exam preparation

I hope you find this set of blog entries useful in your pursuit of becoming the next CBAP.  I am sure you all have many questions.  Go ahead and ask by adding a comment to this blog. We'll start answering them in future blog entries.  We are here to help! 

As mentioned in last week's "Getting Started Part I", I start each project by making notes about what I already know about the project. These are some questions I like to answer about each project to document what I know before I can produce my detailed requirements plan.

Has there been a Project Manager assigned? Do I know the project sponsor? Do I know the priority of the project? Are my role and expected deliverables defined and understood by the project team? Is there a standard methodology that I must follow? Is there a timeline and budget provided for the requirements activities?  

Is there any existing project documentation?  I want to know what has been done (what does the project team know already?). I do not want to duplicate completed tasks. I like to review any documentation available because I may have questions (ok, I always have some questions!).

Do I understand the project purpose and the objectives? Do I know which business processes should be studied? Do I have a good idea about the high-level business requirements and goals? Do I clearly understand the boundaries of this project? Which organizations, people, or systems supply information or requests to the project and who needs to receive information from the project? Do I understand which areas of the business are out of scope?

Who are the key stakeholders who will provide and approve requirements? Do I know any of the stakeholders from previous projects? Do I understand their major concerns and needs? Are any requirements already defined? If any requirements have been documented, have the appropriate people agreed upon them? Have any potential solutions been discussed? Do I know any stakeholders who do not want this project to succeed? Do I know of any other major roadblocks that will impact requirements? Do I know any high business risks for this project?

The good news is that if there is a Project Manager many of these questions are answered during the development of a project charter (see PMBOK). Often the PM and I will work together to define the project charter (also called project initiation document). By making sure I know the answers to questions like these, I ensure that I understand the project in enough detail to work out the details of my requirements plan.