Skip to main content

Tag: Requirements

Business Analyst Development in the Insurance Industry

Written by Cynthia Low on . Posted in Articles.

Transformation. If the topic was not in the last Board briefing, it was in the one before that. A Celent review of the websites of largest 20 property and casualty and life/health insurers found the theme of business/operational/company transformation featured prominently on 40% of them. Major investments are being made in new technologies across multiple areas-policy administration, rules engines, predictive modeling, workflow managers-to change the way business is currently performed.

Enterprise change happens on multiple levels and with the effort of many individuals. It cannot happen without modifications to business processes at the transaction level, as committed employees work with business owners to analyze changes to the way work is done. Once that analysis is complete, support areas such as IT, HR, and Operations must work to implement the new methods. In most insurance companies, the people responsible for identifying, facilitating, documenting, and communicating the new business requirements are the business analysts.

In the Celent report The 18 Month Rule: Avoiding The Endless Project, (November 2006), it was noted that “between 30% and 80% of all large projects fail, with most estimates coming in on the higher side of this range.” The definition of failure is a project that is not fully implemented on time and does not meet the original requirements.

With this in mind, what is the state of development of the critical business analyst function in the industry? Celent researched leading insurance firms and found that the professional development of business analysts lags that of other functions. In many cases, the job lacks clear definition and boundaries. Skills are often learned “as and when” through individual effort and initiative. BA development has been described as an “afterthought.” In contrast to the underwriting (CLU, CPCU, IIA), claims (AIC), and project management (PMP) designations, there is no industry-wide accepted certification of business analysts.

The good news is that disciplined, structured development programs in the insurance industry exist and have been recently implemented. These initiatives have been justified by a disciplined examination of the role and the contribution of BAs.  This report examines these initiatives and also outlines the business case.  Additionally, action steps to move business analyst development to the next performance level are detailed.

What is a Business Analyst?

The business analyst operates at the intersection of business users and information technology. (Note: Since so much business analyst work is IT-related, in this report IT is used as a placeholder for all of the support groups necessary to implement new/revised business requirements.)

Core business analyst (BA) tasks deal with requirements definition, acceptance test case development and execution, and client communication. Defining requirements can include business process design, use case development, and user interface specification. In companies without a dedicated Quality Assurance area, BAs play a prominent role in acceptance testing and may be involved in other test activities (system and or integration testing) as well.  The BA is also recognized as a subject matter expert, having earned this designation through many years of experience with a specific business function or transaction system. Project management tasks can also fall to the BA, especially in smaller organizations or for implementations of limited scope. Emerging duties of the BA include the creation and maintenance of automated rules in rules engine applications, responsibility for business process management (BPM) tools, and the use of automated requirements generation tools.

Table 1: BA Duties

Always

Sometimes

Requirements collection, definition, and communication

Other testing (system,
integration)

Acceptance testing

Subject matter expertise

Client liaison

Project management

Creation and maintenance of automated business rules

Business process management automation

Use of automated requirements tool

Source: Celent

Organizational responsibility for business analysts varies. In some companies, the BA is part of the business. In others, the BA is firmly within IT. More than one insurer shared the fact that, in their company, reporting relationships for BAs periodically move from one side to the other.

The notion that wide-ranging tasks and changing reporting relationships create problems for BA development is a recurring theme in discussions with companies. One of the first tasks that leaders take is to build a fence around the duties of their business analysts. Bringing focus to the function is a key success factor in the leading development programs.

On the other hand, it does not seem to matter whether the BA resides in IT or in the business. What is critical is a corporate investment in the group and sustaining it over time.

When asked, BA managers describe the “ideal business analyst” using descriptors of both skills and personal characteristics. The skills required deal with a keen attention to detail, a “real world” knowledge of the business (especially company-specific operations, systems, and workflows) and effective verbal/written communication. However, because requirements gathering can be so relationship-focused, the best business analysts employ large amounts of empathy and influencing skills. Celent believes that the need to be able to “walk in a user’s shoes” and to exhibit an appreciation of their challenges at the coal face level tip the scales in favor of sourcing BAs from the business rather than from IT.

Table 2: Business vs. IT Sourcing of BAs-Skills Prevalence

Skills / Characteristics

Business       

IT

Attention to detail

Systematic thinking

Structured analysis

Deep understanding of the business

Communication

Empathy

Influencing

Source: Celent

Clearly, BA development is complex and sophisticated. This is not a “just add water and mix” HR exercise.

The Business Case

How do advocates champion the cause within their organizations? Most of the reported justifications are qualitative, but a quantitative case can also be made to justify investment.

Drivers of the change in companies already pursuing a more rigorous approach to development were varied:

  • Desire to support an outsourced IT model with more rigorous analysis by internal resources
  • Sponsorship at a senior leadership level
  • Need to backfill for an aging employee population
    (demographic trends)
  • Recognition that the requirements development process needs improvement
  • Adoption of new tools such as business rules engines

In some cases, a more financially based approach may be necessary to motivate investment. One method is to approximate the dollar value that is dependent on quality BA execution to deliver the full benefits estimated for a project delivery.

For example, assume the net benefit from a system build and implementation is US $6.25million. Using a typical life cycle framework (SDLC), estimate the percentage of the total work effort attributable to each phase. Multiply this phase percentage by the total benefit to arrive at a benefits-by-phase accrual. Then estimate the BA contribution percentage for the each phase. Multiply the BA contribution percentage for each phase by the benefit contribution for that phase, and the result is the BA dollar contribution by phase.

The BA contribution is highest in the requirements phase (80%), and very important in acceptance testing (65%) and implementation (50%) efforts. Using these assumptions, the model calculates that 41% of the total benefit of the entire project depends on the performance of the BA resource on the project ($2,546,875 / $6,250,000). The costs of a BA development program compare very favorably to the income from only a single project.

Conclusion

Successful transformation efforts will invest in the skill development of business analysts. The bad news is that this function has historically not received the attention it warrants. The good news is that there are companies with formal, disciplined programs that are in their second or third year of operation and are beginning to deliver results.

If improved delivery of transformation initiatives is part of your company’s strategy, Celent recommends that you:

  • Identify a senior leader to champion the effort of business analyst development.
  • Establish a certification program for business analysts in the next three months; get the program up and running immediately and perfect it later.
  • Pay for any registration and exam fees for employees pursuing the certification.
  • Implement bonus award recognition for employees who successfully complete the certification.
  • Commit to a goal: If there are no certified BAs in your organization, commit to completing certification of 5% of the BA population in the next year; if there are employees certified, issue a challenge to the company to double the number in the next six months.
  • Create a professional career path for BAs; if feasible, establish a. AVP or VP level business analyst leadership position.

If your company is investing in BA development, redouble your efforts and maintain your lead. If it is not, it is time to begin.                                                                                   

Mike Fitzgerald is a senior analyst in Celent’s (

www.celent.com) insurance practice and is based in the firm’s Chicago office. He has particular expertise in property / casualty automation, operations management and insurance product development. His research focuses on underwriting and policy administration, business process and operations, billing, and project / program management. Prior to joining Celent, Mr. Fitzgerald was Vice President of Enterprise Underwriting Solutions of Zurich North America, where he led the evaluation of technology alternatives to support a new underwriting product development process. He was a business architect at HCL Technologies America, and held a number of positions at Royal & Sun Alliance, including a regional operations executive role.  Mr. Fitzgerald began his career as a business analyst. Mr. Fitzgerald has a B.A. in economics from Davidson College in North Carolina and an MBA from the Fuqua School of Business at Duke University in North Carolina . He is a Chartered Property Casualty Underwriter and a certified Project Management Professional. He can be reached at [email protected]

I Don’t Have Time to Manage Requirements; My Project is Late Already! Part IV

Written by Cynthia Low on . Posted in Articles.

Requirements Summary

In this series we have provided an overview of requirements management, a description of the requirements management plan and its components, and some tips on how to negotiate for realistic time frames that include just enough time for the appropriate amount of requirements management.

Before we conclude, we need to make some important distinctions among terms that are sometimes used interchangeably. These distinctions are important, since they are not only invaluable for requirements planning, but also help clarify roles and responsibilities.

A Few Key Terms

The following are some terms which, when clarified, will aid in requirements management:

Project Management and Requirements Management.

Project management focuses on delivering the end product within constraints, such as time and cost. Project management includes the entire effort to produce the end result, of which requirements management is a part.

Requirements management focuses on defining the features, functions, capabilities, and characteristics of the end product, ensuring that they are defined completely and correctly.

Business Analysis and Requirements

Business analysis is the work of producing requirements. Business analysis can be performed in one project phase or many.

Requirements are the end result of completed business analysis work. Again, they describe the features, functions, characteristics, and capabilities of the end result of the project.

Projects, Products and Solutions.

Project. Endeavor or undertaking that produces a unique end product, service or result.

Product. We are using the term as it is defined in the PMBOK® to mean the end result of the project.

Solution. There can be both business and technical solutions. The business solution is defined by the sponsor and business subject matter experts. The technical solution, if there is a technical component to the project, is defined by the technical subject matter experts. After requirements have been defined, they are turned into a solution to the business problem that needs solving.

Life Cycles, Methodologies, Approaches

Life cycles describe the phases that take the project from its inception to its end. While it can be used to describe products (for example, the life cycle of a new pharmaceutical drug), concepts (life cycles of safety), or of living things (fleas and flowers), we are going to think of a life cycle of the project. Project life cycles are important, because they need to be managed.

Methodologies define how to get from the beginning to the end, usually through prescribed processes and templates. Frequently, phases and phase names are provided, as well as tasks to be completed within each project phase. The methodology may or may not prescribe multiple phases for completing business analysis.

Approaches are like “hybrids,” not quite life cycles and not quite methodologies. Examples are agile and Waterfall. Proponents of certain approaches often refer to “methods,” such as agile methods or SCRUM.

Summary of Requirements Management

Below are activities that need to be performed, either formally or informally, with a great amount of rigor or with practically none. They are closely aligned with the BABOK, version 2.0 but, since that document has not been published, we have avoided specific references to the Knowledge Areas. These are processes that need to be performed, regardless of the methodology or approach used.

Planning Business Analysis

These are the set of activities included as part of planning the business analysis phase, or phases, of a project. Whether planning for a new process, new or enhanced software, a new bridge or a feasibility study, deliverables and tasks must be identified, planning processes must be identified or created, roles and responsibilities must be agreed on, metrics established, and a plan for communications, formal or informal, must be created. Although not all project life cycles include a formal phase(s) for business analysis, the activities that comprise business analysis need to be taken into account.

As described in the series Overview, one of the key deliverables is the Requirements Management Plan, which is a set of documents that can be expected to change over time. The subsidiary plans that comprise the Requirements Management Plan are executed and updated at different points during business analysis.

Elicitation

This set of activities includes gathering stakeholder requirements and ensuring that their needs have been understood. Effective elicitation requires the ability to ask the right questions, listen to and synthesize responses, and record customer requirements. These skills are required for effective project management as well. Finally, elicitation tasks include determining elicitation techniques that are appropriate for the project.

Enterprise Analysis

In a nutshell, this process includes tasks to recommend, which projects to undertake by completing feasibility studies and cost benefit analyses. Once projects are undertaken, recommend the product scope.

Analysis

This set of activities includes the progressive elaboration of requirements from highest level to subsequently lower levels of detail, as more becomes known. Its purpose is to ensure that the business needs are truly understood and that requirements are defined completely and correctly. The requirements need to be elaborated in enough detail so that business clients are satisfied that their needs will be met, and the development team can create the end product or service.

Solution Assessment and Validation

This knowledge area describes how well the solution, or end product, solves the stated business problem and meets the approved requirements. This knowledge area includes activities related to making sure the end product matches the stated requirements, and is closely related to Quality Management.

Requirements Management and Communication

This set of activities involves the packaging of requirements to provide the level of documentation agreed upon in the Requirements Communication Plan (Business Analysis Planning and monitoring), taking into account the various audience preferences for format, level of detail, and frequency of communication. It also covers the handling of conflicts and issues. Finally, this knowledge area describes managing changes to the product and version. Because changes have to be managed across business analysis, it relates not only to Communications Management, but also to Integration Management.

Below is a matrix summarizing the interrelationship between the knowledge areas for Requirements Management, as shown in the BABOK, and project management, as framed in the PMBOK.

 

donthavetime1.png

                 Integrating Requirements Management and Project Management

Final Words

In summation, requirements management, whether done formally or informally is a vital aspect of project management. Without the requirements management plan, the overall project management plan is incomplete. Taking the time to plan and manage requirements will lead to a better end product and increases the chances of having satisfied stakeholders.

In addition, if we revert to when requirements were not managed, we can expect to see the cost of projects and defect repair, as well as scope creep continue to increase. However, if we spend too much time on requirements management, we are at risk of creating a burdensome process that will delay the project. It is important, then, to apply an appropriate amount of requirements management rigor to our projects to ensure that we have:

  • Thought about the approach we will take 
  • Identified the business analysis deliverables
  • Developed a requirements schedule
  • Planned for requirements communications
  • Clarified important roles and responsibilities
  • Communicated our plan to our sponsor, ensuring an understanding of the requirements management plan and its importance

This care will help all stakeholders in planning their time and encourages their active participation on the project.

References
Ambler, S. (last updated March 3, 2007), Agile Modeling, retrieved on January 7, 2008, from http://www.agilemodeling.com/essays/changeManagement.htm and http://www.agilemodeling.com/essays/examiningBRUF.htm

Davis, A. Just enough Requirements Management Part 1, retrieved on January 7, 2008, from http://conferences.codegear.com/article/32301.

IEEE Standard 610,

1990,International Institute of Business Analysis (2006). A Guide to the Business Analysis Body of Knowledge, version 1.6.

Project Management Institute. (2004) A guide to the project management body of knowledge (PMBOK®) (2000 ed.). Newtown Square, PA: Project Management Institute.

Software Engineering Institute (SEI’s) Square Project updated 5/12/05.

Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP

 

are Principals, Watermark Learning, Inc. Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results. With our academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. Our CBAP Certification Preparation class has helped several people already pass the CBAP exam. For more information, contact us at 800-646-9362, or visit us at http://www.watermarklearning.com/.

In this Edition: Managing Requirements, Getting Motivated, IIBA News and New Blogs

Written by Richard Lannon on . Posted in Articles.

sept15-time.pngOnce again we have a mix of the latest part of a continuing series requirements management plus plenty of other new and interesting contributions about the business analysis world – what’s going on now and what to look for in the future – that are sure to give you something to thinks about. Plus we have an update about what’s new at the IIBA. And, of course, our bloggers are back, including one new one.

  • I Don’t Have Time to Manage Requirements: My Project is Late Already! Part III. In this, the third in their series, Elizabeth and Richard Larson discuss the appropriate requirements management process for different projects; too much can be as bad as too little. 
  • Creating Motivation through Discovery. Richard Lannon talks about the importance of motivating people. He says it’s all about asking the right questions, listening and understanding – and then taking the appropriate steps. 
  • Will the First CBAPs Be a Credit to the Profession? Well Will You? Marcos Ferrer bills his blog as one of the world’s shortest blog. But he puts a very important question to all CBAPs. We hope you’ll answer him! 
  • The Cost of Validation. New blogger, Jonathan Malkin takes a look at how much is invested in developing systems but often nothing to ensure the system works, yet, as he points out, Solution Assessment and Validation is an important area in BABOK.
  • IIBA Launches Computer Based Testing of the CBAP Exam and a Letter from the President September 2008 are two important information pieces from The IIBA section of this site.
  • Defining Roles in the BA Life Cycle. Terry Longo asks if a single BA can be skilled in all aspects of the solution life cycle. He thinks single BA ownership makes sense but finding the right individual can be tricky – but not impossible.

Also don’t forget to check out our webinars and the Business Analyst Times book shop. And let us know what you think about this edition of BA Times.

Many thanks.

Adam R. Kahn
Publisher, Business Analyst Times
[email protected]

I Don’t Have Time to Manage Requirements; My Project is Late Already! Part III

Written by Cynthia Low on . Posted in Articles.

Getting to the Right Amount of Requirements Management

Choosing appropriate requirements management processes is critical. It is important to find the balance between the extremes of a burdensome process and no process at all. All levels of rigor can be appropriate, depending on the project and the organization where the process is followed. On some projects, following a great deal of rigor is required; on others little is. Scott Ambler, a proponent of the Agile approach, stresses the importance of “just-in-time JIT requirements elicitation.” Alan Davis supports “Just Enough” approach.

Some of us remember the pre-process and pre-methodology chaos of the 1970s. It was not uncommon for developers to sit down by themselves or at best with a single “user” to hammer out features of a new piece of software. Those of us who lived through that time remember some of the issues of the “users” who articulated their own needs, but who didn’t represent all the stakeholders. Or management who pitted one developer against another to try to get the software developed sooner, or the developers who dictated to the business what was in and what was out of scope.

Nevertheless, too much rigor can become overly-burdensome. Here are some pitfalls to avoid:

  • Misaligning the amount of rigor required with the size of the project with. One example of misalignment is having inappropriate levels of approval, such as requiring a formal Change Control Board for a small, well-understood, low-impact, and well-accepted change. 
  • Developing a requirements management plan that takes more time to create than developing the product • Requiring the creation of a requirements management plan “because that’s the process we follow here.” 
  • Handling all projects with the same degree of requirements management.

The “right” amount of requirements management occurs when there is enough rigor to: 

  • Reduce business and product risks 
  • Communicate effectively with all stakeholders. Communications becomes more complex with more stakeholders, so formalizing the communications on larger, more complex projects is usually appropriate. 
  • Help ensure that a quality product is delivered at the end of the project. 
  • Ensure the production environment is not jeopardized during deployment.

To this end, some applications of requirements management may need more emphasis than others. For example, one of the authors of this article was the project manager on a new retail application where the risk included the possibility of having incorrect prices on all the items in all the retail store locations. The project team spent several months planning traceability, testing, implementation, risks, communications, and other aspects of requirements management, and we implemented a three-year project within days of the projected date, only to have performance so poor, that holiday sales were in jeopardy. She also managed a project that she thought was “small,” ignoring requirements management completely. The team spent several months in “stabilization,” which was a nice term for cleaning up the mess that had been created.

Negotiating the dates

In all likelihood there will be stakeholders who want to complete the business analysis planning more quickly than seems reasonable. Because business analysis is not always perceived as value-added, some stakeholders will attempt to shorten the process. Here’s an approach to follow: negotiate not the deadline, but the deliverables. Trying to change the projected date is fruitless without negotiating the scope, which is comprised of the deliverables that will be produced. If the sponsor wants to bargain to reduce the business analysis time, here are some tips to try: 

  1. Make sure your sponsor is aware of the requirements process and/or methodology and why it was chosen. This implies that thought has been given to that requirements approach and that it was chosen with care. For example, a sponsor may have heard of “agile” projects and may want to dictate that your project be done “agilely.” Emphasize the benefits of the chosen approach. 
  2. Show the sponsor the deliverable Work Breakdown Structure, which serves as a “picture” of the scope of business analysis work. Explain why each deliverable is important to the project outcome. Give the sponsor a choice of removing deliverable(s), but for each one the sponsor wants removed, explain the risks and impacts of discarding it. You can also recommend which deliverables to remove. The sponsor will appreciate your understanding of the impacts and ability to present alternatives and the associated benefits and risks. 
  3. Be prepared to quickly re-estimate the effort with the removal of deliverables. You will lose credibility if the planning process drags on with iterations of estimating, reviewing, and changing, without solid agreement. 
  4. Be sure to be prepared when meeting with the sponsor. Talk to key stakeholders before the sponsor meeting to understand which deliverables really are negotiable, and which are essential to the end product being delivered. Work with the key stakeholders to obtain as close to a consensus as possible, so that you can present your recommendation neutrally thus truly representing the client perspective. 
  5. Be sure that you absolutely understand the business problem that the sponsor is trying to solve. Any deliverables that do not help in solving the problem should be removed from the WBS. In addition, explain how managing requirements can actually save time. Explain how using requirements management tools, such as the traceability matrix, can save time because it ensures there is a clear linkage between a requirement and the business problem being solved. By tracing requirements we not only help ensure that every requirement adds value, and that every approved requirements will actually be produced, but also that scope creep is less likely to occur.

If during requirements planning new deliverables are uncovered, or changes to deliverables are desired, it will be necessary to modify the WBS, create new tasks, re-estimate the amount of time it will take to produce the new or changed deliverable, and discuss what changes in the schedule are required. Negotiating with the sponsor, as described above, is important whenever there is a change. Sponsors typically want to know what every new requirement will cost, so be prepared with estimates when discussing them.

References: Ambler, S. Agile Modeling, http://www.agilemodeling.com/essays/changeManagement.htm and http://www.agilemodeling.com/essays/examiningBRUF.htm 
Davis, A. Just enough Requirements Management Part 1 http://conferences.codegear.com/article/32301

Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP are Principals, Watermark Learning, Inc. Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results. With our academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. Our CBAP Certification Preparation class has helped several people already pass the CBAP exam. For more information, contact us at 800-646-9362, or visit us at http://www.watermarklearning.com.

The Cost of Validation

Written by Jonathan Malkin on . Posted in Articles. 1 Comment on The Cost of Validation

Initial Analysis $100,000
Development and Execution $500,000
Validation Priceless

 

It is amazing, a client pays 100K to 2M or more to develop a system and $0 to make sure the system works. How do we ensure the system meets our needs?

Solution Assessment and Validation

Solution Assessment and Validation is one of six knowledge areas defined in the BABOK (Business Analysis Book of Knowledge). I recently helped a government client document and execute validation under FDA 21 CFR Part 11 rules.

FDA 21 CFR Part 11 Computer Systems Validation outlines validation methods to ensure the system works as expected and meets the business need. All systems must have a Validation Plan, User Requirements, Functional Requirements, and Test Scripts.

User Requirements are general requirements concerning the use of a system.

Functional Requirements break down User Requirements into how users will specifically interact with the chosen system.

Test Scripts are written for each Functional Requirement.

Test scripts are executed, witnessed, and counter-signed. After execution the organization has a fully documented and auditable trail to show the system was properly installed and qualified to meet the business need and technical requirements.

In addition, a validated client documents Standard Operating Procedures for use of the system. This step forces the organization to take a close look at how the system will be used and why it is being implemented. Any time people spend to think through how and why they use a system is a good thing!

Downside?

The downside is less flexibility in making system changes. A COTS system that is highly configurable and easily changed is now subject to a multi-level change control process. A simple configuration change may take days or weeks to propose, authorize, document, and implement.

Conclusion

21 CFR Part 11 Validation is worthwhile where the cost of deviation from process greatly exceeds the cost of change. In the case of manufacturing pharmaceutical drugs or vaccines, minor deviations in process can impact the lives of millions of people with drastic consequences. It’s in these very cases that validation is indeed worthwhile to ensure systems meet the safety and security concerns of all.

Jonathan Malkin is a Business Analyst at Plateau Systems. Jonathan provides configuration, integration, documentation, and deployment support services for a leader in Talent Management Systems. Jonathan’s areas of support include 21 CFR Part 11 Validation and customizations to COTS software for which he has won multiple awards. His experience includes work in the federal government, telecommunications, mortgage and banking, and custom software development industries. Plateau Systems is a leading global provider of adaptable, unified web-based talent management software, content and services to onboard, develop, manage and reward talent.