Tag: Requirements

Want to Really Understand Business Needs? Sharpen your Root Cause Analysis Skills Part 2

Written by Richard Larson on July 22, 2020. Posted in Articles. 2 Comments on Want to Really Understand Business Needs? Sharpen your Root Cause Analysis Skills Part 2

Part 2: Five Root Cause Techniques to help get to Business Needs

Part 1 of this series explored the notion that business needs represent “a problem or opportunity to be addressed” (BABOK Guide v3 definition from IIBA (International Institute of Business Analysis). It stands to reason that root cause techniques are then uniquely suited to understanding those needs since they are designed to get to the bottom of a problem or opportunity.

In this part I review five of my favorite root cause techniques and suggest the kinds of situations for which they are most appropriate.

Five Techniques

These five techniques are not an exhaustive list, but they are some of my favorite tools I have found helpful over my career to understand and ultimately solve business problems. They all have their purpose and are in the BABOK or PMI BA Standard or both:

Consultative interviewing – essential when using the other techniques, including…
Five-whys – more of a mindset, but often overlooked when we are busy – which is usual!
Fishbone/Mind Map – great brainstorming tools to help structure your root cause analysis.
Pareto diagram – A technique that uses data to help find the primary causes of a problem.
Interrelationship Diagram – excellent tool when there are compounding, interactive, (and possibly even competing) root causes.

1. Consultative Interviewing

As we saw in the first part of this series, it is easy to jump to solutions. I believe we need to understand the problem first and use consultative interviewing to do that and to start uncovering business needs.

Consultative interviewing is a special kind of elicitation that is professional and focused on goals and is respectful and collaborative. When done right, it builds credibility, trust, and ultimately buy-in. The latter point is important if the root cause suggests a different solution than one favored by our sponsors.

Many of us already use this form of questioning or interviewing automatically. We know that it requires good listening skills and genuine curiosity and interest to determine both needs and expectations. Consultative interviewing leads to positives such as informed advice, confident recommendations, and viable alternatives. (Confidence is important if, again, we end up recommending a different solution than the assumed one.)

The Right Questions the Right Way

Increase Buy-In. Consultative Interviewing helps discover together what the client’s needs and wants are, and how our solutions can meet them. Eliciting needs, whether in sales or business analysis, is best done as a collaborative discovery process, and not as an “extraction.”

Avoid leading questions. Consultative questions are designed to broaden the conversation and encourage clients to open up and share their needs and concerns. Otherwise, “leading” questions give the impression the questioner has a hidden agenda and is pushing a certain solution. This also helps build trust.

Examples of leading questions to avoid as you interview consultatively include:

“Don’t you think that ________?”
“Isn’t it better to _________?”
“Have you ever thought about a _________?”

Instead work to use consultative phrases that promote open, thoughtful dialogs such as:

Tell me more about…
Let me see if I understand…
Could you elaborate on…

2. Five WHYs

Remember the Jefferson Memorial story form part 1 of this series? It was an example of 5 whys in action. This is not a technique as much as a mindset. It has been part of business since the 1930’s because it is effective and reminds us we need to go deep enough to get to the real needs.

It is simple and easy to use and can be employed often with little preparation. On its own it can lead us to the root cause of a problem, but we can be led down the wrong path if we ask the wring people or those with hidden agendas. Five “whys” is part of other analysis tools as we will see and works best with a consultative interviewing style to ask “why.”

Five WHYs Example

Here is a favorite (and simple) example of mine to illustrate Five whys. Suppose you faced a problem like this:

We need to fix the potholes on Main Street again. How can we patch the potholes the fastest and cheapest way?

1. Why do they develop again so soon? A: The holes develop every year and they do not go away.

2. Help me understand that. A: Over time the asphalt deteriorates and develops holes.

3. Why does that happen? A: The freezing and thawing of the asphalt wears it out.

4. I thought asphalt lasted forever? A: Asphalt is durable for 10-15 years, then the coating begins to wear out, and it cracks easier.

5. Tell me more…A: The City has not resurfaced Main Street for over 20 years – the cost of repairing potholes in any year is less than resurfacing it.

So, the root cause of this example is a funding or budgetary problem, not deteriorating asphalt.

Advertisement
[widget id=”custom_html-68″]

3. Fishbone Diagram/Mind Map

Once we use consultative interviewing or other tools to understand the problem or situation, we can use other more elaborate techniques that incorporate Five Whys to get to the root cause. These two root cause techniques do just that.

Fishbone diagrams and mind maps are snapshots of what is going on today. Assembling them makes use of Five Whys to help get to the root cause. The resulting diagram often exposes areas where we lack knowledge and/or data. See Figure 1 for the structure and Figure 2 for an example.

The Diagram

Figure 1: Fishbone Diagram Structure

Fishbones start with the “Effect” as many fishbones call the problem. Because of that, it is also commonly called a cause-end-effect diagram or Ishikawa Diagram after the inventor. It usually has 4-8 major sub-causes, which can be “5 why-ed” down into sub and sub-sub-causes.

The major causes on the tips of the “bones” can be any relevant categories, but in practice usually come from a standard group such as People, Policy, Process, Place, Machines, Measurements, and Systems.

For example, say you have a problem of transferring medical records too slowly. Here is how to complete the fishbone:

Start by asking why verifications are so slow (consultatively of course).
Maybe you determine there are 4 main categories – People, Process, Measurements, and Systems. Note them on the diagram as shown on Figure 2.
For each of the main categories, ask how the category, like Process, slows down the transfer of records.
Maybe you get the reason of “inefficient transfer process.” From there ask how does an inefficient transfer process slow down transfers. You might hear “too many manual processes” and “serial, one-at-a-time processes.” Note these too on the diagram in a hierarchical structure like Figure 2 below.
Continue adding additional sub-causes as appropriate.
Move on to each of the major categories you identified and drill down each of them. Tip: For both the mind-map and fishbone, I recommend only going about 3 levels deep, otherwise your diagrams are too detailed and “bony.”

Figure 2: Example Fishbone Diagram

Mind Maps

A mind-map is basically the same as a fishbone, but with a format more like an octopus (bad joke). Start with the problem in the middle, like the head of the octopus. Instead of fishbone ribs, the tentacles are the causes, and they in turn can have sub-causes.

Figure 3 shows the same medical records example done as a mind map.

Figure 3: Example Mind Map

Tip: There is no need to do both a fishbone and a mind map since they both diagrams accomplish the same thing. Use whichever one is more appealing or is a standard at your organization.

4. Pareto Diagram

Pareto diagrams are graphical tools applying the Pareto Principle, which is based on the 80/20 rule. They use data to focus efforts on the factors and causes that offer the greatest potential for improvement.

They display the relative importance of problems in a simple, quickly interpreted, and user-friendly format. They are best used when you face problems that have many symptoms that can be measured.

How to Create a Pareto Diagram

Decide on the problem, such as customer complaints.
Choose the issues or causes. (Five whys can help).
Collect data for the potential causes.
Order data from largest to smallest and draw the bar graphs. See Figure 4 for an example.
Calculate the percentage of the total that each category represents and the cumulative percentage starting with the largest category. Excel makes this fairly easy.
Graph the cumulative percentage line.
Analyze the “vital few” breakpoint when the curve hits 80%. These are the most significant causes – the 20% that cause 80% of the problem.

Figure 4: Example Pareto Diagram

5. Interrelationship Diagram

Fishbones and Mind maps have their limitations, with one big one being they are hierarchical. What if your problem is more complex with some causes also being the symptom of other causes and so on like a chain reaction?

The Interrelationship Diagram helps with that situation. It is an excellent tool that helps when there are compounding (and possibly competing) root causes.

Starts with a situation / problem like “Customer reports are not getting out on time.” See Figure 5.
Add in the potential causes as bubbles, using the most likely ones you found, such as from a Fishbone Diagram or Five Whys. Tip: try to limit the causes to no more than 7 plus or minus 2 to keep the diagram at a high level.
Add “cause lines” by drawing arrows from one bubble to the next according to whether a factor is a cause of another or an effect. (For example, Low Wages cause staff shortages and Scheduling problems. Staff Shortages in turn cause paper to run out, database extract delays, and scheduling issues.)
When done with all causes, add numbers to indicate how many times a factor is being caused by another (“Incoming Causes”) or is the cause of another (“Outgoing Effects”). For example, 3,1 for “Not Enough Paper” means it is a symptom 3 times from other factors and is itself the cause of 1 other factor.
Make determinations of which are the most significant (or “big”) causes. These are the important factors to correct such as “Shortage of Staff.” Working on symptoms like “DB extract delays” will not be as fruitful to solving the problem.

Figure 5: Example Interrelationship Diagram

Summary

Understanding and addressing business needs are arguably the most important factors for any successful project, program, or product. This series covered the importance of needs and five techniques that will help discover the root cause of business problems, which equate to the important factors for learning business needs.

2-part series: Want to Really Understand Business Needs? Sharpen your Root Cause Analysis Skills

Written by Richard Larson on July 14, 2020. Posted in Articles. 6 Comments on 2-part series: Want to Really Understand Business Needs? Sharpen your Root Cause Analysis Skills

Part 1: What are Business Needs and why are they so Important?

What makes a successful project? There are many objective measures (such as on time and on budget) and subjective options (e.g., customer satisfaction) to answer that question. As a generality, I think a project is successful when we apply an appropriate solution to a business problem, one that addresses the underlying cause. In short, we are successful when we address the “business need.”

We all know it is easy to jump to solutions or to fix just the symptoms of a problem. We are all guilty of it and is so common it has a name: “jumping to solutions.” When we do this, we often fail to get to or seemingly even want to get to the root cause of a problem.

As an example, let me paraphrase a classic story of solution jumping vs. getting to the root cause. The Jefferson Memorial in Washington DC had a problem a few years back with large amounts of paint chipping off. It required repainting every six months to a year, far more frequently than it should have needed.

If you know this story, then you know it was not poor-quality paint or shoddy workmanship that caused the need for frequent re-paintings. It was because of bugs! Near dusk when they turned the lights on this beautiful monument, a certain type of bug came out. Not a bug, but hordes of them! With so many bugs, the birds in the area swooped in to eat them and then left bird droppings as a souvenir after their insect feasts. The root cause of the problem was bird dung from bugs that caused frequent power washing to clean it, that then wore away the paint that caused the need for frequent re-painting.

To make a long story short, once the U.S. Interior Department got to the root cause, they found that turning on the lights a little bit later fooled the bugs. Far fewer of them swarmed around which in turn reduced the bird droppings and the solution drastically reduced the power washing and repainting needed.

This series of articles will explore how to understand business needs using five common and proven root cause analysis techniques. By finding root causes we can truly understand business needs and not rely on what our business stakeholders tell us their needs are. It is a repeatable way to provide appropriate, cost-effective, and lasting solutions like they finally did for the Jefferson Memorial. Part 1 will focus on what are business needs.

What are Needs?

So, what are needs? I do not mean psychological needs like in Maslow’s hierarchy. I am also not differentiating between needs vs. wants so that if I say I need a new pair of shoes, I do not literally mean I am currently shoeless. What I essentially mean is “I really want a new pair and I’m willing to pay for them.” And that is what any project or program requires – a sponsor willing and able to pay for something new.

When considering “business needs,” what do sponsors pay for? Too often it is a predefined solution. I am sure many of you have experienced a sponsor bringing you a solution. In that case the project or program’s objective is to implement the predefined solution with business needs either previously explored, assumed, or possibly overlooked.

I frequently hear people tell me they are brought into projects after the solution has been chosen – seemingly too late for any needs assessment or root cause analysis. I often respond: “It is never too late!” You can always help forestall project disasters if you are diligent about wanting to get to root causes and actual business needs.

Advertisement
[widget id=”custom_html-68″]

Business needs have many facets including:

They represent business problems
They represent business limitations
They reduce the chance of “solution jumping”
They lead us to requirements and designs
They justify projects

Why are needs so important?

Figure 1: From Needs to Solutions

Anything a project team creates “should” stem from needs. Needs are at the heart of what we do, and they tie back to business problems or opportunities. They lead us to the requirements and are also the basis for designs, both “logical” or physical designs. Designs are turned into constructed things such as solution components, which in my experience has been software, but could be any constructed deliverable. Finally, all the components add up to one or more solutions.

You may intuitively know this but having a visual helps me to see the relationships and the importance of getting needs right. If we fail to understand needs, we risk delivering solutions that will not address underlying business problems and the resulting solutions will have decreased value and may even be scrapped.

What do IIBA and PMI-have to say about Needs?

The BABOK Guide v3 from IIBA (International Institute of Business Analysis) defines needs as “A problem or opportunity to be addressed.”

Looking further into the BABOK Guide, it literally starts with Needs as the core input when planning the BA approach. It is the very first task in the Guide. I realize the tasks are not intended as sequential items, but the placement is hard to ignore.

Figure 2: Needs in BABOK Guide v3

Needs are also the primary input when eliciting requirements, which leads to virtually every other task in the BABOK Guide.

The first Domain in The PMI Guide to Business Analysis (from Project Management Institute) is Needs Assessment. The Business Need for a project or program in that standard is defined during the “Assess Current State” task along with a current state assessment. It is also the entire first chapter in the PMI publication Business Analysis for Practitioners: A Practice Guide.

Figure 3: Needs in PMI Guide to Business Analysis

Needs are formally defined in PMI’s BA Standard as “…the impetus for a change in an organization, based on an existing problem or opportunity.“ It is entirely consistent with the IIBA definition and both standards remind us why root cause analysis techniques are so important for clarifying business needs before analyzing and defining solutions.

In the next article of this series, look for descriptions of five common and useful techniques for root cause analysis, and by extension, business needs.

Sources:

A Guide to the Business Analysis Body of Knowledge (BABOK® Guide) v3 from International Institute of Business Analysis, published 2015.

Business Analysis for Practitioners: A Practice Guide from Project Management Institute, published 2015

The PMI® Guide to Business Analysis from Project Management Institute, published 2017

When to Document in Agile Projects

Written by Larry Blankenship on February 12, 2020. Posted in Articles. 5 Comments on When to Document in Agile Projects

One of the planks of the Agile Manifesto states, “We value working software over comprehensive documentation.”

Unfortunately, people working on the project take this to mean that working software is sufficient and there is no need for any documentation. This could not be further from the truth. What do you need to document? In this article, I’m going to give you some suggestions for deciding what needs to be documented outside of the comments in the software (and yes, commenting your code is still useful as long as you focus on what and why, not how), and what got captured in in the ticketing or project management tool.

There are three places where you can create the most value when doing documentation outside the ticketing system:

Tracking Decision Making
Meta Data about the Project
Process Integration

Tracking Decision Making

Typically, tracking of decisions that the team made in each story happens in the Project Management System or in a system like JIRA or TFS. However, there are times where it will be useful to have a summary that captures the major decisions, who made them and why. This can come in handy during the maintenance process where knowing why the team made a specific design decision may be the difference between changing a variable and rewriting a whole section of code when a change is required.

It can also be helpful during reviews and project post mortems when it can be essential for capturing lessons learned during a particular sprint. A simple way to approach this is to use a list in Sharepoint or an Excel spreadsheet with the following headings:

Release
Sprint
Description of the issue
Summary of Discussion
Decision Made
Effect of Decision

Metadata About The Project

Often, much of the information about the application will be self-contained, which is perfectly good as long as you have the hood up and can get at the wires underneath with ease. There will be times however, that having the application be a black box is going to cause issues for people who work on the application later. Even though applications are supposed to be black boxes, it’s good to keep notes on where the keys are so if you need to unlock the box later, you can.

Information that can be helpful in this instance includes:

When the application went into production
Location of the source code
Location on the network where the production application is located
Database connections or at least which database contains the application data
Business Owner – Who has the authority to make decisions about the application?
External Web Services or FTP servers that are used and any credentials needed (We store credentials in a central password vault)
Any coding standards used (this can be very useful when the work is being done by contractors who may not be available for maintenance work).
Any off the shelf applications that may be part of the system. This can be especially important when the off the shelf application gets an upgrade or has the version in use deprecated.

Advertisement
[widget id=”custom_html-68″]

Process Integration

I am a big fan of process documentation. As one mentor told me, “If it’s not documented, it’s not a process, it’s a regularly occurring event.” ISO-9000, one of the most popular quality standards devotes several clauses to documentation. Process documentation provides a record of the baseline of your process, which you can then use to monitor changes and how well those changes worked.

When dealing with a new system, I like to know how the user will do the process with that system, not just how the system works. When I’ve taught software classes in the past, I’ve focused on a task and how to use the tool to perform that task rather than just how to use the tool. For example, when I taught Powerpoint, I taught how to create effective presentations using Powerpoint, rather than just teaching Powerpoint.

I personally prefer to use flowcharts for process documentation, but depending on your industry and regulations, you may have to write something more formal. The most important things to document when writing process integration documentation are:

What job title does the process?
How many people do the process (useful later when prioritizing trouble tickets)?
Can the process still be done manually or via a work around if the application isn’t working?
What are the inputs and outputs for the process?
Are there feedback loops to let the person who created the input or output whether there was an issue?
What is the value created by the process and how does the software contribute (this is something that you probably did during the requirements phase, but it’s good to go back and review to make sure something didn’t change in the meantime.)?
Keeping some kind of history of changes and so forth can also be very helpful.

How Much is Too Much

One of the reasons that working software is valued more than comprehensive documentation is that comprehensive documentation is a huge consumer of project resources, both in creating the documentation, and in maintaining it. Massive quantities of documentation can result in binders full of information that no one will actually end up reading, or that will be out of date almost immediately. Keeping documentation at a useful level is very similar to writing user stories for a software project.

As a Developer

I need to be able to easily find metadata about an application

So that I can start working on maintenance tasks immediately when asked

As a Project Manager

I need to be able to see a history of decisions made about a project

So that I can improve the decision making process

As a User

I need instructions that show me how to do my job with the application

So that I can be productive immediately and reduce my learning curve

Albert Einstein addressed documentation and software design when he said “Everything should be made as simple as possible, but no simpler.” Understanding the value of what you document will help you do just that.

5 Reasons Why a Great Project is Like Good Chicago Style Pizza

Written by Brad Egeland on November 13, 2019. Posted in Articles. 6 Comments on 5 Reasons Why a Great Project is Like Good Chicago Style Pizza

Comparing project management to a Chicago style pizza may be quite a stretch, but you need to first understand how much I like pizza.

When I’m in Chicago, I always need Chicago style pizza like Giordano’s, Pizzeria Uno or Lou Malnati’s. Once when I was in Boston for a week long training session with my manager who happened to like pizza as much as me -early in my professional career ended up eating at probably 5-6 different pizza places… In a week. So, when people say “I could eat that morning, noon and night”… With pizza I literally would be ok with that. When we first moved to Las Vegas I came first and stayed in the Luxor Hotel and Casino for a month and looked for a house for us while working in the IT department managing the corporate IT application development team, I ate at the food court every day in there. And there was a pizza place… So, I did literally have pizza very nearly every day for a month. I was ok with that.

Let’s take this very odd analogy a step further and consider these five ways or reasons why a great project is like a great Chicago style pizza… bear with me here… you may or may not enjoy this – who knows but please do let me know through feedback.

The crust is the foundation of a good project.

The crust sort of makes the pizza, right? Bad crust is hard to overcome. Everything else can be great, but on soggy crust it’s still just a bad, unsatisfying pizza. And sometimes crazy good crust can bring a pizza back from the dead if the other ingredients are so-so. You know what I’m talking about. For me, the crust is the leadership of the project. Yes, an easier project can have a “fake it till you make it” project manager who is still barely experienced at leading teams and projects. Everyone has to start somewhere. But not many organizations – unless they are so startup or so startup with their PM infrastructure – are going to put a brand new project manager in front of a $1 million project customer. You need experienced project managers in your infrastructure or project management office (PMO) to lead most of your projects – especially the more visible and high priority or complex projects. You can’t just phone in the leadership of these projects… They require the solid leadership and communication skills of the seasoned and proven successful leader of projects to keep those important customers satisfied and happy and coming back for more work and adding more revenue to the organization.

It’s all about the sauce.

For me, the sauce is a critical ingredient of the pizza. Bad sauce, bad pizza. In this scenario, the sauce is like the project communication. Communication is Job One for project leaders and poor communication can and will definitely bring down any size project. The project manager must be an effective and efficient communicator for the project and the team and the customer. That’s meetings, email, adhoc calls, regular weekly status meetings, team meetings. Any and all communications and follow up on key communications is very important so as to ensure that everyone that was part of that communication is on the same page afterwards. If a weekly status call with the team and customer happens, then follow up afterwards with notes asking them to respond with feedback or changes within 24 hours to ensure everyone understands and received the same information. One mis communication can lead to missed last assignments, tasks not being completed or even worked on when you thought you had everyone on the same page, but they weren’t. Never take understanding for granted.

Advertisement
[widget id=”custom_html-68″]

What toppings do you like?

The toppings are big because each pizza has different toppings and add different flavor to the pizza. The toppings are the project team members because they vary with each project and with the skill needs for each project. Some projects actually need two business analysts – I’ve had several projects like that – so that’s like double pepperoni, right? Seriously though, some ingredients are just critical on nearly every project and I believe that – especially on tech related projects – cyber security is becoming one of those ingredients… At least as an input to risk planning and management. So that may be the cheese – hard to have a good Chicago style pizza without cheese! And yes, some teams always have the same types of skill sets because they are similar projects, but the great thing about projects is you can have a huge variety of skill set needs – you just need to understand the needs of the project and obtain the right resources and associated skill sets accordingly.

Perfection takes time.

The perfect pizza takes time to perfect and then it takes time to plan for and repeat that success. Likewise, with projects. Planning is a critical aspect of any good, successful project and lessons learned – just as you learn to make the perfect pizza – must be part of the process if you want to add to your skills and become better managers of the projects, customers, and teams you lead along the way.

Better than the imitators.

The best Chicago style pizza is going to be better than its imitators through hard work, great ingredients, a good team of workers, and a proven recipe of success. And there will be imitators just as there will always be competitors for the work you do or the software you make or the products you build or whatever you are doing for your project customers. You must work toward excellence and remain better than your imitators – your competition. They will always be trying to gain on you and take your customers away from you. Stick with your proven best practices, always be learning and improving and perfecting, and you’ll keep your customers and keep winning on your projects.

Summary / call for input

Building great pizza takes skill… And building the perfect project for your customer and their end users takes skill, planning, learning, time and the right teams. Very different yet very similar. But both take key ingredients to come out great at the end.

Readers – what’s your take – what would you add to this or do you even agree with my pizza obsessed comparison. I know it’s a stretch, but thanks for reading and let me know your thoughts on this.

Differentiating Differences that Make a Difference

Written by Robin Goldsmith on July 8, 2019. Posted in Articles. 9 Comments on Differentiating Differences that Make a Difference

Perhaps you’ve noticed that a lot of people write, speak, train, and consult about Business Analysis (BA).

The number involved grows quickly when we also include those dealing with systems analysis (SA), requirements analysis (RA), requirements engineering (RE), requirements management (RM), and whatever related two-letter acronyms you no doubt could add.

For the most part, each of these probably represents different names for the same thing. Yet, presumably those claiming one term versus another think theirs is somehow different from the others—in some important way that truly makes a difference. Ironically, if indeed there are differences among these terms, they are hard to tell because there are no agreed-upon definitions that actually differentiate among them.

In fact, it gets worse. Thus, one partisan is convinced their term represents a particular characteristic; whereas someone else feels equally strongly that that characteristic represents their different term; and each is unaware of the other’s perception. Stepping back a bit should make evident how silly it all is; but of course, nobody sees folly in something dear to him/herself. It’s not limited to BA, nor is it new. Centuries ago, satirist Jonathan Swift made light of similar silliness in the classic Gulliver’s Travels.

Yet, such perceived differences actually are of great consequence to lots of people. Whether real or imagined, material or superficial, presumed differentiations often are taken very seriously and can have enormous economic and professional impacts. Consider, for example, how picking just the right terms for ads, titles, and web sites affects sales of books, training, and consulting.

Po-tay-to, Po-tah-to

Now that we say it out loud, it’s fairly easy to recognize some of the significant consequences when similar things are called by different names and when different things are called by the same names. Yet, few are aware that in the U.S. and Canada, the International Institute of Business Analysis (IIBA) and its various certifications predominate, whereas in Europe, the International Requirements Engineering Board (IREB) holds similar status. Each is convinced of their unique niche, but darned if I can see the difference. And, yes, a couple of other contenders further muddy the waters.

Where It Really Matters

In the final analysis, whether you call it RE, BA, or BS is superficial form and matters mainly to the handful of brand promoters like IREB and IIBA. However, difficulties differentiating content substance can have a much less evident, but unfortunately far greater and more insidious direct and indirect impacts.

We’re familiar with the physical science concept of inertia, wherein a body in motion tends to stay in motion and a body at rest tends to stay at rest. However, inertia also pertains to thinking. It’s very hard to overcome entrenched ideas, and institutions often create obstacles to further impede challenges to their vested ways of thinking. Establishing and defending a brand takes advantage of such inertia.

We still regularly see news reports of those in power, or seeking power, torturing and murdering people whose ideas are deemed to threaten the establishment/brand—just as they’ve done for dozens of centuries. Yet, once-heretical ideas can become mainstream, often though only after extended sacrifice by initial adopters.

While not happening to the same draconian extent in the BA community, nonetheless both conscious and unconscious forces continually curtail ideas that are counter to brands’ favored conventional BA wisdom. BA has become big business, relying largely on brands to sell products and services. Though probably not apparent to consumers, promoters quite consciously guard BA brands behind the scenes through economic, social, and legal pressures against their few generally easily-identified competitors.

Advertisement
[widget id=”custom_html-68″]

Unconscious Content Confusion

In contrast, content confusion directly affects a somewhat larger but still small group of BA authors and trainers like me. More importantly, though, content confusion can indirectly affect the full BA community by suppressing innovation and awareness of different and potentially better ideas. Content confusion is especially prevalent because it’s seldom recognized or conscious.

Stories of intrigue often advise “following the money.” In BA, money mainly comes from training, consulting, and publishing. Overwhelmingly, buyers choose which BA products and services to buy based on brief titles and descriptions. Not surprisingly, most BA courses and books have similar names. A search for a particular BA topic keyword on Google or even a training vendor’s website implies all displayed courses/books have comparable content.

Indeed, many BA products’ content essentially is interchangeable. Sometimes that’s intended, such as for courses/books to prepare one to pass a particular certification exam. More often it’s unintended, typically occurring because most authors/trainers simply repeat what they’ve learned from other authors/trainers. That’s not my content.

Better-known authors join to institutionalize their repeated content in various BA brands’ bodies of knowledge. Consequently, I find competing brands’ content virtually indistinguishable except for stylistic variations and a few consciously coined signature terms. Most brands avoid confronting competing brands directly, I’d say somewhat cynically because they can’t convincingly describe let alone set apart their differences.

Different authors/trainers do vary in how they present their common content, which presumably makes one product more interesting or informative than others. Over time, popularity and search engine rank should reflect superior products. However, inertia and promotion also affect product perceptions. Since few buyers look past the first page or even first item of a search, prominent item position is mainly what’s reinforced.

Moreover, titles and keywords that buyers think to look for are unlikely to reveal products that have different or innovative ideas content. Even the brief descriptions of similar-sounding products often cannot convey meaningful content differences.

Buyers sometimes rely on sales representatives to explain respective products’ pros and cons. With perhaps 1000+ titles for sale in their catalog, sales reps cannot actually be familiar with more than a few, and may not truly understand them, let alone how their content differs or why it matters. Not surprisingly, sales reps usually stick with pushing the same popular products, sometimes at the expense of possibly preferable ones.

Confusion’s Catch 22

Indeed, parts of my courses and writing are like what others also say. It would be foolish not to gain guidance from colleagues and other experts. However, mostly what’s the same is general concepts and techniques. On the other hand, my work is differentiated by key central models and methods which I developed personally over many years performing real projects of business significance for leading organizations.

Certainly, many people have project experience and maybe even have innovated; but I’ve seen few who critically understand what they’ve done and even fewer who can extend it to benefit others. Besides having a propensity for trying to figure out how and why things work, I’ve been fortunate to build perspective from encountering similar situations several times and having the occasion of creating courses to analyze and translate them into meaningful models and methods others can use to advantage.

For example, my BA work focuses on discovering what I call REAL business requirements, which are very different in ways that make important differences from the “requirements” most authors, trainers, and brands focus on.

Yet, few buyers, sales representatives, or even other BA authors/trainers recognize that my courses/writings (including also Proactive Testing™, REAL ROI™, and Beyond the Textbook™ acquisition) differ from most others, let alone understand the differences or appreciate why my materials are so much more valuable. Differences in titles and descriptions just don’t register with someone until after they’ve learned about my approaches; and they won’t learn about my approaches because the differences don’t register with them. Explanations like this are so important for building awareness.

REAL Business Requirements

Other authors, trainers, and bodies of knowledge do use the term “business requirements,” almost always to mean objectives and purposes/desired value. In contrast, REAL Business Requirements are business deliverable whats that when satisfied achieve objectives and thereby provide value. That’s a real difference.

REAL Business Requirements deliverable whats are satisfied by some product/system/software, whose product requirements/features are ways how presumably to satisfy the whats. Other authors, trainers, and bodies of knowledge focus almost entirely on product/system/software requirements hows, which do not themselves provide value.

Creep, changes to requirements after they supposedly have been settled, is a major cause of project overruns. Conventional wisdom is that creep is caused by requirements, meaning product requirements, which are not sufficiently clear or testable. Testability is largely a function of clarity.

While clarity and testability are important, much of creep occurs because the product requirements, regardless how clear and testable they are, fail to satisfy the REAL business requirements, mainly because the REAL business requirements have not been defined adequately, in turn because conventional wisdom mistakenly thinks that product requirements are THE requirements.

Thus, the key to reducing creep is first to discover the REAL business requirements deliverable whats that provide value when satisfied. Then, define the requirements/features of a product/system/software way how to satisfy the whats.

Traditional BA courses and writings don’t teach this because their authors don’t know it. When I present these ideas to a group of practicing business analysts, about half seem to have aha moments and make comments like, “Now I understand why I’ve been having requirements problems all these years.”

Ironically, many BA guru authors/trainers don’t seem able to understand the differences. Some folks would say it’s because they have a vested financial interest in the traditional model focused on product requirements that they sell. I think it’s more likely their mindsets are so firmly established that they cannot mentally accept something fundamentally different. I think that’s their loss, and more importantly also the BA community’s loss.

In addition to explanations like this to create awareness my courses do differ, I’ll more consistently include hopefully differentiating terms in course titles, such as REAL business requirements, and explain their important differences in course descriptions.