Before we can start building a business solution, we need to know what the users of that solution want it to do for them! Thus, the business analyst's most important role is to ensure that what the users (and other stakeholders) want is carefully captured, documented, analyzed, and then transmitted unambiguously to the people who are actually going to implement it.
In many cases, the term "business solution" implies an information technologies (IT) solution with a software application as one of the end products. However, a solution can involve other technologies as well, or it might even encompass a simple business process improvement project with no new technology added. Business Analysis Planning and Monitoring
The project manager and project team rely on the business analyst to provide well-defined and documented requirements. This requires a disciplined and methodical approach to requirements elicitation, documentation, and communication. The Business Analysis Planning and Monitoring Knowledge Area in Chapter 2 of the BABOK® focuses on this topic, presenting specific tasks that the business analyst should carry out in order to achieve high-quality, unambiguous, and actionable requirements. This planning process allows the business analyst to However, before any work is done, the Business identify both tasks and people (including project team Analyst needs to carefully plan the work to be done, members and stakeholders) that are instrumental for which deliverables to produce, identify the effective requirements elicitation. The success of the stakeholders involved (and how he will communicate requirements elicitation process and the quality of the with them), and how to monitor whether the BA efforts requirements themselves depend on quality work, for are on course with the overall project. These tasks are which an effective plan addressing tasks and overall described in the Business Analysis Planning and process management is quite important. Monitoring Knowledge Area.
Deliverables
As it turns out, the well-documented techniques of project management are well-suited to defining how business analysis activities are going to be performed in the context of the project. In some ways, you might consider this planning process as a mini-project within the scope of the "actual" or overlying project.
If the project were to be developed sequentially, business analysis planning would begin after the enterprise analysis has been completed. In reality, of course, you may need to start planning your requirements gathering even before all the enterprise analysis is finished.
The deliverables of BA Planning and Monitoring include lists of:
Identified stakeholders associated with the project, along with their roles and responsibilities. Deliverables to be produced along with the templates, standards, etc. used by the organization. Specific tasks for requirements gathering along with the people responsible for those tasks. Techniques used to perform the elicitation and communication activities, as well as to estimate the amount of BA work required. Metrics used to assess the BA work and estimates on the duration of BA tasks.
Upon completing this lesson, you should be able to:
Identify the stakeholders for a particular project or initiative. Define the roles and responsibilities for the different stakeholders as they pertain to the current project. Determine the approach to be selected for performing BA work, including the SDLC methodology to be used. Develop a Business Analysis Plan, which includes the planned BA activities, estimates to complete required business analysis tasks, and deliverables that the BA will produce. Develop a communication plan for the BA effort. Develop a plan to manage requirements implementation (i.e., how requirements are approached, traced and prioritized), as well as define a process for requirements change. Define the metrics to be used in assessing the business analysis work effort and the process used to determine if the BA effort needs preventive or corrective action.
Plan Business Analysis Approach
Carrying out the project-related business analysis activities requires a carefully assembled plan. Developing this plan is the responsibility of the project manager working with the business analyst. Without a good plan, there is a danger of not capturing all the requirements or defining them poorly, which could lead ultimately to a final product that doesn't meet the users' acceptance criteria.
Some industries or organizations have specific methodologies for building their products. For instance, software development has the System Development Life Cycle (SDLC) and Project Life Cycle (PLC) methodologies. Since these kinds of methodologies usually include requirements elicitation, a business analyst working for a company that has adopted such a methodology will need to follow it in developing a requirements process plan.
Additional factors to consider during this planning stage include:
Stakeholder expectations Organization or industry standards (that may govern how projects are implemented) Do the business analysis planning activities need to be tailored for a particular project or initiative?
Steps to Implementation
The first step is to identify all the stakeholders from whom the business analyst will elicit requirements. These stakeholders include anyone who has an interest in the functional aspects of the final product. For example, the user of a software package definitely has an interest in how the package works. However, an upper-level manager who only wants to see reports (printed on paper) generated by that software package may not care how the software works. She only wants to see the reports!
At this point, the business analyst must decide how to approach the relevant stakeholders. Some may be physically remote and require travel or teleconference sessions while others are local and amenable to in-person meetings.
Next, the analyst must determine which specific methods of eliciting requirements are appropriate both for the stakeholder being interviewed and the type of information that needs to be acquired. Details of these methods are presented in Lesson 4.
After the business analyst has captured and compiled all the requirements, he must decide upon an appropriate approach for analyzing these requirements and determine the best approach for documenting them. Along with documentation, communication plays a critical role. No matter how well requirements are written down, they are not very useful unless the business analyst can communicate them effectively to various decision makers and the technical personnel who will implement them. These activities are covered in Lessons 5 and 6.
Finally, business analysts must work with a project delivery team to identify implementation tasks in the form of a work breakdown structure (WBS) and formalize a means of evaluating how well the solution meets stakeholders' needs. This is covered in Lesson 7.
The Business Analysis Approach
According to the BABOK,® a Business Analysis Approach describes the set of processes, templates and activities that will be used to perform business analysis in a specific context (i.e., a project or initiative).
There are many ways to approach business analysis work. One approach is to use established methodologies for software development (Waterfall/Agile) or business process improvement (Lean/Six-Sigma). An organization can also use a proprietary methodology or in-house practices and process. The Organizational Process Assets defines the standards, templates and deliverables regarding how business analysis is done in the organization and how it fits into a project and other activities.
Other factors to consider when planning the BA approach are:
the Business Need - the problem of opportunity faced by the organization (and the reason for the project!) and Expert Judgment - the BA expertise either from within the organization and/or the industry at large
BA Methodologies
A plan-driven methodology emphasizes Change-driven methodology focuses on rapid planning and formal documentation of the delivery of solution capabilities in an processes used to accomplish a project and of incremental fashion (i.e., Agile) and direct the results of the project. This methodology is involvement of stakeholders to gather feedback concerned about reducing upfront risk and on the solution's performance. This having control over outcomes over the delivery methodology will accept a higher degree of of a solution. This approach is preferred when uncertainty (risk) regarding the overall delivery requirements can effectively be defined in of the solution in exchange for the flexibility to advance of implementation and the risk of an manage requirement changes. incorrect implementation is unacceptably high (think medical equipment or an oil refinery), or when managing stakeholder interactions presents significant challenges.
Plan-driven vs. Change-driven Methodologies
Almost all methodologies fit along a spectrum between Plan-driven and Change-driven methodologies.
1. Which one of the following activities is not part of the Plan Business Analysis Approach task? a. Abiding to regulatory standards and federal guidelines. b. Understanding the problems or opportunities facing the organization.
c. Developing a marketing plan to promote the product in the local market. d. Using the standard document templates mandated by the organization.
2. According to the BABOK,® Organizational Process Assets is an input to all of the tasks in the Business Analysis Planning and Monitoring Knowledge Area. As such, it includes: a. Methodologies for process change or software development, i.e. Waterfall or Agile. b. Real estate and other assets as described in the organization's Annual Report. c. Corporate governance standards followed by the organization. d. A and C only. e. A and B only.
Team Roles
Stakeholder roles are usually described in a responsibility matrix (RAM), or roles and responsibilities table, sometimes called a RACI matrix.
The initial step in the requirements planning process is to work with the project manager to identify all roles needed to carry out the project (the entire project, not just the roles associated with requirements gathering). Some organizations have defined roles while others give the project team more flexibility. The BABOK® lists numerous possible roles; here are just a few of them:
Executive sponsor - has final go/no-go decision authority. Business analyst - works with project requirements.
Project manager - oversees the overall strategy and tactics for completing a project. Developer - Usually a technical person who creates IT or engineering solutions designed to meet stakeholder needs. Quality assurance analyst - ensures that project activities are carried out as formally specified by organizational, industrial, or professional standards. Application architect - creates a high-level design or approach for solving a particular business problem. Database architect or analyst (often a database administrator, or DBA, with development skills) - technical person who establishes the data storage structure to be used in a given solution. End users - people who interact directly with the project's end product. Stakeholders - anyone affected or impacted by a project's end product.
Stakeholders Information about each stakeholder Project stakeholders are perhaps the most important people in the life should include the following: of a project because they have so much influence over the project's Name existence. They control financial resources and specify the desired end Job Title/Description product. Different stakeholders have different "stakes" in the project Organization/Company so the analyst must look at each stakeholder and identify their Mailing and/or Physical Address individual needs and interests in the project. Sometimes stakeholders Phone Numbers may not be obvious - end users, the public, the government, and Email Address other people or entities may all be stakeholders in some capacity.
It is very important to identify all stakeholders at the beginning of a project. Stakeholders that emerge late in the project's lifespan may demand changes that require substantial rework or may even become adversarial to project outcomes.
The business analyst needs to create a list of all stakeholders - including groups as well as individuals - that have any connection to his/her project. This list should contain names of individuals along with their titles, contact information, etc. For groups, there should be one representative on the list. As a starting point, the business analyst should consult all the documents prepared up to this point in connection with the project.
To identify stakeholders, the business analyst can begin by sending out questionnaires to potential stakeholders and interviewing the likely candidates. The results of the questionnaires and interviews allow the business analyst to classify the stakeholders in terms of their influence on the project. The questionnaires can also help uncover additional stakeholders before the project gets too far along. The BABOK® lists many relevant questions that business analysts can ask to elicit this information.
Once the business analyst has compiled all the information, she can prepare a summary table similar to this one (only three rows are excerpted here):
Stakeholder Project Stake Description Name/ Job Title John Smith, Has been given a goal of Oversees all program activities and Executive increasing the number of strategies; is responsible for Director recipients of program services approving program expenses, by 15% over the coming fiscal including those for information year. systems upgrades. Joan Carlson, Responsible for ensuring the Together with the rest of the Board, Board Memberprogram's success and securing provides leadership and direction for (represents private funding. the program; ensures the program Board of achieves its goals. Directors) Jason Flowers,Directs the program's Leads the IT staff in supporting IT Director information system capabilities program activities with appropriate including the development of hardware and software components. new applications used by Directs all in-house software program staff members. development efforts.
The main goal is to ensure that the execution of the project goes as smoothly as possible. By identifying all stakeholders and knowing how they might influence the project's execution and eventual outcome, the business analyst can help the project manager avoid decisions that later end up creating more obstacles and delays.
RACI Matrix R=Responsible
In order to understand the nature of each role, the (does the work) BABOK® encourages the use of the RACI Matrix, as A=Accountable defined in the table shown here. (decision maker) C=Consulted After specific roles have been identified, the business (must be consulted before work analyst must identify the people that will fill those roles proceeds) for the given project. The stakeholder role is especially I=Informed (only needs to be informed after important and we will take a closer look at it in the work is completed) following pages. Role RACI Executive Sponsor C Business Analyst R Project manager A Developer C Quality Assurance I Analyst Trainer I Application Architect C Data C Modeler/Information Architect Database Analyst (DBA) C Business Architect R Solution Owner C End User I Subject Matter Expert C
Stakeholder Map
It is often useful to categorize stakeholders and put them in groups representing the amount of power (influence) they have and whether they represent inhibiting or supporting factors for the current project or initiative. The Stakeholder Map is a technique that graphically displays the relationship of stakeholders to the initiative and to one another. A typical mapping shows stakeholder influence and the level of interest in the project. From the BA perspective, this map can determine where the stakeholder focus should be.
See additional information on this technique.
Figure 2-5: Stakeholder Matrix, Business Analysis Body of Knowledge® (BABOK® guide), Version 2.0, 2009, International Institute of Business Analysis, Toronto, Ontario, Canada, page 30.
Stakeholder Onion Diagram
Another way to group stakeholders and their relationship to the solution is by creating a Stakeholder Onion Diagram. This diagram consists of an inner circle (the solution), surrounded by outside circles. For example, stakeholders placed in circles closer to the solution are those that will have a day-to-day interaction with the solution. On the other hand,
stakeholders placed in the outer circles will have less involvement with the solution, but still can benefit from it. This diagram can provide insights to potential conflicts of interest between the different stakeholders with respect to the solution.
See additional information on this technique here.
Figure 2-6: Stakeholder Onion Diagram, Business Analysis Body of Knowledge® (BABOK® guide), Version 2.0, 2009, International Institute of Business Analysis, Toronto, Ontario, Canada, page 30.
1. A network integration engineer who is assigned to work on a project that involves modifications to the existing IT network infrastructure would receive which RACI rating? a. "C" because she needs to approve any work that will involve changes to the network. b. "R" because she is one of the people actually carrying out work on the project. c. "A" because she is responsible for identifying which business units will be responsible for developing and promoting new products. d. "I" because she does not need to know about any network changes until after users have had time to gain familiarity with the new system.
2. Which of the following people have the most authority to "kill" a project? a. Senior Business Analyst. b. Project Manager. c. The company's private owners. d. The Chief Financial Officer.
Plan Business Analysis Activities
The fundamental goal when planning the business analysis activities is to develop a concise and clear set of steps or tasks that lead to the implementation of a well- accepted solution. The Plan Business Analysis Activities task includes the following general activities:
Identify the BA deliverables. Determine the scope of work for the BA effort.
Determine the activities that will be carried out by the business analyst. Develop estimates for the BA work.
Which activities and how they are executed will determine the business analysis deliverables quality and timeliness.
When completed, this task will produce the Business Analysis Plan which includes a detailed list of all the activities including the resources needed (a work breakdown structure {WBS} is one way of presenting this list) and a description or diagram presenting the logical dependencies among the activities.
What's Needed for Planning BA Activities
In developing Business Analysis Plans, the BA will use previously collected information from other tasks:
BA Approach - information on the SDLC, deliverables, templates, and tasks that should be included BA Performance Assessment - information on metrics and assessment of the BA effort Stakeholder List (including stakeholder roles and responsibilities) - information on individual stakeholders' behaviors and preferences.
In addition, the organization or a regulatory body might mandate specific deliverables. This comes under the umbrella of Organizational Process Assets.
Keep in Mind ...
In planning the activities to be carried out, particular elements will influence the types of activities and how they'll be performed:
Geographic Distribution of Stakeholders, i.e., whether stakeholders are co-located or dispersed will affect the complexity of the project and impact the estimate of activities. Type of Project or Initiative. The type of project or initiative will influence the business analysis activities being planned (i.e., a new software development project and a process improvement project have different characteristics and will have a different set of activities). Business Analysis Deliverables. Deliverables in the Requirements Package will vary according to the initiative in question. Determine Business Analysis Activities.Typical activity lists are in the WBS. WBS defines scope of work to help with estimation within a hierarchy, decomposing activities and tasks to a greater detail (e.g., work packages). Create a WBS list by decomposing the project by deliverable, dividing the project into phases or iterations, or by using a previous similar project as an outline for current project.
Steps to Implementation
Even though the business analyst has a list - perhaps Next, the analyst must identify individual work units, even a very detailed list - of requirements activities, which consist of very specific tasks or activities that he still needs to estimate the scope of each activity, have a clearly identifiable "product" or end result the resources needed, and the time that will be (which usually feeds into another work unit). Some required to carry each activity out. people define work units as tasks that cannot be decomposed into smaller tasks. Others define work First, the business analyst can divide the entire units as activities that have a finite duration with a requirements process into a collection of milestones, minimum length. (In other words, you don't want to which mark significant events or accomplishments in break down a task into such small pieces as to be the execution of a project. Having a project charter ridiculous!). Obviously, judgment and experience are signed is an obvious example of a milestone. important. Delivering a product to the customer for acceptance testing is another.
Communication
Today, many projects rely upon workers who are distributed globally. Consequently, communications can be challenging despite email, instant messaging, web-based conferencing tools, and other technological aids. It is still important for project leaders to engage in some face-to-face meetings - even if only occasionally - to foster a sense of cohesion.
The internet makes it easier to share common project files so all workers can use the same design templates, electronic interface standards, and technical specifications as they build their portions of the project deliverables. Everyone should be able to look up documented requirements, business process documentation, and other organizational documents that have an impact on their work products. Many project leaders set up online portals for their project teams so everyone can monitor milestones, view current issues, and contribute to forum-like discussions - all from the convenience of their desktops.
Another important component of a successful project is a mechanism for sharing undocumented knowledge that an individual worker may possess but hasn't been formally captured. This knowledge-sharing is very important in the earlier stages of a project when several business analysts may be gathering requirements in geographically different places from stakeholders who rarely communicate with each other. A senior business analyst needs to ensure that everyone shares the information they are accumulating in order to reduce redundancy and resolve conflicts.
Plan Business Analysis Communication
A project involves many levels of communication throughout its lifespan. These communications may involve project managers, business analysts, stakeholders of all kinds, and the people who actually design and implement the solution. On top of this, there may be occasional needs to communicate externally, to the general public, for instance, on projects that have especially high visibility.
The business analyst must plan all avenues of communication in advance as part of the broader business analysis effort. This plan must include interactions with stakeholders, including the actual requirements elicitation activities themselves, along with communications targeting managers and the solution development team. Each deliverable has some element of communication associated with it and the analyst needs to plan those elements at the same time she identifies the deliverables.
The BA Communication Plan is included in the overall Project Plan. Here are the kinds of things the business analyst needs to consider for each deliverable of the plan:
What is being communicated and what is the most appropriate format given the contents and the audience Who should be party to the communication When does the communication need to happen
Plan Business Analysis Communication
The communication of requirements is perhaps one of the most important tasks associated with communications planning. The audiences to which the business analyst must present technical information can range from high- level managers, who may have little technical knowledge, to engineers and technicians, who will create the solution. The format of the communication must match the audience or the message will be lost. The consequences of not paying attention to the audience range from bad to worse: the project might be executed incorrectly by technical professionals who misunderstand the requirements or it might not be approved in the first place by high-level leaders who don't see any business benefits.
Various stakeholders must review project information at many points during the project's lifecycle. It is the responsibility of the business analyst to understand each requirement thoroughly and present those requirements in a manner that is understandable and actionable by these stakeholders.
Communication Types by Stakeholder
Makeup of Type of Communications Audience/Stakeholders Sponsors, CEOs, high- This audience requires summaries and, generally, high- level managers level descriptions. Members of this audience tend to be focused on major outcomes, especially in terms of the financial benefits that could accrue to their organization. Users (or customers) This audience understands the business aspects but may of the business not understand the technical aspects of a proposed solution solution. Requirements must be cast strictly in terms of business functions and outcomes. Members of this audience need to see the requirements in a fair amount of detail since they are the most affected by the solution. Engineers, application These people are the "builders" of the solution. They need developers, systems full specifications that can be translated into specific analysts technological features of the solution they are implementing. It is also very important to provide them with unambiguous success criteria that must be met for the project to be considered successful. Designers and This category of stakeholder is in many ways similar to the developers engineers and systems analysts. The main difference is that these people focus more on the functional elements and user interface characteristics of the solution. They need to understand both the technical and the business requirements. Testing and quality QA personnel need to be involved nearly from the assurance personnel beginning of a project. They need to understand the functional requirements of the solution so they can design test procedures that ensure 1) the solution works correctly and 2) the solution solves the business problem. They need both descriptive and technical details.
In general, the analyst can choose written (text) formats and visual (physical models or abstract diagrams) formats to present the requirements. Text is useful for describing abstract concepts or for setting the context of a requirement while diagrams are better-suited to show relationships among objects or process flows through a system. Sometimes, it's best to have a combination of the two for even more clarity.
Communication Criteria
When deciding the best way to present requirements to a stakeholder (or group of stakeholders), the business analyst needs to consider the following criteria and/or elements:
Purpose of the communication - What will the stakeholder(s) do with the information? Approve a requirements change request? Provide comments and/or constructive criticism? Brainstorm new requirements or refine existing requirements? Specific contents - what does this specific group need to know? How would another group of stakeholders with different needs interpret the contents of the same communication? Level of detail needed - What is the lowest level of detail that will serve the needs of the audience? How about the needs of the business analyst or project manager? Audience's technical background and/or familiarity with the topic - Do they have the prerequisite knowledge not only to understand the requirement, but to work with it? Degree of formality - How formal does this communication need to be? What is the audience expecting? Backup documentation - How much formal documentation needs to accompany any verbal or live presentations? Version control - Which version of the requirement documentation is to be presented? Is this a final version (which is more formal) or an update (which could be rather informal)?
It is important to note that a typical project is usually accompanied by a wide variety of "deliverable" documents ranging from informal work papers or work products to formal reports. For instance, a requirements package is a "deliverable" item that is clearly specified in the project plan. There are usually many deliverables throughout a project.
Degrees of Formality in Communication
Another aspect of technical communications involves There is one important caveat to mention at this point. the degree of formality that is needed for a particular If the business analyst decides to create different project or a particular audience. Projects require more versions of a particular requirements document in formality if they are large and complex (in terms of order to address the needs of different audiences, she implementation strategy and the nature of the needs to ensure that they all are consistent. If a business area), the technology being used is new or requirement changes, she needs to ensure that those controversial, the project's success is of mission- changes propagate throughout all the documentation. critical importance, the project sponsors require For large projects this might become a non-trivial task! formality, regulatory review will be involved at some It's best to plan carefully what needs to be point, or the project will be designed in-house but be documented and how it will be documented so that not produced by external developers. only the audiences' needs are met but the documentation is easily kept up-to-date.
Communications Plan
In smaller projects, the communications plan may not need to be written down formally; in larger ones, it is essential to write the plan down. In many cases, the requirements elicitation activities are included within the communications plan. After all, the main product of requirements elicitation is a document that communicates user and stakeholder needs to members of the project team. As an example of a communications plan, consider the following sample tasks from a software development project for ABC Corporation's Human Resources Department:
Task Audience Forum Deliverable Communications Method Hold the Stakeholders Group meeting PowerPoint Verbal requirements and project presentation presentation kick-off event team members describing the project's vision Elicit Managers and Small group Notes and Written preliminary supervisors in brainstorming sketches documents to be requirements the HR dept. session summarized at a from HR later date management Elicit detailed Managers and One-on-one Notes and Written requirements supervisors in discussions sketches documents to be from HR the HR dept. summarized at a management later date Elicit Senior HR Requirements Grid capturing Document to be requirements representatives, Workshop systematically sent to upper from HR staff clerks, data derived management for members (who entry specialists, requirements review and are the ones department based on comment via that will use the administrators management email new application needs and most expectations frequently) Prepare a Developers, Requirements Preliminary Formal document preliminary cost upper documentation features list, to be delivered to estimate for management review - WBS infrastructure upper developing the development requirements, management and solution and labor project team requirements members via estimate email
1. A junior business analyst working for you just brought you a full-color printout depicting a proposed web interface for an application to be used by the purchasing department to manage their internal operations. To which audience are you most likely to show the printout? a. Project Sponsors b. The CEO and CFO of the company c. Designers and developers d. The company's customers
2. You need to gain the support of a group of company shareholders for a telecommunications upgrade project that will enable field workers to process text messages as well as make voice calls. Which of the following communications approaches will you take? a. Demonstrate the value that the project will bring to the organization in terms of financial performance; avoid technical details. b. Present detailed wiring and cabling diagrams demonstrating your grasp of the technical intricacies of the project; the goal is to build confidence in your approach. c. Present a detailed, step-by-step implementation plan replete with technical diagrams. d. Gather the shareholders together in a conference room and hold a brainstorming session to come up with the best implementation plan.
Plan Requirements Management Process
The purpose of this task is to define (and then follow) the process for planning the requirements work throughout the project or project phase. It defines the process for approving the appropriate requirements for an initiative, as well as the process to manage changes to the solution or requirements scope.
This process also determines:
The process for requirements change Who will be informed on changes Which stakeholders need to approve changes Who does not need to be involved on changes The need for requirements traceability and which requirements attributes to capture
Inputs to the Plan Requirements Management Process Task
The previously defined Business Analysis Approach and the Business Analysis Plans, as well as the organization's approach to requirements definition, are used to determine the process used to manage requirements implementation and change.
Some organizations have a formal requirements process as part of their Organizational Process Assets. Others have inconsistent processes, while some might not have a process at all. In these cases,
requirements are either ignored or folded into other phases of the project or initiative.
Planning the Requirements Management Process
In planning for requirements implementation and changes, the business analyst needs to address the following questions:
Does the organization have a requirements repository? Are requirements organized for re-use? How are the requirements set for traceability? What requirement attributes are going to be selected? What process will be used to prioritize requirements? What criteria is going to be used to allow requirement changes? Who will authorize the changes? Does the requirements management process need to be tailored for a particular project or initiative?
Requirements Attributes
Requirements attributes provide metadata about the requirements but are not part of the solution definition. Attributes, however, provide useful information that can help the project team efficiently and effectively make tradeoffs between requirements, identify stakeholders affected by potential changes, and understand the impact
of a proposed change. Therefore, requirement attributes need to be planned for and determined, along with the requirements themselves.
For a list of commonly used requirements attributes, go to the BABOK®, page 44. Do you use any of these attributes? Which of these attributes do you use?
Handling Changes
As the project moves forward, there will be changes or updates to the recorded requirements, as well as conflicting requirements or conflicting priorities over requirements.
Organizations have either a formal or an informal change management process to deal with these issues.
Business analysts need to consider these items when planning how they will handle requirement changes:
The process has built-in authorization levels for approving changes based on a set criteria like a dollar amount or a certain number of hours. The organization has a formal Change Control Board (CCB) that authorizes requirements changes after they've been approved. A project team or product owner has direct control over requirements changes (i.e., an Agile SDLC environment) Impact of changes to business processes, hardware/software (including interfaces) and other requirements, as well as expected risk from the change. Change request documents - wording and structure. Requirements change prioritization, again based on a set criteria.
Tailoring Changes
The requirements management process sometimes is tailored to meet the needs of a particular project. A business analysis needs to consider the following:
Organizational culture - is the culture formal or informal, and how does this formality/informality react to a change in the normal requirements management process. Stakeholder preferences - distinct stakeholders want different levels of formality for change approvals and/or process documentation. Complexity of the project or product to be delivered - tailoring based on unique characteristics of product or product component or project/project phase. Organizational maturity - how mature is the organization in terms of an established requirements management process. Availability of resources - a major consideration and always a challenge, especially if the organization is launching many projects simultaneously.
Requirements Management Plan
This plan is an output of the Plan Requirements Management Process Task.
The plan:
Describes the approach to be taken to structure traceability Defines which requirements attributes will be used Identifies a requirements prioritization process Identifies a requirements change process and how changes will be requested, analyzed, approved, and implemented
1. How do change-driven methodologies (for example Agile software development) handle requirements change management? a. Change-driven methodologies use a formal requirements change control process and a formal requirements prioritization process. b. Change-driven methodologies do not typically have a change control process that is separate from the requirements prioritization process. All requirements ("new"/"changed") are recorded in the product backlog and prioritized. c. Change-driven methodologies don't prioritize requirements. They handle requirements change in a somewhat arbitrary way, sometimes formally, sometimes informally.
2. Even simple changes in requirements can have far- reaching consequences for the project. So, the Business Analyst involved in planning any type of requirements change management process should be concerned with: a. Determining the cost/time estimate of making the change, as well as either benefits or risks for making the change b. Adopting techniques like risk analysis that could establish whether the change is feasible c. Following an established process for requesting change and determining who will authorize any changes. d. All of the above. e. A and C only.
Manage Business Analysis Performance
The primary purpose of this task is to manage (and monitor) the performance of business analysis activities to ensure that they are effectively executed.
In the planning stage, the business analyst needs to determine which metrics will be used to measure the work performed, such as:
Tracking the BA work Assessing the quality of the work Reporting issues Managing problems
Project and Product Metrics
The next item in this topic focuses on project and product metrics, that is, the processes and methods of measuring how well the project is proceeding.
Project metrics focus on three primary criteria:
More about Metrics
The three criteria of Time, Quality, and Money are measurable and need a benchmark for comparison. This is so the business analyst (and project manager) can evaluate the project's status and make decisions to remain within the specified constraints.
By monitoring these metrics, analysts and project managers can make adjustments to resources (hire more people, ask for more money, negotiate for requirements changes, etc.). Generally, metrics should be collected and reported on a regular basis (such as weekly) and allow ample time for analysis and further data collection, if needed.
BA Performance Metrics
Typically, the performance metrics used for BA work are aligned with the overall project metrics. For example, performance metrics could define a certain number of hours to produce a deliverable or a particular due date. Also, the metrics could be the deliverable itself. It all depends on how the metrics are defined at the beginning of the project.
When defining metrics, there are three elements to consider:
Variance Analysis
Please refer to pages 51 and 52 of the BABOK® for more information and examples of this technique.
Variance analysis is a technique that the business analyst can use to analyze discrepancies between planned and actual performance. One aspect to keep in mind is the magnitude of the variances based on the metric that is being analyzed.
If variances are found, the BA will determine if any corrective actions are necessary.
1. The organization has identified specific due dates for business analysis work within the project. While assessing the performance of the BA work so far, you discover that some of these dates might slip because the work is going slower than expected. Therefore, you a. Keep quiet about this discovery because it will probably correct itself. b. Decide to take corrective action by analyzing the gap
between the expected BA work and the current work so far. c. Update the project team on your findings, incorporating the variance analysis findings and describing a corrective line of action to keep the project on track. d. A and C only. e. B and C only.
In this lesson, you learned about the Business Analysis Planning and Monitoring Knowledge Area. Key topics included:
Plan Business Analysis Approach Conduct Stakeholder Analysis Plan BA Activities Plan BA Communication Plan Requirements Management Process Manage BA Performance
The planning and management of the requirements process resembles in many ways traditional project management, which you may have studied in an introductory course on the subject. Though the BABOK® focuses on the requirements gathering function, it is very useful for business analysts to understand modern project management methodology in general - not only because it helps them create a better requirements implementation and management plan but it helps them understand how to participate on a project effectively.