CHAPTER 3
The Adaptive Business Analyst

To understate the obvious, business analysis is a difficult and risky business. Ideally, we would like to get a clear and thorough picture of the business need before we obtain customer sign-off on the requirements, begin developing the solution, and then set up procedures that limit requirements changes following sign-off. However, regardless of the care taken in requirements engineering, requirements are going to change for several reasons:

In acknowledgement of the difficulty of defining and managing business requirements, it is imperative that we discuss three additional concepts relating to how to implement the business analysis techniques we’ve discussed: agile development, the iterative nature of requirements generation and system development (especially for software-intensive systems), and the element of scalability.

AGILITY

Over the past few years, there’s been a rapidly growing interest in agile (aka lightweight) methodologies. Alternately described as an approach to rid IT development of burdensome bureaucracy or a license to hack, agile methodologies have generated interest throughout the world.¹ The emphasis in agile methods differs substantially from traditional, heavyweight engineering methods. The most notable divergence is that they are less document-oriented, usually resulting in less documentation for a given requirement. Moreover, agile methods often spotlight source code as a key part of requirements documentation. Additionally, there are two more fundamental distinctions:

AGILE REQUIREMENTS ANALYSIS

The world of agile analysis challenges business analysts to become the communication mentors and coaches of project teams. To do this, one of the tenets of agile development must be followed: that of active stakeholder participation throughout the project life cycle. The focus of activities changes from finding out what customers want to helping customers determine what they need to meet business objectives.

An obvious enabler of active stakeholder participation is collocation of the business and development team. However, the business community cannot always free critical resources to work with the development team on a fulltime basis. In addition, project teams are often located many hundreds or even thousands of miles from their internal and external customers. In this case, the business analyst will need to conduct interviews and workshops with the business community in its own environment, with key members of the development team present to hear the voice of the customer. These sessions may be face-to-face or remote, using web meetings and video teleconferencing.

What is agile analysis? According to IBM agile and lean methodologist Scott Ambler, the business analyst follows the agile methods outlined above, while incorporating these traits into the analysis:

Ambler presents this definition of agile analysis:

USING AGILE METHODS

So, when is it appropriate to use agile methods? Current thinking suggests that these methods should be used when the following conditions are present; the absence of one or more of these circumstances will likely put the agile approach at risk.⁴

The improved performance resulting from agile methods can be dramatic:

ITERATION

Although other chapters of this book may suggest that the steps of business analysis are sequential, they are unquestionably performed iteratively. Iterating is the best defense when attempting to control an unpredictable process. Incremental, evolutionary, staged, or spiral methodologies are all iterative in nature.

Throughout the requirements phase, the business analyst should facilitate real dialogue that allows requirements to evolve and permits innovative solutions to emerge. Requirements emerge throughout the project (see Figure 3-1).

The business analyst needs to build in candid feedback mechanisms at frequent intervals to show the real status of requirements and solution design. The genius of this approach is that it allows the team to improve requirements and the solution design after each iteration. During the requirements phase, the solution architects work on early iterations of the solution design and prototypes. As the business analyst conducts requirements trade-off analyses, the architect does the same with solution options. Thus, prototyping is the first step in iterative development. These early prototypes are followed by incremental working versions of the final system containing a subset of the required features. These working subsystems possess limited functionality but are otherwise true to system requirements.

FIGURE 3-1. Emerging Requirements

The value of iterative development is found in regular customer reviews and feedback following each iteration. The best validation that requirements have been met is a tested, integrated system. Documents and models often contain undetected defects. When users actually work with a system, flaws become evident, whether caused by a system defect or a misunderstood requirement.

For the project manager, a new approach to planning is essential. Rolling wave planning is the order of the day, where short-term plans cover a single iteration and are quite detailed, while later iterations are planned at only a high level. Iterative development provides a firm foundation in each increment that becomes the basis of later waves of plans.

SCALABILITY

Whether a team uses a light or heavy methodology, it performs all the activities discussed thus far. They are likely to be executed in a broad sense at project initiation and progressively elaborated as the project traverses its life cycle. For small, straightforward projects that are easily understood, a minimal amount of requirements documentation and models is appropriate. Indeed, the rule is the smaller the team, the less formal the documentation. However, for significant, complex, high-risk projects, a full set of approved requirements documentation is in order. For low- to moderate-risk projects, the rigor should be scaled appropriately, applying more formality and structure in the higher-risk areas of the project.

THE RECIPE FOR PROJECT SUCCESS

Whatever the nature of the project, a business analyst can’t go wrong if she remembers to structure the project by following the recipe for success, which is adapted from the Standish Group’s famous recipe: ⁶

Their message is clear: size matters. When structuring a project or major project phases, the project manager and business analyst should strive to follow these guidelines to reduce project risk.

Ingredients:	Minimization, communications, standardization
Mix with:	Full-time core team members: business analyst, project manager, business visionary, and architects and developers, coached by an involved project sponsor
Bake:	No longer than six months, no more than six people, at no more than $750,000. To achieve success more than 80% of the time, the current conventional wisdom is for even smaller projects: no longer than 3 months, no more than four people, no more than $500,000.

UNAVOIDABLE CHALLENGES

Any discussion of the business analyst role is incomplete without addressing the pitfalls of filling this difficult and vital function. The business analyst’s responsibilities are many—she is expected to scope the system, translate business needs for architects and developers, translate technical issues for business representatives, model and document requirements, act as communication broker, serve as political mentor, test and validate the solution (and in general, represent customers, users, and stakeholders)—but the position may be invested with too much power.⁷ In many organizations, the addition of credible and influential business analysts has greatly improved the elicitation and documentation of requirements. However, there are common problems with the role. It pays the business analyst to take heed and avoid these pitfalls:

USING DIFFERENT MANAGEMENT APPROACHES

Does the business analyst role change, either significantly or subtly, in different project management approaches? If so, how? All projects have a cycle, a sequence of stages through which the project passes. Typical cycles are made up of a series of periods and phases, each with a defined output that guides research, development, construction, and acquisition of goods and services.⁸

Project cycle models are not interchangeable; one size does not fit all. As projects have become more complex, project cycles have evolved to address the various levels of complexity. It is important to understand the complexity of your project and to apply the approach that is best suited to manage or reduce that complexity. In addition, the business analyst needs to have a keen understanding of how to operate optimally within each cycle model.

Project cycles can be categorized into three broad types:

Figure 3-2 shows the distinct differences between linear and adaptive methods.

FIGURE 3-2. Linear vs. Adaptive Methods

FIGURE 3-3. Project Complexity Mapped to Project Cycle Approaches

© 2011 By Kathleen B. Hass and Associates, Inc.

As we move along the complexity continuum from simpler to highly complex projects, we also move along the spectrum of project cycle types. A linear approach works for a simple project whereas adaptive and extreme approaches are used to manage the uncertainties of increasingly complex efforts (see Figure 3-3).

THE BEST BUSINESS ANALYSIS PRACTICES FOR LOW-COMPLEXITY PROJECTS

The traditional role of the business analyst as discussed in Chapter 2 does not need to change much for a business analyst to successfully execute activities on low-complexity projects. However, to optimize the business analyst role, it is wise to adopt some of the principles of agile and iterative development:

THE BEST BUSINESS ANALYSIS PRACTICES FOR MODERATELY COMPLEX PROJECTS

There’s no question about it: agile methods expedite the new product development process, especially for products that are software intensive. Agile is a streamlined methodology, based on having only essential people work in tight-knit teams for quick and efficient results. As we’ve seen, one very important member of the team is the business analyst; if companies hope to achieve strategic goals, they need someone who is focused on the business value expected from the project outcomes. The business analyst provides guidance during a project, before funds are invested, and after the solution is delivered. She continually focuses on the evolving business requirements and serves as the steward of the business benefits.¹⁰

On all projects, business analysts serve by conducting enterprise analysis and developing the business case, in which they analyze the best approach to a particular project, forecast quantifiable benefits, and create a release plan. Once a project is approved and funded, the business analyst continues to oversee and elaborate the business requirements for each release, and makes sure the releases are prioritized according to business value.

Through leadership and collaboration, the project manager and business analyst guide the agile team, ensuring that it is both efficiently and effectively run and that it adds significant long-term benefits for the company. The business analyst plays close attention to the original business case, recommending the project be terminated when the ROI has been realized.

ELICITING FIRM, BASIC BUSINESS REQUIREMENTS

A business analyst’s main priorities when she is first attached to a specific project are to elicit firm, basic business requirements (what we used to call high-level requirements, which outline the breadth of requirements and which we do not expect to change), to collaboratively determine the most feasible solution, and then to categorize releases into valuable features or functions. Then each feature is initially described in enough detail to determine its cost versus its benefits, thus developing an ROI for each release.

Knowing what it will take to deliver each individual component of the solution as well as what the return will be to the organization, the development team can then build components or features based on business value, delivering the highest-value features first. As the project moves through the release schedule, the business analyst elaborates the requirements in enough detail to meet the development team’s needs and continually validates that the emerging solution meets the changing business needs.

TRACKING BUSINESS VALUE

As an agile project progresses through its life cycle of requirements, design, construction, testing, and deployment for each iteration, the team continually learns new information. It becomes clearer how many resources will be needed to perform detailed design, construction, and tests for each release, how much risk there is to the project, and how the risk needs to be managed. Accordingly, it is important to go back and check original assumptions about business value and costs to develop and operate the new solution to see if they are still true, or if the original business case has been compromised. Also, the business analyst continually validates that the emerging solution meets the business needs.

Working with the project manager and the core team of developers and customers, the business analyst updates the business case after each release. For example, the business analyst may discover that a project is going to take 12 months instead of 6 and will cost $10 million instead of $8 million. The portfolio management team needs to be informed of this new information so that they can decide if the project is still a good investment and if it should continue. The business analyst can then make an appropriate recommendation, such as continuation with some sort of course correction, like a scaling down of the requirements.

Because agile projects often involve upgrading information systems, it can be easy for the technical developers to focus on what technology can do rather than on how technology can best serve the specific goals of the company. Throughout the constant adjustments made during the development process, the business analyst keeps the focus on the business requirements, the costs and risks involved, and the value the emerging solution will ultimately return to the organization.

If the project ROI is met early and the value of future releases is marginalized, it is up to the business analyst to bring this to the attention of the project team and project sponsor, recommending that the project be brought to a close and the team members be reassigned to higher-value projects that are waiting to be resourced.

VALIDATING OPERATIONAL COMPONENTS AFTER EVERY RELEASE

The business analyst’s role of liaison between the project manager, the QA/testers, the developers (engineers who may not understand the intricacies of the business process), and customers (business people who may not know what exactly to request technologically) is an important one. By being involved during the development process, business analysts can validate that new components are actually meeting business needs. They also take information to other groups outside the agile team to further corroborate that the changes have the support of other stakeholders. The business analyst confirms that these stakeholders will benefit from the revised requirements or at least not have conflicting requirements that need to be addressed.

ANALYZING AND ASSESSING OPERATIONAL COMPONENTS

In conjunction with the cost of the development of a new business solution, the operational component needs to be analyzed and assessed before the solution is implemented. If it is a major new business system, perhaps there will be a need for some reorganization, retooling, retraining, or acquisition of new staff. Working with management, the business analyst helps to ensure the organization is prepared for the impact of the changes and can support the release plan. That way, when the complete solution is delivered, it can be operated efficiently and effectively.

COMPARING ACTUAL COSTS TO ACTUAL BENEFITS

Once the new system is in place, the actual costs of development or acquisition, deployment, and cost to operate should be compared to the system’s actual benefits to the company. This final analysis shows the organization whether it has received its forecasted return on project investment. If the performance metrics show that the project was a success, wonderful! If not, the business analyst investigates to find out what went wrong. Was the project a bad investment because the risk was too high? Was the project executed poorly and so ended up costing a lot more than expected? Was the organization not prepared for the new way of operating the business, so operating costs were much higher than predicted? This type of post project evaluation is crucial to improving future project decisions because it allows a company to learn from its mistakes.

“LIGHTENING” THE REQUIREMENTS

Agile requirements are typically “lighter” than those developed for linear project models. Requirements are visually documented whenever possible. The wise business analyst uses modeling to manage complexity. Less formal user stories (a high-level description of solution behavior) may suffice, as opposed to use cases. Agile user stories are typically:

MANAGING CHANGES TO REQUIREMENTS

Managing changes to requirements using iterative development is less complex because iterative development eliminates the many-to-many relationships that are often found in complex system builds. This frees the team to welcome changes that add value to iterations that are in backlog, since detailed requirements and design have not yet occurred.

DEVELOPING ADVANCED SKILLS

Advanced skill development is required for business analysts who are working on agile projects. They need to develop new or higher-level leadership skills, including facilitation, coaching, collaborative decision-making, team development, and team building. The analyst will also need to learn a new terminology as well as new skills for documenting requirements and for managing them. The analyst also needs to have a good understanding of software architecture and be proficient in decoupling the breadth of the solution from the depth of the solution into feature-driven requirements.

THE BEST BUSINESS ANALYSIS PRACTICES FOR HIGHLY COMPLEX PROJECTS, PROGRAMS, AND MEGAPROJECTS

Projects sometimes fail because project leadership is inappropriately matched to project characteristics. For highly complex projects, the project manager and business analyst are in critical leadership positions. Once it is clear that a project is highly complex, organizations need to assign their most senior resources to fill project leadership roles—project managers and business analysts who understand how to not just manage complexity, but capitalize on it.

Highly complex projects offer the greatest opportunities for creativity. But the business analyst must understand the nature of complexity to foster innovation and creativity. Complexity is one of those words that is difficult to define. Some say complexity is the opposite of simplicity; others say complicated is the opposite of simple, while complex is the opposite of independent. A complex structure is said to use interwoven components that introduce mutual dependencies and produce more than the sum of their parts. In today’s business systems, this is the difference between a collection of legacy systems kluged together through inconsistent data interfaces and an architected set of integrated business processes and applications.

A complex system can also be described as one in which many different components interact in multiple ways.¹² In the context of a design that is difficult to understand or implement, complexity is the quality of being intricate and compounded.¹³ When project managers characterize a project as complex, they usually mean the project is “challenging to manage because of size, complicated interactions, or uncertainties. Often, anxiety goes hand in hand with complexity.”¹⁴

Since complex projects are by their very nature unpredictable, it is imperative that the project team keep its options open as long as possible, building those options into the project approach. This adaptive approach requires that considerable time be dedicated to researching and studying the business problem or opportunity; conducting competitive, technological, and benchmark studies; defining dependencies and interrelationships; and identifying potential options to meet the business need or solve the business problem. In addition, the team experiments with alternative solutions and analyzes the economic, technical, operational, cultural, and legal feasibility of each until it becomes clear which solution option has the highest probability of success. When the opportunity is unclear and the solution is unknown, traditional linear approaches simply will not work.

MAKING DESIGN DECISIONS AT THE LAST RESPONSIBLE MOMENT

On highly complex projects, it is important to separate design from construction. The key is to use expert resources and allow them to spend enough time experimenting before they make design decisions; the construction activities will thereby become much more predictable. Linear methods will likely be appropriate during the construction phase of the project.

Models for adaptive project management are still emerging. We suggest two that are designed to provide iterative learning experiences, adapt and evolve as more is learned, allow analysis and experimentation to determine solution design viability, and delay decision-making as long as possible (that is, until the last responsible moment, the point at which further delays will put the project at risk): the adaptive evolutionary prototyping model and the eXtreme project management model. There are significant differences between the adaptive and eXtreme approaches (see Figure 3-4).

Adaptive Evolutionary Prototyping Model

The keep-our-options-open approach often involves rapid prototyping—a fast build of a solution component to prove that an idea is feasible—which is typically used for high-risk components, requirements understanding, or proof of a concept.

FIGURE 3-4. Adaptive vs. Extreme Methods

Evolutionary prototyping is quite effective for multiple iterations of requirements elicitation, analysis, and solution design. Iteration is the best defense against uncertainty because with each iteration, the technical and business experts examine the prototype and glean more information and certainty about functions that are built into the next iteration.

The strength of prototyping is that customers work closely with the project team, providing feedback on each iteration (see Figure 3-5). If requirements are unclear and highly volatile, prototyping helps bring the business need into view.

FIGURE 3-5. Adaptive Evolutionary Prototype Model

© 2011 By Kathleen B. Hass and Associates, Inc.

eXtreme Project Management Model

The eXtreme project management model was developed by Doug DeCarlo and is fully defined in his book, eXtreme Project Management: Using Leadership, Principles, and Tools to Deliver Value in the Face of Volatility.¹⁵ The model is designed to be used when a great deal of change is expected during a project, speed is of the essence, and uncertainty and ambiguity exist. Pharmaceutical research for a groundbreaking drug, new product development for a pioneering invention, and major business transformation efforts are examples of extreme projects.

eXtreme project management is sometimes also called radical project management or adaptive project management. Some equate it to agile project management. The eXtreme project management approach consists of a number of short, experimental iterations designed to determine project goals and identify the most viable solution. As in the agile model, eXtreme project management requires that the customer be involved every step of the way until the solution emerges—a practice that involves many iterations. Like the iterative spiral model, the eXtreme model terminates after the solution is found (or when the sponsor is unwilling to fund any more research); the project team then transitions to one of the other appropriate models.

DeCarlo depicts eXtreme project management as a squiggly line that shows the project from start to finish, demonstrating the open, elastic approach that is required. The focus is on the art of project management versus the more scientific and technical scheduling and planning. This approach creates several challenges we need to be aware of. It can be difficult to:

OPERATING ON THE EDGE OF CHAOS

Conventional business analysis practices that assume a stable and predictable environment encourage us to develop all the requirements up front, get them approved, and then fiercely control changes. As we have seen, conventional linear project cycles work well and should be used for predictable, repeatable projects; however, this approach has proven to be no match for chaotic 21^st-century projects. Figure 3-6 compares the characteristics of projects on which conventional linear practices can be successfully used with the characteristics of projects that require a more adaptive model. A blend of the linear, adaptive, and eXtreme models is almost always the answer. The trick is to know when and how to apply which approach.

FIGURE 3-6. Conventional vs. Adaptive Approaches

What exactly does it mean to operate on the edge of chaos? Complex systems fluctuate between a static state of equilibrium and an adaptive state of chaos. If a system remains static, it will eventually result in paralysis and death. Whereas, if a complex system is in chaos, it is unable to function. So, here is the genius of complexity: it breeds and nourishes creativity, as complex systems adapt to changes in the environment for survival. Complexity scientists tell us that the most creative and productive state is at the edge of chaos. (Refer to Figure 3-7.) Therefore, complex project teams must operate at the edge of chaos for a time in order to allow the creative process to flourish. The business analyst assigned to a complex project must use adaptive business analysis methods to foster an environment where creativity is possible. The next section explores the business analyst as creative leader of complex projects.

FIGURE 3-7. The Edge of Chaos—The Most Creative State

PUTTING IT ALL TOGETHER: WHAT DOES THIS MEAN TO THE BUSINESS ANALYST?

A business analyst who is an asset to highly complex projects is comfortable with lots of uncertainty and ambiguity in the early stages of a project. She leads and directs plenty of sessions of brainstorming, alternative analysis, experimentation, prototyping, out-of-the-box thinking, and trial and error, and encourages the team to keep options open until they have identified an innovative solution that will allow the organization to leap ahead of the competition.

What does this mean for the business analyst who has worked successfully on moderately complex projects but has the desire to become a critical strategic asset who works on highly complex endeavors? As you create your professional development plan, include education and experience in the following areas:

NOTES

1. Martin Fowler, “The New Methodology,” 2003. Online at http://www.martinfowler.com/articles/newMethodology.html (accessed July 2010).

2. Scott Ambler, “Agile Analysis,” 2010. Online at http://www.agilemodeling.com/essays/agileAnalysis.htm (accessed July 2010).

3. Ibid.

4. Scott Ambler, “When Does(n’t) Agile Modeling Make Sense?” 2010. Online at http://www.agilemodeling.com/essays/whenDoesAMWork.htm (accessed July 2010).

5. Ibid.

6. The Standish Group International, CHAOS: A Recipe for Success (West Yarmouth, MA: The Standish Group International, 1999): 12.

7. Ambler, “Agile Analysis.”

8. Hal Mooz, Kevin Forsbert, and Howard Cotterman, Communicating Project Management: The Integrated Vocabulary of Project Management and Systems Engineering (Hoboken, NJ: John Wiley & Sons, Inc., 2003): 334.

9. Robert K. Wysocki, Effective Project Management: Traditional, Adaptive, Extreme, 4th ed. (Indianapolis: Wiley Publishing, Inc., 2007): 48.

10. Kathleen B. Hass, “An Eye for Value: What the Business Analyst Brings to the Agile Team,” Project Management World Today (June 2007): 1–5.

11. Mike Cottmeyer, V. Lee Henson, and VersionOne, Inc., “The Agile Business Analyst,” 2010. Online at http://www.versionone.com/pdf/Agile_Business_Analyst.pdf?mkt_tok=3RkMMJWWfF9wsRolv63JZKXonjHpfsXw6uUsW6%2Bg38431
UFwdcjKPmjr1YEERMZ0dvycMRAVFZl5nRpdCPOcc45P9PA%3D (accessed July 2010).

12. D. Rind, “Complexity and Climate,” Science Magazine 284, no. 5411 (April 2, 1999): 105–107.

13. Luay Alawneh, “A Unified Approach for Verification and Validation of Systems and Software Engineering Models,” Proceedings of the 13th Annual IEEE International Symposium and Workshop on Engineering of Computer-Based Systems (2006): 409–418.

14. B. Michael Aucoin, Right-Brain Project Management: A Complementary Approach (Vienna, VA: Management Concepts, 2007): 132.

15. Doug DeCarlo, eXtreme Project Management: Using Leadership, Principles, and Tools to Deliver Value in the Face of Volatility (San Francisco: Jossey-Bass, 2004).