CBAP Question of the Day: Prototype it is...

If you choose Prototype for our last Q&A, you were correct! Actually 50% of you were :)

The question was: "What is the best method used to model a shallow view of system functionalities?"

You can find the answer to this question under section 4.9 of BABOK.

Beside what you will read about prototyping in the BOK. Whethere you are taking the CBAP or if you are curious about prototyping, remember this:
Prototyping is a great way to reduce risks. A prototype is tool used to give a visual representation of the solution. It helps clear any assumptions about the functionalities of the solution and can speed up development process. It's easier to imitate or retrace an existing object than to create one from scratch! There are 4 types of prototypes:

Horizontal prototype: Models a shallow, and possibly wide, view of the system's functionality*
Vertical prototype: Models a deep, and usually narrow area of the system's functionality*
Throw away prototype: Used to quickly uncover interface requirement using simple tools (paper & pencil)*
Evolutionary prototype: More complex than the throw away. This prototype technique uses sofisticated tools to build upon an initial interface.*

*BABOK Definitions

Last Q&A

Those who of you who answered "Assumption" were right on point ;)

The question was:
What is defined as: "Factors or conditions which are considered to be true or to exist without the need to provide documented evidence".

As a business analyst, you have to pay attention to assumption cues. In order to elicit assumptions, you must talk to the stakeholder and really listen to what they are saying. As humans, we easily make assumptions about things. And since communication isn't an easy task to accomplish, assumptions can become risks in your project.
An assumption could be related to resources, time or even money. Project team members and stakeholder can have assumptions about the type of solution that will be used (off the shelf, built in... etc) or they may make assumptions on technology standards.
Flush out the assumptions at the beginning and clear them out before they become risks.

Importance of Perspectives

In my blog about the Zachman Framework, I introduced the framework and its components. Today, I read a great post by Barbara Carkenord at B2ttraining: "Why Identify Business Processes and Use Cases?". The point of her blog post is that Business Analyst shouldn't jump into defining use cases without first describing the business processes because they both come from a different perspective. And as we saw from my Zachman Framework post, Business process emerge from the perspective of the Business Owner.

What is a Business Process?

From wikipedia: A business process or business method is a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers.
There are three types of business processes:
Management processes, the processes that govern the operation of a system. Typical management processes include "Corporate Governance" and "Strategic Management".
Operational processes, processes that constitute the core business and create the primary value stream. Typical operational processes are Purchasing, Manufacturing, Marketing, and Sales.
Supporting processes, which support the core processes. Examples include Accounting, Recruitment, Technical support.

This is the "HOW" or "Activities" that allows the enterprise to create products or services. The Business Owner's interested in business processes stems from their desire to keep cost under control by doing things effectively and efficiently. This is where you will get your business requirements. Skipping the definition of business process means missing out on the understanding of the important tasks within an enterprise and how those tasks are performed. if the end result is to find/build a solution that makes work easy (via automation or introduction of a system), then understanding how things are done is important. A Business Analyst who doesn't understand the business process will not help the Business Owner achieve their desire for effectiveness and efficiency.

Use cases on the other hand contains the definitions of actors (users of the system) and desired system's behavior. This is the perspective of the Architect. When defining the What, How, Where, Who, When and Why, use cases fall under the "WHO" in the Models of Fundamental Concepts. This perspectives looks at the underlying functions of each business process. Your functional requirements will come from use cases.

Moral of the story, you can't have on without the other. As Barbara points out: they are both important. To have a complete set of requirements you must complete both business processes and use cases.

Last Q&A

This question is the fundamental of Business Analysis. Without Elicitation we don't really have much. The foundation of our job is elicitation. Elicitation is where the BA distinguish themselves from other professions. If you don't ask the right questions, if you don't get the right information, you can do as much analysis, communication or documentation as you desire .... your requirements will be no good if you do not pay careful attention to elicitation.

The questions was:

Eliciting Requirements means:

Most of you said answered: To gather requirements from stakeholders (50% chose this)

The right answer is: To draw forth or bring out something latent or potential (18% got it right)

Here you have to pay attention to the meaning of words. To gather means to collect or to bring together. When you gather requirements, you are passively going around and collecting requirements from stakeholders. When I was young my grand mother used to take us out in the forest to pick mushrooms (I will tell you about my background in another story). Mushrooms grow by themselves on the ground and don't need special tools to gather them. You can easily pick them with your hands. Here picking mushrooms is the same as gathering requirements. There is no efforts; it doesn't require thinking, preparing or any tools or techniques. If eliciting was the same as picking mushrooms, everyone could call themselves Business Analysts.

But our profession requires that we actively pull requirements from stakeholders. Sounds pretty aggressive huh! Now, for your imagination, think of collecting apples. We all know that apples grow on trees. In order to collect apples you either have to climb on the tree to get one apple at the time or you can shake the tree for a faster result. This act of climbing or shaking requires a lot of effort. It requires planning, creativity, strategy, tools, techniques... etc. That's what happens when you are eliciting requirements. Elicitation means: To draw or bring forth the requirements. This is a skill, a science and an art. For more references see section 4.1 of your BABOK.

Note: If you think picking fallen apples is also an efficient way to collect apples, think again. Fallen apples are not usually good apples. For you to distinguish the good ones from the bad ones, you will have to cut them (waste) to make sure they are still good (worms may reside inside). Same with requirements... the ones that are obvious or easy to get requires that you dig deeper to draw out more details (those requirements may have hidden assumptions).

Last Q&A

The questions was:
What is one of the techniques used to conduct current state assessment?

26% thought the answer was Context Analysis
15% thought it was Task Flow Analysis
1% answered: Georgraphical Maps
7% answered: Use Case Diagramming

The answer was: Geographical Maps
See section 2.3.8 of your BABOK. I know I threw you off a bit but keep reading and getting ready for the CBAP :)

The BA Connection

I don't know about you, but I am getting tired of all these articles written because of today's economy. It seems that every corner we turn, someone is getting laid off or is looking for work. I met a few Business Analysts who were in this unfortunate predicament. They were kind enough to share their experience in the job market. It seems that even though there are about 2 Business Analyst job openings a day, no one seems to hire. The jobs are very volatile. By the time you submit an application, the opportunity disappears. Recruiters are not much help. They are not in control of their client's budget nor do they have a say in who can come in the door for an interview. Is there a best way to get your foot in the door? Is there hope for the BA job seekers?
Yes, there is a bright light at the end of this tunnel.... I won't claim that I am going to get you a job but here are few tips for you to consider.

1.0 - Network

When I was still a student in college, I remember being told that networking was the best way to get a job. I didn't know much about it but my teacher convinced me to join a network group (it was part of an extra credit). I got my first job through a lady I knew from my network group. I landed my second one through a friend from college.... and so came many other opportunities.
Moral of the story: In this day and age (despite the economy) it's not always what you know... but also who you know.
The number of Network groups are on the rise. There are virtual network groups and well as the face to face ones. You have your pick! The key to networking is to join and mingle.

Here are some BA virtual groups you can join:

IIBA: independent non-profit professional association serving the growing field of Business Analysis
RQNG: a community and knowledge sharing for the business analyst
ModernAnalyst: a community and resource portal for the business analyst
BATimes: forefront of relevant content surrounding all developments regarding business/systems analysis, CBAP Certification, industry events and cutting-edge BA insights
BACollective: another BA community for knowledge sharing
Business Analysis on ITToolBox: learn about Business Analysis methodologies and issues related to business planning, data analysis, business analysis tools, and the role of a business analyst.

Linkedin BA Networking Groups

Atlanta BA
Analyst World
BA Forum
Business Analysis
Business Analyst Group
Business Analyst Professional
Business Analyst
Business Systems Analyst
IIBA on Linkedin
IS Business Analyst

Facebook BA Groups

Business Analysis
IIBA on facebook
Business Analysis Support Group
Business Analysis Mentor

A list of non-virtual Network groups

IIBA Chapters
Atlanta SPIN: to provide a forum for the free and open exchange of software process improvement experiences and ideas
TAG Business Process Management: to provide a leadership forum focused on influencing enterprises to build a process improvement culture to improve competitiveness
TAG Enterprise 2.0: explore key strategic and organizational shifts that organizations need to make in order to adapt to the changing landscape of the digital world


2.0 - Volunteer

You have joined a group, now what? Do you take the back seat and wait for things to happen? Do you come to meetings and hope you make friends?
I hope not! One good way I have found to successfully network is through volunteering.
Volunteering has many benefits. Not only do you get tremendous amount of experience but you also forge relationship with people. Remember, the idea is to let others know what you are capable of. You want to show off your talent or show them what a hard and dedicated worker you can be. The key here is to put in the best of yourself. If you are not currently working, volunteering will keep you marketable. There are plenty of organization in need of help (that's another topic). You also may never know when a budget may get approved to turn that volunteering position into a paying position.
If you join a virtual network, volunteering can be tricky. You want to show that you are there. Most of these networks are knowledge sharing tools. My suggestion is to write articles or blogs to help them with their content. If you can't find what to write about, try reading a BA book and sharing the summary of what you've learned. You can also share personal experiences.
You can also contact virtual network and find out what you can do for them. Nobody will reject free help.

We've come a long way

I recently found this article: Sidewalk: Who owns Business Analysts? by Vinayak. This article talks about the confusion that Organizations as well as Business Analysts had about the BA role. I believe we've come a long way since the time when everyone treated us as aliens because they had NO IDEA what to do with us.
Slowly, the BA profession is shaping itself up. I know there are still some confusion as far as the boundary of our work and the types of BA there are. But at the minimum, when you say you are a BA, people know that you are a liaison between business and IT.
We have come a long way but we still have ways to go. This is why the work done by IIBA is very important. As activities, tasks, techniques of Business Analysis become somewhat common knowledge. More BA will be able to articulate the type of BA they are and what activities they specialize in.

Last Q&A

I see that the question below had us everywhere.
22% thought the answer was Discounted Cash Flow
31% thought it was Net Present Value
4% answered: Internal Rate of Return
and 41% answered: Average Rate of Return

The question was:

What technique is used during the preparation of the business case to measure the excess or shortfall of the project cash flow?

The answer is:

Net Present Value

This question was a bit tricky as the BABOK does not define these techniques. In section 2.5.9 you will find a list of different techniques. Make sure you know where and when to use these techniques. A good definition of NPV is found on wikipedia.

Tools for Success

If you have subscribed to this blog, you are probably looking for answers to your question in Business Analysis or you want to know more about how to pass the CBAP. If you are a seasoned BA, this may also apply to you but if you are in it for the long haul, hear me out.
In order for you to be successful with passing the CBAP, you must have experience in 4 out of 6 knowledge area in the BABOK. Experience doesn't come easy, especially if your manager thinks that you are the best document reviewer and won't give you opportunity to write a few use cases or elicit requirements from stakeholders. If you are seeking this opportunity, you must first show to your superiors that you have the knowledge required for you to accomplish the task. You must to learn to talk the talk before you can walk the walk.
I recently read an article on learning that I thought can help you in your path to learning the BA skills needed. The article is "How to Become a More Effective Learner" by Kendra Van Wagner
One of her tip for learning is to "teach what you have learned to another person". I personally love this method so much that I have applied it in study groups that I run here in the Atlanta area. If your manager doesn't give you the opportunity, in CBAP exam prep study group, you will have the opportunity to show other BA that you know what it takes to get the job done :)
Whether you have 10 years of experience or you're just starting out, you will find this method very effective. You will even gain the confidence needed to share what you've learned in your work place. And who knows, you may even become the expert on the subject that you may land more opportunities to prove yourself.

If you are implementing a study group in your city/state/country... think about ways that you can promote learning and help others achieve their goals

Which BA are you?

I have never heard of a profession that has more titles than ours. Sometimes I wonder if the reason why everyone is so confused about the role of Business Analysts isn't related to the vast array of hats we wear and things we do. For someone who is new to Business Analysis, this can be confusing.
Imagine this scenario: you just read a great BA job description for a job that you are really interested in. The job is asking for someone who understands different Business Analysis techniques and can be a good liaison between different stakeholders.
Without a question, you know you qualify... First day on the job, things are becoming a bit gray. Who do you liaise with? Do you really have the experience using Business Analysis techniques in the context of your new job? How can you tell if an organization is the right fit for your skills? What type of BA are you and should you be?

BA in customer facing organizations

If the organization has external stakeholders -- consumers of your products or services, and is small enough where internal processes are not complicated enough to deliver the solutions; The role of BA in such organization can be solely customer facing. This BA would work with the BA of the other organization (assuming there exist one) to analyze the need of the external organization and define requirements based on the capabilities of their products and/or services. In my past experience, this role requires not only the hard skills of Business Analysis (interviewing, requirement workshops... etc) but you will bring more value to this organization if you knew how to negotiate, facilitate, lead meetings... etc. The skills not taught in school. But most importantly: If you are this type of BA, you may not have the opportunity to define your stakeholder's processes nor may have time to do so. The BA in this role has a number of challenges:

1. Quickly grasping stakeholders process and assessing if the solution will address these processes.
   
2. Defining the gap needed for the product/service to fulfill the requirements.
   
3. Remembering who they work for... hint: not the client!

Internal BA

You may also find yourself working in an organization where your job is confined to fixing internal processes. In this role, there isn't much convincing you need to do. Your job is to define the As-Is (Current State) then work with internal stakeholders to develop a To-Be (future State). Your job is to understand what does the process do... what is its end result. Then assess its efficiency (is the process producing the end result without wasting too many resources - time, money, human capital... etc)

Hybrid BA (and I don't mean PM/BA or BAM)

I am talking about BAs who must interact with external stakeholders to understand their requirements. At the same time, they also review internal processes in order to determine if the implementation of a solution will affect internal processes. For example, after conducting market research your company decides to implement a product. You decipher requirements from the research... before you finish documenting them, you need to turn to the business/operation side of your organization and see how the implementation of the solution will affect their processes (training, customer support.. etc)
You may find yourself documenting the as-is and formulating the to-be process that will support the solution.
This role can be broken up into two BA roles or can be combined into one role. In my experience, companies do not break up this role. The person in this role has to understand process modeling and reengineering to some degree and also be great with documenting business requirements and user requirements. Then translating them into functional requirements.

My question to you is what kind of BA are you? Have you found yourself working in different scenarios than the ones I listed?