We're going to look at mastering business analysis communications. The first thing that we're going to look at is an overview of projects and project teams. So types of projects that involve business analysis are things like web development, new application development, new business development, software, package selection, business process engineering, data warehouse implementation, and enhancements to any of those areas. Now let's look at what a project lifecycle looks like. Every project progresses through several phases of work. And those phases are looked at as the project lifecycle.

We would start with planning the project, then move into scoping the project. And then the next one is the area where the business analyst is really spending the bulk of their time on the project in other Doing the bulk of their work. And that's in the elicit, analyze and document requirements phase, design a solution, build or buy the solution, then we would test the solution, then it would get implemented. And we would conduct a post implementation review. So that's really what the project lifecycle looks like. Now let's take a look at what happens during each one of these phases of the project lifecycle.

So when you're planning the project, that phase involves discovery and documenting what the project is about right what are the needs of the business, why are we doing it and then also assigning resources so there can be market research done. There can also be alignment with corporate standards and strategic objectives and also managing and assigning available resources. A scoping of the project would include clarifying the purpose and objectives identify the organizational units involved with the Project identified people and systems interfacing with the project determining business processes included in and excluded from the project. It's important to not just identify what's included in but specific things that should be excluded from should also be included in that documentation. Also identifying project assumptions and risks and establishing a system for organizing information. So for the life of the project, so all during the lifecycle the various phases of the project, we need to make sure that we have a standard way of organizing the information, a place where we're storing everything together for the project.

So that has to be determined upfront as to how that's going to be handled. The next phase is of course that Alyssa analyzing document requirements phase that I mentioned was so important to the business analyst. This is where you will do the bulk of your work on a project you will determine where to find requirements, you'll define yourself. approach for eliciting requirements is a Jad session, good one on one, interview sessions, group requirement meetings, surveys, what's the best method to get at the requirements that you need to get? So that's what I mean by the approach, also identifying and prioritizing the requirements. So once you've defined the approach, of course, then you go and actually do those actions and then documenting the requirements and documenting the requirements means that you'll be creating several different types of documentation.

You may produce process flow diagrams, business requirements, documents use cases, screen mock ups report mock ups are various different types of documentation that you may create functional design documents, Entity Relationship diagrams and data flow diagrams. There are many different types of documentation to use to include in your what we would call your requirements package. After that the solution would be designed so that's typically done by the system architect and you Be DBAs lead developer might be involved in that, but the design of the solution would come from the technical team. And during that phase of the project, you would be communicating the requirements to them. You may help in recommending solutions or solution alternatives, but you're not defining what that solution is, during the build of the solution or buying of the solution there is writing new or modified software. So if we're going to build the solution, then obviously some code has to be written in order to do that, right and installing any vendor or purchase software and then writing new procedures and assisting with organizational changes.

So you as a BA may come into play in that third bullet point there with the writing new procedures, and assisting with organizational changes. I have sometimes actually delivered training. I've also helped to create training, documentation, job aids, things like that in my role as a BA testing the solution. So the most important task of the software tester is to test based on the requirements, and then also be able to move out of the box to test what isn't in the requirements. During that phase, what's happening is that the software is being verified to make sure that it meets the requirements, we will also be verifying the application looks, feels and acts according to the expectations of the business. And of course, get user acceptance, meaning that there's probably going to be some user acceptance testing done or the stakeholders and the subject matter experts also known as sneeze are doing some testing too.

So on top of the QA team doing testing, you'll have usually some of the business team also doing testing next phase would be implement the solution. So that's where we actually roll it out into the field, right? It's being rolled out to production. If it's an application that's being used, maybe by multiple locations and there is a pilot or a soft launch or a pre launch or something like that going on it can be called Different things where maybe it gets rolled out to just one location first, and they use it and some of the bugs and kinks kind of get worked out of that. And then we roll it out to the other areas that would require a rollout plan where we might be rolling the solution out to various locations, but not all at the same time. So you can have what's called a big bang implementation where you just roll it out to everybody at the same time, or you can have that multi phased approach of rolling it out.

And user training is also delivered during the implementation phase. And then the warranty period gets completed during this phase as well. So that's usually where the project team is continuing to support any issues or things that get identified in production for a certain period of time. You know, typically when there's a issue that comes up with an application a user is contacting the help desk and letting them know that there's an issue during the warranty period that still may happen. Calls may still get routed through the helpdesk, but the issues will be getting routed to the problem. team during that warranty period so that the helpdesk staff isn't bogged down with trying to research and resolve the issues that come up right after implementation to production.

So your warranty period might be a week, two weeks could even be six weeks. It just depends on the size and criticality of the project, then there is conducting the post implementation review. So that's a phase in and of itself. During that time, we would be assessing the solution and eliciting information for enhancements and also really talking about what went well and what could be improved upon in the next release of that application. So now let's take a look at roles of project participants. So every project obviously involves people that have many different skill sets.

And one of the things that clients have told me in the past is that there's so many different names for different roles that it can get a little bit confusing and unfortunately, there's nothing to be done about that. It is absolutely true and there are different names at different places. Organizations for what would essentially be the same role, right? So we're going to look at some of those names that belong to different areas different roles. So the management team could include executive sponsors and account manager, a product manager and a project manager. So any or all of those could be on your project subject matter experts I mentioned those earlier, also known as suis are of course also on your project and they can be people that are business area experts, they could also be customers and they could be stakeholders, project support personnel, so other vital roles to the project.

Outside of that would be our quality assurance analyst or analysts depending on how big the project is usability engineers, facilitators, data administrators, and technical writers. Our technical personnel would be people like systems analysts, database designers, web content designers, technical architects, software developer uppers and network administrators. Now let's look at executive sponsors. executive sponsors will initiate the project. They also provide funding and resources for the project. They're going to make high level decisions about project direction, they'll approve the project scope, and they also ensure that the project goals align with the organizational goals.

The account manager or product manager, depending on what they're known as in the organization you're at defines the overall product requirements. They define the marketing approach to the product, and they'll work with the customer to outline requirements. The project manager identifies and staffs appropriate project team members they create the project plan and schedule. They monitor the project progress and make adjustments as needed. They ensure the project scope continues to reflect the subject matter experts objectives and they address project barriers. They also manage the change control process and the project budget subject matter experts can be inside your organization so they can be employees of it or they can also be outside the organization.

And if they're outside, they're typically customers or maybe vendors that you're working with. This means provide the project objectives, problems and risks set the priorities for business requirements. They get information to the VA about their business and the language that they use in their everyday business. They also provide detailed requirements of business and data and make suggestions about possible solutions. Subject Matter Experts also assist in besides providing you information, they're assisting in other areas as well. So they assist in defining the project scope requirements, discussions that are in focus groups, facilitated sessions, interviews and meetings.

They work with other organizational units to come to a consensus on shared requirements. They help with designing user interfaces and screen design. They also assist with user acceptance testing, right they should be the ones that are actually performing the user, accept Testing but they're not running it you as the BA or somebody from the QA team is typically running the user acceptance testing. They also will assist in updating employee procedure manuals to incorporate the new solutions. So that training, documentation and job as we mentioned earlier, subject matter experts are going to review and assess the requirements, documentation and diagrams, the usability of the software interfaces and the viability of the recommended solution. They're going to make timely decisions about requirements and you will approve the final solution prior to implementation.

So your subject matter experts are really key personnel to the project project support personnel. We mentioned earlier that there were several roles that fell under here. So looking at the quality assurance analyst who's also known as a software tester. They will review requirement documents, they'll write test plans, set up test environments, write test cases, execute and oversee the testing and report and follow up on defects. The business analyst I want to mention can also fill the role of software tester on projects. And you may be asked to do that.

I've done that on several projects that I've worked on the usability engineer or what might be known as UI designer will design user interfaces. They'll assess user interfaces for usability, and they will also assist with testing. a facilitator prepares for facilitated information gathering sessions, they conduct the sessions, they work with the business analysts to document the results of the session. Now I have to ask you, who do you think is usually the facilitator of those sessions? It's going to be you. I would like to say that it's going to be somebody else that you'll always have a facilitator to basically run your meetings for you.

But that's not really the case. You as the BA are typically expected to facilitate the requirement meetings and also document the requirements. Take notes during the meetings and stay engaged in the conversation while you're moving the meeting along And progressing and as well, the data administrator will provide enterprise data model information. they'll provide data naming standards and guidelines. They'll consult on logical data modeling techniques, and they'll review and approve the logical data models, technical writers create software manuals, user training manuals, and they also will right online help text the technical personnel on the team determine how the technology can fulfill the business requirements documented by the business analyst. So you as the BA are looking at more of the what what is needed by the business and the technical personnel are focused on how to implement what is needed.

So some examples of tests that they would perform are things like providing details about design constraints and feasibility of the requirements. They'll design system security system architecture, network architecture interfaces with existing systems, they'll design and maintain databases developed software programs manage so Software configurations support the help desk with issues that come up and unit test software programs. So any changes that they're making they need to unit test it before they pass it along to the QA team to be tested. So that takes care of our presentation on projects and project teams.