I had a template, a big one in fact. It had 20, maybe even 30 sections in it. And my discipline led me to believe that putting something in each and every one of those sections was the best way to be effective as a business analyst.

After all, someone wouldn’t have added it to the template if it wasn’t important, right?

So, what could go in this particular section?

If I didn’t have an idea, I’d ask the project team. After all, that’s what I’d seen the other BAs do when I was sitting in on their requirements meetings.

So I’d ask. And wait. And think. And struggle a bit.

And by now we are all feeling a bit squeamish and uncomfortable. That hot-head architect is just dying to take a pot shot at me and start a discussion about the template itself and completely derail my meeting. I can feel it coming.

“Oh! What about this?” says the product manager.

{collective sigh of relief}

Yes, that works, a few people nod.

I write a note.

We move on.

Of course, I know that we’ve already captured “this” in another section and I’m crossing my fingers under the conference room table that the uber-smart architect doesn’t call me out on it. But since it also fits here, I can decide how to handle the duplication when I get back to my desk. For now, I’m quickly moving on to a more interesting part of this particular requirements review meeting before anyone else notices.

{fast forward a few years}

I switch organizations and am responsible for starting a new BA practice-of-1. One day while working on a draft of my requirements specification, I realize that I own this. No one at this organization has ever seen this template. No one. They won’t know if I just remove a section or two or three or (yikes!) four and let it die a slow and painful death on my PC.

I think about the pros and cons of this decision.

• I realize that I’ve been letting the templates be my master instead of mastering them.
• I realize that as safe as it feels to fill in every section of a trusted template, it’s not safe at all, especially if no one is reading the thing.
• I realize that I can choose a better way.

My business analysis life starts afresh. I will do better. I will write better. I will serve better. Over the course of the next several years, a transformation happens.

• Instead of thinking big, I start to think small.
• Instead of thinking fill in the blank, I think about decisions and next steps.
• Instead of thinking about an abstract sense of completeness, I think about usefulness.

It all starts with losing my dependence on the long, laborious templates that felt very, very safe. Somewhere along the way I shed my greenness and while I keep my discipline, I apply it using a different set of principles. Somewhere along the way, my requirements start to get just a little bit spunky.

From time to time, I still look back.

I wish that way back when I had the license to cut up my templates so that my documentation would have been shorter and relevant and my meetings less painful.

I wish that way back when I had a more concise starting point so that my documentation would naturally be more readable.

I wish that way back when I was told to add if needed instead of play a game of fill-in-the-very-large-set-of-blanks.

I can’t get back the hours I wasted and the spunk I sucked out of those early requirements documents (and their meetings). But I can give you a simpler starting point.

And that’s exactly what I’ve done with the Business Analyst Template Toolkit. The templates are short and you are welcome to add or subtract. And version 2 (which is due out later this week) includes work samples so you can see exactly how the template works and what it helps you accomplish in your requirements documentation. And a brand new guidebook walks you through my approach so you can use it as a starting point for your next project.

I wish I had a lighter starting point way back when, so I wouldn’t have had to learn how to streamline my documentation in a much more painful way. And that’s why I’ve annotated my templates and am sharing them with the business analyst community.

>>Learn More About Templates and Requirements

Click on one of the links below to learn more about how we approach templates and requirements:

• I’m Letting Go of the Big Thick Requirements Document, Are You?
• How to Present Yourself as Capable of Doing Requirements Specifications (Even If You’ve Only Created Informal Documentation)
• Requirements Templates: What To Do When You Must Start From Scratch

When watching coverage of the festival on the news, it occurred to me that every film is essentially a project.  It has funding; there is a timeline, an end-deliverable and a whole range of constraints.  My mind wandered – “I wonder if they have business analysts in the film industry – or if they recognise the art and science of business analysis?”  Well, I’ve certainly never seen the title “business analyst” appear on the credits of a film, but there certainly seem to be similarities.  This probably sounds a little abstract, so let me explain one particular example….

You Wouldn’t Build the Set Before Knowing the Story Line

Just imagine if an impatient director chose the exact details of the set before the storyline and plot were decided.  Perhaps the director chooses to buy a Boeing 747 (as he’s heard they appear in a number of recent successful films) and decides to build a life-size replica of London Heathrow Terminal 5. Well, that would be no use if the film ends up being a period drama set in the 1900s!  You’d end up with massive waste and a solution that just doesn’t meet the actual needs of the movie.

Let’s transport ourselves back to the corporate world.  Unfortunately, a similar pattern does happen in organizations that run projects – and perhaps you’ve experienced it too.  Quite naturally, our sponsors and business experts think in terms of solution, so often they’ll choose a technology and then implement an “IT Project” to implement it.  Perhaps they might not even think they need requirements – after all, the vendor promised them “It’ll work right out of the box…”  However, how do we know that the IT system they are procuring will actually solve the underlying problem or meet the underlying need?

This is where enterprise analysis comes into play.  As business analysts, it’s our job to ensure that robust enterprise analysis is carried out to ensure that we solve the real business need and our organization doesn’t end up buying a 747 when what they actually need is a horse and cart!  We need to ensure that we do what we can to maximise the business and customer value that are delivered on projects.  Not only this, but we need to consider business change from the aspect of process, organization, people and IT.  I strongly believe there is no such thing as an IT project – just projects that involve or impact IT, all of which are likely to be more successful and deliver more value if they are managed more holistically.

Of course, we don’t need to know the full requirements before considering potential solutions; we might make recommendations after having a high level understanding.  Just in the same way that a set designer might take a calculated risk and start designing the set after the storyline and plot are decided, but before the detailed script is finalised.  We’ll help our business stakeholders understand the problem or opportunity they are facing, and the possible solution option(s) that might be available.  We can also help them assess the feasibility of each option and make a recommendation.

Being a BA is Often About Asking the Hard Questions

Having these discussions is tough.  It’s always easier to simply nod subserviently rather than question – but this ultimately helps no-one.  We can add so much value by sensitively challenging our colleagues, with rapport, to ensure that our organizations’ projects run smoothly and deliver the maximum amount of value.  By being transparent, honest, and encouraging our business stakeholders to review the cold-hard-facts, we can help them to make an informed decision.  The ultimate decision is, of course, theirs – but we can help them to make it.

Good luck! I hope you’ve found this article interesting.  Please feel free to contact me if you’ve had similar experiences or would like to discuss the blog post further.

Well, you’ll find plenty of answers out there about the one “right” way to do business analysis, but that’s never been the message here at Bridging the Gap. Here we know and believe that there are many right ways to do business analysis and what’s right for one project, one stakeholder group, and one organization may be completely wrong for another.

That being said, this doesn’t give you much to go on if you are a new business analyst on your first project or an aspiring business analyst beginning to look at what you’ve done using the filter of business analysis.

So how exactly does a business analyst approach a software project?

When thinking of my approach to a project, I like to break my work up into three phases. There’s nothing 100% right about these phases vs. the phases you might see elsewhere. I just find them to be very useful buckets in which to think about business analysis.

Here they are:

• Initiate the project,
• Elaborate the details, and
• Support the implementation.

Let’s look at each of these in a bit more detail.

Initiate the Software Project

Initiating the project involves identifying the problem to be solved and establishing enough about what the solution looks like that a definitive go/no-go decision can be made about whether to fund the project.

This is the time that we bring together the stakeholders and kick off the project and ensure that we have all the information that we need to make an informed decision about the project direction. If you are working in a new business domain this phase would include understanding the key terminology, which is often captured in a glossary or domain model, as well as the organization’s current capabilities.

The deliverable from this phase of work is often a Scope Document (or vision document or business requirements document). And a Requirements Development Plan can prove very useful as well. And if the current business process is unknown, you might do some business process analysis as part of initiating the project too.

In my early days as a business analyst, this phase included a 50+-page functional requirements document. Over time, I realized that there was so much redundancy between the functional requirements document and a body of use cases that formed implementable functional requirements (we’re getting to that next), that I cut this document back significantly and save loads of time. I essentially replaced the list of detailed functional requirements with a high-level list of features (that’s what you’ll find in our Business Analyst Template Toolkit) and have never looked back.

Once you’ve got the go-ahead to move forward with the project, it’s time to elaborate the details. Let’s talk about this next.

Elaborate the Details of the Software Project

Elaborating the details is really the meat of the business analyst role, and it’s probably the piece that you think of most when you think about business analysis.  This is where we get into analyzing the requirements and ensure the implementation team has all of the details they need to build or implement the solution. Often this phase involves working with multiple stakeholders across the organization to ensure their knowledge and needs are incorporated into the detailed decisions about what will actually get built.

In a more traditional or waterfall environment, this phase is combined with initiating the project and that means the decision of whether or not to fund the project may not be made until all of the functional requirements are detailed out. In my experience, that tends to be a bit late in the game, after a lot of stakeholder time and trust is absorbed into the project by then, not to imagine weeks or months of analysis time. More often than not, the cost estimates you can get from a high-level features list are more than adequate to support high-level scoping.

This is part of the reason I stopped doing functional specifications up front, streamlined my scope document template, and replaced the functional specification with a set of use cases and wireframes. (On an agile project, I’ll replace the use case list with a product backlog and the set of use cases with user stories.) Depending on the project, you may need a data specification or model as well.

Regardless of how you choose to specify it, this phase is complete when your stakeholders have signed off on what will be implemented and your developers have what they need to design and implement the software solution. In many organizations today, this part of the project is approached in an iterative fashion. That means that the BA prepares the functional specifications in phases, which are approved by the business and then designed and implemented by the software development team. Use cases and user stories are much more naturally suited to this iterative approach than a single functional specification.

As a certain set of requirements is ready for development to start, the business analyst role typically shifts from an active one to a reactive one.

Support the Implementation of the Software Project

Supporting implementation is when BAs are involved through the end of the life cycle.  BAs are not typically involved directly in implementation unless they’re holding additional roles on the project.  But they are typically brought in if issues come up during implementation that cause some new requirements to be addressed. This could involve facilitating a problem-solving meeting to discover how a particular business need can be met given newly discovered technology constraints.

For example, when redesigning this very website, we had made an assumption about how the author profiles would work. Then we discovered that WordPress no longer supported the functionality we needed. We revisited the author profile page and came up with a simple and elegant solution.

As the implementation is completed, sometimes business analysts do have a more active role. You might be asked to help the business accept the solution that’s being implemented. This can take the form of “to be” business process models that analyze how the business stakeholders will use the new solution to complete specific tasks and activities. It can also include training, user documentation, or user acceptance testing.

It’s becoming increasingly common for the business analyst to continue to be involved in the project through this stage, and this phase is complete when the software is released to a production environment and the business stakeholders are able to use it successfully to do their jobs.

Of course, during the process of implementing the solution, new needs and requirements may be discovered, and the business analyst might pick up new projects to initiate…and the cycle continues.

Interested in Learning More?

Click here to read about the Requirements Specifications a Business Analyst Creates

Even though I have a bit of a love affair with use cases, they are not always the most appropriate choice for every project. However, there can be misconceptions about exactly when and how you can write use cases for a project, so today we’ll look at when they can make a very good selection choice.

A use case is a type of textual requirements specification that captures how a user will interact with a solution, specifically a software solution, to achieve a specific goal. They are a very common way to create “developer ready” specifications in a format with enough context that business stakeholders can provide meaningful feedback too.

Here’s an overview of what a use case is and we cover this in a lot more depth in our Use Cases and Wireframes virtual course.

With the above definition in mind, it stands to reason that use cases will be appropriate if your project involves some sort of technical or software component.

There are three primary types of software projects in which use cases would be an appropriate technique to use.

To Document Existing Functionality

Have you ever worked with a complex system that no one seemed to completely understand? Or perhaps different people throughout the organization had bits and pieces of relevant knowledge, but no one understood the entire workflow from beginning to end?

In these situations, I’ve found a use case to be an excellent technique for capturing exactly what the system does today. Often any documentation that does exist is technical in nature – meaning it might cover the technical design and how the system is built, but not what it actually does. Use cases are a good choice to elevate the understanding of how and what a human being does to use that system to accomplish something that’s relevant to your organization.

And because you eventually might replace that brittle legacy system, the use cases you create could have a decent shelf life and actually help kickstart the scoping process of the new system. Let’s talk about that scenario next.

To Document Functionality for New Systems

Many business analyst roles involve working on new systems or “IT projects”. For these projects, you’ll often start with a list of business requirements, some of which are allocated to the system or software that’s in scope for the IT aspect of the project.

The IT aspect of the project – or the functional requirements – can then be specified in a collection of use cases. Each feature or user goal of the system would have a use case written for it. In these types of projects, use cases have the benefit of capturing core functionality of the system without creating a lot of dependency on the user interface design, which may still be tentative.

(You could also capture these requirements in a collection of user stories or in a software requirements specification. Your choice here is going to largely depend on your project approach and stakeholder needs. I tend to prefer use cases because they capture the functional requirements in context and the format itself helps ensure good analysis.)

For example, when redesigning this website, I could have written a use case for the functionality covering “Join the Email List”. Since the functionality is the same whether you decide to join from the side bar, the home page, the bottom of this post or the page with information on what you receive when you join, by capturing the functionality in a use case, my requirements would not be dependent on the website design. I could make adjustments to the layout of the pages without needing to update the use case. And when you are dealing with big, complex systems, that’s a very nice feature.

(And if you haven’t joined our email list yet, look in any one of those four places – you’ll find an option to put your email address in a box and start receiving more good content from us.)

But with the prevalence of off-the-shelf software today, there are fewer and fewer “green field” projects. Most projects involve enhancements to existing systems or purchased or licensed systems. Use cases can still be relevant in these contexts, so let’s talk about that next.

To Document Enhancements to Existing Functionality

Whether you have an existing system that is built and maintained in-house or you are licensing a third-party system and customizing it to fit your needs, you can write use cases to show enhancements to functionality that already exists.

In some cases, you’ll write an entirely new use case to cover a new feature. There’s not much difference in this scenario from writing a use case for a new system.

In many cases, you’ll capture the current functionality in a first draft of the use case and then identify the changes to that functionality. I like to use color coding to call out the changes. Perhaps gray for what’s being removed, green for what’s being added, and yellow for what’s being changed.

In the case of customizing licensed or off-the-shelf software, you could document the current functionality of the software in a use case format and then color code in any configuration options, workflow variations, or enhancements you need made to the standard system. This would be particularly useful for your stakeholders if they don’t have a good understanding of the current system – your use cases would serve the purpose of both training material and configuration requirements. (In other cases, it would be perfectly appropriate to create a specification that only includes the configurations and work flow variations.)

Still other projects link multiple pieces of software together. The “Join the Email List” functionality is a good example of this. The functionality is enabled through a combination of the WordPress content management system, the MailChimp email software, and a bit of custom code. The use case describes how this collection of systems respond to specific user actions, such as you putting your email address in the box.

So There You Have It

So there you have it – three project scenarios when it’s appropriate to apply use cases – to document current functionality, functionality for new systems, or enhancements to existing systems. And those three scenarios cover most IT projects.

Imagine that! Maybe my love affair is justified after all.

Learn How to Create Use Cases (and Wireframes Too)

Interested in learning more about how to write use cases? Join us for Use Cases and Wireframes – a virtual instructor-led course where I walk you through my process for creating a use case and associated wireframes. The virtual course provides on-demand instruction, live webinar sessions, and an instructor review of your use case deliverable.

Click here to learn more about Use Cases and Wireframes

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.)