A brief introduction to the Project Management Lifecycle.

Project Management Lifecycle The project management lifecycle involves many stakeholders, processes, communication pieces, and other logistical matters, all geared towards developing a solution which meets the needs of the business unit. The Project Management Office (PMO) will facilitate all facets of the project to accomplish the defined goals. It’s critical that each project contains all necessary requirements, clear communications, and consistent processes. When requirements have not been fully identified, communications are unclear, or established PMO processes are not followed consistently, multiple interpretations of the final solution exist. The illustration below shows what can happen when fundamental project management processes are not followed: One of the components in the project management lifecycle that results in providing what the customer really needs, is gathering all the requirements. In working with the PMO, the business unit will identify which requirements are absolutely necessary, which ones are “nice-to-haves”, and which ones are not germane to the project at all. The end goal is to produce a result similar to the tree and tire swing picture…..“What the customer really needed”.
Project Management Lifecycle The project management lifecycle involves many stakeholders, processes, communication pieces,...
Project Management Lifecycle The project management lifecycle involves many stakeholders, processes, communication pieces, and other logistical matters, all geared towards developing a solution which meets the needs of the business unit. The Project Management Office (PMO) will facilitate all facets of the project to accomplish the defined goals. It’s critical that each project contains all necessary requirements, clear communications, and consistent processes. When requirements have not been fully identified, communications are unclear, or established PMO processes are not followed consistently, multiple interpretations of the final solution exist. The illustration below shows what can happen when fundamental project management processes are not followed: One of the components in the project management lifecycle that results in providing what the customer really needs, is gathering all the requirements. In working with the PMO, the business unit will identify which requirements are absolutely necessary, which ones are “nice-to-haves”, and which ones are not germane to the project at all. The end goal is to produce a result similar to the tree and tire swing picture…..“What the customer really needed”.
Project Management Lifecycle The project management lifecycle involves many stakeholders, processes, communication pieces,...
What is a Business Analyst and what do they do? A Business Analyst (BA) is your project resource to ensure the end product meets your requirements. The main areas of responsibility of a BA include: Elicit and Document Project Requirements from the Business Unit Work With the Developers to Create the Solution brainstorming sessions, each one will invariably entail some form of questioning technique. Questioning is a method of eliciting and differentiating exactly what it is the business unit needs, what the business unit wants, and what the project will and won’t undertake. Trust us, the BA isn’t trying to be difficult; just trying to give you an end product you’ll be happy with. Lack of thoroughly eliciting and documenting project requirements will result in some or all of the following: change to the scope of the project, extending the project timeline unnecessarily, the end result is not what the business unit had in mind or wanted, and/or cloudy project expectations. Oversee Testing Activities Assist the Business Unit in Developing Process Elicit and Document Project Requirements “What’s a requirement and why so many questions??” Great question! Whether the BA collaborates with the business unit through workshops, questionnaires, focus groups, interviews, Notice we didn’t touch on the “How”. The “How” is the role of the technical team and they will design a solution to meet your requirements.
What is a Business Analyst and what do they do   A Business Analyst  BA  is your project resource to ensure the end produc...
What is a Business Analyst and what do they do? A Business Analyst (BA) is your project resource to ensure the end product meets your requirements. The main areas of responsibility of a BA include: Elicit and Document Project Requirements from the Business Unit Work With the Developers to Create the Solution brainstorming sessions, each one will invariably entail some form of questioning technique. Questioning is a method of eliciting and differentiating exactly what it is the business unit needs, what the business unit wants, and what the project will and won’t undertake. Trust us, the BA isn’t trying to be difficult; just trying to give you an end product you’ll be happy with. Lack of thoroughly eliciting and documenting project requirements will result in some or all of the following: change to the scope of the project, extending the project timeline unnecessarily, the end result is not what the business unit had in mind or wanted, and/or cloudy project expectations. Oversee Testing Activities Assist the Business Unit in Developing Process Elicit and Document Project Requirements “What’s a requirement and why so many questions??” Great question! Whether the BA collaborates with the business unit through workshops, questionnaires, focus groups, interviews, Notice we didn’t touch on the “How”. The “How” is the role of the technical team and they will design a solution to meet your requirements.
What is a Business Analyst and what do they do   A Business Analyst  BA  is your project resource to ensure the end produc...
Work with the Developers Oversee Testing Activities The BA will work with the developers to bring your requirements into a workable solution. The business unit isn’t, and shouldn’t be, involved in the “tech speak” or the behind-the-scenes building phase of the project. You just need the solution built and the BA understands that. However, you should be aware the BA is working hard for you to make sure the developers know exactly what the end product needs to do from a functional perspective. After the solution is built the BA will collaborate with the business unit to develop testing activities. The goal of testing is to document anything and everything that may not work according to the business unit’s requirements and fix what doesn’t work. The BA will capture the technology development aspect of the project, known as technical requirements, in the Technical Design Specification (TDS) document. The TDS document may not mean much to the business unit and that’s okay, but from an IT perspective this document governs how the solution the business unit needs will be built. The TDS document is also important for the developers, both now and in the future, if enhancements to your system(s) are ever needed at a later time. “So, how does testing actually work?” The business unit, and perhaps other users of the system, some who may not have been engaged in the project up to this point, will perform actions in the developed solution in search of items that don’t work. Kind of like test-driving a car before buying it. It’s time to bring out the cynical side and look for flaws. The flaws, hopefully not very many, will be documented, fixed, and retested. Once this process has occurred and all flaws have been corrected, and only when all flaws have been corrected, the business unit will be asked to give their approval that the developed solution works.
Work with the Developers  Oversee Testing Activities  The BA will work with the developers to bring your requirements into...
Work with the Developers Oversee Testing Activities The BA will work with the developers to bring your requirements into a workable solution. The business unit isn’t, and shouldn’t be, involved in the “tech speak” or the behind-the-scenes building phase of the project. You just need the solution built and the BA understands that. However, you should be aware the BA is working hard for you to make sure the developers know exactly what the end product needs to do from a functional perspective. After the solution is built the BA will collaborate with the business unit to develop testing activities. The goal of testing is to document anything and everything that may not work according to the business unit’s requirements and fix what doesn’t work. The BA will capture the technology development aspect of the project, known as technical requirements, in the Technical Design Specification (TDS) document. The TDS document may not mean much to the business unit and that’s okay, but from an IT perspective this document governs how the solution the business unit needs will be built. The TDS document is also important for the developers, both now and in the future, if enhancements to your system(s) are ever needed at a later time. “So, how does testing actually work?” The business unit, and perhaps other users of the system, some who may not have been engaged in the project up to this point, will perform actions in the developed solution in search of items that don’t work. Kind of like test-driving a car before buying it. It’s time to bring out the cynical side and look for flaws. The flaws, hopefully not very many, will be documented, fixed, and retested. Once this process has occurred and all flaws have been corrected, and only when all flaws have been corrected, the business unit will be asked to give their approval that the developed solution works.
Work with the Developers  Oversee Testing Activities  The BA will work with the developers to bring your requirements into...
The business unit is responsible for reviewing and approving testing documentation, finding individuals who can participate in testing activities, and completing the prescribed testing activities. Keep in mind that if the solution doesn’t work in testing, it isn’t going to fix itself when it goes live. Feelings will not be hurt by pointing out what doesn’t work. This is a critical step in the project lifecycle. Assist the Business Unit in Developing Processes Whether the developed solution is brand new or an enhancement to an existing system, having documented processes for how to use the solution is extremely valuable. The BA will work with the business unit to identify processes and document their existence. Documenting process is often a missed opportunity in projects as it may be deemed unnecessary because everything already works. However, consider your current department and the tasks you are responsible for. How many of those tasks can you refer to a document for detailed instructions? For the tasks that are documented, how much easier is it to perform those tasks, train new employees, and establish standards? Since you already went through testing, you know the outcome will work, it’s now just a matter of documenting actions of the users and outcomes of the system until the desired result is achieved. The End The BA is a resource for the business unit and is 100% dependent on the business unit supplying the needed information. The BA continuously works on the matters detailed in this document until the business unit provides their acceptance at each stage in the project. The relationship between BA and business unit is collaborative with a common result in mind….providing the customer what they needed. Enjoy this journey you are about to undertake!
The business unit is responsible for reviewing and approving testing documentation, finding individuals who can participat...
The business unit is responsible for reviewing and approving testing documentation, finding individuals who can participate in testing activities, and completing the prescribed testing activities. Keep in mind that if the solution doesn’t work in testing, it isn’t going to fix itself when it goes live. Feelings will not be hurt by pointing out what doesn’t work. This is a critical step in the project lifecycle. Assist the Business Unit in Developing Processes Whether the developed solution is brand new or an enhancement to an existing system, having documented processes for how to use the solution is extremely valuable. The BA will work with the business unit to identify processes and document their existence. Documenting process is often a missed opportunity in projects as it may be deemed unnecessary because everything already works. However, consider your current department and the tasks you are responsible for. How many of those tasks can you refer to a document for detailed instructions? For the tasks that are documented, how much easier is it to perform those tasks, train new employees, and establish standards? Since you already went through testing, you know the outcome will work, it’s now just a matter of documenting actions of the users and outcomes of the system until the desired result is achieved. The End The BA is a resource for the business unit and is 100% dependent on the business unit supplying the needed information. The BA continuously works on the matters detailed in this document until the business unit provides their acceptance at each stage in the project. The relationship between BA and business unit is collaborative with a common result in mind….providing the customer what they needed. Enjoy this journey you are about to undertake!
The business unit is responsible for reviewing and approving testing documentation, finding individuals who can participat...