Skip to main content

Tag: Business Analysis

Business Analysis According to Sherlock Holmes

I have been reading and rereading Arthur Conan Doyle’s stories and novels about the brilliant detective Sherlock Holmes for years. With the possible exception of Edgar Allen Poe’s lesser known Auguste Dupin (see The Murders on the Rue Morgue), Holmes stands as the pre-eminent and archetypical critical thinker and detective of all time. Sherlock Holmes provides the model for all the genius eccentric crime solvers who occupy the books, airwaves, and movie theaters of today. Holmes has a lot to say about how to analyze information and evidence and deduce the best solution or the perpetrator of the crime.

Sherlock Holmes is one of the charter members of the Business Analysis Hall of Fame. He has left a vast legacy of advice and counsel to business analysts of all ages. Herewith, direct from 221B Baker Street, are the words of wisdom from Sherlock Holmes.

“Approach the case with an absolutely blank mind, which is always an advantage. That way you formed no theories. You are simply there to observe and to draw inferences from your observations.” (Adventure of the Cardboard Box)

The business analyst needs to be objective. The business analyst cannot have preconceived notions, including those foisted on them by the customer, sponsor, or subject matter expert. When eliciting information the business analyst listens naively and asks questions without prejudice (see the series “How to Ask the Right Questions”, especially part 4: “Asking the Naked Question” for more information about listening naively). When the business analyst comes to an interview with a solution in mind, for example, one proposed to them by the sponsor or another stakeholder with political clout, the business analyst will tend to ask questions and hear the answers that support the solution and ignore or discount any information that may cast doubt on the solution. This is called confirmation bias. Sherlock Holmes cautions us against such behavior if we want to be top notch business analysts.

“It is a capital mistake to theorize before one has data. One begins to twist facts to suit theories, instead of theories to suit facts.” (A Scandal in Bohemia)

This is Holmes’ way of saying “Don’t jump to solutions.” A business analyst should look for more than one solution to a business problem. Once a solution has been established, ask “is there any other way to solve this problem?” In that way we keep ourselves from accepting the first, and not perhaps the best, solution that comes to mind. Looking for that second or third solution also forces us to seek out more information, some of which might invalidate the original solution (that is also a reason for not seeking additional information: it might prove our initial solution wrong, and who wants to be proven wrong?)

“Nothing clears up a case so much as stating it to another person.” (The Silver Blaze)

The Silver Blaze was a race horse and presented a challenging puzzle for Holmes. At one point he asks Watson to listen to him while he “enumerates over the facts of the case.” He knows that verbalizing what is in our heads forces us to focus on what we are saying and how we are saying it. We are trying to get the pictures and concepts in our brains into the brain of someone else and will tend to make those concepts simpler and clearer. And so he does. And so should we. Before conducting an information gathering session, perhaps it is a good idea to ask another business analyst the questions you plan to ask the subject matter expert or another stakeholder. Hearing the questions aloud might cause you to restate a question or two, or not ask them at all. You might also verbally walk through your solution, or your requirements, with another business analyst before committing the solution to a formal document for submission. And if you are creating user stories in an agile environment, reading them aloud is not just a good idea according to Sherlock Holmes, but also from others including the “inventor” of user stories, Ron Jeffries.

“There is nothing more deceptive than an obvious fact.” (The Bascombe Valley Mystery)

There are “facts” that everybody thinks they know. One of the more common is “It’s done this way because it’s always been done this way. It’s the only way to do it.” The business analyst is aware of the ‘fact” that cannot be proven, but must be taken as truth. In The Bascombe Valley Mystery, Holmes is responding to Watson’s claim that the evidence as reported is somewhat condemning to their client. Holmes points out that evidence, especially circumstantial, points in one direction, but with a little shift in your point of view, you may be looking at something completely different. It is similar in business analysis in the pursuit of a solution. The solution that everyone seems to agree to may not be the best solution when all the facts are in, including those facts not in play at the moment. In theory, those thinking the solution is best assume that all the facts are known.

“When you have eliminated the impossible whatever remains, HOWEVER IMPROBABLE, must be the truth.” (A Study in Scarlet)

“It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth.” (The Beryl Coronet)

“We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth.” (The Adventure of the Bruce-Partington Plans)

These similar quotes refer to the method that Sherlock Holmes uses to solve a mystery. He begins to construct theories based on the data that he has in front of him. He is creating alternate solutions to the problem (the problem, of course, is to figure out who committed the crime and how was it committed). He then looks for more data or evidence that will either further confirm or eliminate each theory. Eventually, through a logical process of elimination, Holmes has solved the mystery. As business analysts we can perform a similar process of elimination by starting with the facts, confirming those facts, and then forming potential solutions. Then our investigative job becomes one of gathering information to disprove or eliminate each solution. As solutions are eliminated based on evidence gathered, we can determine the one, best solution. (Note that if all potential solutions are eliminated, we need to go back and re-theorize.) As Holmes says:

“If the fresh facts which come to our knowledge all fit themselves into the scheme, then our hypothesis may gradually become a solution.” (The Adventure of the Wisteria Lodge)

“A further knowledge of facts is necessary before I would venture to give a final and definite opinion.” (The Adventure of the Wisteria Lodge)

In this piece of advice, Holmes is suggesting that we hold off on rendering opinions or conclusions until we have enough information to do so. In many of his adventures he had the solution to the mystery in mind (his predominant theory, for example) and refused to disclose it until he got that last piece of evidence that confirmed the theory beyond doubt. We should be as careful about advancing our solutions until we are sure of them based on the information. (Or to quote someone from a different world altogether: Davy Crockett said, “Be sure you’re right, then go ahead”)

“Education never ends, Watson. It is a series of lessons with the greatest for the last.” (The Adventure of the Red Circle)

As brilliant as Holmes was, he never stopped learning. He admitted when he made a mistake, immediately recognizing what that mistake was. You get the feeling that once admitted he would never make that same mistake again, or perhaps not make even a similar mistake. For example, in “The Adventure of the Stock Broker’s Clerk”, Holmes and Watson enter a room to confront their suspect who is sitting at a table reading a newspaper. Upon seeing them, the suspect races into the next room and attempts to hang himself. Holmes is at first mystified that the fellow would attempt suicide at their appearance. Later when the man is revived, the motive for the suicide becomes apparent. It was something he read in the paper. Holmes then exclaims, “The paper! Of course! Idiot that I was! I thought so much of our visit that the paper never entered my head for an instant.”

Sherlock Holmes had a lot more to say that still resonates across the decades to us, advice that can be applied to our day-to-day work as business analysts and critical thinkers.

If we could all be like Sherlock Holmes, Conan Doyle’s protagonist would never have achieved the publishing success and lasting fame that Holmes has enjoyed for over a century now. We don’t have his remarkable ability to eradicate the emotional, eliminate the irrelevant, and focus with laser-like intensity on the given problem. We don’t have Holmes’ amazing powers of observation. (He could distinguish 75 different perfumes (The Hound of the Baskervilles) showing that he even brought his sense of smell into his observations). However, we can learn to better examine the information we receive with more critical thinking and withhold our judgment longer when evaluating that information. We can learn to restrict our observations more to the evidence that exists rather than what we think exists, or what we have been told.

While we are pursuing the best solution to the business problem and endeavoring to add value to the business through improving processes and solving problems, we might find we are doing a better job of it if we remember and apply the acronym WWSHD: “What would Sherlock Holmes do?”

Don’t forget to leave your comments below.

Can You Develop Standards That Embrace Both Agile and Traditional Approaches?

In recent years, we’ve seen even the most conservative, tightly-structured organizations begin to experiment with agile and hybrid approaches. These organizations have a long and comfortable relationship with the traditional waterfall approach, but their curiosity leads them to dabble in agile. Where does this leave their well-defined and well-protected organizational templates, standards, and best practices?

When these traditionally waterfall organizations add agile teams or transition to an agile approach, interesting things happen. I have seen and heard all of the following:

  • Teams say, “We don’t need templates because we are agile.”
  • Team leaders say, “We just need a waiver for agile projects to skip the templates.”
  • PMO Leaders say, “But we need standards and consistency!”
  • BAs are confused about their role and responsibilities!
  • Traditional BAs start projects with standard templates and then re-shape details into user stories.
  • Agile BAs build story maps and user stories with the team and then re-shape details into traditional requirements templates.

The confusion about governance, templates, standards, best practices, roles, etc. turns most agile teams into castaways, isolated from the rest of the organization or PMO like this:wick april28 img001

Or they get chucked out in the rain like this:wick april28 img002

The move to agile causes everyone to question the importance of standards, templates, and project processes. Are they still relevant? If we don’t use templates, where do we document details? Do we need to document? Can we have the same standards for all project approaches?

I realize some people think the words agile and standards should never be written in the same sentence. Standards may seem completely antithetical to the agile mindset. However, we need to consider the purpose of standards and challenge how they evolved to become so rigid and ill-suited for most projects.

We know that appropriate standards provide many benefits to organizations including:

  • efficiency, consistency, quality
  • a common path to shared understanding
  • shared lessons-learned and best practices
  • strengthened corporate culture and values
  • reduced legal and regulatory risks

So, how can we bring agile to the mainland? How can we get agile out of the rain? Many people would assume that agile projects need their own standards:wick april28 img003

But why would we build, manage, track and apply two completely different sets of standards for requirements, especially considering it’s rare that modern-day projects align 100% with any one methodology? In fact, most projects exist in some type of limbo-hybrid, where each part of the project team does what makes the most sense, or more commonly, what they perceive as most comfortable. (We’ll save this topic for a future blog!)

Some will question if it’s okay to have a hybrid model. Is that really following agile? Are we getting the benefits if we are not really 100% agile? What is 100% agile? Manifesto, Principles, or following an agile methodology? Can we follow agile principles and uphold standard governance all at the same time? Is there a middle ground where we can leverage the best of multiple approaches while balancing organizational culture, risk, value and pace?

So here’s the challenge: Can we work toward a single set of organizational standards for requirements?wick april28 img004

Can we build requirements standards that apply to all projects regardless of methodology? Yes and yes!

If we elevate our standards, we can identify core components for every project. Here are a few suggestions:

  • Identify universal truths. Elevate your standards by stripping away the details related to methodology and focusing on the purpose and goals of your solution development process. Review your current standards and templates and understand their function and value. What risk do they minimize? What regulatory requirement or corporate policy do they satisfy? Is the policy needed? Consider corporate culture and core values and how your requirement process should support them, accept what the cultural limitations are, and yet push the organization where it can be pushed for positive change. Look at the timing and detail required: question if they matter based on purpose and goals.
  • Identify universal constraints. Regardless of approach or methodology, every organization operates under at least a few widely accepted constraints. What are your financial, physical, political, cultural, regulatory constraints? Are they real or assumed, temporary or long-term? Use the real, long-term constraints to elevate your standards above the details related to methodology.
  • Decouple. Standards may not include details related to format and timing. Let go of standard assumptions about when and how tasks need to be completed. Remove standards that require specific deliverable created in a specific format or tool. Also, look at timing and stage gates. Stage gates are typically about a certain document, and perhaps level of detail, at a certain time. Stage gates could be about shared understanding and other attributes of decision making. Challenge what we currently view as the purpose of the stage gates and what is really needed to make good decisions. Good decisions are based on shared goals, shared understanding, and understood risk; they are not based on fear of something not getting done or someone not following through.
  • Redefine good requirements. Focus on quality, value, and purpose. Any requirements properly decomposed, organized, and elaborated can work. Good requirements communicate the context in terms of users, processes, and data. Standards should not define how and when requirements are written, instead standards should focus on users impacted, user goals, and decomposition of detail. Agile and waterfall requirements seem so different, but good requirements are fundamentally the same regardless of approach and methodology. Teams can deliver good requirements in many formats, and different levels of detail at different times. The more complex the projects and solutions are, the more adaptable we need our requirements process and standards to be.
  • Share techniques and tools. Don’t put limits on techniques and tools. Don’t categorize them by methodology. Be open to using the appropriate technique or tool needed to meet the needs or address the risks for each project. Story maps and user stories can be used for agile or traditional projects, and process modeling may be needed for both types of projects too. It’s only the timing and format that are different. Many traditional BA techniques (process modeling, scope modeling, etc . . .) need to be used in agile approaches as well. The timing, detail, and collaboration looks different, but the same technique in concept is used.

We use techniques and models in both waterfall and agile projects, but not at the same time or at the same level of detail. Though agile projects might present requirements in the form of sticky notes, whiteboards, a tool, or a SharePoint library of user stories, does that really require a unique set of standards vs. the waterfall word templates? The approaches seem so different, but fundamentally, the standards are the same.

So, what do you think?

  • Can you envision useful standards that apply regardless of methodology?
  • Do you think requirement standards are still relevant and important for organizations?
  • What are the consequences when we allow projects to operate outside of standards?

As always, please share your thoughts in the comments below!

Don’t forget to leave your comments below.

Business Analyst Skills – Overview

In my previous post I promised to list the skills a Business Analyst must have. While there are many qualities/skills required I list only those that are critical. After all, there is no “ideal” BA!! Before I do that let me briefly discuss the types of BA’s as the skills differ slightly for each.

BA’s can be classified into 4 types – Operational, Project, Enterprise, and Strategic. An operational BA is responsible for one or more systems that are currently in use. This person analyzes issues, prioritizes them with business users, coordinates with the technical team and ensures the issue is fixed. The original BRD/FS is appropriately updated. A project BA, as the name suggests, is part of the project team to build or implement a new system. An enterprise BA has a cross-functional view of the organization. A “go-to” person when the project cuts across multiple business units or functions. A strategic BA is more of an advisor/consultant interacting with the business constantly and guiding them in making long-term decisions related to business processes or systems. What skills must a BA in general possess?

Google for BA skills and you will find plenty of them – “4 key skill sets for a seasoned BA”, “8 BA skills for success”, “The Top ten skill sets for a BA” and so on. I listed some of the skills in my previous blog, which I repeat here in greater detail. A few more skills are also added to the list. Again, these are based on my past experience and are common to most situations. Additional skills will be required for different situations.

  1. Active listening. It is a communication technique used in counseling, training and conflict resolution, which requires the listener to feed back what they hear to the speaker, by way of re-stating or paraphrasing what they have heard in their own words, to confirm what they have heard and moreover, to confirm the understanding of both parties . Communication is incomplete if the listener does not comprehend what is being said. Re-stating and paraphrasing is an effective way to understand what the other person is saying. While doing so do not miss out on important facts. Watch for body language too. It provides clues to the importance of the requirement as well as UI design. For example, while discussing a requirement the users may gesture a drop down or a click without verbally stating it. Note them down.
  2. Patience. It’s a virtue that all BA’s must have. First, not everyone has clarity of thought. Second, business users do their job really well but may not be articulate enough. Third, they may not have the patience to sit and explain fundamental things to you. It’s like being in a relationship. Two impatient people make the situation quite explosive. This attribute is something to be cultivated. If you have not read Dale Carnegie’s book “How to Win Friends and Influence People” please do so. There are many examples in there that show how patience can get what you want.
  3. Persistence. You have to strike the right balance. Extreme persistence will annoy people. Extreme non-persistence will result in inadequate requirements. Walk the thin line. Persevere until you get the information required without annoying the business users. Patience and humor are important tools here. Yet another approach is to understand the mental makeup, idiosyncrasies, likes and dislikes, interest, hobbies of the person you will be dealing with. How to get this information? Have an informal chat, coffee, lunch with the person/s before setting off on the formal process of requirements elicitation. Here is a cue from Dale Carnegie – people love to talk about their experience. Once you establish a personal connection, not much of effort is required on the persistence front. Remember, nothing comes easy.
  4. Documentation. Translating requirements as communicated by the users and as understood by you into a BRD/FS requires a good command over written English. Ability to document in a lucid way without diluting the essence of the user needs is a necessity every BA must possess. Supporting user needs with examples in a clear, concise manner ensures the business users and the technical team understand the requirements in a consistent fashion. The key word here is “consistent”. Business users and the technical team must comprehend it the same way. Writing need not be Shakespearean. Simple, grammatically correct sentences are good enough. Where do you start?
    1. Review some of the existing documents. Do they appeal to you? Do they grab your attention? How would you revise it to make it more appealing? Are they clear? If not, what is missing? Remember to try to add those missing ingredients to your documents.
    2. Rewrite some of the documents, if not the whole, at least the portion that is dowdy.
    3. Do not use words where the reader has to refer a dictionary (dowdy is a good example, it means dull, unattractive).
    4. Peer review is yet another way to improve your documentation skills. Some people are very good with punctuation (my weak point). Some are good with word choice and some are good with spelling (my strong point). (I had this document peer-reviewed too).
    5. Use Microsoft Word’s built-in, rudimentary spell check and grammar check. You can ward off some of the basic problems.
    6. Some of the fundamental writing mistakes to avoid – mixing up tenses, switching between first, second and third persons, verb-number disagreement.
    7. Write in active tone.
      Keep in mind that a poorly worded document is rarely read to completion. Also keep in mind that a BRD or FS will be a live document as long as the system exists. So, get the documentation right.
  5. Analytical skills. The bread and butter of a BA. Ability to dissect a requirement, understand its need, study its impact on upstream and downstream systems, and comprehend its role in the grand scheme of things (seeing the forest AND the trees) is absolutely essential. This website lists areas where analytical skills are required and is not restricted to BA’s. I have seen some amazing young BA’s with excellent analytical skills too as well as some experienced ones with waning analytical abilities. How to improve analytical skills? (the assumption here is you already have a level of analytical skills) There are many tools to help you, like Fishbone diagram, 5-why methodology, and much more. Playing Sudoku (not during office hours) helps a great deal in improving analytical abilities. How much to analyze? Enough to implement the requirement and avoid analysis-paralysis. Here are some points to bear in mind:
    1. Always keep the objective in mind.
    2. Establish a time limit to conclude your analysis process.
    3. Perfection is not the criteria, adequacy is.
    4. Check with a senior colleague.
    5. Go with your gut feel.
  6. Conflict management. Conflict is common place in the life of a BA, while gathering requirements, analyzing, communicating to technical team, and testing. Some of the skills mentioned in my earlier blog will definitely help manage these conflicts. Eliyahu Goldratt in his book Theory of Constraints (TOC) provides a methodical way of resolving conflicts. He calls it the “evaporating cloud” . It is a logical and graphical way to resolving conflicts. The diagram must be viewed from right to left (like Arabic). Yet another method is to follow the 2-minute rule. If a resolution is not found within 2 minutes, keep it aside and table it later. Never get into an argument. You may win it but you will lose the goodwill of the person.
    Be aware of the escalation process too. Do not escalate at the drop of a hat. Tact is absolutely essential so as not to mess up the relationship with the business.
  7. Communication. Here is a high-level list of things to do:
    1. Have an agenda for each meeting and share it before hand.
    2. Follow up each meeting with a written communication of what was discussed and provide readers with a timeframe by when they should confirm.
    3. Keep the communication channel with the business users open. There is a general tendency to switch it off once requirements are gathered till UAT. In the interim keep the users updated of the progress being made.
    4. Have walk-through sessions with the technical team to explain the requirements.
    5. Document all explanations and clarifications provided. This will help avoid a ‘you-said-she-said’ situation.
    6. Communication must be clear, concise and correct. Use bullets instead of paragraphs where possible.
    7. If you are not sure how your message will be understood, save the communication as draft. Revisit it a day or two later and if it still sounds good send it.
    8. Spell check and grammar check before sending out the communication. When in doubt, ask someone else to read it.

The list is by no means complete. Different situations demand diverse skills. Some can be acquired while others come through experience. In my next blog I will discuss the techniques available to a BA for eliciting requirements but before that let me acquire some more of the below skills myself !!!

Don’t forget to leave your comments below.

Why Are We Still Talking About PM vs BA?

12 years ago when the IIBA began to form, many debates were had over what the project manager did on the team vs. the business analyst. I am sure the conversations were around before then. And I am shocked there is the same amount of discussions still going on today. It may be because I have a heightened awareness, but I dare to say there are more conversations happening today. Here are some examples of recent activities that sparked this blog.

I recently participated in a LinkedIn Group discussion where people debated the role of a Project Manager and Business Analyst. A majority of the group felt there should be two distinct roles and most had definitive answers on what a PM does and what a BA does. And there were differences in opinion. Another LinkedIn discussion was started by a question, “Should BAs be a little data scientist?” The poster went on to ask “Isn’t it about time that BAs should upgrade their skills to be associate data scientists?” Some respondents felt a strong need to clarify what a Business Analyst does.

The problem is the focus is incorrect in discussions about what a PM and BA should do on a project. It causes people to think in terms of absolutes. Unnecessary and unhelpful debates are had about the roles and people begin defending and protecting titles and job descriptions. Why is this mindset a problem? Very little, if anything, is accomplished by having the debate. The goal for teams is better outcomes to improve the business for which you work. Each individual on the team should have the same goal. In addition, people in the PM and BA field are not robots. All people have different strengths and weaknesses. To assume someone with a title of Project Manager does certain tasks and a person with the Business Analyst title does other tasks is just crazy. And if those conversations don’t put me over the edge, I start talking to people about what a junior analyst does vs. a senior analyst…what does a jr. PM do vs. a senior PM?

And these types of conversations don’t end with just the PM and BA. What about BAs and testers, Developers and DBAs, System Architects and Business Architects, moms and dads. At a macro scale it matters less than thinking about this at a micro scale. Talking about specific job descriptions at an industry level yields little results. At the team level, team members need to understand what capabilities they need to be effective and who on the team has those capabilities. This has to be done regardless of one’s title. Teams need to identify what capabilities they are lacking and fill the gap. That can be done through training and/or bringing in new team members.

What it boils down to is the focus should be on collaboration. Don’t think about your team in terms of roles, think in terms of capabilities. The focus needs to be on capabilities of a team, of an organization, not specific capabilities of a title. These two pictures created by my colleague, Kent McDonald, illustrate what I mean. Don’t create and assign tasks based on what is shown in Figure 1. Be more like figure 2.

kupe April13 01Figure 1: Team built based on roles or titles
kupe April13 02Figure 2: Team built based on capabilities

Does a CIO or the business leaders you work with care that independently you have a good BAs or good PMs? No way. They want teams to deliver outcomes that help move the business in the direction they want. You need to consider yourself a team member first. This means you will do what is necessary for team success. Second, think about how you can best help the team succeed. What skills do you bring to the table? Don’t think in terms of I am a Business Analyst and I have a job description listing 15 tasks so that’s what I can bring to the team. Work hard and work unselfishly.

All the best,

Don’t forget to leave your comments below.

5 Ways to Find Missing Requirements

Doesn’t it seem like we can hardly go a day without reading about how missed requirements are leading to incredible amounts of wasted time, energy, and money on information technology projects? I have been on enough projects to know that the statistics are most likely telling a realistic story about how projects get scoped, defined, and delivered, but that they are not necessarily giving a comprehensive account of the situation.

In this article, we’ll look at 5 practices we employ as business analysts to discover hidden requirements, and how organizational pressures, project circumstances, and business analysis processes can negatively impact the outcomes of those techniques, leading to the costly reality of overlooking requirements.

Practice #1 – Requirements Reviews and Buy-In

It is not uncommon to discover dozens of requirements during the final requirements review stage. Walking through a requirements specification, or a portion of a requirements specification, with the goal of being sure everything necessary has been included, almost necessarily uncovers additional information.

When you are getting ready to approve, finalize, or simply be done with a requirement, your stakeholders tend to invest a little extra time and energy in being sure it is right.

But the review process only works if you establish the importance of the review, making it very clear that once we review this document, development will begin based on what is inside it, and that means the cost of change starts to go up.

This stage of the process can go wrong if stakeholders do not show up to requirements meetings, do not understand the enormity of what approval means, or do not feel bought into the project in the first place. It also does not work if a critical stakeholder is not invited in the first place, which leads us to the next way to find missing requirements.

Practice #2 – Include All Possible Stakeholders

While it is never a great idea to invite dozens of people to a single requirements meeting, good business analysts ensure that all relevant stakeholders are looped into the project and given the opportunity to share their concerns, needs, and expectations. If you are consistently neglecting requirements in a particular area, identify a new stakeholder from that area to include on your project teams.

This part of the process can go wrong when business analysts are assigned to specific areas of the business and projects are assumed to only impact that area. It can also go wrong when managers assign uninformed stakeholders to projects or refuse to assign stakeholders at all. Organizational politics can also be a factor, say, if a business sponsor purposely excludes one or more stakeholders from the project.

Practice #3 – Apply Analysis Techniques

While stakeholders are the source of many requirements, other requirements are discovered by analyzing the stakeholder needs and discovering implications. The result of good business analysis is a complete view of the solution. For example, every field on a report must be entered into the system at some point, whether directly by a user or by some sort of data feed.

Unfortunately, well-intentioned templates can negatively impact the analysis process. When you are capturing requirements in long lists, it is difficult to make all of the necessary links between requirements. As luck would have it, the same is true if you are capturing requirements in a substantial product backlog. You need analysis models, such as business processes, use cases, or data models, to help you discover the missing connections.

What’s more, a large template can give the false sense of security. Just because you have filled out a 30 page template with twice as many sections does not necessarily mean that you have discovered all of the requirements!

Practice #4 – Invest (Just) Enough Time

Good requirements take time from stakeholders, from technical experts, and from someone performing business analysis activities. Part of being a business analyst is putting together a reasonable plan that explains the steps you will go through to elicit, analyze, and confirm the requirements, identify who needs to be involved in each step, and about how long each step will take.

While it might seem counter-intuitive, more time is not always better. Business and technology contexts change quickly. Investing too much time in the requirements process can mean that your early requirements become stale before they are even ready to be implemented. Minimizing missed requirements comes from crafting a plan that secures just enough time to discover the best possible requirements given the project goals and constraints.

However, it is not uncommon for a business analyst to be assigned a mere week or two to finish requirements before development on a sizable project is targeted to start. When organizations shrink project timelines, or the time dedicated to the requirements aspect of the project, without also shrinking the scope of the business analysis effort, then we nearly guarantee we will miss requirements.

Practice #5 – Start at the Beginning

You cannot solve a problem that you do not understand. You cannot address a business need that has not been defined. You cannot sell a product that the customer does not want.

Business analysts understand the big picture of the project, which includes why the organization is investing in the project and the over-arching goal to be accomplished.

I would venture to say that the vast majority of missing requirements are actually missed at the very beginning of the project. If no one inside the project compels the business community to be clear about exactly what problem needs to be solved, or if a business sponsor resists a business analyst’s typical “why” line of questioning, the entire team is working like a ship without a rudder. You run the risk of chasing rabbits down holes and discovering a lot of requirements that are irrelevant, while overlooking the big important requirements that should be staring you right in the face.

Create More Positive Outcomes

As business analysts, we can expect to face circumstances that, if left unchecked, will cause us to miss requirements. It is up to us to clarify the conditions under which we can do our best work and improve our contexts so we can improve our requirements.

Don’t forget to leave your comments below.