What this article says about designers also applies to business analysts: don’t wait or ask for permission to showcase your potential.

Work Samples

Don’t wait to get hired to start building a work sample. If you are an aspiring BA, that will help provide evidence to prospect employees how good you are at documenting requirements. Choose an application you currently use (say, a project management tool, or wiki solution, or email client application) and start documenting the requirements as if it’s a future product your company wants to build. Once you are satisfied with your sample, put it in an interview folder and offer to send it to recruiters and hiring managers as part of your application.

(If you need help in this area, the course Crafting Better Requirements will give you the knowledge and confidence you need to write high-quality requirements.)

Process Improvement

Don’t wait for permission from management to start thinking of ways to improve a business process or the requirements or quality assurance process at your organization. Once you come up with a good plan, put it on paper and start preparing to sell your ideas to your boss in a persuasive way.

Elicitation Skills

Don’t wait for an opportunity to start leading requirements sessions to practice elicitation skills. If you need help in this area, the course Essencial Elicitation Skills will drastically reduce your learning curve. But don’t ask for permission – invite a group of coworkers to discuss a process improvement initiative, or colleagues from a local professional association group to brainstorm ideas to attract more members, and start facilitating meetings to get practice.

Ready, Set, Action

Here are examples of questions we receive at Bridging the Gap:

My organization expects me to take both project management and business analysis responsibilities. How do I convince my manager that a blended PM/BA role is not as effective, and that my time is better spent doing what I was hired to do — business analysis — without having to wear the project manager hat as well?

I’m in a company that disregards the BA role. The developers start their design before we’re even finished with our requirements. How do you keep forging ahead and try to get an organizational acceptance of the importance of BA work?

I was recently hired as an IT business analyst. After 6 months on the job I realize that what they really want is more like a project coordinator or admin assistant. My boss forbids me to write design documents or detailed requirements for our software projects. How can I turn this around, or is it likely to be a mistaken hire?

The answer to all these questions boils down to the same essence: having convincing arguments relative to the importance of the business analyst role and your ability to fulfill this role, and knowing how to present these arguments in a compelling way.

Clearly, in order to have convincing arguments, you must be good at what you do, and provide evidence that your work (facilitating requirements sessions, documenting requirements, achieving consensus around the business problem and what needs to be built to solve it, and so on) adds value to the organization.

However, being good is not enough: you must be able to present your case in a manner that creates rapport with your audience and instill readiness for action. Persuasion is an inseparable part of most professions, and business analysis is not an exception. Make it one of your goals to learn how to influence people.

What are you waiting for?

Just start, right now.

>>Get Started

Click here to sign-up for Bridging the Gap’s free email course.

(You’ll also receive new article and course offering notifications, giving you all sorts of ideas on how to get started.)

Would you be interested in learning more about how to visually represent your requirements, even if you have little to no technology skills? Have you been seeing the terms “wireframe”, “mock-up”, and “prototype” in BA jobs and wonder what they mean?

In this article, we’ll discuss what these terms mean, as well as provide some examples that you can use to match up your own career experience.

But first, a story.

My husband and I have taken to watching a lot of Jimmy Fallon lately. (We love to laugh and Jimmy is great, especially when replayed on the DVR at 8:30 pm. ) Not too long ago, Jimmy had someone on his show with a plastic 3-D printer. These have been around for years, but now they are affordable outside of big scale R&D organizations.

How cool is that?

For a few thousand dollars and some extra garage space, I could print out plastic prototypes of physical objects.

Why would I bother? If I was designing a physical product, I could actually hold that product in my hands before investing in producing the real thing.

Have you ever held a pen that didn’t feel right in your hand while scribbling down meeting notes?

Did you wish someone had done some better prototyping for people like you before producing that pen?

That’s the power of prototyping.

And prototyping is a relevant technique when creating IT systems too. Except it’s not about printing plastic. But it’s still called a prototype. Well, sometimes. Other people call it user interface mock-ups. You’ll also see them called wireframes.

Each of these terms has their own formal and closer-to-”right” definitions and we’ll get to those below. But the reality is that the terms can almost be used interchangeably. What’s more, depending on who you are talking to they can mean very different things (or the same exact things). This means that when any one of these terms are used in a job posting, it’s best to clarify what exactly is meant. (And especially to do so before saying, “I’m not qualified to do that!” because you may very, very well be qualified.

Let’s look at the collection of activities that might be considered relevant to anyone using prototype, wireframe, mock-ups, visual renderings, or any other variation on these terms.

In short, any of these visual renderings is a representation of a graphical user interface (GUI), or any interface that allows a user to interact with a device using images and clicks rather text commands.

• This web page and any other you might browse is a GUI and so are the apps you download to your iPhone.
• The TV programming screen where we select the recorded Jimmy Fallon episode with the highest potential to make us laugh is a GUI.
• If your organization has a proprietary software system, whether it’s web based or deployed on employees’ desktops, it probably has a GUI.

As a quick aside, I once worked for a company that called their internal system simply the “GUI”. As they replaced a phone based information management system, their consultants told them they were building a GUI and the application never got a more specific name. GUIs are everywhere. But I digress.

Let’s get back to the visual representation of the GUI, because that’s the part you might work on as a business analyst. The representation can include one or more screens or pages, show the navigational elements on each page, and sometimes show the navigation between pages.

We cover this in more detail in Use Cases and Wireframes.

For example, here’s a visual rendering I created for the next version of Bridging the Gap. (By the way, we’re launching a new website soon – target date is the end of May.)

(This type of rendering is closest to what would typically be called a mock-up, because it’s low fidelity. It was created with a tool called Balsamiq which is available for less than $100. The tool is much more powerful than what you see here. If I had invested more time, I could have made this look a heck of a lot better. But I tend to take shortcuts when wireframing so that I don’t get bogged down in the process.)

And here’s an example of what my super-amazing web designer, Blue Steele Solutions, did to turn this conceptual rendering into a more exact rendering. Starting to look a bit more beautiful, eh?

(This type of rendering is close to what would typically be called a wireframe, because it is showing the exact intended look or what’s called high fidelity. And because my designer chose to create this rendering in a web framework, it is actually more like what would most commonly be called a prototype, because I could click around and get the experience of the new website, just like I could hold a plastic pen in my hand and pretend to write.)

So let’s talk about prototypes for a minute.  Shall we?

In general, like the WordPress prototype my designer created for Bridging the Gap, a prototype is functional in nature. And that means your user can actually click things and have something reasonable pop up as a result, which helps them provide a great amount of feedback in the elicitation process. (I’m expecting that any day now my designer will stop being so gracious about my feedback and adjustments!)

Without any coding knowledge, I’ve created similar, albeit less visually pleasing prototypes (again, I love those shortcuts), using a tool called Axure.

Here’s an example of a a pretty ugly prototype that ended up being the current (soon to be old) home page here at Bridging the Gap. (This is a screen shot from a click-through prototype created in Axure – those yellow icons indicate clickable buttons.)

You’ve Probably Done This, Right?

If you’ve ever created anything along the lines of what you see above – or significantly less beautiful (such as a hand-drawing or whiteboard drawing) or significantly more beautiful (such as a wireframe created in Photoshop) or significantly more functional (such as working code that was intended for a demonstration), you have relevant experience in this area of business analysis.

At the end of the day, it’s not about the technology you used. What “counts” as relevant experience is the putting something visual and tentative in front of people who will actually use the finished product and getting their feedback.

Essentially, you allow your users to hold a plastic pen. Now I’m going to head back to watching the next promising Jimmy Fallon episode. Ah! There’s a 30-second commercial. Here’s mine:

Learn More About Creating Wireframes (and Use Cases Too)

Looking to incorporate wireframes on your next project? Want to learn how to blend wireframes with use cases to create a package of requirements that helps everything gel? Then join us for Use Cases and Wireframes - a virtual self-study course where I walk you through my simplified process for creating a use case and associated wireframes, ensuring that the wireframes themselves are at the right level of fidelity and add real value to your project.

Click here to learn more about Use Cases and Wireframes

As someone with a business background, do you find that many business analyst jobs involve some interaction with the IT team or IT systems? Are you wondering how you’ll fulfill those responsibilities if you don’t have much (or any) technology knowledge?

As a technical professional, would you be interested in learning a technique for sharing exactly what the technology can do for the organization? Have you been asked to talk about the technology using less “tech speak” but aren’t quite sure what that means?

In what follows, I describe use cases – a commonly used business analysis technique that captures requirements for a software application. If you have an analytic mindset, you’ll be able to write use cases even if you don’t understand or want to use the technical jargon.

What Are Use Cases?

Use cases are a type of textual requirements specification that capture how a user will interact with a solution to achieve a specific goal. They describe the step by step process a user goes through to complete that goal using a software system.

Use cases capture all the possible ways the user and system can interact that result in the user achieving the goal. They also capture all the things that can go wrong along the way that prevent the user from achieving the goal.

For example, one use case I’ve created for just about every project captures the user logging into a software system. You could also have use cases for Manage Account, Create Order, or (why not?) Read Content on Bridging the Gap. Think of any piece of software you use, via the web or installed on your computer, television, or smart phone. There is a use case and probably many use cases written or waiting to be written to describe the system’s functionality.

How Do You Write a Use Case?

Use cases contain the following elements:

• Name – A clear verb/noun or actor/verb/noun descriptor that communicates the scope of the use case.
• Brief Description – A brief paragraph of text describing the scope of the use case.
• Actors – A list of the types of users who can engage in the activities described in the use case. Actor names should not correspond to job titles.
• Preconditions – Anything the solution can assume to be true when the use case begins.
• Basic Flow – The set of steps the actors take to accomplish the goal of the use case. A clear description of what the system does in response to each user action.
• Alternate Flows – Capture the less common user/system interactions, such as being on a new computer and answering a security question.
• Exception Flows – The things that can happen that prevent the user from achieving their goal, such as providing an incorrect username and password.
• Post Conditions – Anything that must be true when the use case is complete.

We cover each section of a use case in more detail and provide several work samples in our Use Cases and Wireframes virtual course.

Use Cases Capture What the Software Does

In the vast majority of contexts, use cases should be used to capture what the software does, not how the software does it. Another way of saying this is that they are implementable – meaning a software developer clearly knows what needs to be built – without specifying the implementation details such as what coding language to use, how to connect various technical components, or what database fields to add.

One of the most common problems I see when reviewing use cases from our course participants is that the use cases either contain too much detail or not enough.

• Use cases that do not include enough detail tend to be more like business processes. They capture what the business user needs to do, but not what the software needs to do to support the business user.
• Use cases that include too much technical detail tend to be more like system design documentation. They read like pseudo code and sometimes lose the context of the user actions.  (To be fair, the use case structure can be used to capture technical design details and technology systems can be “actors”. But out of the few hundred use cases I’ve written in my BA career, I’ve only used them to capture the detailed technical design 2 times that I can explicitly remember. It can be done, but it’s not common for a business analyst to do it.)

Use Cases Are Primarily Textual

One of the more common misconceptions among participants is that use cases must include complex visual diagrams, such as UML activity diagrams or actor-use case diagrams.

You can certainly add visuals to your use cases – I often find that simple workflow diagrams and user interface wireframes nicely complement the content of a use case and make them even easier for stakeholders to understand and provide feedback on.

But in essence, use cases are textual models that capture the requirements in context. That’s why the use case templates we include as part of our BA Template Toolkit (they are also included with our Use Cases and Wireframes virtual course) are in Word and Excel.

Use Cases Help You to Get to the Right Details

As a business user, if you can write a use case that describes what a piece of software does or needs to do, you’ll know enough about the “technology” to talk to technologists about software systems. You’ll also go down a path of asking and answering many important questions about the requirements.

As a technical professional, if you can do the same, you’ll learn how to talk about technology without using the technical jargon that is not relevant to the business community.

Interested in Learning More?

Click here to read about my love affair with use cases

(I’ve been using them since my very early days as a business analyst and have a lot of personal stories to share. And that’s a big part of the reason I decided to capture my approach in our Use Cases and Wireframes virtual course.)

A few months ago one of my favourite bands, The Scissor Sisters, were playing in my home town here in the UK.  I bought some tickets as soon as they were released, and I wasn’t disappointed – they put on an excellent show.

During the show, just before they sang one of their most popular songs, they thanked their crew and the “roadies” that help keep them sane throughout the tour.  As they were introducing their song  “I don’t feel like dancing”, Jake (the lead singer) explained that when they are on tour, visiting countless venues in different countries, sometimes they just don’t feel like dancing. They love their music, they love what they do, yet some days they just don’t feel like performing.  It’s those around them that give them the energy to continue.  This support allows them to get psyched up and put on an outstanding show every night.

I wouldn’t for one moment compare the art of Business Analysis to the art of surviving a world tour… however, sometimes it does feel like there’s an element of performance in our work.  There are times when we need to be “on stage” facilitating a workshop, playing back a requirements document or meeting stakeholders for the first time.  All of this requires an element of extraversion and an element of energy.  To do it well, it’s necessary to build rapport and build relationships.  Yet it has to be said that not all analysts are natural extraverts (I know I’m certainly not).

This leads to a challenge.  Sometimes you might be on your way to work on a Monday morning knowing you have a couple of stakeholder interviews booked, followed by a workshop that you’ll be facilitating, followed by a week of stakeholder interactions.  If it’s raining, you’re tired and you just aren’t in extravert mode (or, as the Scissor Sisters might say, you “don’t feel like dancing”) what can you do?

Here are some tips that work for me:

• Allow preparation time immediately before:  There is nothing worse than getting straight out of your car and running to a workshop or stakeholder meeting and arriving out of breath.  Yes, there are times when this will be necessary, but it’s best to allow some time before so that you can “get in the zone”.  This allows time for you to re-cap what the meeting objectives are, and iron out any last minute logistics.   Plus, it’ll give you time to find your mojo!

• Remember: Introversion isn’t shyness,  but you may need to plan in some “down time”:  I remember having a Myers Briggs four-letter code thrown on me during a “management training course” several years ago.  All of a sudden I was branded an introvert – this was a shock to the system!  The world, in my view, misunderstands this phrase – there’s often the assumption that introverts are shy, quiet people.  I’m certainly neither shy or quiet (as anyone who has met me will attest).  However, I personally find it takes me more energy to meet new people than some of my extravert friends.  Therefore, if you’d consider yourself an introvert, it may be worth planning some “down-time” into your schedule.  For me, this doesn’t need to be anything more than a 15 minute break where I can sit quietly, write up my notes and compose my thoughts.  It helps me to mentally recharge.

• Phone a friend:  One of the greatest way to solve problems or change mood is to speak to someone else.  It’s well worth building a support network of people who know you well.  If you’re feeling in a funk one morning before a workshop, a friendly colleague may be able to help you “get in the zone”.

• Start with energy:  In workshops and meetings, often the amount of energy that the attendees throw back is directly proportional to the amount of energy you put in as a facilitator or leader.  So it’s worth starting big – that way the attendees will respond with increased energy, which is likely to quickly get you in the mood for “dancing”, metaphorically speaking!

• And if all else fails…. Perhaps try a coffee or donut!

I hope you’ve found this article useful, and that you’ll think about these tips on those gloomy mornings when you just can’t find your mojo.   Good luck!

We put a lot of burden on ourselves as business analysts to get as much information as possible as early as possible in the process. The questions we think to ask are critical to getting the right information. But every once in awhile, we find ourselves needing to ask a question and not having one ready-at-hand. Other times, we sense we’re missing something, but are not sure what it is.

What if there were a handy list of questions we could ask in almost any requirements-related conversation to get more relevant information from our stakeholders?

That’s the topic of today’s article. You can think of this list as the questions to ask when you don’t have any specific questions to ask but know you should be asking questions.  (And you should almost always be asking questions.)

Questions to Ask At The Start of a New BA Assignment

What’s Been Done to Solve This Already?

Often we assume (or like to assume) that we’re brought in at the beginning of  a project. But very often, that’s simply not the case and this false assumption leads to us irritating our stakeholders by rehashing what they feel is a finished discussion. And even if we’re at the beginning of the project, it’s likely our stakeholders have at least thought about the problem and have some pre-conceived ideas about the solution.

Use this question to figure out the current status of the project and, more importantly, get into your stakeholders’ current mindsets about the project. Simply asking the question also starts the trust-building process because you are indirectly communicating you are not going to bull-doze your way through the project.

What Do You Need (Most) From Me?

We can bring a lot of expectations to our roles – templates we think need filling out, specifications we’d like to create, and models we’d like to draw. But sometimes what our stakeholders need is different from what we want to provide them. And sometimes what they think they need and what they really need are very different.

The answer to this question gets you information about what they think they need so you can either start fulfilling their expectations directly or starting the process of resetting their expectations about what you’ll be doing as the business analyst.

As You Are Getting Into the Details

Can You Give Me an Example?

If you sense you are not getting the whole story, ask this question. Asking for an example or many examples to represent different requirements can help expand the conversation and ensure your requirements cover all the scenarios.

What Problem Are We Trying to Solve?

This question often must be asked multiple times to get to the real answer and it also must be asked with finesse so that it doesn’t generate conflict. Click here to find 10 ways to discover what the problem really is.

In my experience, most conflict and significant stakeholder project disagreements result from either a difference in business goals (which you’ll discover by getting to the root of the problem) or a terminology misunderstanding. And that’s the topic of our next question.

What Does That Mean?

Resolving misunderstandings in terminology is an area where a business analyst can demonstrate strong leadership skills. This question often leads  a discussion where stakeholders share their different definitions, begin clarifying each others definitions, and offering up examples of negative cases to clarify the definition.  This type of discussion often leads to at least a few “aha” moments – for you and everyone else.

Ask questions about acronyms, confusing terms, and organization-specific phrases. And don’t overlook the obvious and generic terms like customer, order, or issue as often they have the most false assumptions surrounding their meaning. Since these terms seem so obvious, often no one has bothered to ask what they mean in a long, long time.

As You Are Closing a Discussion

Is There Anything We Didn’t Discuss?

Use this question and variations of it whenever you can – between agenda items, at the end of a meeting, and before finalizing a requirements specification. Once your stakeholders get into the habit of you asking them for their questions, they’ll get better at filling in gaps and providing more relevant information.

Is There Any Reason We Can’t Move Forward?

While the previous set of questions are more open-ended in nature, this question creates a sense of urgency that gets your stakeholders to commit to the next step. Used at the end of the meeting or when finalizing a deliverable, this question ensures that sign-off really means sign-off.

Get More Information From Your Stakeholders

Essential Elicitation Skills is a virtual, instructor-led course that provides templates, work samples, instruction, and individual feedback on your elicitation plans and meeting agendas. You’ll learn what questions to ask and how to ask a bunch of relevant questions without irritating your stakeholders. (And you’ll earn 7 PDs or CDUs too.)

Click here to learn more about Essential Elicitation Skills