Every year, organizations around the world face startlingly high project failure rates. Some research has shown that less than 30 percent of software projects are completed on time and on budget—and barely 50 percent end up meeting their proposed functionality. If you’re a big league baseball player, failing five to seven times out of ten will get you an endorsement deal and a spot in the Hall of Fame. But, for the rest of us, these types of failure rates represent billions in cost overruns and project waste.
In 2005, ESI International surveyed 2,000 business professionals to try to find out why projects fail. The answers were numerous and varied and included such common thorns in the side as inadequate communication, risk management and scope control. But of all the answers, one showed up more than any other. Fifty percent of those surveyed marked “poor requirements definition” as their leading project challenge.
Failing to properly and accurately define requirements at the very beginning of the project lifecycle points to a distinct lack of business analysis competency. The role of the business analyst is an important one, and, sadly, one that is underutilized by many organizations around the world. In essence, a business analyst acts as a translator or liaison between the customer or user and the person or group attempting to meet user needs. But, that’s just speaking generally. What about the specifics?
Below, I’ve put together a list of eight key competencies that every business analyst—or every professional performing the duties of a business analyst—should possess. I’ve included specific emphasis on tasks associated with junior, intermediate and senior business analysts. If performed effectively, the items on this list could save organizations millions.
Competency #1: Eliciting Requirements
A major aspect of a business analyst’s job is eliciting and documenting user requirements. Requirements can be conditions, functionality, products or services for internal or external use. Requirements are needed by a user or client to solve a business problem, and they’re tied to the needs of business rather than the constraints imposed by technology. Business analysts spend time gathering requirements not because they enjoy it, but because it’s the most effective way to help organizations understand the challenge at hand before trying to propose the solution. Think of it as printing a Google map before hopping in a rental car and hitting the gas pedal.
The techniques necessary for capturing requirements are often referred to as elicitation. Depending on an individual’s level of competency and the situation, the type of elicitation techniques applied will vary.
Competency #2: Creating the Business Requirements Document
A business requirements document (BRD) is an exhaustive written study of all facets of regulatory, business, user, functional or non-functional requirements and provides insight into both the as-is and to-be states of the business area. The BRD is a detailed profile of primary and secondary user communities and should come directly from the requirements the business analyst has already gathered. Once the document is completed, the business analyst and the client or user should meet for a formal review to approve the BRD. Next, the document should be shared with the rest of the development team, including the project manager.
In creating the BRD, the senior business analyst will be largely responsible for defining the various sources for requirements as well as the placement and relevancy of those requirements. For example, senior business analysts may identify such items as the project charter and vision, business case, requirements work plan, vendor request documents and, potentially, business contract documents. They may also work with the project manager to define the project and product scope. Any requested changes to any area of the BRD—before or after work has begun—must be carefully reviewed by the senior business analyst. An intermediate business analyst may work with the client or user, discussing changes necessary to gain approval. And, the junior business analyst is expected to assist the intermediate and senior business analysts with the organization and the actual documentation.
Competency #3: Structured Analysis
Structured analysis refers to the art of modeling. In business analysis, modeling is used to support and enhance text-based requirements, help identify and validate requirements, document and communicate requirements and, finally, organize information into coherent ideas. The most common types of business analysis models are business models, process models, data models and workflow models.
When modeling, junior business analysts should be able to easily identify a variety of modeling techniques and to create simple models based on information given to them by their intermediate or senior counterparts. Examples include organizational charts or business interaction models. An intermediate business analyst may begin to develop such models as entity relationship diagrams, functional decomposition diagrams and ever-popular use case models. The senior business analyst takes the models from the junior and intermediate business analysts and examines the as-is state in order to create the ideal to-be state.
Competency #4: Object-Oriented Analysis
Within a business context, an object model is an abstract representation of a system’s process and data requirements based on decomposing the system into units—which are called objects. Each object encompasses the data and operational characteristics of one business item. Object-oriented analysis is particularly important as a business planning tool to depict the hierarchy of business functions, processes and sub-processes.
Those looking to master object-oriented analysis should be competent in structured analysis. Object-oriented analysis requires a clear understanding of both the process and data modeling techniques, including functional decomposition.
Junior business analysts may get involved in the functional decomposition of the as-is state of a project, including forming a simple model of this state. From this model, an intermediate business analyst may consider developing activity diagrams to further clarify requirements. With diagrams in hand, a senior business analyst is likely to begin designing the to-be state during one-on-one interviews, group interviews and the documentation process.
Competency #5: Testing
The first thing to understand about testing is that the term applies to several different levels of work. First, business analysts are looking to test the products to validate whether the requirements have been met. Test scripts, test plans and test scenarios are based on the as-is state as well as the to-be models.
The second level of testing is more familiar and consists of testing the functionality of the physical product. This ensures that the desired state has been reached based upon user acceptance.
Junior business analysts are often not heavily involved in testing, acting usually as assistants. The intermediate business analyst, however, might take on the role of designing test cases and reviewing the results. The senior business analyst acts as an overseer in the testing phase. His or her job is to see the project to fruition and manage quality.
Competency #6: End-User Support
It’s a common misconception among project teams that the project ends when the deliverable is completed. Not so. Business analysts should be aware that end-user support after the product is delivered is a vital part of the process. Also, it’s important to note that the role of the business analyst is not to act on behalf of the training team, but to complement the training team’s efforts with their knowledge of the business requirements.
Ideally, a junior business analyst will work with end-users in the post-deployment phase to clarify any high-level questions that need to be addressed. An intermediate business analyst would work closely with training managers and facilitators to define requirements to deliver the training support the business needs. A senior business analyst would assess and evaluate all feedback from his or her team members, those individuals involved in the deployment of the product and any pilot or “test” groups to ensure that the requirements necessary to correct any issues are addressed in future releases, iterations or versions of the product.
Competency #7: IT Fluency
How much IT knowledge is enough for a business analyst? The answer is a little complicated because it depends on the individual project and the industry vertical in which that project exists. Just because an individual is fluent in a given technology does not automatically qualify him or her as a business analyst. In theory, a great business analyst should have the wherewithal to understand which resources are appropriate to help define and validate requirements and specifications within a given project and product scope.
A junior business analyst would need to have a clear understanding of the IT products and tools necessary for the business to function. An intermediate business analyst may understand interconnectivity and relationships between the tools and system architecture and information architecture. A senior business analyst will demonstrate his or her IT fluency across an industry vertical. He or she may also have a very clear understanding of how different IT products are related, interface with and connect to each other, as well as the positive or negative effect they may have in a given situation.
Competency #8: Business Process Re-Engineering
Considered the “big-picture thinking” of business analysis, business process re-engineering (BPR) is a rapidly growing part of business analysis. In fact, lately, many companies have been grouping business analysts around this specialty and developing teams of process analysts. This is the phase in which business analysts seek out and identify problems and opportunities. BPR uses a variety of modeling techniques in order to look at the bigger picture while still thinking tactically.
BPR is a competency in which all levels of business analysts must be highly skilled. The junior business analyst’s responsibility is often to identify, using various modeling techniques, possible areas of improvement. The intermediate business analyst might have the job of walking the client or user through each step of the process, examining individual tasks that could potentially be improved. The senior business analyst begins to actually make suggestions for improvements.
Where to From Here?
A list of competencies in an article is just a list of abstract ideas. To put them to work in real life, organizations should begin implementing each competency as guidelines for all projects. Once this is accomplished, it’s essential to formalize the business analyst job description and begin developing the suite of skills in each business analyst through comprehensive training and internal mentorship. There are a number of organizations around the world that offer such training. My advice: find the one that fits your organization’s goals and objectives and get started immediately.
Author: Glenn Brûlé, Director of Client Solutions for ESI International, has more than 18 years of experience in many facets of business, including project management, business analysis, software design and facilitation. He is former Chair of International Business Development for the IIBA, and is a frequent speaker at professional association meetings and conferences around the world, including ProjectWorld/World Congress for Business Analysts and IIBA events. At ESI, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. Glenn's background as an educator, communicator and business consultant has served him well through his many client engagements across various industries, including financial services, manufacturing, pharmaceutical, insurance and automotive, as well as government agencies.
Glenn has authored numerous articles on business analysis and was instrumental in the development of two ESI white papers: “Eight Things Your Business Analysts Need to Know – A Practical Approach to Building and Improving Competencies” and “Establishing and Maturing a Business Analysis Centre of Excellence – the Essential Guide.”