What’s available

As part of supporting professional development everywhere and getting the word out about Bridging the Gap resources, it’s my pleasure to be able to offer professional association chapters a complimentary copy of the following eBooks:

• How to Start a Business Analyst Career ($20 value)
• How to be a Contract Business Analyst ($15 value)
• The Promotable Business Analyst ($75 value)

These eBooks can be used as door prizes for chapter meetings or for any other award the Chapter Board of Directors deems appropriate.

All I ask is that you mention the eBook was donated by Bridging the Gap and that you refer interested members to http://www.bridging-the-gap.com for more information.

Logistics

To receive a complimentary copy, please confirm the appropriateness of the association in advance with Laura Brandenburg using the “Contact Us” form.  Any IIBA chapter meeting is pre-approved.

Download the one sheets below to provide as a handout in your chapter meeting. This explains how the award works and lets the recipient know what they will be receiving.

Once the eBook has been awarded, email recipient’s name and email address by using the “Contact Us” form on Bridging the Gap. An email with a link to download the appropriate eBook will be sent to the recipient within 5 business days (usually expect a turn-around within 24 hours). Recipients of The Promotable Business Analyst will also receive an invite to an exclusive LinkedIn group.

Restrictions

• One copy of each book is available to each chapter within a calendar year.
• eBooks cannot be awarded to chapter board members.

download: The Promotable Business Analyst - One Sheet (363.08KB) description: Download a printable one sheet to share with the recipient of The Promotable Business Analyst.

download: How to Start a BA Career -- One Sheet (311.54KB) description: The must-have resource for professionals interested in becoming a business analyst! Download this one sheet to share with your lucky recipient.

download: How to be a Contract BA - one sheet (285.85KB) description: In today's world, contracts can sometimes be easier to come by than full-time positions. Help you recipient plan their career as a BA contractor with this handy how to.

Related posts:

1. Why I introduce eBooks with an introductory price and offer If you are subscribed to our newsletter, you already received...
2. What part does the IIBA play in your professional development?: Interview with Kym Byron, CBAP The best business analysts are open-minded. They let you help...
3. IIBA Interactive Webinar: The BA Career Path – Becoming, Being and Building Editor’s Note: This IIBA(R) panel and webinar is open to...

You are a good software engineer, database manager, or software quality assurance professional who recently discovered that business analysis is the role you enjoy the most. How do you go from a technical role to a business analysis role?

This is a problem faced by many aspiring business analysts, and even by people who already spend time doing business analysis work in technical positions. What should you do to prove to potential employers that you have the necessary skills to take a formal BA role? How to avoid being constantly “dragged back” to an IT role when the volume of development work grows or the size of the IT staff is reduced?

Having solid technical skills can be a great starting point for someone looking to develop a career in business analysis. In Why do we see technical skills in business analyst jobs? Laura lists a good reason why many BA jobs ask for technical skills: BAs with technical knowledge are more likely to ask the right questions about technical implementation.

The assumption becomes if you can write code now or could write code in the past, you are less likely to be trampled by the developers.

I remember at least one situation in which my technical background (electrical engineering, with time spent programming in C and Java) came to the rescue of a system enhancement project in danger of not fulfilling the business need. The developer (who had inherited the code from someone else), was adamant that one of the business requests could not be implemented without a major code rewrite, which would require time and budget the project didn’t have. I asked him to explain to me the basis for his opinion. After some investigation, I discovered that the initial implementation had a flaw that could be easily corrected. By simply changing a primary key in the database (to the one that actually made more sense from a system and business perspective), it would be possible to implement the feature the business requested. The developer wasn’t exactly convinced by my arguments, but I scheduled a meeting with him and the head of development (a manager with excellent technical background), and the manager immediately saw that my analysis was correct. The featured ended up being implemented without the major code overhaul proposed by the developer.

Situations like the one described are not uncommon when business analysts with a technical background work together with business subject matter experts and the IT team to find the optimal solution for a business problem. A business- and technology-savvy analyst can be instrumental in helping determine the business need and define the optimal solution to meet this need.

The biggest obstacle for IT professionals interested in developing a BA career is the lack of well-developed business skills. One might argue that “soft skills” (the ability to communicate with clarity, precision and eloquence, work well with other people building effective contacts and relationships across and outside the organization, and so on) are more important for a BA than being business-savvy. However, in my experience, software engineers who are passioned about business analysis already value and develop their soft skills, so it’s typically not the main competence gap they face when they try to switch to a BA position.

Understanding things like revenue streams and profit centers, on the other hand, may require a mode of thinking that is relatively unfamiliar to many technical people. Often, IT professionals are more skilled at writing elegant code, and producing software rich and features and functions, than at helping stakeholders determine the right set of project requirements capable of balancing the needs of the company, the market, and the users.

If you have a background in IT, and want to become a business analyst, here are some steps that will help you reach your goal:

1. Read Bridging the Gap regularly. Here you will be able to interact with BAs who successfully made the the transition from a technical role, and read articles like What jobs will lead to a BA role?, which will give you good insight on how to highlight your BA experience in your resume, and how to use other roles as stepping stones to get a BA job.
2. Periodically reassess your competence gap and make sure you have a plan to address them.
3. Learn to “talk the talk” of business analysts. The site Modern Analyst offers a useful list of potential interview questions that can help you formulate your thoughts and become better prepared to answer screening and interview questions.
4. If you haven’t started yet, read business books, and blogs such as the ones from Harvard Business, as well as resources that can help you build your business analysis skills, like the ones I recommend here.

Finally, if you are truly invested in developing a business analysis career, buy the eBook How to Start a Business Analyst Career: A guidebook to help you explore the business analyst profession and find entry-level business analyst jobs (affiliate link that generates a commission for this social project at no additional cost to you). This comprehensive and well-thought handbook by Laura Brandenburg will help you get a better perspective about the different types of BA roles available and add some shape to your target position, as well as teach you everything you need to do to put yourself on the right path to landing a BA job.

Related posts:

1. Why do we see technical skills in business analyst jobs? Why do we see technical skills in business analyst jobs?...
2. Help a BA! How do I transition from an intellectual analyst to a business analyst? Reader Question: I have honed serious analytical skills in college...
3. Help a BA!: Will I gain portable BA skills as a Technical Analyst? Reader: I had a question for you and would really...

Reader question:

I’m working as a BA in a company which provide web based Travel Technology. Is there any document from where I can learn on the process and acquire domain knowledge?

Kimberley’s answer:

Where to for information on the travel industry?

I’m afraid there isn’t any short term fix for acquiring domain knowledge. It really is a matter of building experience and knowledge on the job. You are already fortunate to be in a BA position in a company that delivers travel technology, and I would ask if there are opportunities for you to expand on that role. For instance, does your company have internal guidelines for troubleshooting common system errors? If not, can you offer assistance in this area and provide a document that can be accessed by the business side and by your IT colleagues? Have you identified what area of the technology you are strongest in, and that which interests you most? This often presents an opportunity for you to build on that strength and become a Subject Matter Expert.

Find out what the challenges exist in the current state of the system and what the company’s vision is for this system.  It really depends on the system’s functionality and your role in that organization as to what opportunities will exist for you to acquire additional domain knowledge and to create a niche for yourself. But rest assured, there is always an opportunity somewhere if you are willing to look for it.

I would also encourage you to post questions to members on Business Analysts in the Travel Domain, a LinkedIn group I created to provide a forum for Business Analysts, IT and travel industry professionals, and travel domain experts who participate in business analysis activities in their current role, or who desire to springboard into a Business Analyst career in the travel domain.

What do you think? How would you answer this reader question?

Related posts:

1. Help a BA! What retail industry domain knowledge is required for business analysts? Reader question: “What domain knowledge is required to be a...
2. Help a BA!: How do I break into the financial industry with no industry experience? Editor’s note: This week we are tacking the tough question...
3. Is your strength grounded in system knowledge or business analyst competencies? Do you pull from your strengths as in communicating and...

Part of preparing for requirements elicitation is identifying questions. You definitely want to avoid securing valuable stakeholder time only to be lost about what questions to ask! Some stakeholders will talk your ear off, but others need to be led through a conversation. Regardless, I’ve found that preparing a list of requirements questions helps me keep the conversation on track.

Requirements questions can feel like peeling off the bark of a tree

This post is about identifying targeted questions for a scoped project. Often I do this by building a requirements questionnaire. If the scope of your project is not yet defined, you might want to check out “5 questions to ask before starting any technology project” for some generic elicitation questions that work on most any project or “10 ways to discover what the problem really is” for alternate ways to ask about the problem space.

Update 8/31/2010: As has been pointed out in the comments, asking “why” is very important. If you don’t have a clear understanding of the “why” behind the main features, you are probably not ready to create a requirements questionnaire and should start with one of the posts above to help you discover the business needs before drilling into the details.

What is a requirements questionnaire?

A requirements questionnaire is a list of questions about the project requirements. Typically the questions are organized by feature (or business requirement or project objective). Essentially each high-level requirement from your scope document should have a list of questions to further refine your understanding. Investing time in a requirements questionnaire will help ensure you not merely gather up requirements, but also that you discover undreamed of requirements as Adriana writes about in “Beyond gathering, eliciting, and trawling for requirements.” The more you learn about a topic the more questions you have. So requirements questionnaires tend to evolve over time.

Requirements questionnaires are project sensitive. No one questionnaire will work for all projects. If your organization does projects of the same type, you might be able to build a questionnaire template. If you are working on multiple different project types, you will need to write a questionnaire for each project. There are some resources scattered across the web where you might find question lists for your project type and that’s one of the resources I’ve considered building as a Bridging the Gap product.

What requirements questions should I ask?

I work through each feature one at a time. I write down what I know about that feature (or what I assume to be true about that feature). Then I go about drafting questions. Most of the time, the questions evolve naturally as I think through the implications of a feature. But sometimes I need to spur my thinking a bit.  Just like a good story, requirements will answer all the important questions. Think about the how, where, when, who, what, and why.

Here’s some generic questions you can use to spur your thinking.

How requirements questions

• How will you use this feature?
• Is this feature a process and, if so, what are the steps? Or, what questions can I ask to ascertain the steps?
• How might we meet this business need?
• How might we think about this feature a bit differently?
• How will we know this is complete?

Where requirements questions

• Where does the process start?
• Where would the user access this feature?
• Where would the user be located physically when using this feature?
• Where would the results be visible?

When requirements questions

• When will this feature be used?
• When do you need to know about…?
• When will the feature fail?
• When will we be ready to start?

Who requirements questions

• Who will use this feature?
• Who will deliver the inputs for the feature?
• Who will receive the outputs of the feature?
• Who will learn about the results of someone using this feature?
• Who can I ask to learn more about this?

What requirements questions

• What do I know about this feature?
• Or, what assumptions am I making about this feature that I need to confirm?
• What does this feature need to do?
• What is the end result of doing this?
• What are the pieces of this feature?
• What needs to happen next?
• What must happen before?
• What if….? Think of all the alternative scenarios and ask questions about what should happen if those scenarios are true.
• What needs to be tracked?

Why requirements questions

Why questions are great wrap-up questions as they help confirm that the requirements you just elicited map back to a need you identified when you scoped the project.

• Why do we need this feature again?
• Is there any other way to accomplish this?
• Does this feature meet the business need and solve the problem we’re trying to solve?

A sample requirements questionnaire

As an example, here’s a list I came up with for a recent search feature, with a bit of ambiguity introduced to protect the client.

1. Where is this search triggered in the product?
2. Do you have to select a category to see the results list? Or, would we show all items in the results list?
3. What do you see when you search? Does this look like an existing listing or different?
4. Are the products in this list presented the same way as on our current product?
5. What if the user has not selected a location?
6. What if a category does not exist?
7. What if a category has multiple associations?
8. What stats need to be tracked when this happens?
9. How/where will those stats be visible and to whom?
10. How can we expose this new feature to make sure it’s well used?

Using the requirements questionnaire to ask the right questions

Oftentimes I will share a questionnaire with the stakeholder, but I never expect them to prepare their answers. And when I go into elicitation, rarely do I go through the questions one by one. Instead, I typically select a few core questions off the list and to try to get the stakeholder talking. Then, as they are talking about their vision for the feature, I use this questions list to guide the conversation and ensure we’re discussing the feature completely. I would say I typically only actually ask about a half of the questions on the list. The rest the stakeholder typically answers indirectly through conversation.

How do you prepare for requirements elicitation? Do you use a requirements questionnaire or does another technique work better for you?

Related posts:

1. How to become more confident in requirements elicitation The initial meetings with a stakeholder can be nerve-wracking. Oftentimes...
2. Reverse engineering requirements: Create a Work Plan By now you are probably ready to start meeting with...
3. Using a stakeholder requests list as part of scope definition Oftentimes a business analyst gets involved in a project with...

Reader question: I find it frustrating that recruiters take such a huge mark-up on my salary. It seems that I am doing most of the work and responsible for delivering value to my employer. Why do they get paid so much?

Steve’s answer:

Recruiters have to make money somehow. They provide a service ‘adding value’ by helping employers find suitable candidates for roles. A recruiter saves a busy employer time administering job adverts, receiving the many applications that a role inevitably would receive, filtering out suitable candidates, and vetting them before presenting them to the employer.

A recruiters job can be tough and time consuming. As one recruiter friend explained to me, recruiters are people brokers, finding the demand, then finding and selling a product that fits that demand, with the added risk that that product could choose to walk away from that deal at any moment! It is an unpredictable risky business and their reward for this task is the mark-up on the salary paid to you by the employer. This means that the recruiter only gets paid upon the signing of a contract.

Editor’s note: To learn more about the recruiting process and contracting as a business analyst, check out Steve’s eBook How to be a Contract Business Analyst (International Edition).

Related posts:

1. What is the difference between a BA contractor and a consultant? I’ve been getting a lot of questions about being a...
2. Help a BA! I don’t think this recruiter understands the job requirements Reader question: I’ve interviewed for a job and I’m fairly...
3. Overcoming common challenges to find contract business analyst jobs In this article I will describe the common challenges that...