A few things I believe…

We all have things we know to be true. Here are a few of mine:

  • The more we each do the work that matters to us, and that lights us up from the inside out, the better place the world becomes.
  • Change and growth is part of business and it is part of life.
  • To expand in the future, we need to let go in the now.

One of my special unique abilities is helping people feel more confident in their skills and abilities. And over this year, I’ve come to realize that the absolute best way I can do this is by providing skill-based training, the kind we’re offering through The Business Analyst Blueprint and through the separate components that make up The Blueprint.

Once upon a time, I created a set of 3 courses from a different place and based on a different skill set. As a hiring manager, I built a 15-person team and conducted close to 100 interviews and resume reviews. I’ve also been on the interviewee side of the fence several times, as a consultant, contractor, and full-time employee.

The take-aways from all of that experience got bundled into these 3 courses:

We’ve since bundled these 3 courses together as part of the BA Job Search Pack, where you can save $84 over your individual purchases. This was good work. It was in my zone of excellence at the time and I’m proud of these courses and they’ve already helped more than 1000 professionals be more confident and strategic about their job searches.

But I’m realizing that this is no longer my work to do. To expand in the future, and make room for my best and brightest work and my biggest contribution to the business analyst community, I have to let go in the now. So these courses will be retired.

However, it didn’t feel right to pull the product from our virtual shelves without giving you one last chance to join the program. This email is your one week notice.

All 3 courses and the 3-course pack will continue to be available through next Thursday, December 7. Then they are gone. Like forever gone.

>> Click here to check out the BA Job Search Pack <<

As always, I wish you the absolute best success as a business analyst. I trust you are also doing your best and highest work. And I’d also encourage you to consider what you need to let go of as we close out the year. What is it time to leave behind so you can do YOUR best and brightest work? Leave a comment below.


The 3 Hygiene factors of the Agile Business Analysis

the-3-hygiene-factors-of-the-agile-business-analysisWritten by: Adam Davies

In this article we are going to be hearing from Fred Herzberg, the Wachowski siblings, that other BOK from the Business Architecture Guild, and Ann Landers in an endeavor to identify the prerequisites of agile business analysis.

3 Diagrams to Add to Your Business Requirements Document

Do you create a traditional Business Requirements Document to capture your business and/or functional requirements? Adding a few diagrams to your BRD can make it more impactful and easier to understand.

In this video, I demo 3 different diagrams that can easily be added to your BRD. And while a full-text transcript is available, you’ll want to check the video for an insider peek into our 3 examples from the Visual Model Sample Pack.

For those who like to read instead of watch, here’s the full text of the video:

Today, we’re here to talk about three diagrams that you can add to your business requirements document because BRDs can be long and difficult to understand.

Business Requirements Documents Can Be Text Heavy

While I personally no longer create BRDs, and our template toolkit does not include a BRD template, instead, we have a three-page statement, and then models for business process documents and use cases that are separate.

I know many of you do and you had a question about how your organization, or if your organization requires you to use a BRD template, how can you make it more user-friendly by adding some visual models to it?

Today, we’re going to demo a couple of diagrams. These are from our Visual Model Sample Pack. You can easily add to a BRD to make it more clear.

Add a System Context Diagram to a Business Requirements Document

The first one of these diagrams is called a system context diagram. This shows the central system under design and the primary ways information flows into and out of the system.

You see, here, we have a portal, and then we have the accounting system, internal system, email server, document management system. These are all showing how information goes back and forth between the central portal, which was the system under design, and then the other related systems. This is useful in the BRD because it can help you to show the big picture of the system and how it fits together with everything else in your organization.

It’s included in our three-page scope statement template that we offer at Bridging the Gap, and it’s included in a lot of different diagrams. It’s common diagram for business analysts to use because it brings a lot of clarity very quickly.

Add a Business Process Diagram to a Business Requirements Document

The second model you might look to create, and this one you might be familiar with, is called a workflow diagram, or a business process flow diagram, or business process model. While you can create them at a low level of detail, this one is relatively detailed and dialed into a specific business process. You can also create them at a very high level to show the big picture of how the process related to the requirements in your BRD.

You can have a big picture high-level map in your BRD, and then, maybe, some supporting ones. If your BRD is comprehensive and includes all the requirements, you might include a workflow diagram for each key section of requirements that, essentially, is showing how those requirements fit together.

If you’re a higher level, then you could just have one that shows the big picture, and you can drill into those more detailed requirements than a business process model.

Add a Scope Model to a Business Requirements Document

The third thing that I would include is called a scope diagram, or any sort of diagram that shows, functionally, how you decompose or organize, the requirements.

The technique from A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide is called functional decomposition. You might have more of a hierarchy than we have here, so, you could also show this as more of an organizational chart view where, maybe, job seekers have key functionality. You want to show the hierarchy between job seekers and applications, and resumes, and search. Things like that; employers, and reviewing applications, and what all the key functions employers do.

You could break this down in a hierarchy. Here, we were just showing the really big picture of what are the key features in the product platform. What are the key areas that we’re looking at and how do they…we weren’t even showing how they, really, together, we could, but we just chose to be abstract to get the big picture.

What’s inside the product platform, and what’s outside? There was a system context diagram field to this as well, even though it’s not modeled as system context diagram.

This, I would use to organize each area of my requirements. If I had a section on requirements for employers, and then a section on requirements for partners, this would be that visual model that shows the big picture, how is this document organized? How are the requirements in this document organized?

You want to look for a way to functionally organize your document and show how the business requirements or functional requirements fit within that and decompose the overall structure of your documentation.

Check Out the Visual Model Sample Pack for 22 Visual Models

These are swipe files. What you’re seeing here is the PDF. In our Visual Model Sample Pack, we have swipe files in the native format of each of the models. We have 22 different models covered. I’ve just been focusing on the visual here because it tends to be the most interesting. But inside that pack, you also get an overview of the model, a link to the BABOK® Guide, and why I created the model. All of these were created in my real-world work as a business analyst.

A description of the different elements of that model, different terminology that can be used, and how this fits in with business analysis techniques and terminology, when you would use it, and the step-by-step guide on how to create a similar model, and finally, what to watch out for.

These are common mistakes people make with this model and how that trips them up in their business analysis work.

Again, you can download the Visual Model Sample Pack from our website. It is a paid product. It’s $97. You get 22 of these PDF documents along with the actual source files that you can use right away to start creating these in your own business analysis work.

To recap, if you’re looking to add to your BRD, the three models I would suggest paying attention to make it more user-friendly are:

  • The system context diagram.
  • The process flow diagram to show either that high level or maybe several of them to show a lower level detail for each area of your business requirements document.
  • Then the scope model, or something that shows, in general, how this document is organized and how are the requirements in this document organized.

Those are going to take you a long way to making a clearer document that’s easier for your stakeholders to understand, easier for you to review with your stakeholders, and get lots of buy-in on that as well.

Again, Laura Brandenburg from Bridging the Gap. Happy modeling.

Click here to learn more about the Visual Model Sample Pack.

A Crucial BA Skill: “Making Space” And Avoiding Mud-Digging

Excavator digging mud
Image Credit: © rpferreira – Fotolia.com #126024037

Now, more than ever, the business world seems like a hectic, fast-moving and sometimes volatile place. Businesses operate within fast-moving environments and the rate of change can be phenomenally high.  Data flows around organisations, and in many organisations decision makers can see more and more data about their business and its environment than ever before.  Emerging technology means that previously unimaginable things become plausible, and societal changes and trends mean that customers expect better and better service.


It is an exciting time to be alive, and as business analysts we are front and centre of this ever-changing world.  I suspect many people reading this article will be working on some type of initiative that is responding to (or pre-empting) an external change—perhaps a competitive force, a regulatory edict, or a change in customer need.


Yet with such a fast-moving environment, we risk being a generation of knee-jerk decision makers. With so much information and data zooming around an organisation, it is easy to perceive a trend—to see urgency—when we are actually looking at a “blip” or outlier.  Or if a trend is emerging, it is easy to make a tacit assumption as to the causation. You can imagine a Sales Manager demanding to know why sales from the website are down 30% in the last few weeks, asking for an urgent analysis of the technology (as she fears the server must have been down). This might lead to a whole “infrastructure refresh” programme and significant levels of investment.  But perhaps the real reason (and the bigger problem) is a new competitor has emerged, or an existing competitor ran a temporary promotion.  Jumping straight to solution—without appropriately and holistically thinking through the problem—can be a recipe for wasted effort.


This is where business analysis is essential.  Of course, I could write about pre-project problem analysis and strategic business analysis techniques—but instead I want to discuss something ‘softer’ that is often overlooked. Namely, our ability as professional change agents to create space.


Making Space and Stopping the Storm

Too often ideas, projects and initiatives take on a momentum of their own. They become “too big to fail” and become tricky and political.  Throughout the innovation and change lifecycle it is important that we make space, press pause (briefly) and cultivate conversations that lead to reflection and reflectivity.   It’s important that we ask the “Why” question not just at the beginning of our work, but also throughout.  An initiative may start to solve a particular problem and achieve a set of objectives—but the environment or the problem may change!


When things get tricky and stakeholders are caught in a political storm they often (understandably) just want the whole thing to stop. They see their only option as ploughing through the mud, even though they may know in their heart of hearts that any victory will be a shallow one.  They may know that the “solution” proposed three years ago that has been delayed, deferred and passed around the internal ‘bureaucracy of busywork’ is no longer valid—but they may figure that it’s too late to change now. Hey, anything is better than nothing, right? Maybe. Maybe not.


It is at times like this that we need to play our joker—be bold—and call out what we see.  We have a duty to serve up the cold hard facts so that decision makers can objectively decide how to proceed. Of course, they may be aware of bigger macro-level factors—perhaps even confidential ones—but by cultivating a conversation and making space for discussion we ensure that the initiative stays on the rails.


It takes guts to press pause. There is often a perception that it will slow things down. Yet, if you are lost, you would probably look at a map. Does it slow you down? Well, perhaps—you stop, unroll the map, and work out your direction, then you accelerate away. The same is true in organisations—too many organisations are lost, spinning around, and are addicted to activity and the illusion of progress. They continue digging through the mud, and revel in stats that show how much mud has been dug.   Confusing activity with achievement is a dangerous doom-loop to engage in, it is very easy to compound the problem and get more lost.


Part of this equation relates to organisational agility. Increasingly it is vital that organisations are architected to allow experimentation and continuous learning.  Yet making space applies at a macro as well as micro level. It applies to the big discussions (“What business are we in, who are our customers?”), as well as the micro decisions (“Are we sure this group of features will actually enable our customers to realise value? How will we test this?”).


As BAs we are trusted advisors, and we have a professional duty to work with our stakeholders to make space and keep things on track. We need to call out the mud-digging.


What are your views on the topics in this post? Do you have any tips, perspectives or anything to add?  I’d love to hear your thoughts.   Please add a comment below, and let’s keep the conversation flowing! 

If you’ve enjoyed this article don’t forget to subscribe.

Subscribe to Adrian Reed's Business Analysis Blog

About the author:

Adrian ReedAdrian Reed is Principal Consultant at Blackmetric Business Solutions, an organisation that offers Business Analysis consulting and training solutions. Adrian is a keen advocate of the analysis profession, and is constantly looking for ways of promoting the value that good analysis can bring.

To find out more about the training and consulting services offered at Blackmetric, please visit www.blackmetric.com

Blackmetric Logo

BDD – An introduction to feature files

The purpose of this article is to explore feature files. Feature files are documents that contain those Gherkin scenarios & requirements – they can be very useful to teams working on BDD projects. Feature files may be a key deliverable for BAs.  Feature files are where BAs store requirements & can create the bridge between requirements and automated tests (more on that later).