In an episode of "That 70's Show" Hyde teaches Jackie how to be Zen.  What he's really showing her is how to respond in a way that the person listening has no clue if there was agreement or not. He shows her how to respond to every statement & question with a casual: "whatever." This is a great example of ambiguity.

In my newest role, I am not managing a team or monitoring other BA's.  I am the BA and so I find myself writing the requirements instead of critiquing and coordinating them. In doing so, I have to follow the guidelines I have been using to judge the work of others for years.  The most important thing I keep in mind as I write is not to let ambiguity in.

About a week ago, I was incensed by an article on requirements excellence because the author seemed to take the defensive position.  "It’s not me, I write great requirements and project failure is out if my hands." Well, I have to say that's not true. The leading cause of project failure is requirements, and the leading cause of requirements failure is miscommunication. Why? Ambiguity!

So just what is ambiguity? Well, in a nutshell, ambiguity is anything that is unclear or vague. In requirements ambiguity is anything that can be interpreted in more than one way, language that is inconsistent, use of jargon and incomplete logic.

Multiple Interpretations

When I read requirements I pick them apart. I pull out words like should, could, some, few and many. You can't measure or quantify some, few and many. Should and could mean the item is a nice to have. Be assertive. If the tool must do something, write that the tool must do it.

On ham radios, you use special language to get a clear message across.  You say correct instead of right and Roger instead yes. We need to follow similar guidelines. Use simple language. The more you embellish a thought, the more unclear it becomes. If you are not sure how to describe it, bounce ideas off a colleague or work the idea over using mind mapping or brainstorming techniques.

Inconsistent Language

In addition to embellishing requirements language (some really fall just short of “thou shalt…”), many BA's also use terms interchangeably. A big part of ambiguity creeps in here. The terms might actually be interchangeable in conversation over the water cooler, but they are not interchangeable in a requirements document. All you're going to do is confuse your audience. It could be as bad as the "who's on first?" by Abbott & Costello in some meetings.

A product typically has a full name, and a nick name; it might be part of a suite or product line; and it is always associated to the company that created it. These are not interchangeable! At the start of your document define the name you will use throughout the document. Define it with the full company name, product line, and product name. Adopt one name and stick to it.

An example is the project I am on now. We are making enhancements to a web application for making reservations on a ferry. I had to resist the urge early on to use reservation and booking interchangeably when writing about the reservation records. I separated them because booking is actually associated to the process of making reservations and to travel agents.

Use of Jargon

We are so bad for using jargon in software we think we invented it!  The trouble is that so many of the terms we use have a completely different meaning to the business users. This means they won't understand how we're using the terms and again, we miscommunicate information to the audience.

Warning: Excessive use of jargon may cause business users and stakeholders’ eyes to glaze over.

If you're in a meeting, and you don't have a hot clue what they're talking about it's pretty hard to contribute. If you can't contribute, you get bored. If you get bored, you're disinterested and less likely to ask questions that add value to the quality of the end product by challenging the requirements. And guess what... ambiguity creeps in because people have gone past the ability pay attention and really care.

Incomplete Logic

I would have been a wealthy woman if I had a dollar for every time I heard "we didn't think about that" on my last project. So many BA's focus on defining what the software has to do under a given set of circumstances, they forget to explore the 5 W's of what it should do if those circumstance or any combination of them is not met.

Trust me, I've seen requirements from BA’s on the defence, and they are riddled with these logical inconsistencies. If you ever find yourself defending your requirements to a team that is telling you I can't understand them... It's not them, it's you. Drop the ego and fix it. Accept responsibility, make it right, learn & move on!

It kind of reminds me of my son when I come across this defensive attitude. My teenage son's knee-jerk response is "it wasn't me." we live in a house with two cats and occasional visitors. (I'm starting to suspect we might have actually have another roommate that likes to take things out and leave them around.) The point is, he gets defensive, and the more he sits in denial the more he looks like an uncooperative ninny.  Because I know it was him!

360 Degree Perspective

The best solutions come from the marriage of ideas from different sources. Many great documents like the Declaration of Independence, the Constitution and the Charter of Human Rights & Freedoms were created this way.

Requirements are no different. Ambiguity is best addressed by looking for it with a peer & team review. Be sure to Track all ambiguities in an ambiguity log containing metrics for measuring the statistics on them. After giving them a chance to read the requirements against the ambiguity criteria (tell them what the criteria are!) host an ambiguity walk through.

Guidelines for Hosting an Ambiguity Walk Through

Ensure you schedule lots of time for these meetings. Quality review sessions and walk throughs involve developers, testers, architects and business intelligence. This means you will sessions of a minimum of 4 hours per day over the course of up to 2 weeks including breakout sessions.

Set rules for the sessions to go faster & smoother. The best rules I have used for breakouts state that any issue that will take longer than 5 minutes to resolve, requires more analysis or requires input and decisions from someone not in the current meeting, get moved to break out sessions.

Define the approach and the criteria for turning an item into a break out. Go over the approach at the start and remind people again at the start of every session.

Ideally, you want to talk about the requirements from a high level functional perspective. An example is: "this function is intended to provide the functionality for check-out. The basic processing is X. 

Did anyone see anything in this section that does not make that clear?"

Collaboration as a by-product of Ambiguity Management By utilizing the ambiguity management techniques outlined in this article, two things will happen: the quality of the product built will increase with greater alignment to the project objectives, and your team will learn to collaborate on an unprecedented level.

When architects, developers and testers provide the kind of 360 degree feedback you'll get in this forum, you wind up with requirements that fully define a product. Not only will that product meet business objectives and drivers, but it will have more of the target functionality, fewer bugs and you will actually decrease the break and fix cycle! On top of that, all team members will feel like they’ve been heard, had their concerns addressed and that they contributed to a quality product. It doesn't really matter where they're at right now, it just might take longer to get there.

Well, here they are.

Now, I don't usually make resolutions. But this year is different. Maybe because there is so much that I want to accomplish and so much that has to be done this year, that I just had to find a way to prioritize them and making resolutions seemed like a good way to do just that.

In case you hadn't noticed, I'm an avid writer. I started back in sixth grade and knew even then, that no matter what I did for a living, I'd write about it (although back then I imagined myself as being more of a female Indiana Jones type). Until recently, my record for writing was 65 pages in 4 days. It seems that all I really have to do is let the hamsters out and find the wheel and then they start furiously churning stuff out and all I have to do is manage to keep my fingers on the keyboard.

It's just that there are so many ideas floating around my head that it really seems that all I ever have to do is sit down when inspiration hits, and I've got another article or something. So that takes me to resolution number 1.

Complete the book that I have been working on for J Ross Publishing. It's all about Business Analysis (of course), and presents some ideas that I think will start some new trends. I'm very excited about that. You see I like being a trend setter. Always have.

Some of the trends I've started are related to things people say (I was first to start using the term "challenged" instead of disabled), things they wear (my Mom will tell you that because I made her search every shoe store in town for a pair of saddle shoes back in the 80's when they were no longer cool - only to discover they were not due in until fall, but by then I had moved on), and things that people do (if you don't know this one - I created the first university accredited Business Analysis Diploma program and the first real requirements methodology).

I like sharing and using my creative ability to set trends to help others and that of course brings me to resolution number 2.

Help another 400 Business Analysts become GREAT Business Analysts this year. That one's a tall order, and so I might need some help in finding all those Business Analysts. I'll probably have to do a lot more marketing and speaking at events, and just plain connecting with people. Which actually kind of brings me to resolution number 3.

I have to goal to have something brilliant to say about Business Analysis and get it posted on Ted Talks. But that's going to take a lot of work, so I've broken into into smaller goals. Like, get better at public speaking (try to manage that pesky stage fright) and eventually get invited to be a Keynote Speaker at a very large industry event. I figure after that, I should be ready to tackle Ted Talks.

Anyway, those are my resolutions for this year. I'd love to hear yours and maybe even help with them if I can. And of course, if you can help me with mine, I'd be really grateful!

Drop me a line at revolution@requirementstoolkit.com to tell me what yours are and where you might need some help.

http://youtu.be/Sw_rMITlAmU

One of the biggest superstitions that I see lighting up the discussion boards is the idea that you have to learn business analysis purely through experience.

This only partly true. Recently, I read that the difference between academic knowledge and specialized knowledge is the degree to which you are also trained to organize and apply the knowledge that you have learned. In a way, I have been saying this same thing for years. I have postured that while universities teach you the information, they don’t readily teach you to think and apply the knowledge.

Now don’t get me wrong, I do believe that both have their place and should be equally valued. It’s just that one cannot go well without the other. I have met MBA graduates without any real world experiences and I have also met people with little or no formal academic training and I can tell you that if I had to choose, I’d probably choose the person with real world experience simply because they will have knowledge that I do not have the time or the inclination to teach, and the MBA grad would have to learn how to think and apply the knowledge that they have learned only in theory. I tend to be biased and think that is a much longer learning curve than having to teach one some situational knowledge before letting them loose on the playground.

Hearing this sentiment now from business analysts, reminds me that my real preference is to have business analyst candidates with both. Here’s why: I should really only have to teach them some minor situational knowledge instead of the whole enchilada as it were, and they would come with a diversity of other generalized knowledge that I could show them how to apply. You see the real world experiences will teach them what to do with that other information on their own and it will begin to make sense without me having to teach them everything.

To be honest, the whole argument over academic education or real-world experience reminds me of how people once thought that the world was flat. Yes there were debates back then too, and I’m sure if they had Facebook and LinkedIn we would have seen a greater diversity of arguments pouring in over it.

I can tell you this, most of the business analyst you will meet today got a lot of their knowledge from the school of hard knocks after they spent years in university or working as developers and testers, but that doesn’t make it right and it doesn’t mean that others have to follow in our footsteps. The educational programs that exist today simply did not when we were honing our craft. We created them so that the rest of the analysts don’t have to keep putting their hands on the stove to learn that it’s hot when it’s red.

My best suggestion is this, take advantage of the programs that seniors are putting together so you don’t have take the long road to Tipperary, you can take the shortcut. Get all the precise knowledge and skills we’ve accumulated within a shorter period of time than it took us with fewer mistakes and headaches along the way. After all, isn’t that how and why school began in the first place?

There’s an irony in Business Analysis. While recruiting, screening, hiring, and even teaching others for and about the role of a Business Analyst, we demand and filter for the technical and academic skills. Yet, once they are hired and in the role, we insist that the job being done is too volatile and uses too many soft skills to be measured. That these factors alone deem the measurement and benchmarking of requirements activities, progress, performance, quality and even effectiveness can’t be accurately pinpointed and evaluated.

In a recent discussion, someone quoted a BA evangelist that they were aware of. The quote was “The softer your skills, the harder it is to sell yourself.” Well, I disagree. I believe this evangelist has mistaken soft skills for passiveness. In truth, the more finely-tuned your soft skills, the more assertive you are and the more are able to negotiate and the more effective your ability to communicate, because these are some of the hardest soft skills to learn. Don’t get me wrong, learning the theory behind soft skills can be really easy, but learning it to the point of applying them consistently is hard work.

Essentially, there is a longer learning curve on the soft skills than there is on the technical. Maybe this is due in part to the visibility of the results and the willingness of others to hold us accountable for not applying the technical skills throughout the job. Heck, we can even build accountability into the system through process controls and governance models. Let’s face it, the only “governance model” for the application of soft skills is the performance management system, policies and practices in place.

Unfortunately, this system is highly subjective. It is subjective because the skills of others that are judging us may not be at our level, company politics can play into their application of the system and quite simply, perspective and interpretation impacts views of the same situation from different angles.

I recently gave a talk at a conference, and while many people came up and told me how great they thought I did, another person wrote in their comments that I was “passionate, knowledgeable, and somewhat negative”. So you can see everyone at that talk had a different perspective on my performance because of things in their own life that led them to interpret the same talk in multiple ways.

While there are many differing opinions about how you achieve requirements success, on thing is certain, each of those opinions is based on a set of basic principles and a set of “rules” to follow.

But this is where they usually stop. It’s not so much what the rules are, but rather, how they are implemented. I think most experienced Business Analysts can agree that the basic rules are: Identify and define the objectives, define the requirements, document them, verify the requirements against the objectives and validate the requirements.

So why do we still struggle if we are following this basic set of rules, even if we are implementing them differently? Well I believe that in part that is due to the fact that not everyone is actually verifying and validating the requirements.

I recall recently, where someone asked me if you still had to validate and verify stand-alone requirements. Ummm… YES! Why build ANYTHING that doesn’t align to the business objectives or is wrong?

I think we are all writing requirements the way that most people diet. We are looking for a quick way to get the job done without having to do any of the heavy lifting involved because it’s too difficult. We substitute various tools and iterative or compressed techniques the way some people go through diet pills. The reality is that it shouldn’t matter what tools you are using if you know, understand and apply the basic and fundamental work-out behind requirements definition. That means understanding why certain tasks are done and the value that they add to the project, as well as where they fit into the rules.

But you also have to then take some time learn and to hone the underlying skills (such as Effective Listening, Facilitation, and Assertiveness) like muscles so you can apply and utilize them more effectively. Only then can you become adept at applying the rules of requirements in a way that gets the job done as proficiently as possible.

My best advice when you’re shopping around for a training program this year is to find one that teaches not only the academic and technical skills, but also the soft skills that will make you stand out in the crowd. Not everyone does, and it’s time you did just that for yourself because after all your hard work, you’ve earned it!

We've all seen ads on LinkedIn and other sites looking for Business Analysts with specific domain knowledge. In fact many industries are notorious for being exclusive about the candidates having a specific amount of tenure domain as a Business Analyst.

For a long time, when this question pops up on LinkedIn discussion boards I pop in and assert that it is because the recruiter or hiring firm doesn't really understand the value proposition that a skilled Business Analyst brings to the table. To be honest, this is only about half true.

While we struggle to showcase that value proposition to prospective clients and recruiters, the rest of it is rooted firmly in the functional complexity of the environment and the flexibility of the client to take risks in hiring someone that simply doesn't have that knowledge.

Most of us have been on a project at some time or another where we've struggled to ramp up, and the there were more than a couple of systems to integrate with, or more than a few companies to implement across. We knew it wasn't going to be easy, and maybe we knew because we've done a similar project in the past and so we knew that there were integration points, elements and layers that added to how long it was going to take or how many resources are going to be needed, so we understand and realize that it impacts estimating the project.

But it also impacts requirements and the numbers of requirements, not just from a functional perspective but also from a regulatory perspective. It impacts change control, size and timelines when regulatory bodies make changes to their mandates and limit the time to implement the changes. In some industries, projects feel more like a tennis match with stop and start, and routine changes in direction.

So by asking for someone with domain knowledge, these companies are really trying to address functional complexity of the project in a big way. For skilled Business Analysts, this is not a real issue, because they understand that business generally operates on the same principles and they have the ability to think on their feet. They expect change and they plan for it. However, for the average Business Analyst, they are often just trying to keep ahead of the curve on a project and don't look up often enough to be able to make plans for the "what if" scenarios.

That's exactly why it's important to learn how to measure functional complexity before you start the requirements activities. It will make it easier to ramp up, estimate and plan for the changes and implementation.

Just what is functional complexity and how can you measure it? Well, simply put, functional complexity is the layers and elements of a project that will directly increase how difficult the project will be to complete and the risks involved in completing it. These will in turn, directly impact the number and types of risks, the number of requirements, the numbers and types of stakeholders, the number of integration points and will ultimately spill over into the project planning and impact the time to complete the project, the number of resources required to do the job and finally the overall budget.

Over the years, I have worked with, mentored, trained, managed and interviewed hundreds of Business Analysts. What I am about to tell you will shock you. 99%[1] of the analysts I have worked with are missing critical steps in requirements.

But don’t blame the analysts. They are missing these steps because business analysis is still a collective practice and not a formal profession with standardized tasks, metrics and tools. Many of the analysts are simply borrowing tasks, tools and techniques from other development areas.

The lack of professional formalization means that there is no single tried and true set of business analysis best practices. There are indeed some commonalities, but without a standardized set of best practices, there can be no real assurances that enough has been done to ensure that we have captured the right requirements for the right products. This is exactly where we get stats that illustrate only 20%[2] of features are used all the time and 42%[3] are never used!

For the past couple of years, I have struggled to put what I really do into words so I usually revert to "I'm a Business Analyst".

But after a conversation with my former CEO, and a couple of other valuable connections, the truth is that I haven't really been a true BA for some time. Sure I fill the role with clients, but it's not my passion.

Yes, I am passionate about Business Analysis and the critical role it plays in the success of projects and organizations alike. For a while I was a business/solution consultant. I enjoyed getting to that point which I believe to be the upper echelon of the Business Analyst's career path, and I enjoyed doing the work. But my biggest passion is building organizational capability & capacity. I excel at it (that's not bragging, I heard it repeatedly during conversations with some of my really top-notch connections).

What is it and what does it mean? Well, in a nut shell it's building the framework for an organization to manage it's people resources, an environment for the development of those resources and filling capacity gaps along the way. I guess my very unique background contributed to my ability and passion for this area, but my obsessive compulsive personality allowed me to perfect it when I found a niche called Business Analysis.

Twenty years ago I had a reputation for developing positive learning environments for my physically & mentally challenged clients. Because I did the same thing. I helped build the frameworks and environment to help these clients achieve their potential and have experiences many thought they would never have because of social biases or physical limitations.

Why is building capability & capacity so important? Well, in all of the technology organizations I have worked, Business Analysts are the one group that is literally a ship without a captain. Companies are simply not managing these resources the way we manage other groups like developers, testers and PM's. What I mean by that is that many companies do not have a dedicated manager for business analysts. This means that their is no real career planning or progression, there is no real capability development and most have been using business analysis like a stepping stone to something else.

That's where I come in and that's exactly what I do. I establish the framework to manage groups like business analysts, create the environment of collaboration, the key performance indicators, assessment tools, competencies, and career plan. Above all else, I bring them together as a unit, and motivate them to do better. Because the truth is, most people only really know when we do a bad job and most people don't know what we do or how to track real quality of our deliverables. I know that because I see it when they advertise for a BA/Tester or BA/PM. The roles are joined because they don't know what we do that adds value to the process.

No one but another BA can really evaluate how good we are at our jobs, not even a Project Manager. They can tell how manydefects or ambiguities popped up but that's all and that is really not a true and exclusive measure of the BA performance.