Tag: Business Analysis

From the Archives – The Value of Business Analysis: Assessing Organizational Readiness

Written by Aaron Whittenberger on June 2, 2015. Posted in Articles.

Originially Published 10/27/14

One of the key roles of Business Analysts in the solution implementation process is to assess the readiness of the organization to take full advantage of the new solution. This is the role in which the Business Analyst acts as a Change Agent in the organization. Whether this is a software enhancement, new system implementation, business architecture, business intelligence, data, business process, product change, or change implemented by a customer, supplier or regulator, effective communication of the upcoming change to all affected by the change is important to preparing the organization to capture the expected benefit of the change.

The Goal

The goal of an organizational readiness assessment is to make sure that all affected parts of the organization, inside and outside the organization, is ready for a change that is about to take place within the organization. Effective communication is the key element in informing the organization that a change is on its way. The communication plan should include a description of the change, why this change is necessary and being made, how it will impact all the parts (business units) of the organization and the necessary steps of organizational change to prepare for the change. When the change is big enough, simple communication may not be enough to prepare the organization for the change, and training requirements need to be identified.

External Initiated Change

Sometimes a change is initiated by an external organization or agency that impacts your organization. This may be a customer, supplier or business partner that makes a change for their organization that impacts yours; such as they change a system interface you use to get information to or from them, or they change a business process that impacts your processes. Sometimes this is a regulatory agency that enacts a new legislation or guideline that your organization must conform to. This mostly impacts organizations in heavily regulated industries such as financial services, pharmacy or biotech.

Internal Change Affecting Others

Your organization may make a change of its systems or operations that affect your customers, suppliers or business partners. Your communication plan must extend beyond the walls of your organization; you must inform your business partner(s) of the upcoming change, timeline and the expected impact upon their organization.

Internal Change Affecting Only Your Organization

Then there is the change that affects only your organization. Whether this is a system change or operational change, effective communication throughout the organization may determine the success or failure of the change. It may not be that the solution or change was bad or inappropriate for the organization, but the acceptance of the change was not successful. This could simply because affected business units were not informed or prepared for the organizational change; or possibly just not prepared in time for the change.

Elements of the Organizational Readiness Assessment

When assessing the readiness of the organization for an upcoming change, you must assess the organization’s culture, operations and impact of the change on the organizational units. Proper assessment of these elements will give a full picture of the state of the organizational preparedness to make the necessary change to use the new solution.

Culture Assessment

Assess the beliefs, attitudes and feelings of the affected people within the organization and their willingness to accept the proposed change. The goal of this assessment is to determine whether the affected people understand the reason for the change, whether they believe that the change will be beneficial to them and the organization, and they understand why the change is required. So, in general, you trying to determine if the people affected by the organizational change want this change to be successful.

Operational Assessment

Assessing the organization’s operations determines whether the organization is able to take advantage of the new capabilities of the change, and evaluate whether the people within the organization are prepared to make use of the new solution. Determine if training is necessary and has been performed, whether new policies or procedures have been defined, whether IT systems are in place to support the new solution are in place, and whether the solution is capable of performing at the required level to give the organization the expected benefit.

Impact Assessment

Impact assessment assesses whether the people within the organization understand how the change will affect them. Some things that need to be examined are the functions, location, tasks and concerns of these people and the impact of the change on these things.

Transition Requirements

From this organizational assessment you may be able to identify transition requirements; capabilities needed to get from the current state to the new solution. Once the new solution is implemented these capabilities are no longer needed. Training is such a capability. Training on a new or enhanced system, new procedures or business process may be necessary, but once everyone affected is trained continual training is not necessary. For a system migration, it may be necessary to migrate data from the old system to the new system. Once the data is transferred, it will not be necessary to perform that function again. You may have manipulated servers or system communication channels to move that data more easily and quickly. Once the data is migrated, you may remove those capabilities.

Implementation Plan

The organizational assessment may identify transitional requirements, and these may become part of the Implementation Plan. The implementation plan is the plan for implementing the new solution, or how we get from current state to the new solution. The implementation plan will identify the culture, operational, systems and stakeholder changes that must be made to make full use of the capabilities of the solution being implemented. This is the essence of the organizational change; the execution of the implementation plan takes the organization from its current state through the changes necessary to prepare for the main organizational change to take place.

Conclusion

Changes within organizations aren’t just made, they are planned then executed. Assessing the state of the organization and the steps the organization must make, on a culture, operational, technical and stakeholder impact level is necessary to ensure that the organization will gain the most benefit from the new change solution. Proper organizational readiness assessment will help ensure that the organization is prepared to implement a new change solution for the organization and take full advantage of the new capabilities of that solution.

Don’t forget to leave your comments below.

What is your Business Analyst Brand?

Written by Aaron Whittenberger on May 25, 2015. Posted in Articles. 1 Comment on What is your Business Analyst Brand?

I give complete credit for this article to Bob “the BA” Prentiss. I had to privilege and pleasure of hearing his keynote address to the Southwest Ohio Business Analysis Regional Conference (SOBARC), hosted by Cincinnati IIBA Chapter. It was a very entertaining and thought provoking presentation. So I invite you to consider “What is your BA Brand?”

Did you know that you had a brand? What is a brand? Many think it is a marketing tool that companies use to sell their products and services in the marketplace. Absolutely correct; don’t you think that Apple, Google, B2T Training, The Solarity Group, Bob the BA, and Watermark Learning have brands?

However did you know that you, an individual Business Analyst in your company, have a brand? What is your brand? The more important question, what do you want your brand to be?

These are the questions that Bob “the BA” Prentiss asked us at the recently concluded SOBARC conference during a very inspirational keynote address. He gave excellent tips on how to brand yourself and make yourself distinguishable among the business analysts in your organization.

One thing that impressed me during Bob’s presentation is that he never went up on stage; he delivered his entire presentation walking among the audience. When he asked the audience “What do you think about Bob the BA?” He received the joking answer “pushy”. He did not get upset, but rather took a negative and turned into a positive. He continued to discuss how we from time to time have to change the mindset and the way of thinking of some of our business and technical stakeholders to create that “shared vision”. Ending that thought with “sometimes pushy, yes I can accept that because sometimes that is what it takes to get the job done”.

So, did you know that you create your brand every day at work? So what is your brand, and what do you want it to be? As ‘Bob the BA’ puts it “Be consistent, creative, memorable, have a signature that ‘you’ cocktail…” is how you develop a great brand.

So are you consistent?

Do you consistently deliver your work deliverables on time? Early? Late? Do you “own” your work assignments? How do you want to be remembered? What is the impact to your projects and service work? Can your teammates count on you to deliver? Do you communicate to your Project Manager and other team members to properly set expectations? How is the quality of your work? That will be remembered, possibly most of all. Do you take extra time to put the professional touches, add that craftsmanship, on your work before sharing it with the team? Just a word of caution, don’t allow the professional touches make your work consistently late.

Are you creative?

Do you just take a template for an artifact and fill it out? Have you ever added something to a template? Have you ever questioned why a particular section is in the template, or challenged that it should not be in that place or in the template at all? How creative are you on your business analysis techniques? Do you just do typical individual or group interviews (discussions with business stakeholders)? When is the last time you facilitated a brainstorming or wireframing session?

Are you memorable?

Six months after a project ends, will the business stakeholders remember you as the business analyst that worked on that project? What will they remember about you? Will they say “typical BA”, “nothing special”, “shoddy workmanship”; or will they say “excellent BA”, “knows their stuff”, “kept me engaged”, “enjoyed working with them” or other favorable feedback on your work. How will you be remembered?

Are you passionate?

Do you enjoy your work and does it show in your daily work? Are you passionate about the BA role? Do you look forward to going to work every day? Will feedback come back that you’re a passionate BA? Do you go that extra mile for your business stakeholders and other team members? How will you be remembered?

The Message

I recently attended an IIBA meeting in Dayton, Ohio entitled “Craftsmanship for Analysts” by Terry Wiegmann. The message was the same as Bob the BA’s message: “Cocktail your brand”. Continuously improve, but stay consistent in your message and work. I don’t intend to take anything, or keep anyone, from seeing either of these professionals speak. In fact, I encourage anyone that has the opportunity to go participate in any of Bob or Terry’s presentations, do so; you will receive a lot from the experience.

Did this post get you thinking about your brand, and your daily work? How will you change to make your brand what you want it to be?

Don’t forget to leave your comments below.

Process Approach to Requirements Gathering

Written by Mani Ramasarma on May 4, 2015. Posted in Articles.

This blog was supposed to be on requirements elicitation techniques, but it ended up being an example of what peer review does. I finished my blog and handed it over to my colleague for feedback. He pointed out that I assumed people knew how to gather requirements for them to start using the techniques mentioned in the blog. In other words, the blog on techniques was a step ahead, and I should first explain the approach. Ouch! The bump on my head still hurts. So, here we go.

I interview many candidates. Whenever I ask “How do you approach requirements session?” the answers invariably include something akin to “I use JAD session” or “I shadow users”. JAD (Joint Application Design), shadowing, interviewing, and brainstorming are techniques used AFTER you have an approach. Think of it this way. You decide to go on a vacation. How do you approach it? You don’t start with “I will drive” or “I will fly”. These are ways (techniques) by which you reach the destination. The first thing you need to do is decide where to go, when to go, and how to go (approach). The series of steps you take (approach) has to precede the decision to drive or fly (technique). There is a very fine difference.

So, how do we plan an approach to a requirements gathering session? Do we call for a meeting and ask the business user “ok, so what do you want?” or “I am ready, go ahead and list your requirements?” Don’t be surprised if you get a very lengthy grocery list! To avoid such mishaps here is a process-based approach to requirements gathering.

The first point in my last blog was “Do your homework”. The first step as part of homework is to understand the organization and the unit. This understanding provides the big picture so that the goals of the requirements that are to be gathered align with the goals of the organization and unit. Next is to understand the business under consideration, and the scope of the system being worked upon. There are many avenues to it. One of them is to get hold of an AS-IS process diagram.

Start from a high-level process. Some call it “Level 0” or “L0.” Drill down from here to the lowest level possible – L1, L2, L3 and so on (do not confuse this with support levels). Normally you would achieve this by L3 or L4. If AS-IS diagrams don’t exist, your task is to create them.

A mature organization typically has all the “as is” processes documented. Go over it. Go over any other document related to the system that may be available – business bequirements focuments (BRD), functional specifications documents (FSD), user manuals, data flow diagrams (DFD), entity relationship diagrams (ERD), and DDD (sorry, I just created that one!). Get access to the test system and play around in the sandbox – see what it does, see what it doesn’t do. Talk to the technical people. Sometimes they know more about the business than the business users themselves. Ask for a walk-through by technical and/or business folks. If you have a knowledgeable lead, talk to them. By now you should have a good understanding of the way business is conducted. As you assimilate information, note things that don’t seem right. Always remember your title – Business Analyst – so make sure that you are always trying to analyze as you proceed.

Armed with enough knowledge, proceed to capture the “to be” process. Remember, you are documenting only the “to be” process and not the requirements. A common pitfall is to embed requirements in process documents. Be sure to avoid it.

Make a copy of the “as is” process and mark bottlenecks, pain points, workaround’s, manual processes, and non-value add processes. See if you can measure lead and lag times between points in the process. All the current weaknesses should be resolved in the “to be” process in addition to any new functionality or change in the process itself. Beware not to resolve a process inefficiency by automating it. You will be automating inefficiency.

Again start from Level 0 or L0. Make necessary changes. Each of the tasks define your high-level requirements. Here is an example of a L0 procurement process in a bureaucratic organization

Use the gathered requirements to prepare your high-level BRD.

Each of the boxes can further be broken down into next level processes. For example, the first task can be decomposed into

Again, each of the tasks can further be elaborated (here is a buzzword for the interviews – Functional Decomposition). Here is what it may look like, assuming that we go all the way to the lowest level possible (do not magnify the picture. It is there for illustrative purpose only):

At each level look for opportunities to eliminate both the deficiencies (what is missing) and the inefficiencies (what isn’t needed) in the current process. Keep this maxim in mind while redesigning processes – the shortest distance between two points is a straight line. A straight line is not always practical or feasible, but use it as a guideline to streamline the processes. Even if you manage to eliminate or refine one or two steps, it can result in significant time and cost savings.

The hazy little light blue rectangles in the diagram above specify the system that performs that particular task. The diagram also includes manual tasks, reports, and emails. Check if you can automate manual tasks, and whether consecutive manual tasks can be replaced by a workflow. Again, do not automate inefficient processes. Deal with reports separately. Once the “to be” process is documented, have it validated by the business users. Validation is mandatory. It is so mandatory that I will say it again – it is mandatory to have these “to be” processes validated and approved by the business users. What you are left with is a bunch of tasks at the lowest functional level. It is for these that you need to gather functional requirements.

There is one more step you need to do before diving into the requirements gathering process – organize a requirements elicitation kick-off session. Invite business users and the technical team members. Highlight the importance of requirements, characteristics of a good requirement, what has been achieved so far, next steps, and the need for continued user participation and cooperation. The most important component is listing and explaining a good requirement. What are the characteristics? Here is a website that explains it really well. (The next blog will address this and requirements gathering techniques). There are some good examples on the website of how not to write a requirement, which is equal in importance to how it shall be written (a touch of BA humor there!).

The following diagram summarizes the approach

We are ready to launch into the requirements gathering process. That bump on my head is now better.

Don’t forget to leave your comments below.

Business Analysis According to Sherlock Holmes

Written by Steve Blais on April 28, 2015. Posted in Articles. 1 Comment on 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?

Written by Angela Wick on April 28, 2015. Posted in Articles. 2 Comments on 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:

Or they get chucked out in the rain like this:

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:

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?

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.