The Span of Control is the number of people for whom a supervisor is responsible. This metric is most relevant in hierarchical organizations, and in fact was originally a military concept. Simply put, if a manager has five people reporting to her, her Span of Control is five. What is the optimum Span of Control? It will vary by situation, including the tasks being performed and characteristics of both the supervisor and workers. Is the supervisor watching everything that everyone does, or does the supervisor mainly answer questions or solve problems as they arise? Is one worker taking an inordinate amount of the supervisor’s time? What have you found to be a good Span of Control in your position?
December 16, 2009
December 15, 2009
October 19, 2009
Ethics in Business Analysis
Ethics is part of the BABOK®’s Behavioral Characteristics competency, which is one of six general competencies that a successful business analyst should possess. For each competency, the BABOK lists effectiveness measures. These effectiveness measures for ethics include: making decisions that consider the interests of all stakeholders, being clear with the reasons for decisions, disclosing potential conflicts of interest, honesty about one’s one abilities, and taking responsibility for errors. As can be seen, the values stressed here are fairness, openness, honesty, and taking responsibility.
Business analysts who have earned their CBAP® have agreed to the corresponding CBAP® Code of Ethical Conduct & Professional Standards. This can be found at http://www.theiiba.org/AM/Template.cfm?Section=Application&Template=/CM/HTMLDisplay.cfm&ContentID=5975 under “Code of Conduct Form.” There are two major sections of this code: Responsibilities to the Profession; and Responsibilities to the Client and the Public. Responsibilities to the Profession has three sections: Compliance with all Organizational Rules and Policies, Candidates Professional Practice, and Advancement of the Profession. Responsibilities to the Client and the Public has two sections: Qualifications, Experience and Performance of Professional Duties; and Conflict of Interest Situations and Other Prohibited Professional Situations. The code especially emphasizes acting in accordance with the law, not mis-representing yourself, maintaining confidentiality, and avoiding conflicts of interest.
October 16, 2009
October 15, 2009
Business Analysis Performance Assessment
The Business Analysis Performance Assessment document indicates how well the business analysis activities are being performed during a project. It is created as part of the BABOK®’s Manage Business Analysis Performance task which also plans how the performance of business analysis activities will be measured and reported. The Business Analysis Performance Assessment should contain a comparison of the plan to actual performance. This is the heart of Variance Analysis, which examines differences between planned performance and reality and suggests how to make reality consistent with the plan when the work is not meeting expectations. Root Cause Analysis examines the underlying reasons for a problem that is preventing performance from being consistent with planned performance.
Here is a simplified example of a Business Analysis Performance Assessment. “Carl has a total of 10 engineers to individually interview for purposes of requirements elicitation for our car re-design project. The deadline for the interviews is next week and at this point only four engineers have been interviewed and one additional interview is scheduled. The SPI is .80. After gathering some information on Carl’s schedule, it appears that he has a tremendous number of hours committed to another project. It is suggested that we do resource leveling and recruit another member of the team to perform at least three of the remaining interviews.”
October 14, 2009
Business Analysis Communication Plan
Effective communication among team members and other stakeholders is critical for project success. Specifically planning how communication will occur concerning the business analysis component of a project is outlined in the Business Analysis Communication Plan. This document is created through the BABOK®’s Plan Business Analysis Communication task. The Business Analysis Communication Plan describes the requirements for communication; the format, content, medium, and level of detail for communications; and names who is responsible for the various communication duties. When planning communication, take into account how co-located versus dispersed the stakeholders are. Is it possible to have quick meetings or to stop by someone’s office? Or are stakeholders scattered throughout the world making in-person meetings not possible? Another element to consider is the stakeholders’ backgrounds. Are there language barriers or the potential for cultural misunderstandings? Determine how frequently communications need to occur and how formal they should be. A small team may be able to have quick conversations in the lunch room, whereas a large team may necessitate more carefully written documents dispersed to the group. What communication mediums work best for the team? Does everyone have frequent email access and a fax machine? Do certain stakeholders strongly prefer conversations and dislike writing? Also document the level of detail for communications. Perhaps a weekly email update should be no more than a paragraph for the sponsor and much more detailed for those developing the solution. The nature of the project itself also needs to be considered. A ground-breaking project will likely require more communication than a routine project that team members have done previously. All this should be documented in the Business Analysis Communication Plan so that everyone is clear on how communication will be handled.
October 13, 2009
Requirement Attributes
Requirements (something needed by a stakeholder to meet a solution) have a number of attributes. The BABOK®’s Plan Requirements Management Process task provides a listing of common requirements attributes and their definitions. Documenting the attributes of individual requirements aids in the management of all the project’s requirements. Here is a listing of ten commonly documented attributes along with an example of each. Katy is going to be assisted by her daughter Karen as she performs a cooking demonstration at their state fair. She will be baking cookies that require the pan to be greased. The requirement “pan must be greased” is used as the example requirement below.
Absolute reference is the identifier for the requirement. It could be numerical or textual. (#1254)
Author of the requirement is the person who wrote the requirement. (Katy Cook)
Complexity is how hard it will be to implement the requirement. (Easy to implement)
Ownership is who needs the requirement or will be responsible for it. (Karen Cook is responsible)
Priority is which requirements need to be implemented beforehand. (Two requirements implemented beforehand—Obtain pan and Obtain cooking spray)
Risk is what occurs if the requirement is met versus not met. (The cookies may burn if requirement not met)
Source of the Requirement is from what authority the requirement originated. (Better Baking Cookbook)
Stability is whether the requirement is mature or still changing. (Mature, we know the pan should be greased and how we want to do it)
Status is whether is has been accepted, verified, cancelled, etc. (Accepted as a requirement)
Urgency is how quickly it is needed. (Within two minutes into the cooking demonstration)
October 12, 2009
Business Analysis Plans
The Business Analysis Plan is the roadmap that guides all later business analysis tasks. It describes the scope of the work, which may include a Work Breakdown Structure, and it may contain an Activity List with estimates for these activities. How this plan may be altered during the course of the project should also be stated.
The Business Analysis Plan is developed as part of the BABOK®’s Plan Business Analysis Activities task. The inputs for this task are: Business Analysis Approach; Business Analysis Performance Assessment; Organizational Process Assets; and Stakeholder List, Roles, and Responsibilities. The task contains four elements beginning with a consideration of the geographic location of the stakeholders which can be found in the Stakeholder List, Roles, and Responsibilities document. If stakeholders are co-located (at the same location), in-person requirements workshops may be useful, whereas if they are dispersed (in multiple locations), there may need to be increased reliance on conference calls and phone interviews. The second element of the Plan Business Analysis Activities task is determining the type of project. Is this a feasibility study? Process improvement? The next element is listing the deliverables specifically for the business analysis aspect of the project such as a Requirements Package. Lastly, the appropriate business analysis activities are chosen and described in the Business Analysis Plan.
October 9, 2009
Conduct Stakeholder Analysis
The Conduct Stakeholder Analysis task described in the BABOK® is performed early during the business analysis work and is often ongoing. It is similar to the PMBOK®’s Identify Stakeholders process. The primary purpose is to understand a project’s stakeholders. There are three elements to this process: identification; categorization; and attitudes and influence. One first needs to know who the project stakeholders are, which is the essence of identification. Known stakeholders are often able to indicate additional stakeholders that should be included. Once the stakeholders are known, it can be useful to group them into categories. Stakeholder location can be a useful category if they work at different sites. When scheduling a meeting, it is useful to know who is typically able to attend in-person and who may need to call in. The individual categorizing stakeholders should use whatever categories are helpful to the current project. Lastly, the attitudes and influence of the stakeholders are documented. Stakeholder attitudes may be documented towards the current project, the sponsor, business analysis in general, etc. Influence describes how much power the stakeholder has over the project. The output of this task is the Stakeholder List, Roles, and Responsibilities document. For more information, see the earlier posting of Stakeholder List, Roles, and Responsibilities (posted October 7, 2009).
October 8, 2009
Document Analysis
The technique of Document Analysis is based on the simple concept of reading through existing documentation to find relevant information. In business analysis, it is used to uncover additional requirements. The BABOK® lists a number of common types of documents used in Document Analysis: “business plans, market studies, contracts, requests for proposal, statements of work, memos, existing guidelines, procedures, training guides, competing product literature, published comparative product reviews, problem reports, customer suggestion logs, and existing system specifications.” To perform this technique, first decide which documentation to use. Read through these documents taking note of useful information and any questions you may have. Discuss the information with subject matter experts and have any questions answered. Lastly, write the information as requirements.
For example, Katy wants to bake an old-fashioned peach cream pie. She finds her grandmother’s old cookbooks and an old cookbook from her local library. These are the documents that she will analyze. After finding several recipes, she takes note of which ingredients and steps are common across all recipes. One recipe states that the ingredients should be “Mise en Place” which she does not understand. She asks a professional chef who tells her that it is a French term meaning that all the ingredients should be set in place beforehand, such as having the peaches already sliced. Lastly, Katy writes her findings in terms of requirements for the peach cream pie she will make.
tapuniversity
dkohrell