Induction plan for a new BA into the project

Question: You have joined a new project as a BA. What do you think you should do to acclimatize to the project and set yourself in the BA role?

Response:

In an ideal project the BA lead or the project manager should:

•         Have an induction plan and a well-defined process to bring you up to speed on the project.
•         Introduce you to the project team or at least the team members working on the module you need to work on.
•         Assignments and deliverable expectations ready for you to work on.

The fact is that this kind of induction plan never exists. At the maximum you may get your computer and get introduced to couple of team members. Many times you are left in the cold to learn the hard way.

Nevertheless, a BA should have his own induction plan. The new BA should take an appointment with the BA lead or ask to assign a person to go over the induction plan. The induction plan can include:

         

Assignments –

o   A brief Introduction about the project

o  The assignment you need to work on and how the assignment fits into the big picture. The assignment could be a change request or a brand new module. You may also want to know the background and the importance of the module.
o   Request to include you in the related status and requirement meetings

Document repository – Where does the team store the requirement artifacts? Where does the project management plans and schedule are kept? These could be at a SharePoint location or a shared folder.

Resources: Ask about:
o   The software you need to get the work done for example to read the XSD or XML files, to create diagrams, client databases, etc. 
o   The access rights to different SharePoint locations and folders.
o   Formalities to put request for the above two things.

Environmental factors - Ask your lead to explain:
o   The typical process for requirement gathering for example how the requirements are received, who is the main stakeholders, what are the general requirement gathering techniques followed, etc.
o   Templates and Document approval – where are the template and sample artifacts kept, what is the life cycle of a typical artifact for example initial draft, peer review, QMO review etc.
o   Life cycle of a release – How does a release start, how the modules are allocated, what are the release start and end activities, what are the approximate time lines, and so on. 

Organizational factors - 
o   Who could help you with the current assignments and if you can be introduced to them.
o   How the team is organized internally – For Example – Interface BA, Requirement BA, development, testing, management team, and so on. Ask where the organization chart is located.
o   The important external stakeholders for example – client, vendors involved, and so on. The client may split the project among many vendors.

You may not know the above details in one session and may have to reach out to different people formally or informally. Learning the finer details could be a gradual process. It could also vary from person to person depending upon the background knowledge and grasping capabilities.

Certifications for a Business Analyst

Question: What are the different certificates a BA can pursue?

Response: 

Certifications not only put a stamp of knowledge about the skills but also enhance the possibility of selection. There are many certifications that a business analyst can pursue.  It becomes easier to earn the certification when you are working in that particular area. It’s easier to pass the certification exam when you are able to relate the theory and practical. There is no end to the number of certifications you could pursue. Every organization and area has its own certifications. Some of the popular certifications a BA can pursue are:

• Certified Business Analysis Professional (CBAP) from International Institute of Business Analysis (IIBA);
• Project Management Professional (PMP) certification  from Project Management Institute (PMI);
• OMG Certified UML Professional (OCUP) from Object Management Group (OMG);
• Six Sigma level (Green Belt, Black Belt, Master Black Belt, etc.);
• ITIL certifications from IT Service Management (ITSM);
• Certifications from IBM on Rational Product suite;  and
• Certified Software Quality Analyst (CSQA) from QAI Global Institute (QGI).

You can also pursue domain related certifications for ex:

• FLMI – LOMA if you are working in the Life and Health insurance;
• Courses from America’s Health Insurance Plans (AHIP) if you are working in the Healthcare; and
• Property and Liability Insurance Principles Exam (INS 21, 22, 23) if you are working in the P&C insurance.

Requirement Artifacts by Business Analysts

Question: What artifacts you would produce to satisfy developers and business stakeholder’s need?

Response: 
The way I approach is that I do a brief assessment of technical and business needs of the project. I also look for any environmental factors such as already existing templates, tools used, and so on.

My main aim is to decide a format/template in which I can put the requirements so that both the parties agree; we can stabilize the requirements and move forward in the acceptance and development process. The target is to generate accurate and concise artifacts.

I also try to understand the assumptions and constraints while eliciting the requirements.

If it is a functional requirement (like System Requirements Specifications (SRS), Business Requirement/Specification Document (BRD or BSD)) then I usually produce a flow diagram and use case document with screen shots. The document also contains UML diagrams, data dictionary assumptions, business rules, related reports, error handling, testing strategy, etc. If we have an existing system, then I would also include configuration changes, and data changes.

If it is a process requirement I would dissect each part of the process into various steps. For each step I would talk about the input and output data. What processing or decision will occur at each step? We can put a context diagram and then explode it into data flow diagram showing each level. We can also use Business process modeling.

If it is an interface requirement (like Interface Control Document (ICD)) I will mention technical details on frequency, format, fields, field length, mapping with existing data dictionary, Service Level Agreement (SLA),  along with the steps involved in how the interface will work. We will attach XSD or XML sample if possible.

This document could also include the non-functional requirements then I include performance, security standards, data migration and conversion needs, availability required, and interface needs (batch or messages).

Requirement elicitation approach

Question: How do you start the requirement elicitation and analysis work? Or what would be your approach for collecting requirements?

Response: 

The elicitation and analysis begins the moment the Request for Proposal (RFP) or any other client requirement document is received or understanding from prior discussions.

We study the document and research the topic and make a requirement elicitation plan which includes:

•   What techniques to use to collect requirements? For ex. focus groups, interviews,     Joint Application Development (JAD) sessions, shadowing, questionnaire, etc.
•   How to record the information you collect?
•   Time frame/schedule for information collection?
•   Initial design/architecture on base system.

In parallel we dissect the requirement and try to develop a Work Break Down structure in which we define the smallest unit of deliverable we need to produce. For ex. Let’s consider a sport’s club system in that has epics and user stores. For instance, member accessing my account can be an epic, whereas member login, or reset password can be user stories.

In this process we collect questions we need answers for clarifications.

Initial requirement artifacts are developed which are used during JAD sessions with Subject Matter Experts (SMEs) and clients. We try to nail down the requirements as much as we can.

We document the requirements in Business Requirement Documents (BRDs) and Functional Specs which include use cases, flow/activity diagram, data requirement, configuration needs, business rules, assumptions, exclusions. The document templates vary with company.

Documents goes for internal approval, walk through sessions are organized consisting of internal stakeholders. Once changes are incorporated, and internally accepted, it’s forwarded to client for acceptance and sign off.

Types of requirements

Question: What are the different types of requirements? In other words, how would you categorize the different types of requirements?

Response:

Broadly speaking the two types of requirements are:

•          Functional – A functional requirement try to seek answers to what a system needs to do to satisfy the objectives / needs; and
•          Non-Functional – A non-functional requirement try to gather information on how a system needs to do activities to fulfill the functional objectives for ex. security, performance, availability, configuration needs, etc.

Requirements can also be categorized from an architecture point of view such as:

•           Business: How a business work. A very high level view. For example: product and service, financial structure, business processes, etc.
•      Application: Services and functionalities from a end user perspective. Automated and non-automated services.
•           Operations – what the organization needs to run the processes and operations like data management, replication services, security levels, etc.
•          Technology – S/W and infrastructure requirements such as environment, database, security, network and so on.

Difference between requirements, wants and needs?

Question: What are requirements? What is the difference between requirements, needs, and wants?

Response: 

Requirement: A requirement is a condition or capability needed by a stakeholder to solve a problem or achieve an objective.

In other words, requirements indicate the characteristic of the process that are essential for meeting the goals of the business.

Needs: Needs are the capabilities a stakeholder deem necessary to achieve objectives, and approved by the sponsors.

Requirements are subset of needs.

Wants: Wants are important but not essential to achieving the business goals or resolving the business challenges. Wants are based on the actual day to day experiences of the people. However, they represent an ideal stake of how people would like things to be in the business. During SDLC some wants may become requirements and vice verse.

For example: Let’s consider a company trying to venture in the insurance market.

The new company needs new business, underwriting, and policy administration, but has budget for only new business system.

In this scenario, apart from the new business system the company has to have underwriting, and policy administration system to run its operations, but so far because of constraints sponsors were able to establish only the new business process and solution. Therefore, new business, underwriting, and policy administration are the needs of the new insurance company but the new business system is the current requirement.

In case the sponsors thinks that a capability for the customer to do changes to the policy online will be better instead of calling the company, but they are constrained. In this scenario online system is a want and capability of calling the company is a need, and a requirement for the IT department.

Tell us about your Business Analysis background

Question: Can you tell us about your Business Analysis background?

Response: As a business analyst I actively participate in all phases of software development life cycle (SDLC) and project management life cycle (PMLC). However, my role and responsibilities varies depending upon the project requirements.

In the planning phase, I work with Project Manager/leads in creating the work break down structure (WBS) from the client requirement documents or request for proposal (RFP). I assist in creating schedule, resource planning and artifact template creation activities.

In the requirement phase, I organize JAD sessions, workshops or employ other requirement elicitation techniques to get detail client requirements, manage and document requirements. Usually we create business requirement documents (BRDs) and functional specifications. BRDs contain use cases and detail information about the scope.

Functional specifications contain various models, process flow diagrams, data needs, screen layouts, reports required, and configuration needs (if any). It really depends upon how much detail information the project needs. The template varies between organizations. In some projects I have also created data dictionary, data migration and conversion, and report analysis. We also have to follow the internal and external requirement approval processes.

In the development or coding phase, I guide the development team in better understanding of requirements or defect, clarify their doubts.

During testing phase, I work with the testing team to create test cases and automation scripts. Since BA has the first hand information about the requirements his role becomes even important. As a product owner at times I participate in functional testing. I make sure that there is traceability right from client requirement document, BRDs, functional specification up to test cases.

In the roll out phase I work with the project manager and deployment manager in preparing the roll out checklist, pilot and training activities.

When the project goes to maintenance, I study the change requests, analyze the impact and gap, and submit my analysis to change control board (CCB) for a decision.

To summarize as a BA I am heavily involved in all phases of a project. Compared to other roles a BA has the maximum and wide variety of tasks.