Skip to main content

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

Written by Ellen Gottesdiener on . Posted in Articles.

“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

Written by Kathleen B. Hass, PMP on . Posted in Articles.

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.   

How to Become (or Manage) a Successful Business Analyst

Written by Glenn R. Brule on . Posted in Articles.

Completing information technology projects on time and on budget is both essential and a struggle for most organizations. Business analysts can help shepherd projects through to successful results by gathering requirements from a business area and presenting them in ways that are understandable and actionable by the organization. Unfortunately, the business analyst’s job description is often vague. While many organizations know what needs to be done, they don’t know how to identify and develop the skills necessary to meet these needs.

As such, we’ve outlined here eight essential competencies necessary for success in this job. For each competency below, we explore the skills, knowledge and abilities inherent to each competency and provide practical tips for using these competencies as guidelines for improving the efficiency of business analysts within any organization. By definition, a competency is made up of three components: knowledge, skill and ability. Knowledge considers “what is being measured?” Skill looks at “how is it done?” Ability examines “to what degree can it be done?” 

Competency #1: Eliciting Requirements On the most basic level, the business analyst’s job is to gather and document user requirements. Requirements are needed by a user or client to solve a business problem or achieve a business activity, and they are tied to the needs of business, rather than the constraints imposed by technology. This means that the business analyst’s job has more to do with identifying the desired results than the actions or resources required to reach these results. The purpose of gathering requirements is to provide an understanding of the problem or opportunity before trying to propose the solution. 

Competency #2: Creating the Business Requirements Document A Business Requirements Document (BRD) is an exhaustive, written study of all facets of regulatory, business, user, functional or non-functional requirements. It is a detailed profile of primary and secondary users and comes directly from the requirements the business analyst has already gathered. It only makes sense, then, that the BRD should be written by the business analyst. After the document is completed, the business analyst and the client, or user, meet for a formal review and to formally approve the BRD. The document is then shared with the rest of the development team, including the project manager. In creating the BRD, a business analyst should define the various sources for requirements and the placement and relevancy of these requirements. 

 

The Essential Business Analysis Skills• Analyze & solve problems• Understand the business• Communicate effectively (write & speak)• Manage client relationships• Facilitate discussions• Negotiate & build consensus• Model data & processes• Plan & manage activities• Facilitate & develop business strategy• Understand & manage organizational change

 

For example, senior business analysts may identify such items as the project charter and vision, business case, requirements work plan, vendor request documents and business contract documents. They may also work with the project manager to define the project and product scope. Any requested changes to any area of the BRD, before or after work has begun, must be carefully reviewed by the business analyst who would then work with the client or user to make the necessary changes. 

Competency #3: Modeling Modeling refers to the ability to conduct structured analysis. In business analysis, modeling is used to support and enhance text-based requirements, help identify and validate requirements, document and communicate requirements and, finally, organize information into coherent ideas. The most common types of business analysis models include business models, process models, data models and workflow models. Experienced business analysts develop models such as business interaction charts or entity relationship diagrams and examine how the business process works now, in order to develop improved charts and help troubleshoot in the future. When looking at models, the business analyst is looking for problems and opportunities that will change the process or the deliverable. 

Competency #4: Object-Oriented Analysis An object model is an abstract representation of the process and data requirements of a system, based on separating the system into units called objects. Each object includes the data and operational characteristics of one business item. Object-oriented analysis is particularly important to business analysts as a business planning tool to depict the hierarchy of business functions, processes and sub-processes within an organization. Generally speaking, individuals working on object-oriented analysis should be competent in structured analysis.Object-oriented analysis requires a clear understanding of both the process and data modeling techniques, including the ability to separate systems into objects. Junior business analysts may get involved in the functional separation of the as-is state of a project, including forming a simple model of this state. From this model, an intermediate business analyst may consider developing activity diagrams to further clarify requirements. With diagrams in hand, a senior business analyst is likely to begin designing the to-be state during one-on-one interviews, group interviews and the documentation process. Essentially, each of the processes involved in object-oriented modeling ensures that the requirements are properly communicated to the developers and administrators. 

Competency #5: Testing When it comes to testing in business analysis, the first thing to understand is that the term applies to several different levels of work. First, business analysts are looking to test the products to validate whether the requirements have been met. They develop test scripts, test plans and test scenarios based on the as-is state as well as the to-be models. Testing requirements should be done in recurring stages to ensure that, by following the requirements, the desired deliverables will be met. The second level of testing is more familiar. This is testing the functionality of the physical product – testing lines of code and user testing of graphical appeal, speed and functionality. Black box testing and glass box testing fall into this category. As with the first type of testing, this testing also makes sure we reach the desired state, but it is based on user acceptance. In testing situations, business analysts design test cases and review the results from these scenarios. 

Competency #6: End-User Support It’s a common misconception among project teams that the project ends when the deliverable is completed. This isn’t true. Business analysts should be aware that end-user support after the product is delivered is almost as important. The role of the business analyst is not to act on behalf of the training team, but to complement the training team’s efforts with their knowledge of the business requirements. Much of the documentation created in the process of identifying the deliverables is invaluable to the development of training needs and end user support, including user manuals and reference materials. Business analysts work with end-users after deployment to clarify any high-level questions that need to be addressed. They also work closely with training managers and facilitators to define requirements to deliver the training supporting the business needs. Finally, business analysts assess and evaluate all feedback from team members, those individuals involved in the deployment of the product and any pilot or “test” groups, to ensure that the requirements necessary to correct any issues are addressed in future releases, iterations or versions of the product.   

Competency #7: IT Fluency How much IT knowledge is enough for a business analyst? The IT background for a competent business analyst depends entirely on the environment and possibly the industry vertical within which he or she works. It’s important to remember that IT fluency is just one of eight competencies that a successful business analyst must have. Also, just because an individual is fluent in a given technology does not automatically qualify him or her as a business analyst. This is a mistake made by many organizations. In theory, a great business analyst should have the wherewithal to understand which resources would be appropriate to help define and validate both requirements and specifications within a given project and product scope. In examining the different stages of a business analyst, a person at the junior level would need to have a clear understanding of the IT products and tools necessary for the business to function. An intermediate business analyst may understand interconnectivity and relationships between the tools and, perhaps, system architecture and information architecture. A senior business analyst will demonstrate his or her IT fluency across an industry vertical. He or she may also have a very clear understanding of how different IT products are related, interface with and connect to each other, as well as the positive or negative impact they may have in a given situation. 

Competency #8: Business Process Re-Engineering Considered the “big-picture thinking” of business analysis, Business Process Re-engineering (BPR) is a rapidly growing part of business analysis. In fact, lately many companies have been grouping business analysts around this specialty and developing teams of process analysts. This is the phase in which business analysts seek out both problems and opportunities. BPR uses a variety of modeling techniques in order to look at the bigger picture, while still thinking tactically. Business analysts’ responsibilities are often to identify, using various modeling techniques, possible areas of improvement to walk the client or user through each step of the process, examining individual tasks that could potentially be improved and then to actually make suggestions for improvements. 

You’ve Defined the Competencies . . . What Next? Now that the competencies have been spelled out, how do companies go about developing business analysts? First, they must develop and document specific job functions, and the task or tasks related to a particular level of competency. Next, they should assess existing knowledge. Finally, they must provide the training needed to develop the competencies outlined above. The first step in ensuring that an organization’s business analysts have the knowledge, skills and abilities necessary for success is to develop job functions, associated tasks and activities, and expected inputs and outputs, that would in turn support an organizations defined competency. When job descriptions have been determined and approved, it’s essential that organizations “take inventory” of the competencies their business analysts already possess. There are specific assessments to test these competencies. Such tools will establish the knowledge level of individuals in each competency area and of the team as a whole. If knowledge isn’t base-lined, improved cannot be observed, and overall performance for the individual and the organization. After establishing the business analysis knowledge and ability levels within an organization, the next step is to implement training to improve any competencies that may be lacking. The competencies above can also serve as a validation tool for such training. They can be used to ensure that the performance improvement program is comprehensive, that no behaviors or competencies are missed, through proper training, on the job experience as well as the appropriate coaching and mentoring. Keeping in mind the eight competencies, as well as the necessary people, processes, tools and technology, will put an organization on the path to better business analysis and, ultimately, to more successful projects.    

Reducing the Trend of Failed Business

Written by Kathleen B. Hass, PMP on . Posted in Articles.

Change is the norm; fierce competition is the driver, and lean thinking is the latest call to action. Organizations in both the public and private sectors are struggling to not only react to the velocity of changes in the economic, political and global landscape, but also to proactively stay ahead of the curve. Organizations bring about change through programs and supporting projects. Projects play an essential role in the growth and survival of organizations today, for it is through projects that we create value in the form of improved business processes, and new products and services as a response to changes in the business environment…

To manage change effectively, organizations need to be good at: (1) establishing business strategies and goals, (2) identifying new business opportunities, (3) determining solutions to business problems, and (4) selecting, prioritizing and funding projects to implement major change initiatives, and thus meet business needs and achieve strategic goals. The major change initiatives that transform businesses may be:

 

  • Business process improvement and/or re-engineering ventures to replace inefficient and outmoded legacy business processes and technologies.
  • Significant change programs to continually tune the organizational structure, capabilities and competencies as the business model changes.
  • New lines of business requiring new business processes, organizations, and technologies to support the new operations.

Since data and information are the lifeblood of virtually all business processes, information technology (IT) systems are often a major component of these large change initiatives. As organizations depend more and more on technology for business communications and operations, software-intensive IT projects are becoming more and more essential to turn an organization’s vision and strategy into reality. Executives across industries and in the public sector have their eyes on the portfolio of business change initiatives and the supporting IT projects to ensure that they: (1) invest in the right mix of projects, (2) develop expert capabilities to deliver flawlessly, (3) allocate their scarce resources to the highest priority projects first, and ultimately, (4) capture the added value to the business that was expected.

How Well Do We Execute Business Transformation Projects? What is the track record for completion of complex business process changes accompanied by software intensive IT systems? We have an abundance of surveys that have been administered during the last decade revealing the rather dismal record of project performance, particularly for significant IT projects. The StandishGroup 2004 Third Quarter Research Report exposed the difficult nature of managing IT projects today: 71% of projects were challenged, meaning over time or budget; or failed altogether, meaning nothing of value was delivered to the organization.1 A public sector source of equally illuminating information is from the U.S. Government’s Office of Management and Budget (OMB), the federal government agency that evaluates the effectiveness of federal programs, policies, and procedures, assesses competing funding demands among agencies, sets funding priorities, and approves funds for major capital projects. This OMB March 26, 2003 study stated that 771 projects included in the fiscal 2004 budget – with a total cost of $20.9 billion – were at risk. The conclusion: the high cost of failure is unsustainable. As a result, the Federal IT Project Manager Initiative was chartered to raise the capability and maturity of project management for major change initiatives in the Federal Government.2

What is the Root Cause of Failed and Challenged Projects? What is the cause of this very disappointing record? It is almost certain that there is no single cause of the persistent state of troubled projects. However, there is a growing notion that poor requirements engineering is one of the leading causes of project failure. Requirements are hard to get right, especially for software – very hard. It is becoming clear that business system development must be treated as a specialist discipline, implementing requirements formed through good requirements elicitation, documentation and management techniques. Existing requirements engineering approaches, methods and tools simply don’t deliver the results that are vital for the success of organizations both public and private. As businesses across the globe rely on successful business transformation projects with critical IT components for their very survival, the stakes are too high to continue in a business-as-usual mode. The question is: what can we do to begin to reverse the trend of failed projects? In a response to the belief that more rigorous attention to requirements management will add considerable value to project team effectiveness and greatly improve project performance, business analysis is emerging as a valued business competency.

Business Analysis: An Emerging Profession In their quest to build the organizational capabilities to select, prioritize and manage projects, organizations have discovered that the core competency of business analysis must be elevated in importance, developed, supported and matured. Most organizations have invested handsomely in innovation and new product development projects, and in IT systems to help operate the business and capture business intelligence about the marketplace. Indeed, over the last ten years or so, organizations have begun to embrace the practice of professional project management. However, businesses and government agencies are just now beginning to understand the importance of the capabilities needed to identify strategic business needs to operate effectively and efficiently, and to act on those needs expeditiously. Those who acquire and master business analysis competencies will more effectively react to and pre-empt changes in the marketplace, flow value through the enterprise to the customer, thus remaining competitive.

The Business Analysis Professional The International Institute of Business Analysis (IIBA), founded in 2003, is an organization dedicated to advancing the professionalism of the business analysis occupation. The IIBA is the independent non-profit professional association serving the growing field of business analysis. The IIBA membership consists of individuals with various titles and filling a diverse set of roles – requirements engineers, systems analysts, business analysts, requirements analysts, project managers, technical architects and developers, and consultants – anyone involved in analysis for systems, business or process improvement. 3 The IIBA has developed the Business Analysis Body of Knowledge (BABoK) for the profession. The IIBA plans to work continually with practitioners around the globe to upgrade those standards through education, research, and the sharing of effective tools and techniques. 4 In addition, IIBA is developing a Business Analyst Certification Program, unique to the profession of business analysis. Establishing a certification for business analysis will go a long way in standardizing and professionalizing the practice of business analysis. The Certified Business Analysis Professional exam is offered in North America in 2007, with an international launch in 2008. The certification will create common expectations on the part of organizations for the knowledge, skills and competencies acquired to become a Certified Business Analyst.

 

NOTES 1. The Standish Group International, Inc. (1999) Unfinished Voyages, A Follow-Up to The Chaos Report. Retrieved Apr. 08, 2005, from The StandishGroup Web site: http://www.standishgroup.com/sample_research/unfinished_voyages_1.php.2. Federal IT Project Manager Initiative retrieved December 27, 2005http://www.ocio.usda.gov/p_mgnt/doc/CIO_Council_Guidance.ppt#425,1,Federal IT Project Manager Initiative3. International Institute of Business Analysis home page http://www.iiba.com/ retrieved December 21, 20054. International Institute of Business Analysis, Business Analysis Book of Knowledge draft version 1.4http://www.iiba.com/pdf/BABok_Release_1dot4_2005Oct27.pdf retrieved December 21, 2005

Building a BA Centre of Excellence.

Written by Glenn R. Brule on . Posted in Articles.

Where to Start and What to Consider
 It strikes me as odd that, given the number of clients I have dealt with over the years, there remains a constant assumption that, because you provide training to a group of individuals in any given organization, you, by right of passage, become a “mature” practicing organization.   Get them together on an individual basis, however, and any one of them would tell you quite the opposite.  Disarray is perhaps the most fitting descriptor for this case.
We are always willing to acknowledge that which we continuously seek, industry standards. Sadly such industry standards are nowhere near where we want them to be.  Take, for example, the Chaos Report developed by the Standish group.  It maintains that, of all the projects it assesses in North America, only 34% of them would expect to finish on time, on budget and within the original scope defined.  ESI clients have shared with us in a recent survey the fact that the number one challenge in turning requirements into deliverables is poor requirements definition, followed by improper risk management and finally, scope creep.

 Why are our projects in a state of disarray?  It’s likely not the project management practice. Most organizations have a well-defined PMO and all the disciplines have been identified to conduct their day-to-day activities.  It is business analysis and the lack of structure, discipline and rigor around its day-to-day activities that, I believe, is the traceable root cause of project distress.

 It’s the situations where we have no formalized process for eliciting, analyzing, documenting, validating/testing, and tracking our requirements.  I’ve seen it time and time again where great degrees and variations of the above exist.  Organizations have 47 flavors of Business Requirements Document templates and they call this a standard. Their corporate solution development lifecycle gets hacked down, expanded, massaged, and tailored to meet a particular business unit’s need, and again we call this a standard. Methodologies are adopted and then tailored or crafted according to need or thought de jour!

 Another area of weakness: how can our resources possibly be expected to deliver with any degree of accuracy if we are not even clear on the tasks and activities that need to be performed to achieve the desired results?  Even more seriously, there is no linkage to our “standard methodologies.” As such, we insist on sprinkling the “magic fairy dust” over unsuspecting subject matter experts, and with a mighty push out the door in the direction of our stakeholders, who “don’t know what they don’t know,” expect them to achieve great results. Tell me that’s not a problem waiting to happen!  The other very interesting situation that continues to present itself where competencies and career definition are concerned, is that organizations continuously expect that PMs and BAs can perform each other’s given tasks.  Our resources are stressed out, and being asked to do more with less, in a shorter period of time. Clearly this need for speed is not working in our favor.

 It’s interesting to note that, while we would all acknowledge and recognize the errors of our ways, the real error is not being able to identify a starting point from which we can begin the process of maturing our BA practice. In a world where our daily activities are under constant scrutiny, I find myself repeating an old Japanese proverb “vision without action is a daydream and action with vision is a nightmare!”  The question still remains: where do we start?

Three things must be considered. 1) Have a plan, 2) Be patient and 3) Know your capabilities.  To have a plan, a project plan, means that, to some degree, you have considered the scope of what it is you and your team are about to embark upon. You clearly understand the major tasks and deliverables, and the time frame in which to accomplish such goals. Tactically, all tasks and activities that need to be accomplished to fulfill the needs of a developing Center of Excellence (COE) are easy to accomplish. Strategically, a cultural shift will not happen overnight, as a change in business practice must be carefully nurtured over a period of time, so we must be patient. Knowing your capabilities will allow you to understand the scope of what it is you are about to undertake. Being honest about the true level of maturity will allow the sponsoring organization to focus on the priority issues. Not all problems can be solved at once, even using advanced “technologies, thoughts and process.” For example, if it is understood that your organization is in its BA development infancy stage, why apply the most complex formulas to begin your baseline metrics. You must walk before you run.

Any good project manager or business analyst will tell you that, without active support, input and feedback, your initiative may be all for naught. Consider your stakeholders with thoroughness.

  • The Executive Team:  The strategic decision makers
  • Executive Sponsor:  May or may not be the same individual or individuals, but essentially hold the budgetary and resource means by which you will accomplish your endeavour
  • BA Director/Manager or Supervisor:  This individual will serve as the liaison between the tactical and strategic sides of the endeavour; they will be ultimately responsible for managing and maintaining the COE.
  • BAs:  Get them involved! Give them a sense of ownership; have them solve some of the challenges facing the organization; select a team of champions that represent the diversity of the BA group. After all they will be on the frontlines!
  • Project Managers:  Without requirements there are no deliverables. Without deliverables requirements have no meaning. This is a mutually exclusive relationship, and should be treated as such. Not including the project managers will encourage a siloed/ independent approach to the delivery of projects and alienate team members. Also consider that much of the structure and foundation of how PMOs evolved can be used as lessons learned for the development of a BA COE.
  • Functional Managers: There will come a time when the COE will have to engage the functional managers to provide additional resources for the definition and creation of requirements. As such, the borrowing of resources should not be impeded by a misunderstanding or lack of knowledge of what the COE’s purpose is.
  • Customers: Frequently, customers can be heard complaining about analysis paralysis, and are more focused on the outcome rather than the process used to get there.  It is the lack of knowledge and appreciation of this that is important to share with clients. Their feedback and assessment of the performance of the COE will be critical to its growth.

Have a plan, be patient and know your capabilities.

Levels of Maturity: Ask any organization and fifty percent of the time they tell you flat out that they are mature in their BA practices. They tell you they have three standard methodologies, and did some training, “our people are very competent” and, therefore they are operating at a Center of Excellence capacity.  The reality is this: while it may be true that investments are made to develop resources and put into place tools and methodologies this by itself does not constitute excellence.  The sum of all parts and the practice of organized and disciplined business analysis over a period of time constitutes maturity.  For the sake of this article, I have defined three possible levels of BA maturity. The titles themselves are arbitrary and may be changed according to the requirements of the sponsoring organization. It is the classification and characteristics of each level of maturity that will provide the needed assessment and guidance for development.

 

Level I – Community of Practice

Most organizations today are performing business analysis at a community of practice level.  They have recognized the need to develop the skill sets of their BA resources, and may have even gone as far as doing an assessment and evaluation of the level of competency of their BA group. As such they were able to identify any gaps that might exist in both performance and overall competencies and job descriptions.  Other organizations have also begun to put into place a solution development lifecycle and are likely to be in the process of either redefining or developing one.  A common question that comes up is this; what do we develop first, the people or the processes?  My response is go with the egg, eventually the chicken will come!  The processes need to define what needs to be done, and how it will be done, in the context of an SDLC. Job descriptions must define the ability, skill and knowledge necessary to perform the tasks and activities defined in the SDLC. The solution development lifecycle and job descriptions/career paths and competencies must be closely interrelated. They may begin to demonstrate an alignment with the PMO.

An overall acknowledgement by the organization of the role of the business analyst and its importance to the success of overall project deliverables is beginning to form. At this point our services, if sought, perceived as being reactive in response to an immediate need, and generally sought after as a utility. At this point, our accomplishments are only beginning to have any real recognition at the middle management level because of the tactical nature of our services.

Level II – BA Bureau of Maturity

There is no doubt in my mind that many organizations have demonstrated in some capacity their level of maturity given a specific area with the guiding principles in level of maturity. They may include some of or all of the following items, but in order to move from one degree of maturity to another demonstration of the following with consistency over a period of time is necessary.  A direct reporting structure to either the PMO or the CIO may be in place a Director of the BAB is likely to be the leader of the BAs and as such is making strides to present his team as a distinct business unit. The team is clearly a distinct pool of resources.  From a services perspective they are beginning to show signs of credibility amongst the business unit leaders as a result of consistent performance excellence. Business Unit Leaders are seeking out the team to provide assistance when needed, and the recognition of moving from a tactical to strategic role is beginning to form.

Level II – Center of Excellence

You’ve developed partnerships with the executive. Your team is sought after as the change leaders of the organization. You are clearly recognized as a customer service solution. You and your team have demonstrated your discipline both tactically and strategically. Most importantly, you have clearly defined the art of Enterprise Analysis (EA) and demonstrated your ability in the five areas of EA including, Business Architecture, Information Architecture, Application Architecture, Technology Architecture, and Security Architecture. Your team is providing and sponsoring studies to participate in overall corporate advanced and BPI & KPI’s and overall business effectiveness.  Your continuous assessment and evaluation of performance on internal process and customer satisfaction has become commonplace.

There are two keys to clearly understanding your level of maturity with the presented model. Acknowledge that it is likely that your organization may demonstrate maturity at a variety of levels given this framework. Also consider that true excellence must be demonstrated and evaluated as consistent over a period of time. As an example, training may be delivered in order to move the organization into a Community of Practice / level one of maturity. Training and learning do not stop here. Certification, coaching and mentoring, participation in improvement initiatives, and membership in organizations such as the IIBA, are the contributing factors that move an organization from one level of maturity to the next. In short, the sum of the parts is equal to the whole!

Glenn Brûlé, Director of Client Solutions for ESI International, has more than 15 years experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. Glenn’s background as an educator, communicator and business consultant has served him well through his many client engagements that have focused on understanding, diagnosing and providing workable business solutions to complex problems.In addition to his position at ESI, Glenn serves as a Director at Large for the International Institute of Business Analysis (IIBA). His primary responsibility is to form local chapters of the IIBA around the world by working with volunteers from organizations across various industries and government agencies. Glenn has successfully launched eight chapters in major Canadian cities and is currently working on launching eight more U.S. chapters and nine outside of North America. Glenn Brûlé is a frequent speaker at professional association meetings and conferences around the world, including ProjectWorld/World, Congress for Business Analysts and IIBA events. He has authored numerous articles on business analysis and was instrumental in the development of ESI’s white paper titled “Eight Things Your Business Analysts Need to Know – A Practical Approach to Building and Improving Competencies.”  

 
Watermark Learning Reports Increased Demand for Business Analysis Training

 As awareness grows in the project management industry, demand is increasing for business analysis training, since business analysis is frequently cited as a key problem area for providing inconsistent deliverables. As a result, companies such as Allianz Life have established a Business Analyst Center of Practice to ensure that their business analysts have the framework, processes, skills and techniques to excel in their profession.

 “Allianz Life engaged Watermark Learning for training because of its Masters Certificate Program in Business Analysis as well as its practical learning approach based on best practices,” said Lynn Lang, Allianz Life.

 “In today’s competitive landscape, businesses must perform with razor sharp efficiency and productivity,” said Terri Swanson, Watermark Learning, COO. “More business leaders are recognizing the value that business analysis training brings to an employee’s contribution and the effectiveness of an organization as a whole.”

 Since launching the Masters Certificate in Business Analysis in July 2005, Watermark Learning has received hundreds of participants in the program, including Allianz Life, a life insurance company.

 Allianz Life identified the business analysis process as their key problem area providing inconsistent deliverables. They established a Business Analyst Center of Practice to ensure that their business analysts had the framework, processes, skills and techniques to excel in their profession. As part of this initiative, Allianz Life looked to partner with a training vendor who could provide a professional business analysis certification program based on industry best practices, designed to specifically address their business needs.

 “Allianz Life engaged Watermark Learning for training because of its Masters Certificate Program in Business Analysis as well as its practical learning approach based on best practices,” said Lynn Lang, Allianz Life. “Not only will our business analysts receive a Masters Certificate, but they will also gain Professional Development Units through PMI as well as CEUs through Auburn University.”

 Watermark Learning is actively involved in raising industry awareness of the value of business analysis and was named an IIBA Endorsed Education Provider. It’s principals and founders, Elizabeth Larson, PMP, and Richard Larson, PMP, have helped develop the Business Analysis Body of Knowledge (BABOK), a document created to identify the key tasks that a business analyst would be expected to understand and perform