Skip to main content

BA Rising

This is the first entry in Marcos Ferrer’s blog, BA Rising, an an ongoing series where Marcos shares his views, observations and thoughts on business analysis – and would like you to share yours.

When I was young, I asked my dad what he did at work. “I’m an analyst”, he responded.

In the course of my career I have run into (and sometimes been grouped with) systems analysts, financial analysts, organizational analysts, sales analysts, marketing analysts, computer analysts, network analysts, security analysts, user interface analysts, software analysts, investment analysts, business analysts, enterprise analysts, quality assurance, analysts who analyze analysis, psycho-analysts, and probably others.

Needless to say, my father’s answer, back then, didn’t provide much insight as to what he did to keep the family going. In fact, at the time, I didn’t give it any thought at all. Most of the analysts seemed like people who knew some stuff about some specialty, that’s all. Most were pretty smart, but not all.

Nor did it make sense that in my time there, IBM called me a Systems Engineer. Yet, It didn’t bother me; I figured they knew what to call it. Still, it didn’t feel like engineering. To me if just seemed like a bunch of things to know about computers – and the world – that let you help your customers. Some of it was just knowing that large inventories at year-end were financially punishing to businesses that had them. Some of it (e.g., correct balanced systems and network configuration) was stuff that customers could have figured out for themselves, if IBM had provided the means on-line. Instead, IBM’s engineering support systems gave me information power with my customers, and I used it to leverage information out of them concerning their business interests, becoming an analyst without knowing it.

When Mendes Worldwide (high tech bowling company) called me an Industry Rep, again, it didn’t bother me. They must know! When a client of mine installed the world’s first fully automated duckpin bowling center, after a year of negotiations and Excel “what ifs” with Duckpin industry officials, Duckpin Bowling Center proprietors and potential investors, someone said to me that I must really know the business. Again, I was operating as an analyst, without even knowing to call it that.

What I figured out later (when I found IIBA) was that I was practicing business analysis the whole time. I just didn’t know it was business analysis. I know I didn’t know, because every boss I ever had (except one) challenged me by spluttering “What are you doing, why are you doing that?” And with comments like, “don’t let me catch you doing that ever again!” And I never knew what to say except “But, it’s working!” and “I promise you‘ll never catch me doing that again!”

Over time, I met other people who made things work. They made them work well. They were different from the ones who made things look good. The “look-gooders” made things look good just long enough to get promoted, so someone else would actually have to fix the mess. A small number of people seemed to be able to make things look good AND make them work. All these people seemed to be CEOs; high-level executives, but certainly not business analysts.

What the “make things work” people did, always made sense, got results, and allowed energy time and resources to complete tasks and quickly focus on new opportunities,

In a word, these people left things better than they found them.

That was not easy at IBM, nor is it easy in organizations of any size larger than, say, one person. None of this was identified with business analysis, or analysis of any kind – at least not by my bosses at IBM in 1983 – this changed later.

The Eureka moment for me came while I was consulting with DOL as a client/server analyst. Peter Gordon introduced me to the International Institute of Business Analysis (IIBA, www.theiiba.org). I read their material, and then their Book of Knowledge (if that sounds pretentious, remember that it is really the Business Analysis Book of Knowledge – BABOK – the name adds a little humility, in my opinion, and all to the good).

The IIBA BABOK had summarized (it is still a work in progress) all my knowledge and more techniques than I had ever heard of, but it all made sense – anyone trying to “git ‘er to work” instead of just “git ‘er done”, might do exactly the things listed in the BABOK.

Business analysis meant thinking/being thoughtful! That’s what first attracted me to IBM – the motto – “Think” – and what chased me away later – the lack of actual thinking. Business analysis is what one does, if one really cares about achieving the outcome! Risk analysis doesn’t pay if you will get promoted regardless of project outcome. It only pays if you care, AND if you use it wisely, for issues that the project can truly affect. Anyone with major meteor (>50km diameter) strikes in their risk plan is obsessive, not thorough, and not to be admired, as they have no concept of risk vs. cost. Anyone considering small (<.0.1m diameter) micrometeor strikes, is working on space travel, or is also (frankly) screwy.

Now that I realize my “common sense” skills, that I took for granted and have used during my career, really consisted of BA practices and CBAP standards, I’m hooked. Stay tuned. It will hook you too. Imagine a world where stuff worked better – stuff like medical care, flight safety, telecommuting, war plans, credit protection, law enforcement, more.

Remember, there is strength in numbers – the more CBAPs there are, the better our chances of being heard, and making the difference that is so needed. Join us, or give up and be a spectator. I know you will join, because if you could help it, you would have quit this complex and difficult career long ago.

Again, welcome, and please share your thoughts with us.

, is an experienced teacher, public speaker, and instructor with ESI International. He has over 20 years of experience in the practice of business analysis and the application of Information Technology for process improvement. Mr. Ferrer began his BA career in 1982, while still a student at the University of Chicago, when he developed a consulting practice (he didn’t know it was BA then) with local property management and accounting firms. After graduating in 1983, Mr. Ferrer joined IBM in Chicago, where he worked on requirements and systems implementations in a number of different fields. In 1990 Mr. Ferrer became an independent consultant, again working with a variety of customers, most notably in the Family Entertainment industry. He has also worked on multiple government systems projects and “business” projects, including A-76 work.

In November of 2006 Mr. Ferrer became one of the first 16 CBAPs certified by the IIBA. He has served as VP for Certification at theDC-Metro chapter of the IIBA, and is speaking publicly and promoting certification (CBAP) on behalf of that chapter (www.iibadc.org).

Copyright 2007, Marcos Ferrer. All rights reserved.
07/27/07 


Marcos Ferrer, CBAP

Putting the User Back into User Acceptance Testing

Why is getting users involved in User Acceptance Testing (UAT) so challenging? Isn’t it called UAT because the users are the main participants? My experience has shown that involving users in all phases of the project, especially UAT, is the best way to ensure project success.

I recently worked on a project in which a major defect was found after the software application moved to production. This defect caused the users to perform three days of manual processes. Users on the IT project team worked countless overtime hours. The defect also resulted in a frustrated user group and business sponsor. The project team’s morale was low and the business users lost a great deal of confidence in the project team’s ability to deliver quality software solutions. To reduce the risk of making this crucial mistake in the future the project team improved the UAT approach by getting users more involved.

Traditional Approach

Too often, User Acceptance Testing is not taken seriously. For many reasons UAT gets shortened, is not conducted in a way that ensures a successful project or, the worst scenario, is not done at all.

An approach I have used in the past consisted of the project team members—Business Analysts and QA Analysts—writing test scripts and providing demos of the new application to the users. The users would then walk through test scripts step-by-step. In some organizations the BAs write and execute the UAT tests and then present the results to the users for sign-off.

Traditional approaches are often not effective because they are missing a key ingredient—the right amount of user involvement. In the project previously mentioned, there were five major issues relating to UAT that we had to address. These are common problems in many organizations related to lack of user involvement:

• Users may not be fully vested in UAT. In the traditional approach the users are directed by the BA during UAT and are brought in too late in the project to have an impact on the test plans. This results in a lack of ownership by the users and less responsibility on their part for the success or failure of the project.

• Users do not fully understand how the new functions should work when they are asked to test them. Just seeing a demo is typically not enough. This can result in the UAT session becoming a training opportunity and not a true test.

• Tests are often generic and are not all based on real-life scenarios. If the test scripts are written by the IT project team, there is a greater risk for missing real-life scenarios. This is because, unlike the user, the IT project team does not use the application every day.

• Project team members are usually pressed for time. Often a BA has already been assigned to perform requirements activities on another project during UAT. Balancing multiple projects means that BAs have a hard time focusing on UAT, while meeting their other project deadlines.

• High pass rate of UAT test plans. Ironically, this is not a positive thing. Often a BA writes test scripts and tests them himself prior to UAT to ensure the scripts pass. When a BA writes the test scripts the users are not given an opportunity to interject enough real-life scenarios to validate the system.

A Recommended Approach

To address these common issues and increase the chance for project success we need to take a new approach to UAT.

1. Involve key users early

Once Quality Assurance (QA) begins testing, UAT planning should start. Identify users who have a deep understanding of the business requirements and are change agents for the group. Identify all of the tasks that need to be accomplished, the owners of each task, and a high-level timeline. This will help ensure that all the right people are involved.

2. Provide hands-on training of the system for the UAT participants

Providing a demo is not good enough. Once QA feels the application is stable enough, give hands-on training to the UAT participants. It is critical to explain to the users that issues may arise because QA testing is not complete. Ask the users to stay focused on how the application works and not so much on the fact that it is not fully operational.

3. Use facilitation sessions to create test plans

Have the users write their own test plans. This may sound far-fetched, but it is key to getting UAT as close to real life as possible. The BA’s primary role is to facilitate the UAT test plan creation process, but not to write a single test script. Using process workflow diagrams and Use Case documentation from the requirements package, ask the users to determine what processes and system functions need to be tested. Provide the UAT participants with examples of test scripts and explain the need to capture the goal of each test, the necessary steps, and the expected results. The steps become second nature to the users of the system, and they often find it difficult to document each step they take to accomplish a goal. Help them think through their processes in detail to ensure they have documented each task completely.

Review the test plan. Once the test plans are written, the BA reviews the test plans to ensure all the necessary functions and processes impacted will be tested.

Determine necessary inputs and outputs. Once all the test plans are written, ask the users to document the inputs they need to complete each of their test scripts and the outputs that will be generated. Make sure all UAT participants have the necessary inputs to complete their tests based on all of the outputs. If some are missing, enlist other users to create those inputs during testing execution.

Make it as close to real life as possible. To enhance the real life feel, the BAs work with the users to determine a testing schedule. Make sure the schedule follows their daily process. Again, use process workflow and Use Case documentation to ensure the test plans are executed in the order the activities would be done in real life.

4. Ensure users execute the test

The BA’s role is to ensure the test environment is set up and to assist the users as they execute the tests. The user’s role is to execute their tests and document the results.

The Results

Recommended Approach to UAT

1. Involve key users early

2. Provide hands-on system training for the UAT participants

3. Use facilitation sessions to create test plans

4. Ensure users execute the test

Using this approach can help reduce the risk of major defects making it to production and ensures the users are satisfied that the solution meets the objectives of each project. Here are some of the key results from using the improved approach:

• The UAT participants take responsibility for the success of the release. They feel part of the team due to their collaboration with the IT project team and involvement in UAT planning, and test creation and execution. They also help champion the benefits of each release to the larger user base.

• Due to the pre-test training, users are comfortable with new applications. This allows the users to develop real life test scenarios, and the time allotted for testing is not used for training.

• Since the users create and execute test plans, the tests are very close to real life scenarios and the users are more comfortable running the tests.

In addition there are tangible benefits to future projects:

• QA incorporates the scenarios documented by users in the QA test plans for future releases.

• Over time there is decreased use of the BA’s time for UAT. With the BA facilitating the UAT process and not doing most of the work, the BA can focus on other necessary tasks – like launching the next project.

Implementing the Approach

A lack of user involvement in UAT is not uncommon. I urge you to try this approach even if you have not yet experienced a drastic wake-up call, such as major defects in production.

As we are called upon to deliver solutions faster and faster, it is just a matter of time before major defects make it to production. Here are some tips for getting started:

• Start small. To help manage the changes with the new approach, identify a release with a low number of users and/or new functions. This will allow you to test the new process, discover lessons learned, and make the necessary adjustments.

• Plan for additional time. Using this new approach will initially require more time. Work with your Project Manager to plan more time into the UAT phase for your first two or three projects. As you get accustomed to this approach, it will require less time.

• Identify power users and champions of application. They are your best testers and have the most interest in the project’s success.

• Sell the benefits of the new approach to your users. As with any new approach, BAs need to help the users understand what the approach is, and how it will ultimately improve their business.

• Save the user test plans for future releases. Reuse of test plans will help speed up the time dedicated to UAT in future releases and can be used to update your QA test plans. Successful implementation of this approach helps ensure projects meet the user needs. The collaboration of users with the project team leads to a shared responsibility for the success and failure of the project.

What is UAT and Why We Do It?

UAT is the final approval by customers signaling the new system or enhancements can be deployed. UAT is unlike other types of software testing (e.g., unit testing, system testing, integration testing), because during UAT we are looking for conformity. We need to validate that the solution meets the business objectives and works correctly with real-life scenarios. UAT is typically conducted by users with assistance from the BA and other project team members.
UAT is most often conducted before a system is deployed into a production environment. For higher risk projects UAT may continue for a period of time while running the old system and new system in production. This gives the users ample time to become comfortable that the new system meets their needs. For commercial software companies UAT is also know as “Beta” testing. Here the system is launched into a production environment, but only to a subset of customers who will provide feedback on defects and necessary improvements. 

The Business Analyst as Strategist

A recent survey conducted by Evans Data Corporation, The New Business Analyst: A Strategic Role in the Enterprise, found that business analysts are key players in making strategic decisions. “A clear line in the corporate sand has been drawn as to the importance of the business analyst. The BA plays an increasingly integral and strategic role in organizational success,” said Evans Data Corporation President John Andrews. Business analysts are emerging as the central business competency of the future. Different from systems analysts or project managers, business analysts (BAs) not only manage project requirements, they also contribute vital information to strategic planning, goal setting and strategy execution. It is in this capacity that BAs can have the greatest impact on the long-term success of the enterprise.

Business Analyst as Master Strategist

In their Body of Knowledge, the International Association of Business Analysts (IIBA) defines a BA as someone who “works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.”

To help distinguish the roles played by the BA and the project manager, consider an analogy from the world of sports. On a football team, the coach (the project manager) is given a game (the project) with requirements (to win), as well as team members and resources (players and equipment). But what happens when the requirements change? The team owner feels it’s not enough just to win games, and the goal is now to win the Super Bowl. Enter the general manager (the BA). Responsible for the team’s overall strategy for success, the general manager continually validates that the project team is focused on the strategic imperatives. Similarly, the BA keeps her eye on strategic-level decisions that impact the project, leaving the project manager free to focus solely on optimizing project team performance.

No analogy is perfect, of course. In football, the coach reports to the general manager, but in business, the BA and the project manager share leadership of the project team. Much like a general manager, however, the BA keeps track of the overall direction of the team’s season, freeing the project manager to “get in the huddle” with the team and direct it on a play-by-play basis.

Specific Strategic Planning Tasks

Of course, the BA is not the only one on the project team familiar with the strategic goals of the organization. Employees perform best when they understand their organization’s plans and their role in them. One vital role for BAs is to translate strategies into new proposals for the company, as well as to ensure existing operations mesh with the strategy. In fact, all proposals for organizational change should be aligned with corporate strategies, and the BA is best suited to handle the enterprise analysis needed to ensure alignment.

The BA must have a thorough understanding of the organization’s strategic goals to facilitate the process of matching project objectives to business needs.The BA assures the project deliverables meet the business needs and helps to realign the project when requirements change. BAs makes certain that throughout their life cycle, projects continue to meet business needs and deliver benefits that outweigh their costs. Because of their familiarity with the organization’s strategic goals, the BA is often adept at securing additional support from the business sponsor, if needed. At the end of the project, the BA examines the ROI to determine if the project met its goals.

The BA can also be a valuable provider of information to the strategic planning team or top-level management. BAs may perform analyses of the competition, gather customer feedback and complete benchmark studies to support a business case or project investment decision package. In addition to providing data for decision-makers, senior BAs may also conduct goal setting meetings and even help conduct strategic planning sessions.

A Vital Role

Just how important is the strategic planning role that is filled by the BA? Judging from the poor success record of projects in the business world, very important. Consider these statistics:

  • $80 -145 billion per year is spent on failed and cancelled projects (The Standish Group International, Inc.)
  • 25 percent – 40 percent of all spending on projects is wasted as a result of re-work (Carnegie Mellon)
  • 50 percent of projects are rolled back out of production (Gartner)
  • 40 percent of problems are found by end users (Gartner)
  • Poorly defined applications have led to a persistent miscommunication between business and IT. This contributes to a 66 percent project failure rate for these applications, costing U.S. businesses at least $30 billion every year (Forrester Research)
  • 60-80 percent of project failures can be attributed directly to poor requirements gathering, analysis, and management (Meta Group)
  • Nearly two thirds of all IT projects fail or run into trouble. (See Figure 1 for the results of the 2006 CHAOS Survey.)


Figure 1: Project Performance Track Record – The Standish Group 2006 Chaos Report

Until the creation of the professional BA, there was no one person responsible for ensuring that business requirements were accurately determined and managed throughout the lifespan of the project. Business sponsors often do not have the time or the technical expertise to provide oversight to projects on a day-to-day basis, and their role is best left to securing funding and resources and using their authority to help effect institutional changes in support of the project. Project managers are focused on delivering what was asked of them within time, cost and quality constraints, not constantly reevaluating and validating the business need.

The Future

The high-velocity change occurring in the business world today requires more than employees capable of completing assigned tasks. It calls for multi-skilled practitioners who are systems thinkers, comfortable in both the boardroom and the server room. As they seek to increase project success rates, more companies will include business analysts in their project teams, recognizing the added strategic value they bring to the table.

The Top Nine Requirements Misconceptions: Why Arent YOU Doing Requirements Right?

“We don’t need to explore requirements—we know what we need!” “Hey, we’re using agile methods—we don’t need to define requirements!” “Oh, we don’t have time for requirements!” And so it goes. You’ve probably heard—and perhaps yourself offered—any number of excuses or rationales for not doing requirements right. No matter who makes these excuses—technical staff, the business sponsor, the project manager, or even business analysts—failing to carefully define your project’s requirements will put your project in peril. In my twenty years of working with projects, I’ve heard them all. Here are my top nine requirements misconceptions—and how you can refute them.

 

“We know what we need”

In practice, project team members mostly don’t know what users or customers need. Requirements development takes exploration and learning. It’s unrealistic to expect your team to understand requirements up front.

For one thing, users, product managers, customers, and other stakeholders don’t really know all their needs at the beginning. Requirements naturally thrash and evolve. Indeed, it’s wise to be suspicious of claims to the contrary. Remember, almost half of the requirements you specify never get implemented (Standish Group International, 2003b).

In many projects, the perception that requirements are known is mistaken. Most errors in delivered software (30% to 50%, depending on the study) originate from flawed requirements (Schwaber, 2006; Nelson et al., 1999; Leffingwell and Widrig, 1999; Lauesen and Vinter, 2001).

The top three risks that threaten successful e-projects all relate to requirements— constantly changing requirements, poor requirements specification, and customer involvement issues such as delayed approval, requirements thrashing, and poor communication (Rodrigues, 2001).

Don’t rely solely on product and business managers for defining user needs. Unless they are former users themselves, they will not understand direct user needs without inquiry and exploration. And rarely do product and business managers have the subject matter expertise you need to represent the entire set of requirements.

Ask yourself: have you solicited the voices of all your stakeholders? Do you know who all your stakeholders are? Have you prioritized conflicting needs? Have you explored both technical constraints and possibilities? You may think you know what the needs are, but your list may be shortened by technical realities or lengthened by technology possibilities.

What you think you know can hurt your project more than what you don’t know.

“We’ve got this covered. We’re [pick one: outsourcing/
using agile development methods/ buying a software package]”

Outsourcing, agile development methods, COTS solutions—these are often great ideas, but they don’t eliminate the need to develop excellent requirements. You still need to articulate requirements, adapting your requirements development practices to these scenarios.

The critical need for proper requirements development increases when you outsource your project. You need to communicate requirements with even more rigor when the development staff is not physically co-located with customers and project managers. In addition, you will need top-notch business analysts (Schwaber, 2006).

If you’re adopting agile practices, it doesn’t mean you don’t need requirements. In agile projects, iterations are driven by requirements. They don’t go away—they’re successively elaborated.

And if your product is large and complex, agile projects need to start with a requirements-driven product and release roadmap. From there, the team develops chunks of requirements—based on those roadmaps. Success with agile development means balancing suitable-quality requirements with speedy definition of needs.

Many organizations hope to accelerate delivery by seeking and installing software package solutions (commercial off-the-shelf software, or COTS). In that case, you still need to understand your requirements and the impact your project will have on your business process. Requirements should drive your choice as well as your implementation strategy.

“My staff already knows what good practices are”

Too many projects rely on written requirements, often viewed as the most important good practice. But written requirements are rife with ambiguity (unclear meanings). To top it off, project and product needs are rarely known up front.

In fact, writing textual requirements (“the system shall…”) is not the best way to understand your users’ needs. Textual requirements have their place when you need formal specifications, but most successful projects also adopt other techniques to explore business and user requirements.

Effective requirements development makes use of requirements models that are verified and validated continually and iteratively. Using good practices—such as requirements modeling, facilitated workshops, prototypes, scenario verification, and more—takes practice, coaching, and reinforcement.

Following sound requirements processes, actively involving users, documenting requirements appropriately, validating and verifying requirements, and managing requirements changes—all these skills and techniques are essential to successfully reduce the many risks associated with requirements errors (Leishman and Cook, 2002).

“We can’t afford to get training or consulting”

Roughly one-third of your software project budget is consumed fixing requirements errors. That means you’re spending about $150,000 of your $500,000 project fixing defects or errors that originate from your requirements (Schwaber, 2006; Nelson et Al., 1999; Leffingwell and Widrig, 1999; Weinberg, 1997).

The earlier you discover these errors—missing, wrong, conflicting, and ambiguous requirements—the cheaper it is to fix them. Finding and fixing a requirements error during the requirements phase might cost you $25 to $100. If you don’t find it until the construction or testing phase, fixing that same error is going to cost you $500 to $1000 (20 to 40 times more). Left undetected, that requirements error will cost you as much as 300 to 1,000 times more. That $25 cost becomes $10,000! (Reifer, 2007)

For every dollar you invest in your staff learning good requirements practices that incorporate customer collaboration, you can get a 10:1 return on investment (Jones, 1996a).

You cannot afford not to correct your requirements deficiencies.

Pay now—or pay more, later!

“It will take too much time to do things differently, to take time out for training, or get project help from the outside”

Yes, there will be a learning curve. This is a normal part of change and learning. But there are things you can do to accelerate the process. Schedule formal training to coincide as closely as possible with the project work. Provide real-time coaching to the team. Set up sponsorship contracts so that new practices and behaviors are reinforced in the organization—both top-down and bottom-up. Find out from your staff what they need from you to be successful with requirements, and provide it.

And remember, some requirements work is better than none. On complex projects, one study showed that investing even 10% in the effort before freezing requirements reduces cost overruns significantly (NASA Comptroller Office, reported in Hooks and Farry, 2001).

Many organizations are turning to external service providers, outsourcing their development efforts. And they are learning that highly skilled business analysts who can develop and manage requirements are essential to successful outsourcing (Henschen et al., 2007; Light, 2005).

“Users don’t know what they want”

Users are not supposed to know what they want. Understanding user needs is both an art and a science—a combination of discovery, interrogation, exploration, and decision making.

Involving users in requirements development is widely recognized as one of the—if not THE—most important factor for project success. Yet business people, as well as IT people, continue to complain about their inability to work effectively together to define the right requirements.

Healthy collaboration with users is crucial—and it doesn’t just happen. Both sides of the relationship—business and IT—are accountable to co-develop the right requirements in the most efficient and effective manner possible.

That’s why great analysts employ an appropriate combination of requirements elicitation techniques. It’s one of their most valued skills. These elicitation skills, married with artful choices in requirements models, go a long way toward active and productive user involvement.

Sponsors who pay for the development (product managers, marketing managers, or internal business managers) also need to be engaged. This doesn’t take unlimited time and money. Not all requirements are created equal. User priorities need to be evaluated continually if the team is to make smart product development choices.

“Customers are too busy to participate in requirements work with us”

IT needs to employ techniques that make good use of business people’s time and actively engage them in requirements work. At the same time, business people need to fully participate in defining their requirements. If you do it right, good practices for effective user involvement sell themselves.

Here are some ways to do it right. Represent user needs in ways that “sing” to users and customers. Use a variety of elicitation techniques. Verify and validate requirements as you proceed. And, importantly, conduct continual requirements retrospectives to get feedback that will allow you to adapt your requirements practices.

“Our users are distributed. We can’t get everyone’s requirements”

User requirements are the focal point of your product. When users are scattered, you still need to identify the various types of users, understand their needs, and determine how you might need to alter requirements based on location.

When your users are geographically distributed or there are vast numbers of them, you may have to rely on surrogate users or subject matter experts who can research user needs. Find a small sample of representative users from various locations who are important to product success. Then adapt your elicitation practices to make efficient use of these users in requirements development and verification.

For some products, it’s best to combine surveys and other research methods with deeper representative user involvement.

Regardless of the approach you take, ignoring user needs is a recipe for disaster.

“We got the book We’ll just follow that”

Reading a book (e.g. The Software Requirements Memory Jogger) helps. It gives you awareness and knowledge. Reading does not, however, enable you to apply skills without practice and reinforcement.

Many business and requirements analysts are not trained and skilled in the toolkit of requirements development and management practices they need to be successful (Schwaber, 2006).

Analysts with extensive experience are more successful than novices in analyzing and uncovering user needs. Expert analysts demonstrate the ability to select among elicitation techniques based on the situation and integrate multiple models to represent requirements (Hickey and Davis, 2003).

Gaining expertise in requirements saves time and effort, reducing your total cost of application ownership (Light, 2005).

Training and coaching accelerate the learning curve and will earn you savings in time and money.

Copyright: Ellen Gottesdiener 04/23/07

Ellen Gottesdiener, Principal Consultant, EBG Consulting, helps you get the right requirements so your projects start smart and deliver the right product at the right time. Her book Requirements by Collaboration: Workshops for Defining Needs describes how to use multiple models to elicit requirements in collaborative workshops. Ellen’s most recent book, The Software Requirements Memory Jogger describes essentials for requirements development and management. In addition to providing training and consulting services, Ellen speaks at and advises for industry conferences, writes articles, and serves on the Expert Review Board of the International Institute of Business Analysis (IIBA) Business Analysis Body of Knowledge™ (BABOK™). You can subscribe to EBG Consulting’s free monthly eNewsletter Success with Requirements (http://www.ebgconsulting.com/newsletter.php) for practical guidance and requirements-related news. When you sign up, you’ll receive a free .pdf article by our Senior Associate, Mary Gorman, on an essential requirements modeling technique.

References
Henschen, Doug, David Stodder, Penny Crosman, Michael Mcclellan, Neal Mcwhorter, and David Patterson. 2007. “Seven Trends for 2007.” Intelligent Enterprise, January. See http://www.intelligententerprise.com/showArticle.jhtml?articleID=196603897

Hickey, Ann M., and Alan M. Davis. 2003. “Elicitation Technique Selection: How Do Experts Do It?” Proceedings 11th International IEEE Requirements Engineering Conference. September.

Hooks, Ivy F., and Kristin A. Farry. 2001. Customer-Centered Products: Creating Successful Products through Requirements Management. Amacom.

Jones, Capers. 1996a. Patterns of Software Systems Failure and Success. Thomson Computer Press.

Lauesen, Soren, and Otto Vinter. 2001. “Preventing Requirement Defects: An Experiment and Process Improvement.” Requirements Engineering, June 6:37-60.

Leffingwell, Dean. 2003. “Calculating the Return on Investment from More Effective Requirements Management.” IBM Developer Works, December.

Leishman, Theron R., and David Cook. 2002. “Requirements Risk Can Drown Software Projects.” Crosstalk: The Journal of Defense Software Engineering, April.

Light, Matt. 2005. “Agile Requirements Definition and Management Will Benefit Applications Development.” Gartner RAS Core Research Note G00126310, Gartner, April 18.

Nelson, Mike, James Clark, and Martha Ann Spurlock. 1999. “Curing the Software Requirements and Cost Estimating Blues.” The Defense Acquisition University Program Manager Magazine, November–December.

Reifer, Donald J. 2007. “Profiles of Level 5 CMMI Organizations.” Crosstalk: The Journal of Defense Software Engineering, January.

Rodrigues, Alexandre G. 2001. “Project Goals, Business Performance, and Risk.” Cutter Consortium e-Project Management Advisory Service Executive Update, 2(7).

Schwaber, Carey. 2006. “The Root of the Problem: Poor Requirements.” IT View Research Document, Forrester Research, September.

Standish Group International, Inc. 2003b. Standish Group Study. Reported by Jim Johnson, chairman, XP 2002 Conference.

Weinberg, Gerald M. 1997. Quality Software Management, Volume 4: Anticipating Change. Dorset House.

04/23/07

The Coming of Age of the Business Analyst

The dismal success of enterprise-wide IT projects is a matter of national record. According to Meta Group Research (now a part of Gartner), “Communication challenges between business teams and technologists are chronic – we estimate that 60%-80% of project failure can be attributed directly to poor requirements gathering, analysis, and management.” Forrester Research concurs: “Poorly defined applications have led to a persistent miscommunication between business and IT that largely contributes to a 66% project failure rate for these applications, costing U.S. businesses at least $30B every year.” James Martin reports that “56% of defects can be attributed to requirements, and 82% of the effort to fix defects.” Standish estimates that nearly 70 percent of projects are late, over budget or  fail outright; Gartner reports that 50 percent of projects are rolled back out of production. Carnegie Mellon states that 25-40 percent of all spending on projects is wasted as a result of rework. And the Office of Management & Budget reported on March 26, 2003 “…771 projects included in the fiscal 2004 budget – with a total cost of $20.9 billion – are currently at risk.”

Those statistics are troubling. So, what exactly is the problem? Project managers are held accountable for getting projects completed on time and on budget. Technical managers are responsible for quality technological solutions. But no one has been accountable for keeping an eye on value as the implementation proceeds. That’s why the new position of business analyst (BA) is fast emerging to fill the gap. The BA’s task is to gather accurate requirements, analyze them and manage them properly throughout the project’s implementation to ensure a value-added outcome that improves an organization’s bottom line. Business requirements, derived from business goals, are the essential activities of the enterprise that must be supported by the system – so much so that at conferences, BA courseware and presentations have become hot topics, and cutting-edge companies are already hiring BAs or investing in professional development for internal candidates. 

Defining the Role

 In virtually every organization, the pivotal leadership role of the business analyst is beginning to shape the future of IT. In a nutshell, BAs are focused on business needs and on monitoring the value a project has promised to deliver to the organization throughout its implementation. The BA continually scrutinizes costs and compares them to benefits to ensure the project remains sound.  

In October 2003, as the role of the BA emerged, the International Institute of Business Analysis (IIBA, www.iiba.com) was created as an international, not-for-profit professional association for business analysis professionals. “The IIBA was founded in response to a real demand in the business community for more BAs,” says Kevin Brennan, a consultant with blue sands, inc. in Toronto, Canada, who serves as Co-chair of the IIBA’s Body of Knowledge Committee. “Businesses have been facing a shortage of people who are qualified to perform requirements analysis, and proper requirements are critical to developing software effectively, on time and in concert with overall business strategy. When companies hire new employees for these roles, they have no guarantee that these candidates actually have the knowledge and skills required. Without a pool of people who can perform business analysis, it’s difficult for IT departments to deliver what the business needs.”  

The impetus for the Institute’s launch came from a group of companies based in the Toronto area that had experienced difficulties in hiring business analysts. “Applicants presented all sorts of skills and all sorts of backgrounds, but could not consistently be expected to be effective in the role,” says Brennan.  

The IIBA’s mission is to develop and maintain standards for the practice of business analysis and for the certification of practitioners. It defines the position as follows: “Business Analysts are responsible for identifying the business needs of their clients and stakeholders to help determine solutions to business problems. The BA is responsible for requirements development and requirements management. Specifically, the BA elicits, analyzes, validates and documents business, organizational and/or operational requirements. Solutions are not predetermined by the BA, but are driven solely by the requirements of the business. Solutions often include a systems development component, but may also consist of process improvement or organizational change. The BA is a key facilitator, within an organization, acting as a bridge between the client, stakeholders and the solution team. Business analysis is distinct from financial analysis, project management, quality assurance, organizational development, testing, training and documentation development. However, depending on an organization, a BA may perform some or all of these related functions.” 

As with any other profession, there are entry-level, mid-level and senior positions. Senior BAs emerge from talented people current in both technical skills and business acumen, and they represent a critical strategic asset to their organizations. They work with the executive team and with project portfolio planning and management teams on:

 

  • Pre-project analysis and feasibility studies
  • Building business cases for new change initiatives
  • Comparing initiatives to identify which one can be implemented with the fastest time to market and lowest cost and risk to achieve the highest value
  • Decision-making to invest in the most valuable projects

Competencies and Skills

 Business requirements’ analysis differs from traditional information systems’ analysis in its focus, which is exclusively on adding value to the business. In particular, project managers rely on BAs to assist in providing more detailed project objectives; business needs analysis; clear, structured, useable requirements; trade-off analysis; requirement feasibility and risk analysis; and cost-benefit analysis. Without the key liaison of the BA, requirements’ definitions will remain poor, resulting in disconnects between what IT builds and what the business needs. Although the function of BA is distinct from that of a Systems Analyst who fulfills a primarily technical role, some BAs are former Systems Analysts or IT managers. With additional professional development, technical specialists can advance into a business-focused BA position.  A future job opportunities ad for a BA will likely call for the following skill sets and competencies:

  • The BA is “bilingual” in that he or she speaks the language of management and leadership, as well as the language of the IT organization. This ensures requirements are developed and documents structured for optimum use by technical personnel in the design and development of solutions. At the same time, these requirements and documents need to be understandable to the management team, so it can use them to validate business needs. 
  • Technical proficiency and skills in requirements’ elicitation
  • A thorough understanding of business process work flows
  • Ability to plan, execute and facilitate workshops at which requirements are gathered from users, customers, stakeholders and developers
  • Interviewing and surveying skills to obtain information from business subject matter experts
  • Prototyping competency to work with technical teams in procuring early validation of projects
  • Strong communication skills, and specifically expert writing skills, to ensure that statements of textual requirements are unambiguous, accurate and complete. While requirements must be written in business language rather than in technical terms, they must be understandable by technical personnel.
  • Excellent project management skills to plan and manage business analysis activities
  • Good knowledge of modeling techniques and risk management
  • Verification and validation skills, to ascertain that requirements are valid
  • Problem-solving skills
  • Organizational change-management skills. Once a solution has been developed, the BA prepares the organization to implement and operate it efficiently, so that the value of the new asset is maximized

While technical knowledge is a prerequisite for the role, it is insufficient for successfully managing the requirements of the large, enterprise-wide, complex, mission-critical projects that are the norm today. “One of the goals of the IIBA is to raise the quality of software requirements analysis and thus improve the overall delivery of IT projects,” says Brennan. “Currently, software requirements analysis frequently takes place without directly considering the strategic goals of the enterprise. While business users are interviewed and their needs synthesized and analyzed, there are always competing interests that don’t necessarily tie into enterprise goals. In the future, BAs will effectively tie IT efforts to the business and help drive change efforts across the enterprise.”

 

 Business Analyst Knowledge and Skill Set Requirements 

Image

Training for BAs

 Since there appears to be a never-ending demand for new IT products and services, executives across the spectrum are adopting the business analysis process to increase the value IT projects bring to the business. In building the business analysis competency within their organizations, they rely on training companies that have developed leading-edge BA course materials and entire BA certification programs.  

Training organizations are working in concert with the IIBA, which is in the process of setting standards and developing a body of knowledge for the discipline. “The IIBA’s Body of Knowledge is similar to that developed by the Project Management Institute (PMI) for project management professionals,” Brennan explains. “It describes industry standards for business analysis based on practitioner input and industry best practices. We surveyed the literature of the field and distributed task surveys to practitioners and asked them to review drafts of the Body of Knowledge in comparison with their day-to-day professional practices. At last count, we have had over 600 responses from Business Analysts around the world. That gives us the confidence to say that the content of the Body of Knowledge is in fact reflective of the realities of a BA’s work day.” The first release of the Body of Knowledge was in July 2006 with an update scheduled for later this year. It will be used by training organizations, individual practitioners and businesses that need to develop BA job descriptions. More information is available at www.theiiba.org  

The IIBA is also developing a certification test to award the designation of Certified Professional Business Analyst. “We are using the task survey to validate the certification process to ensure compliance with ISO standards for professional bodies,” says Brennan. The Business analyst student must acquire mastery of a unique combination of technical, analytical, business and leadership skills. The curriculum of a business analysis certificate program consists of studies of computing and management information systems, coupled with traditional business administration courses. It is designed to enhance participants’ ability to elicit, analyze, document, secure agreement, test, trace and manage requirements throughout the life of a project. Courses may include subjects such as the following:

  • Fundamental skills for mastering business analysis
  • Skills for planning and managing project requirements
  • Business analyst leadership skills
  • Project meeting management skills
  • Advanced skills for crafting high-quality requirements, verifying and validating solutions and managing projects for value.

In addition to certification programs, training companies offer half-day and full-day workshops that concentrate on building various key skill sets, such as facilitation, communication, modeling and writing. Of course, effective business analysis career development goes beyond classroom study. Companies will also need to provide mentoring and on-the-job training; advancement based on education, testing and experience; defined evaluation and compensation processes; and suitable titles and advancement opportunities. 

How can a BA acquire the stature and influence that will make an executive team listen? It may take some time for BAs to prove themselves and gain recognition. As they conduct expert studies and present solid information to management, either during the strategic planning process or in the course of project selection, they will gradually raise the executive team’s confidence until they become an indispensable strategic asset.

Where Will the BA Reside?

 Should mid-level and junior BAs reside in the business-operating unit or in IT? Both solutions have pros and cons. If the BA resides in the business unit, management will take greater ownership of systems problems, gaps and capabilities. It can then collaborate with the BA to develop solutions, which may range from procedural to technical. When the BA resides with the IT group, a possible disadvantage is that the business side may attempt to throw problems over the fence without taking responsibility. On the other hand, if the BA resides in the business organization, he or she may tend to grow increasingly distant from the company’s IT operations. Some organizations have solved this problem by building “communities of practice” in which BAs from all the different business units cooperate according to set standards with the goal of continuous improvement. A good rule of thumb is that mid-level BAs who work on small enhancement projects and troubleshooting should reside in the business unit and consider themselves a team of BAs that are decentralized across the business. In this manner they can work together under a single leader and according to standard processes.  

The role of systems analyst will continue to be separate and important. Once a BA documents the requirements from a business perspective, systems analysts will use those requirements to develop systems specifications and solutions. In small organizations one individual might fulfill the role of both BA and systems analyst. He or she will convert business requirements into systems specs and work with IT architects to design the best, most feasible solution. Larger organizations will have teams of systems analysts and teams of BAs who will be exclusive in their roles. 

Senior-level BAs can be most effective when they report to a high-level, enterprise-wide project management office or center of excellence where they work to support strategic planning and project selection and to manage major change initiatives. From this vantage point, they will have a perspective of the entire organization rather than being limited by a functional silo. Whether senior BAs are working in a strategic mode on business transformation projects, mergers and acquisitions, new lines of business or multi-million-dollar IT projects, they need a bird’s-eye view of the entire enterprise to ensure that the investment is sound and that the organization will realize the expected benefits. 

Creating Value 

Depending on the level of responsibility and placement in the organization, a Business Analyst’s duties may include the following:·        

  • Identify and understand the business problem and the impact of the proposed solution on the organization’s operations.
  • Document the complex areas of project scope, objectives, added value or benefit expectations, using an integrated set of analysis and modeling techniques.
  • Translate business objectives into system requirements using powerful analysis and modeling tools.
  • Evaluate customer business needs, thus contributing to strategic planning of information systems and technology directions.
  • Assist in determining the strategic direction of the organization.
  • Liaise with major customers during preliminary installation and testing of new products and services.
  • Design and develop high quality business solutions.

 Once a large, high-risk project is funded, the BA becomes one of the full-time, core team members along with the lead developer, key subject matter experts, the project manager, the technical lead and the business visionary who is sponsoring the initiative. While the sponsor need not be a full-time team member, he or she must be available to the team and be fully empowered to make decisions on behalf of the business.  

As a member of a project team, the BA’s key role is to keep an eye on the business case and promised value. At each key phase in the project – every time project plans and budgets are updated and when risk is reexamined – the BA revalidates the business case by comparing costs and benefits. He or she manages the entire systems requirements life cycle, from understanding the business need to ensuring that the delivered solution meets the need and adds value to the bottom line. No longer will initiatives be funded for two years only to end in failure because no one performed consistent checks along the way to determine if the investment still made sense. Since projects are negative assets while under way they must be constantly revalidated.  

Among the BA’s strategies is the creation and delivery of feature-driven requirements in increments so the business receives value sooner at lower risk. Although each increment is only a small piece of the new solution, feature-driven requirements can be prioritized based on business value. The IT team delivers the highest value features first for immediate benefit. 

Once the project is completed, the solution delivered and the project team dissolved, the BA works with the executive sponsor to measure the benefit and report it to all decision-makers. If the benefit does not meet expectations, the BA analyzes what went wrong. For instance, was it a poor investment decision; was it poorly executed; or did it cost more than expected, resulting in poor ROI? This analysis is critical because its results will improve the selection and execution of future projects.  

Maturity and Mastery

 Companies depend on IT solutions for their very survival. In order to change quickly, respond to new customer demands and beat the competition, they require well designed and built systems. Once management has developed a portfolio of valuable IT projects, the focus is on flawless project execution to maximize the value delivered to the organization.  

All too often, however, IT project success is elusive. Projects are late, over budget or may never even be delivered. Sometimes work is incomplete, does not meet requirements or does not deliver the expected benefits or ROI. In many cases, once the results are delivered a few years after the business case was first proposed, the marketplace or company’s needs have changed. Disasters such as these have created a sense of urgency to build a stronger bridge between business and IT. Now, the role of BA has emerged to serve as a liaison between the business community and the technical solution providers throughout the project life cycle. As projects become larger, cross-functional, global and more complex, organizations are realizing that requirements’ management skills are indispensable.

Companies are struggling to manage their portfolios of IT, R&D and other projects. The ideal is to invest in projects that will bring the highest value quickly at the lowest possible cost and risk. But senior decision-makers have neither the time nor the skill sets to analyze competing options, particularly when they involve highly technical solutions. For a mature and effective portfolio management process, leadership needs to be able to depend on a professional trained to perform the necessary analyses, present the best solutions and manage projects for value-added outcomes. The role of the BA is vital to the success of both projects and organizations. Those organizations that are first to acquire and master business analysis competencies and elevate them to a leadership role will more effectively respond to and preempt changes in the marketplace. As a result, the flow of value through the enterprise and to the customer will achieve a significant competitive advantage.