Skip to main content

Tag: Methodologies

Best of BATimes: 10 Best Business Analysis Books For Beginners

Corporate analysis is a discipline in which business requirements are defined, and solutions are identified for business issues.

 

For an organization to thrive and function successfully, some things need to be placed during its foundation. Here are some books that can be of assistance.

 

1.   Writing Effective Use Cases (Agile Software Development Series) by Alistair Cockburn

Business analysts profit from case studies where they talk about how people use a system. This helps in planning projects and use cases is a crucial feature of business and software systems. The problem is that it is not so easy to write straightforward and succinct cases. Author Alistair Cockburn utilizes modern methods to write case stories in this novel.

You can learn about advanced principles that are useful, whether you are an experienced analyst or a novice. Cockburn presents strong and bad case examples to help you quickly and rapidly understand the difference. The main aspects of situations, like stakeholders, scenarios, etc. Design, moment tips, pre-built templates can be utilized.

 

2.   Business Analysis Techniques: 72 Essential Tools for Success by James Cadle

Every analyst needs the necessary resources to accomplish the job. The work involves solving problems and exploring ideas. You need to know how to solve various types of problems, like identifying project specifications or handling changes.

This book describes these strategies carefully in order to help the reader deliver reliable results in business work. Think about it as a market analyst, a manager, or a student who is learning the trade, as a cheat sheet you can talk about.

 

3.   Project Management Absolute Beginner’s Guide (3rd Edition) by Greg Horine

You have just started working as a project manager? In this book, you can easily and rapidly grasp key concepts by disrupting vital project management activities. You can learn how to organize and manage budgeting, planning, team management, and more. Each phase is outlined so that you can start right away.

The guidelines are simple and convenient. You will discover that the project managers make daily errors to avoid taking the same route. You can also understand what heading projects entail instead of merely overseeing them. If you do not know how to begin your job or your career, take this book to learn what you need quickly.

 

4.   Project Management: A Systems Approach to Planning, Scheduling, and Controlling by Harold Kerzner

This is referred to as the Project Management Bible” since it offers practical insight into all facets of becoming a project manager. At all levels of a project, you can learn the techniques and methods to use. But it’s more than tips in this book. This text covers market changes, failure, agile project development, evolving industry topics, and project measurements.

There are just a few components that can limit performance in project management. This book is not a guide to project management, which is easy. There are plenty out there. When you want to know information about project management, quality assurance, and customer cooperation, this is the book you need to collect.

 

Advertisement

5.   Business Analysis for Dummies by Kate McGoey, Kupe Kupersmith, and Paul Mulvey

Business Analysis (BA) is a group of activities that ensures that the company has the best solutions to achieve its strategic objectives. In order to carry out this workforce, it is important first to define the actual objectives and evaluate and propose solutions for a solution that needs to be addressed.

Provide guidelines as to how the market analysis will influence your company. Shows the tools and strategies to be a competent analyst. Provides many examples of how to market evaluations can be carried out irrespective of your position.

 

6.  Adaptive BABoK Study Guide  by the Adaptive US

BABOK® summary graphically represented to enable simple, engaging learning of concepts and practices of business analysis. However, a visual presentation and a summary of this information are effective for you to learn. BABOK® guide includes a large amount of structured text information.

 

7.   3D Business Analyst  by Mohamed Elgendy

Three distinct fields of 3D Market Analysis – business analyzes, project management (PM), and lean 6 sigma – with historically different skills and career paths. When, however, the components of these skill sets are analyzed and understood, a simple overlap is generated. When used together, they provide the BA with the required concepts, theories, and ends so that it can interact more effectively with stakeholders in its own language.

 

8.   Agile and Business Analysis: Practical Guidance for IT Professionals  by Debra Paul and Lynda Girvan

Agile is an iterative approach to software development that has quickly become the most common replacement for conventional project management in the IT industry. The use of an agile approach will revolutionize work practices for business analysts. It allows for a clearer vision and definition of performance steps, greater participation of stakeholders, and a better understanding of consumers.

 This book offers an extensive introduction and discusses Agile methodologies in the sense of market analysis—ideal for companies wishing to learn and understand Agile Practices in an Agile Environment.

 

9.  Business Analysis: Best Practices for Success by Steven Blais

A full overview of the business analysis method in addressing business issues is given by this book. This guide is also full of real-world stores from the author’s more than 30 years of experience working as a market analyst, full of tips, tricks, methods, and guerrilla tactics that allow the entire process to face often daunting political or social obstacles.

  • It offers strategies and advice to conduct a business analyst’s challenging tasks at times.
  • Authored by a professional in the sector with 30 years of experience.

 

10.   Seven Steps to Mastering Business Analysis by Barbara A. Carkenord

Business analyzes are now the fastest growing sector in business and both strategically and tactically the position of the business analyses. Seven steps to mastering business analysis illustrate how all these variables, along with many others, are the secret to success.

This book offers insight into the ideal skills and features of good market analysts and is the basis for the learning process. This guide also allows you to prepare for enterprise analysis certification by describing the tasks and fields of expertise in the Knowledge Body.

 

Conclusion

Businesses form an important part of a state. Encouraging young people to venture into business only increases employment opportunities. Through business books, this becomes an attainable goal as they offset with their best foot forward.

 

Published on December 3, 2020.

Best of BATimes: 7 Warning Signs that You Are Too Soft

Simple question: Do you believe that you tend to be too soft at work?

 

What I mean by too soft is demonstrating behavior that results in being consistently less effective than what is otherwise possible—and needed—in performing responsibilities.

Whenever I ask this question at conferences, seminars or webinars, most people respond with a “yes.” From experience, I have found most project managers and business analysts, indeed, to be too soft—they are not willing to make the tough and unpopular project- or business analyst-related decisions, even though their instincts warn them that they are not taking the most effective action.

Being too soft harms your effectiveness, your career, the respect from others and your ability to make a difference and make things happen.

Examples of Too-Soft Behavior

Here are seven examples of too-soft behavior. Do you see yourself here? If so, this article may cause you to leave your comfort zone.

1. You behave as if you have the responsibility but without the authority

If you behave as if you have the responsibility but without the authority, then you’re too soft. I do face time with thousands of people each year. I frequently hear project managers and business analysts say that they have the responsibility but not the authority. This just isn’t true. You almost always have the authority; the problem is that you don’t take it.

Here’s an example. When was the last time you were called on the carpet—challenged—for exceeding your authority? Was it within the last week? The last month? The last year? Was it ever? My experience is that less than 15% of people in a large group—a statistically valid size group—have ever experienced being confronted for exceeding their authority. This is sad to me. But what is sadder is that, statistically, most people reading this article will never experience being called out on exceeding their authority across their entire career! My assertion is that you almost always have the authority—you just don’t seize it… you’re too soft.

2. You put off insisting on and driving good project management or business analyst practices

Whether I’m in a public setting or at a private company, it’s common for PMs or BAs to approach me for advice about their project problems. During the discussion, many times it’s relevant for me to ask about the project management or BA practices that they follow. I often hear them say that the practices they follow are weak and insufficient. They will state or imply that management in their organizations isn’t doing enough to provide and continuously improve the practices.

I’ll ask them what their role on the project is and they will tell me that they are the PM or a BA. If you are in either of these roles, then insisting on and driving good practices is your job. Not management’s. Not anybody else’s. It’s your domain of responsibility. You can seek help if you need to but the buck stops with you. If you do not insist on reasonable practices then you’re too soft.

Advertisement

 

3. You complain rather than constructively work issues to closure

I don’t believe that you should ever complain about anything—ever! Complaining is negative energy and adds no value to solving the issue at hand. People who complain are exhibiting too-soft behavior by averting truly getting the problem fixed. But make sure you understand what I mean by complaining. An example of complaining is when person A complains to person B about something that person C can fix. In this case, person A just wasted his time and person’s B’s time. However, if person A “complains” so-to-speak to person C—the person who can fix the problem—then this is not complaining to me. This is the first step of the solution by informing the person who can do something about it.

4. You evade taking a position on issues

If you evade taking a position on an issue, you’re too soft. A role of leaders is to help resolve conflict among team members. They take appropriate business-based positions on issues even if it doesn’t please all parties. Let’s look at an example.

I was mentoring Sarah who was a project manager of a sizeable project. We were walking through a hallway heading to a room where a meeting was soon to take place. We come upon two team leaders—Laura and Larry—discussing an issue in the hallway. Actually, discussing is too kind of description; they were angry at each other and loudly protesting the other’s views. Upon seeing this, Sarah leaned in to me and asked if I would mind if we join in on their discussion. Sarah said we have a few minutes before we must be in the meeting room. I said that that’s a good idea and we joined the two team leaders. After standing with the two team leaders and listening for a few minutes, Sarah turns to me and said we have to go; she did not want to be late for the meeting.

Once we were out of hearing range of the two team leaders, I asked Sarah why she didn’t say anything back there to help resolve the conflict. Sarah said if she had sided with one team leader then the other team leader would have been upset with her. I said that’s not how it works. Besides you now have both people upset with you because you did not assert your authority and help find an appropriate resolution. I went on to tell her if she sided with Laura and that left Larry upset with her, that’s not her problem—it’s Larry’s problem. I said never avoid taking a position because you fear that someone won’t like you. This is business, it’s not personal. Decisions are made based on what’s in the business’ best interest; not what’s in Larry’s best interest. Here again, Sarah was too soft in dealing with this situation which meant she was not as effective as she could be and should be.

5. You avoid or excessively delay making key decisions

Decision making is a critical action in any team, project or organization. We all have experienced instances where we felt decisions were being made far too slow. Make sure that you aren’t the problem. If you avoid or excessively delay making key decisions then this is another example of demonstrating too-soft behavior.

If you wait to make a decision until all data is known to ensure that you are making the very best decision, then you will lose all competitiveness. Better to make a decision and occasionally be wrong, then make no decision or excessively delay in making the decision.

6. You fail to perform your assignment as if you own the business

When you look around you for the people who you respect the most, they are likely folks who come to work each day with the mindset that they perform their duties as if they owned the business—and the business is defined by their domain of responsibility. If you have ever owned your own company, you will know exactly what I mean. You cannot put food in your belly or pay your bills unless you are successful. It’s this passion that helps people achieve their best. These are people who make things happen.

They believe—and their actions demonstrate—that the buck stops here and that they are fully accountable for the project or their assigned domain. Your boss and your senior management want you to take charge over your domain of responsibility with the passion that comes about when you behave as if you owned the business. If you hesitate or routinely pull back then, again, you are demonstrating too-soft behavior.

7. You require the personal approval of others to function

You are too soft if you personally require the approval of those around you to function from day-to-day—and without it you feel inadequate—then you will likely find their behavior to have an immobilizing effect on you; it can stop you in your tracks. Don’t ever give that kind of power to another person. What other people think of you should never be more important than what you think of yourself.

In Closing…

I have revealed seven examples of too-soft behavior. If you routinely exhibit these too-soft behaviors, then you’re clearly too soft—you tend to take the easy way out rather than do the right thing by demonstrating the most effective behavior. If you only occasionally slip into this behavior, then that may not be a serious cause for alarm.

If you fear that not being too soft will cause you to be “too hard” and therefore you will be seen as being rude, insensitive, abrasive, arrogant or a bully… don’t go there. You are a good and decent person and will not give way to these behaviors.

 

You might be asking yourself if an upside of demonstrating too-soft behavior is that you might win friends and respect? After all, if you are consistently too soft, those you work with will see you as very easy to get along with and passive—you’re always rolling over and abdicating to others. The problem is that if you’re a leader and are consistently demonstrating too-soft behavior, you will lose respect from those you lead, and from your peers and from your superiors. Being too soft will also have a negative effect on your project’s outcome because the best business decisions are not always made or made in a timely manner. All this can lead to your career becoming stagnant or even shortened.

Now, go become your imagined self!

 

Published on February 28, 2017.

Factors Impacting Analysis

As Business Analysts, we are experts at defining good quality requirements and processes that enable the implementation of solutions which are fit for purpose and deliver the benefits from the business case. We may have several Business Analysis qualifications and many years’ experience working on all types of projects, from simple process changes to complex technical overhauls with multiple integrations, data migration and significant business change elements, and everything in between.

Yet our skills are just one of the many components that enable us to do our job well. There are some other factors which we don’t have much control over but which are also hugely important. We need to be aware of them and should consider them upfront and throughout the delivery of our projects to set ourselves up for success. Unsurprisingly, they can all be grouped under communication within project teams and organizations’ delivery standards and processes.

 

  1. Consider the delivery model

Are the delivery frameworks from your organization and any third party you are working with aligned? Organizations tend to have slightly different definitions of the same terms, for example “delivery phase”. Does the delivery phase consist purely of coding and configuring what has been defined in great detail in previous, distinct analysis and design phases? Or will the delivery phase also include collaborative sessions at the start where technical teams, BAs and users flesh out these details together?

 

  1. Consider roles and responsibilities

This is particularly important in organizations which have a high staff turnover, use many contractors or employ staff on short, fixed term contracts. The execution of testing can be a grey area for example, particularly User Acceptance Testing (UAT). Who is expected to write the test scripts? Is it the Tester(s) on your project, the business Subject Matter Experts (SMEs), or even yourself?

 

  1. Consider the experience from other key roles within the project team

Do the Project Manager and other key roles within the project team have a good understanding of the role BAs play, what we do and don’t do? For example, do they know that BAs need to be present in all meetings with the users and technical team(s) where the scope is discussed? Or that we cannot make an on-the-spot decision about the validity of a change request, such as descoping an area of functionality because of new budget constraints, without assessing the impact on the processes and the integrity of the solution overall?

 

Advertisement

 

  1. Consider the project plan

How will the project plan be produced? Do you need to do some “right to left” planning, because the go-live date can’t be moved, which is common on a lot of commercial or regulatory projects, or can you estimate the duration of each phase before agreeing on a go live date?

In the first scenario, you will need to timebox each activity and almost certainly compromise on some elements of your analysis. In both cases you need to really think through any assumptions which are being made around the effort required to produce each deliverable and any dependencies. You should also document any risks you foresee as a result of the approach being undertaken.

One common oversight is the business users’ availability to support the project, which can really hinder progress if not managed effectively. This can range from planned absence, such as annual leave, to having to perform  Business As Usual (BAU) activities no one else can backfill, or supporting other projects which have a higher priority.

 

  1. Consider the project governance

Does your organization have well defined processes to govern the decisions required around the different project milestones and the challenges you will meet in the course of the delivery? For example, are you clear on the documentation that you need to produce, or contribute to, at each stage gate? What is the change control process you need to follow when a new requirement emerges after the requirements catalogue has been baselined?

 

  1. Consider the Sponsor’s role

Sponsor engagement, and the BA’s access to the Sponsor, are critical to the success of the project. Are you able to have one-on-one meetings where you can speak openly to update them or seek guidance when you are uncertain about the direction you should follow? Does your Sponsor know the level of involvement they need to have so that they support you, the Project Manager, and the delivery of the project, without interfering with the methodology or the due diligence required, for example?

Conclusion

There are no simple answers to these issues. Every organization has its own culture, and each project team has specific dynamics.

However, identifying them as early as possible means that you can prepare for them and address them effectively within the constraints that you operate in, even if it means you’re not able to follow best practice. When dealing with these challenges, regardless of your level of experience, you will achieve something much bigger than the delivery of your project.

This may be learning something new about the way that you communicate, educating your colleagues about the role of the Business Analyst, or even instigating an improvement in the way in which your organization delivers change.

Soft Systems Methodology for Business Analysis

Soft systems methodology is an approach that an analyst can embrace when phasing messy and complex problems. SSM is a way of organizing, thinking and learning in a problematic situation.[1] [2]This methodology allows the observer, faced with a vague and unstructured problem situation, the possibility to approach as holistically as possible, concentrating, combining and co-housing all existing perceptions and to suggest ways to improve the existing situation.

Business Analysts can use Analysis with SSM before the analysis and design of an information system begins (i.e. before using UML or a traditional structured development methodology).

 

The Methodology

A basic pillar of the methodology is the distinction between the real world and the systems thinking about real world. The methodology recognizes the complexity of the modern world and tries to reconcile the mental models we try to construct to simplify the world with the real needs and environment upon which any change will be implemented.

In addition to eliciting the perspectives from different stakeholders, it is also important to investigate different perspectives of the problematical situation.

This involves analyses of:

  1. The intervention, including the actors involved,
  2. The socio-cultural context including roles, norms and values and
  3. Existing power structures

The following diagram depicts seven-stage model of SSM (adapted from Checkland & Scholes, 1990, p. 27)

 

We can group the activities in the real world versus the activities in systems thinking.

Ιn real world:

  • First: we learn/analyze the problematic situation
  • Ultimately: we intervene with the aim of bringing about improvements

Systems thinking include:

  • Identifying relevant systems of human activity with ‘key definitions’
  • Creating mental models from the basic definitions

 

Tools

1st Step:

To understand the complex problem situation we use the rich image.

Emphasis is placed on illustrating the following:

  • roles in the system and views,
  • disputes and controversies,
  • system limit,
  • elements of the environment

An example of rich image is given below:

Source: elabor8.com.au

 

Advertisement

 

2nd Step:

In the next stages of the methodology (systems thinking) we create basic definitions and then a mental model of the system.

The basic definition can follow the following structure:

  • Do P by Q in order to contribute to achieving R” (P = what? Q = how? R = why?)
  • CATWOE is a good way to think holistically about actors.[3]

A mental model is an explanation of how something works. The phrase “mental model” is an overarching term for any sort of concept, framework, or worldview that you carry around in your mind.[4]

The following diagram represents the structure of a simple mental model.

 

3rd Step:

Finally we return to the “real world” for the last 3 stages of the methodology, aiming to make effective changes to the problem situation.

Collaborative learning is achieved through the SSM process.  Development of shared meaning and understanding across individuals and groups are enabled and can ensure faster requirements elicitation and more precise requirements that will add value to the different stakeholders.

 

Conclusion

The internal and external conditions are complex, interdependent and unique. Either the change of only an internal or external component creates a different dynamic and a different system and may trigger a chain of events that can affect indirectly other components. The “Ceteris paribus” assumption in some microeconomics models seems to be utopia in the modern business environment. Systems thinking and the holistic approach are basic characteristics for effective conduction of business analysis. SSM encapsulates the systems thinking mindset and can be a useful methodology in the pre-analysis and/or early analysis phases.

 

[1] Checkland P. Systems thinking, systems practice. Chichester: John Wiley and Sons; 1981
[2] Checkland P, Poulter J. Learning for action: a short definitive account of soft systems methodology and its use, for practitioners, teachers and students. John Wiley and Sons Ltd: Chichester; 2006.
[3] CATWOE Analysis: A Holistic Approach to Problem Solving – SlideModel
[4] Mental Models: Learn How to Think Better and Gain a Mental Edge (jamesclear.com)

The 6 Most Important Requirements Practices

Authors sometimes make things longer and more complicated than necessary. Some readers might feel that I’ve been guilty of this myself. The third edition of my book Software Requirements, co-authored with Joy Beatty, is about 245,000 words long, nearly 640 pages in a rather small font. Maybe that seems like overkill, but to be fair, the requirements domain is large and complex.

Books like Software Requirements, Mastering the Requirements Process by Suzanne and James Robertson, and the IIBA’s Business Analysis Body of Knowledge describe dozens of valuable techniques for requirements elicitation, analysis, specification, validation, and management. They’re all useful when thoughtfully applied in appropriate situations. But if you don’t have time to wade through these large volumes, you might like this TL;DR version of the six most important requirements practices that every project team should perform. This article is adapted from Software Requirements Essentials: Core Practices for Successful Business Analysis by Karl Wiegers and Candase Hokanson.

 

Practice #1: Define Business Objectives

Organizations undertake a project to solve a problem, exploit a business opportunity, or create a new market. Defining the project’s business objectives communicates to all participants and other stakeholders why they are working on the project. The organization could hope to achieve both financial and non-financial business objectives with the new product. Try to quantify the business objectives, and make them measurable, with statements like these:

  • Capture a market share of X percent within Y months.
  • Reach a sales volume of X units or revenue of $Y within Z months.
  • Save X dollars per year currently spent on a high-maintenance legacy system.

Using business objectives aligns all of the team’s work and key decisions. Without defined business objectives, you can’t craft a clear product vision statement or establish the scope of either the entire project or any development increment. The team can’t make good decisions about scope changes or proposed functionality unless they know how those changes match up with the business objectives.

Keeping the scope in focus helps the team avoid scope creep while still adapting to changing business realities. And how can you know if the project was a success unless someone defined its business objectives and success criteria up front?

 

Practice #2: Understand What Users Need to Do with the Product

I strongly advocate taking a usage-centric approach to requirements development and solution design, rather than a feature- or product-centric approach. Understanding the tasks that users need to perform and the goals they want to achieve lets the business analyst (BA) derive the functionality that developers must implement.

When you focus on exploring features rather than user goals, it’s easy to overlook some necessary functionality. It’s also easy to include functionality that seems cool but doesn’t help users get their jobs done. Use cases are an effective technique for maintaining this usage-centric mindset.

Seeking to understand what users need to do with the product implies several other important BA activities, including these:

  • Identifying a wide range of project stakeholders
  • Characterizing distinct user classes that have largely different requirements
  • Identifying individuals to serve as the voice of the customer for each user class (product champions)
  • Selecting appropriate requirements elicitation techniques to engage with users
  • Establishing decision-making processes to resolve conflicts and priorities across user classes
  • Building and evaluating prototypes or early releases to stimulate user feedback

 

Advertisement

 

Practice #3: Prioritize the Requirements

I doubt that any project has ever implemented every bit of requested functionality. Even if you could implement it all, you can’t do it all at once. Your goal is to deliver the maximum business value to your customers at the lowest cost and in the shortest time. Achieving this goal demands that you prioritize requirements so the team can work on them in the most appropriate sequence.

Prioritization involves considering how much each proposed requirement contributes to achieving the project’s business objectives. Prioritizing requirements lets the team decide which of the work items remaining in the backlog to defer or omit because of time and resource constraints. There are numerous requirements prioritization techniques available, including these:

  • In or out
  • Pairwise comparison and rank ordering
  • Three-level scale
  • MoSCoW
  • Relative weighting
  • $100 test

Some of these methods take more effort than others, but those methods also help the project manager or product owner make finer-grained choices. Choose any technique that lets the right stakeholders make good business decisions throughout the project to avoid a frantic “rapid descoping phase” late in the game.

 

Practice #4: Explore Nonfunctional Requirements

People naturally focus on a product’s functionality when discussing requirements, but those are only part of the solution. Nonfunctional requirements contribute heavily to user satisfaction and suitability for use. When speaking of “nonfunctional requirements,” people most commonly think of quality attributes, sometimes called the “-ilities.” These product characteristics include usability, maintainability, security, reliability, and many others. To help designers devise the most appropriate solution, BAs need to discuss nonfunctional requirements as part of requirements elicitation.

Developers generally don’t directly implement requirements that describe safety, reliability, portability, security, or other characteristics. Instead, these attributes serve as the origin of many functional requirements and drive design decisions. Table 1 indicates the likely categories of technical information that different types of quality attributes will generate.

 

Table 1. Translating quality attributes into technical specifications (from Software Requirements, 3rd Edition)

Another challenge is that it’s not possible to optimize all of the desired quality factors at once. Designers must make trade-off decisions among the various attributes. Therefore, the team needs to determine which ones are most important to customer success and optimize those. Carefully specifying quality attributes lets you build a product that delights its users, beyond merely doing what it’s supposed to.

 

Practice #5: Review the Requirements

How do you know if your requirements are accurate? How can you tell if they’re clear enough so all the team members know what to do with them and other stakeholders know what to expect in the solution? No matter how you choose to represent requirements knowledge, it is sometimes ambiguous, incomplete, or simply incorrect.

One of the most powerful quality practices available is peer review of requirements. Convene some colleagues to review both textual requirements and diagrams. Different project participants—BAs, designers, developers, testers, users—will find different kinds of problems during these reviews. Requirements reviews pose some particular challenges. Rather than simply inviting people to look over the requirements, provide some training so reviewers know how to participate effectively and can find as many issues as possible.

A related requirements validation practice is to write conceptual tests based on requirements. Testing requirements is something you can do early in each development cycle to reveal many errors before they are cast into code. Requirements and tests are complementary views of the same knowledge. Requirements describe how the product should behave under certain conditions; tests describe how to tell if it’s exhibiting the correct behaviors.

 

Practice #6: Plan for Requirements Change

No matter how well you understand the problem and how carefully you prepare the requirements, they won’t be perfect, complete, or static. The world changes around us as we work. New users and new ideas appear. Business rules surface and evolve. Projects inevitably grow beyond their originally envisioned scope. Every team must anticipate requirements changes and establish mechanisms for dealing with them without derailing the team’s commitments.

When you know the project outcome is incompletely defined and likely to change a lot, an incremental, agile approach is a good way to cope with it. You plan to build the requirements—and the solution—in a series of small chunks, expecting the direction to change and accepting the uncertainty of what you’ll have at the end and when you’ll have it.

 

When the likely degree of change is less extreme, plan to accommodate some growth (along with risks, imprecise estimates, and unexpected events) by building contingency buffers into development schedules. Establish a requirements change process so the right people can get the right information to make good business decisions about which proposed changes to incorporate to add value with minimal disruption.

Don’t use the expectation of change as a justification for skimping on requirements thinking, though. Excessive requirements churn often indicates that objectives were unclear or the elicitation approach wasn’t effective.

 

Neglect These Practices at Your Peril

Of course, there are many other valuable requirements activities besides these six. However, these practices greatly increase your chances of building a solution that achieves the desired business outcomes efficiently and effectively. Applying them doesn’t guarantee success for any BA, product owner, or product manager. But neglecting them likely ensures failure.