allPM.com :: Theme of the Month: From Project Management (PM) Certification to Business Analysis (BA) Certification By Greta Blash, PMP

Theme of the Month: From Project Management (PM) Certification to Business Analysis (BA) Certification By Greta Blash, PMP

Published on Monday, April 09, 2007 - 04:04 PM

Just as PMI has established a baseline for the project management profession, so has a new organization been established for Business Analysts (otherwise known as Systems Analysts, Business Systems Analysts, etc.). Since many of the processes identified during the Initiating and Planning Processes within the PMBOK® Guide are often done by a combination of project managers and business analysts (or one person performing both roles), I am going to address the similarities and differences between the two “Bodies of Knowledge” based on my previous experience in both of these roles.

The IIBA

In order to understand the “beginnings” of the IIBA, we set off to do some investigatory reporting and discover the story behind the initial organizational effort.

In August 2003, during the planning session of the first Business Analyst World conference to be held in Toronto, ON in May 2004, a member of the advisory committee suggested that it was time the BA community established a professional association to support the needs of Business Analysts - similar to the Project Management Institute (PMI). That suggestion was embraced by 23 like minded individuals and under the leadership and guidance of Kathleen Barret, resulted in the formation of the International Institute of Business Analysis™.

On March 3rd, 2004, the IIBA became the official association for Business Analysts. 35 representatives from two countries – the US and Canada – formally joined the organization, ratified the constitution and voted in the officers. Recently IIBA celebrated its third anniversary and the statistics demonstrate its success, all accomplished with a staff of volunteer and three paid employees.

3,500 members
62 Countries
102 Chapters

The organizations growth has been remarkable and it reflects the growing demand for capable, qualified Business Analysis professionals.
If you are interested in joining and supporting this exciting new profession, go to www.theiiba.org. You can get more information on chapters in your area (<a href="http://www.theiiba.org/content.asp?contenttype=Chapters"target="_blank">http://www.theiiba.org/content.asp?contenttype=Chapters).

BA Certification
In November 2006, the IIBA held its first certification exam in Orlando, FL. The certification program has been carefully designed to be in compliance with the International Standards Organization (ISO) 17204 standard for certifying the competence of personnel. Interested BAs who wish to sit the exam must qualify. The criteria includes 7500 hours of business analysis experience in the past 10 years, 21 hours of BA related education in the past four years and two references. Additional exams are being held in 2007 - eight scheduled exams will be held in Canada, US , UK and Australia. The exam consists of 150 multiple choice questions and is proctored over a three hour period. Successful candidates will receive the designation of Certified Business Analysis Professional TM.

The BABOK™

The release of the IIBA Body of Knowledge was the work of many dedicated volunteers devoting hundreds of hours to the task. Version 1 was released at the 2nd Annual General Meeting in April 2005. Version 1.6 was released at the 3rd AGM and formed the basis for the items contained in the certification exam. The BABOK is the “sum of knowledge within the profession of Business analysis and reflects what is considered currently accepted practice.”¹. the BABOK™ outlines the set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems

This document is available on the International Institute of Business Analysis™ (www.theiiba.org) web site.

The PM view of the BABOK

To understand how the roles of the Project Manager and the Business Analyst overlap, a few definitions from the BA BOK have been included here:

Business Analysis - “the set of tasks, knowledge and techniques required to identify business needs and determine solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement or organizational change.”²

Business Analyst Role - “works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.”³BA BOK Knowledge Areas

The BABOK lists six areas of knowledge that include:

Enterprise Analysis (feasibility studies, business case, pre-project )
Requirements Planning and Management (stakeholder analysis, activity planning, requirments change management)
Requirements Elicitation ((techniques for obtaining the right information from stakeholders)
Requirements Communications (presentations, communication planning, liaison between business and IT)
Requirements Analysis and Documentation (determining the solution, documenting clear, concise requirements)
Solution Assessment and Validation (reviewing requirements and solutions, and getting sign off)

The following diagram depicts those knowledge areas and their relationships:⁴

Enterprise Analysis (EA)

This initial knowledge area addresses the collection of pre-project or project selection activities. The results of this effort are used as input to the project selection process. Depending on the level of effort and the specific role of the business analyst in an organization, these activities may be a feasibility study, a business architecture initiative or a project in itself. These activities are most often performed by a Business Analyst (or a Project Manager playing the role of the Business Analyst since no formal project effort has been initiated) and would be considered as part of the Portfolio Management effort in the project management world.

Enterprise Analysis activities normally begin after the organization’s executive team has identified strategic plans and goals and continues with the gathering of the information required to propose new programs and projects for a go/no-go decision on whether to select, prioritize and fund a new project The implementation of a project will require that the Enterprise-level BA update the Business Architecture documentation. (This entire subject of Enterprise Analysis and the Enterprise Architecture is a subject/practice of its own, similar to that of Portfolio Management in the Project Management area).

Enterprise Analysis (EA) activities performed by the Business Analyst include those listed below:

Creating and maintaining the Business Architecture
Conducting feasibility studies to determine the optimum business solutions
Identifying new business opportunities
Scoping and defining the new business opportunity
Preparing the Business Case
Conducting the initial Risk Assessment
Preparing the Decision Package

Often the project manager is asked to participate in some of these EA activities, but would be considered to be functioning as a business analyst. These can often involve the Feasibility Studies that may be conducted as a mini-project to help determine the viability of an idea. Many of the techniques used during a Feasibility Study are identified in the Integration Knowledge Area of the PMBOK® Guide, and as a result most certified project managers are familiar with these.

The resulting documentation of an Enterprise Analysis effort is provided to the project manager, depending on the level of effort, either as the Project Charter, or as the supporting documentation to be used as part of the Project Initiation processes. The BABOK includes the development of a project scope to provide a documented basis for building a business case for proposal to the project governance group. This scope document becomes the initial scope statement that is included in the Project Charter. As the project proceeds, and the requirements are further refined, the final Scope Statement is developed and baselined.

Project Initiation

Once a project has been initiated, the knowledge areas of the BABOK and the Initiating and Planning process from the PMBOK overlap. In order to ensure that the effort during this time in a project is well coordinated, the definition of the specific roles and responsibilities of both the project manager and the business analyst should be defined.

According to the BABOK, the BA “supports the project manager in initiating and planning the new project. During the project initiation and planning processes, the BA is eliciting, analyzing, documenting and validating business requirements and collaborating with the system architect during initial design of the business solution to be delivered.”⁵ In the specific case where a new IT-enabled business solution is being considered, the BA is responsible for establishing a strong relationship between the business and technical communities and “translating” the specific languages of each group.

The BA works in partnership with the PM to update the Business Case at key checkpoint control gate review to provide management with information to help determine whether to continue to invest in the project. (For more information on the Business Case development and usage, refer to the article Casing Out the Problem, by Steve Blais).

Project Requirements

The major emphasis of the Business Analyst role pertains to that of Requirements. These are addressed in the next four Knowledge Areas including:

Requirements Planning and Management
Requirements Elicitation
Requirements Analysis and Documentation
Requirements Communication

Requirements Planning and Management (RP&M)

The Requirements Planning and Management (RPM) Knowledge Area defines the work of the Business Analyst throughout the requirements process and begins with the planning and management of the requirements gathering activities. Through this effort the definition of the activities and how they will be performed on a project, in accordance with any existing standards in the organization, are identified. Since the BABOK includes the identification of key roles, selection of requirements activities, management of the requirements scope and ongoing communication of the requirements gathering status as the BA activities, the overlaps between the roles of the PM, as defined in the PMBOK, and the BA must be resolved for each project effort.

Since the Project Manager and the rest of the project team are relying on the Business Analyst to provide clearly defined requirements for the project that can be managed and approved at the conclusion of the implementation effort, the identification of specifically how these “requirements” are planned and managed is critical to the success of the project.

In business-oriented projects, where the first “phase” further elaborates the “what” or “requirements” of the project effort initially identified in the project charter, the planning function should be shared between the project manager, who is ultimately responsible for the project, and the business analyst, who is responsible for the execution of the requirements definition. As a result the identification of the roles, activity definitions, and communication plans assigned to the BA, become a subset of the overall project roles, activities and communication plans that are the responsibility of the project manager. When these distinctions are not clearly defined, or multiple roles are played by the same individual, the process becomes less specifically defined.

The BABOK identifies the following tasks in the Requirements Planning and Management Knowledge Area that the BA will define and manage though the requirements gathering process (some of the definitions have not been completed as of version 1.6):⁶

Understand Team Roles for the Project

Identify and Document Team Roles for the Project
Identify and Document Team Role Responsibilities
Identify Stakeholders
Describe the Stakeholders
Categorize the Stakeholders

Define Business Analyst Work Division Strategy

Divide Work amongst a Business Analyst Team

Define Requirements Risk Approach

Identify Requirements Risk
Define Requirements Risk Management Approach

Determine Planning Considerations

Identify Key Planning Impact Areas
Consider the System Development Life Cycle (SDLC) Methodology
Consider the Project Life Cycle Methodology
Consider Project Risk, Expectations and Standards
Re-Planning
Consider Key Stakeholder Needs and Location
Consider the Project Type

Select Requirements Activities

Determine Requirements Elicitation Stakeholders and Activities
Determine Requirements Analysis and Documentation Activities
Determine Requirements Communication Activities
Determine Solution Assessment and Validation Activities

Estimate Requirements Activities

Identify milestones in the requirements activities development and delivery
Define Units of Work
Estimate effort per Unit of Work
Estimate duration per unit of work
Identify Assumptions
Identify Risks
Modify the Requirements Plan

Manage Requirements Scope

Establish Requirements Baseline
Structure Requirements for Traceability
Identify Impacts to External Systems and/or Other Areas of the Project
Identify Scope Change Resulting from Requirement Change (Change Management)
Maintain Scope Approval

Measure and Report on Requirements Activity

Determine Project Metrics
Determine the Product Metrics
Collect Project Metrics
Collect Product Metrics
Reporting Product Metrics
Reporting Project Metrics

Management Requirements Change (this area has not be fully defined yet in version 1.6)

Plan Requirements Change
Understand the change to requirements
Document the changes to requirements
Analyze change requests

Many of the preceding tasks are very similar to those identified in the PMBOK (and in fact in many cases the PMBOK is specifically referred to for additional information). The BABOK states that the Business Analyst needs to “develop, define and manage the roles and tasks associated with requirements gathering, in coordination with the project manager.”⁷

During the Execution process, as identified by PMBOK, the BA BOK identifies three iterative knowledge areas:

Requirements Elicitation
Requirements Analysis and Documentation
Solution Assessment and Validation

In addition to the definition of tasks the BABOK also includes various techniques that can be used in fulfillment of each task. In a future version it is expected that an entire chapter will include additional information regarding basic and advanced skills that can be utilized by a business analyst. Many of these skills refer to “tools and techniques” that have evolved over the years. It is anticipated that a “Tool of the Month” column, to help educate project managers to the terminology, purpose and usage of these various analysis tools can be included in the allPM.com newsletter. If such a column would be helpful to you, please email Co-Publisher Judy Umlas at judy.umlas@allpm.com to let her know.

Requirements Elicitation (RE)

The Requirements Elicitation (RE) knowledge area defines some standard techniques used to collect the requirements of the system. Depending on the scope and type of “system” that the requirements pertain to, various methods can be utilized based on the applicability of the technique’s purpose, key features and strengths and weaknesses. Often multiple methods are utilized to ensure that complete understanding of the requirements is captured.

Requirements Analysis and Documentation (RA&D)

The Requirements Analysis and Documentation Knowledge Area defines the methods, tools and techniques used to organize the raw data collected during Requirements Elicitation, identify gaps in the information and define the requirements of the solution in a structured, comprehensive manner. This documentation includes the iterative process of refinement based on stakeholder feedback.

The results of this document, often know as a Requirements Document (the basis of which is used to identify the Scope Statement identified by PMBOK), will be used to develop the plan, time, resource and budget estimates for the follow-on project efforts required to implement a solution(s) to fulfill the identified requirements.

In the process of requirements analysis there are a number of Requirements Specifications developed. These obviously have different meanings to different organizations. It behooves a project manager to have a thorough understanding of the development and usages of these various requirements specifications as they will be used to manage the delivery of the solution as the project proceeds.

Requirements Communication (RC)

The Requirements Communication Knowledge Area is an ongoing, iterative activity that is done in parallel with Requirements Gathering and Requirements Analysis and Documentation and includes the presentation, communication, verification, and approval of the requirements from the stakeholders.

Just as a Project Manager must determine the most appropriate method for the various communication requirements of a project, an effective business analyst must present the requirements gathered in a manner appropriate for the intended audience. In addition to the format selected, the same questions must be answered:

When and where should the information be communicated
What should be included in the communication and what approach should be used
How should be information be “packaged” to achieve greatest understanding

Requirements must be “packaged”, reviewed and approved as part of the governance process as defined by an organization. These approved requirements become the “guts” of the scope baseline that the PM manages as part of the integrated change management process.

Solution Assessment and Validation (SA&V)

This knowledge area covers the business analysis tasks after the solution has been developed and helps ensure that the solution meets the stake holder objectives, is thoroughly tested, and is implemented smoothly. In this area the Business Analyst works very closely with the Quality Assurance organization supporting user acceptance testing, defect reporting and resolution.

This area is highly dependent on the type of project being implemented. If the project is a process improvement effort there is little if any IT technical solution involvement. On the other hand if a new IT system is being developed (or more likely in this day and age, a packaged solution of ERP is being implemented), the BA becomes more involved in the change management that is required in the business community to adapt to the new way of “doing business”.

The managing of the originally defined and accepted requirements and their final implementation is critical to meeting the expectation of the business. If the requirements have been clearly and thoroughly defined, the assessment and validation of their implementation can be accomplished. If, on the other hand, when the requirements have been defined at a very high level, the final acceptance and ability to meet the expectations if difficult and often impossible, resulting in projects that are deemed “unacceptable.”

Summary

As Maureen McVey, Director of Business Analysis for International Institute for Learning, noted, “The BABOK was a defining moment, literally and figuratively, for me. The BOK provided a framework for me to create a personal development and career path. I wasn’t just an employee running around trying to gather requirements and put them on paper, I was contributing to a solution and as a professional was accountable for the product that was delivered. It also helped me to define my day-to-day work which included both PM activities (WBS, budget) and Business Analysis activities (elicitation, requirements).”

IIBA has come a long way in three short years. It is to the credit of the hard work of volunteers and members, under the leadership of Kathleen Barret, who are supporting the career path and certification of the Business Analyst profession. The organization has had it bumps along the way, but with time and continued effort the IIBA will join PMI® as a world-class professional organization. For more information on the IIBA and how you can contribute go to www.theiiba.org.

To me, the BABOK and the work that the IIBA organization has done elevates the activities that those of us who have spent our careers in IT-related projects to a profession. Many of us, including myself, have followed the route of Business Analyst to Project Manager, and often times, because of the “lean” project environment today, still play both roles on any one project.

The Business Analysis Body of Knowledge (BABOK) is not a methodology, but rather a framework similar to the PMBOK Guide. While it defines activities, tasks and techniques that a business analysis professional needs to know, it does not specify the sequence of these components. The information provided should be used to help guide the work within the analysis discipline of requirements gathering and validation.

The tools and techniques from years ago may have changed slightly but the basic process of ensuring that clear understanding of the business requirements, the management of those requirements, and the validation that those requirements are met at the end, has not changed. And to that end the BABOK is a welcome addition. As in the television industry, we all hope that the “spin-off” will run as long as the original series.

We all look forward to the completion of this Body of Knowledge and the usage of it within each and everyone one of our projects in the future.

Footnotes:

¹ BA BOK, version 1.6, pg 7

² BA BOK, version 1.6, pg 8

³BA BOK, version 1.6, pg 9

⁴BA BOK, version 1.6, pg 15

⁵ BA BOK, Version 1.6, pg 19

⁶ BABOK, Version 1.6, pg 61-151

⁷ BA BOK, Version 1.6, pg 65

© 20007 allPM.com

About the Author

Greta Blash, MA, PMP has extensive experience as an executive and consulting IT professional. Her areas of experience include project management, software product management, information system implementation, with emphasis in the areas of system implementations and conversions, customer relationship management (CRM), data warehouse/business intelligence (DW/BI), and data management. She has developed customized life cycle methodologies for major international organizations as well as training courses in the areas of project management, requirements analysis and data management and has spoken frequently on these topics at conferences world-wide. She is currently a Senior Instructor at International Institute for Learning (IIL) and resides in Las Vegas.

What area of organizational business objectives is most impacted by projects?