Article - The 8 Competency Areas of Highly Effective IT BAs - V1.0

7/29/2019 Article - The 8 Competency Areas of Highly Effective IT BAs - V1.0

1/6

Page 1 of6

The Eight Competencies of Highly Effective IT Business AnalystsBy Prasad Kamath Email: [email protected], Tel: +91-9833990271, Mumbai,India.

According to the Business Analysis Body of Knowledge, Second Edition, business analysis isthe set of tasks and techniques used to work as a liaison among stakeholders .

to recommend solutions that enable the organization to achieve its goals. A BusinessAnalyst is any person who performs business analysis activities, no matter what their jobtitle or organizational role may be.

In the context of the above definition, put simply, a Business Analyst is a problem solver.The problem need not necessarily be related to software. The success in the role of aBusiness Analyst primarily depends on the Business Analysts ability to clearly identifybusiness problems (or opportunities) from his / her elicitation sessions with the keystakeholders and obtain consensus on them. The need for this ability cannot be emphasizedenough considering the fact that:

1. Most stakeholders dont understand their own problems but they certainlythink they do. Very often, you see stakeholders specifying solutions when asked to

articulate their problems. I remember a key project stakeholder mentioning in one ofthe first project meetings that he needed a Supply Chain Management system, whenasked about the business problems he was facing, being blissfully ignorant of the factthat what he specified was actually a solution and not a problem.

2. The stakeholders who do understand their problems are rarely able toarticulate them clearly. Try asking a stakeholder to document a business problemhe is encountering and youll see the difficulty he faces.

If stakeholders exactly knew their business problems and could clearly articulate them, therole of a Business Analyst would be redundant. The Business Analyst adds value by helpingstakeholders understand their problems and recommending the best solution that wouldenable them to meet their business goals and objectives.

In the Indian context, when someone refers to a Business Analyst, he actually refers to anSME (Subject Matter Expert). However, over the years, the industry realized that simplyhaving subject matter expertise is not enough for effective business analysis. The methodsand practices used by the SME are equally important. This fact, along with the release of theBABOK (Business Analysis Body of Knowledge) v2.0, made organizations work towardsenhancing their business analysis practices beyond simply recruiting subject matter experts.

This article aims at highlighting the important competency areas a Business Analyst shouldpossess in order to do justice to his / her role, primarily on software projects in the Indiancontext. Figure 1 shows the eight major competency areas of a Business Analyst, many ofwhich overlap with IIBAs Business Analysis Competency Model V2.0 and ESI InternationalsBusiness Analysis Competency Model. The intent of this article is not to present a newcompetency model but to expand on the IIBAs and ESI Internationals competency models.

1. Business Analysis PracticesBy business analysis practices, I mean primarily the 32 tasks (same as processes)described in IIBAs BABOK v2.0. The BABOK focuses on the processes to effectivelyperform business analysis on any project. Hence, as one would expect, the BABOK isnot specific to any business domain and can be applied equally well to any businessdomain.
mailto:[email protected]:[email protected]


2/6

Page 2 of6

It is imperative for any Business Analyst to internalize the BABOK tasks andtechniques in order to produce consistent results on projects, as far as businessanalysis is concerned. For instance, many projects directly begin with a discussion ofrequirements, without first obtaining a consensus on the business problems beingencountered by the key stakeholders. The BABOK v2.0 includes a knowledge area(discipline) called Enterprise Analysis, that requires the Business Analyst to perform

problem analysis (or opportunity analysis) and arrive at a Business NeedsStatement, before the solution requirements can be fleshed out.

This approach remains the same, irrespective of whether its the Insurance, CapitalMarkets or the Healthcare domain. That is the value the BABOK provides to an SME a set of global business analysis best practices.

Figure 1: Business Analysis Competency Areas

2. Usability EngineeringMore often than not, project teams tend to develop solutions, systems or products forthe stakeholders who communicate requirements to them, without being cognizant ofthe fact that no matter who communicates the requirements, if the end-users cannotuse the system effectively, the project fails!

The Standish Group, a popular research organization that publishes the top 10success factors on projects, every year, based on its analysis of a large number ofprojects in North America, has been including the project success factor userinvolvement in the top 5 factors every year. Its strange to see that, in spite of that,

a large number of systems continue to be rejected by end-users once made availableto them, typically during user acceptance testing or post-deployment. Usabilityengineering is the answer to this issue.

Most people who dont understand usability engineering invariably think that it isnothing more than designing user interface screens and their look-and-feel. However,to be precise, that is part of user-centered design, which is just one subset ofusability engineering. Usability engineering includes the entire usability engineeringlifecycle, right from UCA (User-Centered Analysis), through UCD (User-CenteredDesign) and Usability Testing that ensures that the solution is developed in close

Business AnalystCompetencies

1. Business Analysis Practices(E.g. BABOK)

5. Documentation(E.g. Requirements Documents)

5. Documentation(E.g. Requirements Documents)

2. Usability Engineering(User-Centered Analysis and Usability

Testing)

6. Business Domain(E.g. Insurance, Banking etc)

3. Object-Oriented Analysis(UML Modeling)

7. Business Process Management (BPM)

(E.g. BPM CBOK)

4. Quality Control(Reviews, System Testing, UAT)

8. Technology Awareness(E.g. SDLC and IT technologies)


3/6

Page 3 of6

collaboration with the appropriate end-user representatives. In fact, user-centeredanalysis is an integral part of business analysis that keeps the end-user at the centerof all the business analysis activities. It focuses on the end-users mental model,which is their sub-conscious way of doing things.

It is absolutely essential for all Business Analysts to have a strong understanding of

the usability engineering lifecycle, particularly, user-centered analysis and usabilitytesting. User-centered design does not fall within the scope of work of a BusinessAnalyst.

3. Object-Oriented AnalysisThe BABOK v2.0 includes a set of 34 generic techniques that can be applied tomultiple business analysis tasks. Many of these techniques are relevant to object-oriented analysis. Considering the fact that most software systems today are basedon object-oriented technologies, it is important for Business Analysts to be well-versed with techniques relevant to their scope of work.

UML (Unified Modeling Language) enables Business Analysts to convert requirementsinto different types of models or diagrams, each of which describes a particularaspect of the requirements. Additionally, use cases are a very simple, easy-to-understand technique to document requirements, primarily, functionalspecifications (though they can be used to document business requirements aswell), such that it becomes easy and much less error-prone to convert it to technicaldesign and subsequently, to code.

It is important to acknowledge that one of the biggest communication gaps onprojects is between the Business Analyst and the Development or project team thatconverts the requirements specified by the Business Analyst to working software.UML makes it easy to communicate requirements specifications in a form that is easyfor the project team, especially System Developers, to interpret and convert to low-level design, using simple UML tools.

Most Business Analysts I have seen stay a mile away from UML, thinking that it istechnical and hence meant for the System Analyst or Technical Analyst. UMLincludes a set of over 10 types of models or diagrams that are developed at variousstages of the system development lifecycle. What many Business Analysts probablydont know but need to know is that the initial set of diagrams are the responsibilityof the Business Analyst (though this sometimes overlaps with the responsibility of theSystem Architect), whereas these diagrams developed by the Business Analyst getfurther converted by Technical Designers to lower-level diagrams that form part ofthe low-level technical design.

The BABOK v2.0 includes Scenarios and Use Cases as well as 5 other UML diagramsin its Business Analysis Techniques section. If the techniques are described in theBABOK, they come within the scope of the Business Analysts work and hence theBusiness Analyst must certainly know them. Again, as I have proved to Business

Analysts in every Business Analysis class of mine, UML is no rocket science and thereis nothing technical about it. It can be easily mastered by the so-called non-technical Business Analysts, if they do away with their mental block towards UML.

The industry certainly prefers Business Analysts with an understanding of UML.

4. Quality ControlSince its a Business Analysts responsibility to ensure that the solution delivered tostakeholders meets the business need(s) for which the project was undertaken, itsimportant for the Business Analyst to verify and validate the requirements


4/6

Page 4 of6

(typically part of the requirements review activity) as well as validate the solution(typically part of UAT) to confirm that it actually does meet the business need(s).

These activities are a subset of Quality Control activities.

A Business Analyst must be skilled at planning and facilitating user acceptance tests.This includes ensuring that all the right stakeholders are included in the test and the

right aspects of the solution are validated as part of the test. I have seen very manyUATs that are nothing different from System Testing, except that they are performedby end-users, that too, not the right ones. Its not very surprising then that in spite ofan apparently thorough UAT, the solution throws up many problems in theproduction environment that are not really related to the environment.

System Testing does not fall within the scope of a Business Analysts work, as there isno corresponding task or process in BABOK v2.0. However, within the Indian context,a Business Analyst is often required to support the System Testing activity. Whethera Business Analyst is involved in System Testing or not, it is certainly important forthe Business Analyst to understand how functional and more importantly, non-functional testing (such as performance testing, security testing, usability testing etc)are performed. This is because it is the Business Analysts primary responsibility toelicit and document testable non-functional requirements specifications, arequirements-related activity that I have seen many Business Analysts not evenfamiliar with. It would be difficult for a Business Analyst to write testable non-functional requirements if hedoes not understand how they will be tested.

5. DocumentationThis is one competency area that I would say, is the single biggest contributor toeffective and successful business analysis, though the others are certainly veryimportant. It is a known fact that a large percentage of the defects discovered duringthe System Testing and UAT activities are associated with poor quality requirementsdocumentation. One of the major reasons for this is that the Business Analystinvariably assumes that the consumer of the documentation, primarily, the SystemDevelopment team that actually builds the solution, possesses the same level ofunderstanding of the business domain, as him or her. This makes him subconsciouslyexclude a lot of important details that deserve to be specified.

This problem gets compounded by the fact that most project team members,including Business Analysts, detest documentation, if I may use that word. Theinteresting aspect of an ambiguously written requirement is that the individualreading and interpreting the requirement might believe that he has perfectlyunderstood the requirement, when his interpretation might actually be quite differentfrom what was meant by the Business Analyst who documented the requirement.Unfortunately, the only time both might get to know that is during the UAT or worse,during the production run, that leads to an unacceptable amount of rework. Thatexplains the need for unambiguous documentation.

In all my business analysis classes, I emphasize the need for a Business Analyst to

focus on developing his documentation skills, whether he likes it or not, becauseultimately what gets incorporated into the solution is whats in the requirementsdocument! I also know of some Business Analysts taking a course in TechnicalWriting. While that might not be absolutely necessary, it only demonstrates theircommitment towards being a better Business Analyst.

6. Business DomainBy business domain, I mean industry verticals like finance, insurance, banking,healthcare etc. Though BABOK v2.0 explicitly mentions that the role of an SME


5/6

Page 5 of6

(Subject Matter Expert) is distinctly different from that of a Business Analyst, it alsomentions that often both might be performed by the same person. That is very true,especially in the Indian context. The Business Analyst would probably not be called aBusiness Analyst if heis not an SME in the relevant business domain. And to a greatextent, a Business Analyst is likely to be more effective in his role if he possesses afair amount of breadth and depth of knowledge and experience in the business

domain relevant to the project.

7. Business Process Management (BPM)As mentioned at the beginning of this article, a Business Analyst is primarily aproblem-solver. One of the things that enable him to identify and analyze problems(or opportunities) and to recommend the best solution is his ability to understand andanalyze business processes. Modeling and analyzing the as-is business processes inscope and then modeling the to-be processes is one of the key business analysisactivities. As a result, it is essential for a Business Analyst to have a goodunderstanding of BPM concepts and techniques.

The ABPMPs (Association of BPM Professionals) Business Process Management CBOK(Common Body of Knowledge) describes nine different knowledge areas (ordisciplines) of BPM that a Business Analyst must understand well. Though someaspects of BPM like business process modeling and process analysis (to a smallerdegree) have been addressed in the BABOK v2.0, there are other aspects of BPM likeprocess design, process transformation and process performance management thatare equally important and central to the role of a Business Analyst. In any case, theyare essential in order to solve a business problem.

8. Technology AwarenessThough a solution need not necessarily have an IT component, in all probability, mostof them will, because most businesses today are IT-enabled. Hence it is imperativefor every Business Analyst to possess the ability to understand how IT systems andtechnology can help solve business problems. In addition, since an IT BusinessAnalyst works within the context of a software or IT project, a good understanding ofthe SDLC (System Development Life Cycle) is essential to perform business analysisactivities effectively. In fact, the SDLC methodology (waterfall, iterative, agile etc)selected for the project directly influences what business analysis activities would beperformed and how.

The eight competency areas described above can be used by a Business Analyst,new as well as experienced, as a self-assessment checklist. The assessment wouldhighlight those areas that either need to be entirely developed or enhanced further.

______________________________________________________________________________I hope this article has been insightful as well as useful and also hope that it helpsgood Business Analysts get better! If you have any comments, please feel free towrite to me at [email protected].

Prasad Kamath, MBA, CBAP, PgMP, PMP, MCTS (Project 2007),CSM, CUA, Six Sigma Green Belt, ITIL (V3 F), CISSP,is a Consultant,Auditor & Corporate Instructor possessing over 17 years of overallindustry experience in both the IT and BPO industries, with strong competencies inprogram and project management, business analysis, usability engineering, softwaredelivery, information security and business continuity. He possesses strongexperience in managing multiple concurrent projects and programs and isexperienced in all phases of the SDLC. He has delivered a large number of projectmanagement and business analysis skill building workshops as well as certification-oriented programs for the CBAP, PMP and ITIL V3 Foundation certifications.
mailto:[email protected]:[email protected]


6/6

Page 6 of6

Article - The 8 Competency Areas of Highly Effective IT BAs - V1.0

Documents

Transcript of Article - The 8 Competency Areas of Highly Effective IT BAs - V1.0