This information was culled from an ESI International white paper obtained during gantthead’s 2009 virtual PMXPO today. I found this document very interesting and it provided nice insight from the BA perspective as opposed to the PM perspective. The document is too long to include here in full, but I’ll provide some highlights.
Why Are Projects Failing?
In an online poll of 2,000 business professionals, the question was asked, “What are the key challenges in translating user needs into system specifications for mission-critical projects?” 50% stated poor requirements definition as the key challenge. Inadequate risk management (17%), poor scope control (15%), and communication problems (14%) followed far behind as key challenges.
If a project fails, it’s often assumed to be the project manager’s fault. More and more, however, research is showing that this is not the case. In this survey, with an overwhelming 50% of respondents citing poor requirements definition as their biggest challenge, it seems to raise a new question. When projects fail, most organizations are quick to blame the project manager. But what about the business analysts? What role do they play? More importantly, what role should they play?
Role of the Business Analyst
At the most basic level, a business analyst acts as a translator or liaison between the customer or user and the IT person or group attempting to meet this user’s needs. According to the International Institute of Business Analysis, business analysts are “responsible for identifying the business needs of their clients and stakeholders, to determine solutions to business problems.”
The follow-up question, therefore, is “what competencies does a business analyst need to accomplish these tasks successfully?” ESI’s white paper presents the following eight competencies as key for the business analyst.
Eliciting Requirements
On the most basic level, we know that a big part of a business analyst’s job is to gather and document user requirements. Requirements can be conditions, functionality, products or services for internal or external use. They are needed by a user or client to solve a business problem or achieve a business activity, and they are tied to the needs of the business, rather than the constraints imposed by technology. This means that the business analyst’s job has more to do with identifying the desired results than the actions or resources required to reach these results—that’s someone else’s job.
Creating the Business Requirements Document
A business requirements document (BRD) is an exhaustive written study of all facets of the regulatory, business, user, functional or non-functional requirements and provides insight into both the as-is and to-be states of the business area. It is a detailed pro?le of primary and secondary user communities. It comes directly from the requirements the business analyst has already gathered. It only makes sense, then, that the BRD should be written by the business analyst. After the document is completed, the business analyst and the client or user meet for a formal review and for approval of the BRD. The document is then shared with the rest of the development team, including the project manager.
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 include business models, process models, data models and work?
Object-Oriented Analysis
Within a business context, an object model is an abstract representation of the process and data requirements of a system, based on decomposing the system into units called objects. Each object encompasses the data and operational characteristics of one business item. Object-oriented analysis is particularly important to business analysts as a business planning tool to depict the hierarchy of business functions, processes, and sub-processes within an organization.
Testing
When it comes to testing in business analysis, the first thing to understand 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. They develop test scripts, test plans and test scenarios based on the as-is state as well as the to-be models. Testing requirements should be done in iterative stages to ensure that, by following the requirements, the desired deliverables will be met.
End-User Support
It’s a common misconception among project teams that the project ends when the deliverable is completed. Not so. Business analysts, speci?cally, should be aware that end-user support after the product is delivered is almost as important. It should be stated, too, 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.
IT Fluency
How much knowledge is enough for a business analyst? With regards to IT knowledge, this has been a long-standing debate. In reality, the answer is as varied as it would be for any other professional. The amount of necessary IT knowledge is truly based on the project. The IT background for a competent business analyst depends entirely on the environment and possibly the industry vertical he or she works within.
Business Process Re-Engineering
Business process re-engineering (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.
My Summary
I can’t say that I agree 100% with this white paper, but I feel that it touches pretty well on the key responsibilities of the Business Analyst on an IT project. How those responsibilities line up with the phases of the project and who approves what differs from my overall project management methodology and approach, but the concepts are basically the same.