Project Management KP1

Summary

This video serves as a comprehensive guide to project management, diving into its definition, characteristics, and life cycles. Alina from Training Center walks us through the essentials, covering various project development models like Waterfall and Iterative, and the inherent roles within a project such as developers, managers, and analysts. The build management process and the intricate details of crafting an effective test plan are explained thoroughly. Explorations of test approaches, risk management, and test schedules are elaborated to provide a holistic view of maintaining quality control throughout the project life cycle. Viewers will gain a clear understanding of project dynamics, roles, and the importance of detailed documentation, making it an invaluable overview for both novices and seasoned project managers alike.

Highlights

• Project management is about achieving goals with limited resources and time 🕒.
• The Project Life Cycle includes initiation, planning, execution, control, commissioning, and completion 📈.
• Different project models, such as Waterfall and Iterative, cater to various project needs and challenges 🌊🔄.
• Roles like developers, project managers, and QA engineers drive project success 🏗️.
• Crafting detailed test plans and approaches ensures quality and standards are met 🧪.
• Build management and testing stages are critical for project development 🚀.
• Effective risk management and documentation are key to handling project challenges 📚.

Key Takeaways

• Projects are unique, goal-oriented activities with specific timelines 📅.
• Multiple project models exist, each with its pros and cons, like the Waterfall and Iterative models 🌊🔄.
• Understanding project roles, from developers to managers, is crucial for coordination 👥.
• A comprehensive test plan and test approach help in maintaining quality standards across all project stages 🧪.
• Managing risks and having mitigations in place is essential for project success 🚨.

Overview

In the world of project management, every project is a concerted effort aimed at achieving specific goals within a set timeline and resource allocation. From inception to completion, each phase of the Project Life Cycle plays a pivotal role in driving a project towards success. Understanding the characteristics of a project, including its uniqueness, temporariness, and goal-orientation, is crucial for anyone involved in project management.

Project development models such as Waterfall and Iterative offer distinct pathways for handling various project challenges. While Waterfall is linear and ideal for projects with well-defined stages, Iterative models allow for flexibility and continuous improvement. Each model presents its own set of advantages and potential pitfalls, with understanding them being key to selecting the right approach for your project needs.

Roles within a project are as diverse as the projects themselves. From developers who build and fix software to project managers who oversee timelines and resources, each role is essential for seamless execution. The importance of testing, risk management, and thorough documentation cannot be understated, serving as the backbone of effective project management. Whether it's understanding test plans or build management, every detail counts toward the overall success of the project.

Chapters

• 00:00 - 00:30: Introduction In the introduction chapter, Alina introduces the topic of project management. She outlines the key points that will be covered in the discussion, including the definition of a project, its characteristics, and the project life cycle. Alina also mentions the different project development models, roles involved in a project, and the management process. Furthermore, the chapter promises an in-depth discussion on test plans and test approaches.
• 00:30 - 01:00: Definition of a Project A project is defined as a unique set of processes aimed at achieving a specific goal within fixed resources and a certain timeframe. It involves managed and coordinated tasks, each with a start and end date. Understanding project features is crucial, as every project must have a clear purpose and goal. There is no such thing as a project without an objective.
• 01:00 - 01:30: Characteristics of a Project This chapter explores the characteristics that define a project. A project should have coordinated participant actions aimed at achieving a specific goal, have a start and end date indicating its time-bound nature, be unique and original, and include a leader or supervisor. It also introduces the concept of a Project Life Cycle, which is a sequence of phases tailored to project management needs. The phases mentioned include initiation, planning, execution, and control.
• 01:30 - 02:30: Project Life Cycle The chapter 'Project Life Cycle' discusses the different stages involved in the lifecycle of a project. It highlights that a QA engineer can participate in almost all stages, except for the completion phase. Specific actions and responsibilities associated with each stage, like initiation, which includes defining scope, stakeholders, and potential risks, are also reviewed.
• 02:30 - 04:30: Project Development Models The chapter 'Project Development Models' begins by detailing the planning phase of project development. During this phase, detailed plans are created, which involves defining the project requirements, allocating resources, and creating prototypes if necessary. This sets the foundation for the subsequent execution stage, where the actual development takes place. In this stage, code is written, tasks are performed, and main deliverables are produced. The chapter also covers the control stage, emphasizing the importance of testing to ensure deliverables meet the required quality standards. Upon approval, the deliverables are then operationalized, signifying the final stage of this development model.
• 04:30 - 07:10: Common Project Roles This chapter covers the various roles involved in a project's lifecycle, specifically during the commissioning and support, and completion phases. In the commissioning and support phase, roles are active in overseeing project finalization, while in the completion phase, final documentation, training, and handover activities are conducted. Notably, a QA engineer does not participate in the completion phase as their tasks are considered complete. The chapter begins to touch on project development models, starting with the waterfall model.
• 07:10 - 10:00: Build Management Process The 'Build Management Process' chapter describes the sequential software development model, also known as the waterfall model. In this model, progress flows steadily downward through distinct phases such as requirements development, project planning, project implementation, testing, and commissioning. The key idea is to avoid circling back to previously completed stages. This model offers advantages, such as requiring complete and consistent documentation at every stage, which are discussed alongside its disadvantages.
• 10:00 - 54:00: Test Plan and Test Approach This chapter discusses the importance of proper documentation in project management, specifically in the context of test planning and approach. It emphasizes that thorough documentation allows for the estimation of project timings and costs. However, it also warns that if errors are made and not identified early due to the inability to revisit previous stages, it can lead to increased project risks and costs. Each project stage has unique actions, implying that the responsibility is distributed among participating stakeholders. This approach underscores the need for careful planning and error management to avoid project failure.

Project Management KP1 Transcription

• 00:00 - 00:30 hey guys I'm Alina and the topic we're going to cover today is project management from this video you will learn what is the definition of project and what are the characteristics of a project what is the life cycle of a project and which project development models exist we will also cover all the project roles build management process and devote quite significant time to discuss all the points of test plan and test approach and let's get started with the definition of project well something we call a project is an activity aimed
• 00:30 - 01:00 at achieving a certain goal with fixed resources in a certain time in other words this is a unique set of processes which contain the managed and coordinated tasks with their own start date and end date which are undertaken to achieve a certain goal also knowing the project features can help you better understand what is a project and every project should always have a purpose like there is no project with no goal that we want to achieve
• 01:00 - 01:30 also it should have the coordinated actions of its participants to achieve this predefined purpose or goal it should have the start date and end date which means that every project is time limited it should be unique and original and it should always have its own leader or supervisor Project Life Cycle is a sequence of project phases which are set based on the needs of project management now let's see what are these phases these include initiation phase plan planning execution control
• 01:30 - 02:00 commissioning and support and completion phase as you can see from the slide almost at any stage of Project Life Cycle QA engineer can be involved this with the only exception of completion stage where the QA engineer is not joining now let's see what are the possible actions that can be performed at each of the stages of the Project Life Cycle if we speak about initiation phase this is about defining the scope stakeholders and potential risks associated with the project in the
• 02:00 - 02:30 planning phase the detailed planning takes place and at this stage we Define the requirements allocate the resources and create the prototypes in case this is needed execution stage involves putting all the plans into action and this is when code is written tasks are performed and Main deliverables are produced at the control stage testing is conducted to ensure that the deliverables meet the quality standards once the project deliverables are approved they are put into operation or
• 02:30 - 03:00 are commissioned this is happening at commissioning and support phase and if we speak about completion phase this is when the final documentation is created and some remaining activities are performed like training or Handover activities again this is the only stage at which QA engineer will never join as long as their activities are no longer required speaking about project development models let's start with the waterfall one and this is is a
• 03:00 - 03:30 sequential software development model in which the progress flows steadily downwards through distinct phases those phases include requirements development project planning project implementation testing and commissioning the idea of this model is that we never Circle back to the previously completed stages and this causes both advantages and some disadvantages the pros of waterfall model is that this model requires complete and consistent documentation at every stage and having this complete
• 03:30 - 04:00 documentation provides the opportunity to easily determine the timings and cost of the project but because we can never Circle back to the previous stages this might cause some errors being accumulated in the early stages of the project which would result in the increase of risk of failure of the project as well as the increase in costs for the project also because each of the stages of the project has its own set of actions the load of project particip ANS
• 04:00 - 04:30 is uneven unlike the waterfall model which progresses linearly through phases the iterative model cycles back to refine and improved project and successive iterations obviously such approach provides a number of advantages which include focus on most important or critical areas of the project or continuous iterative testing it helps to early detect the conflicts in requirements and solve them and it also provides the more balanced load of project participants as well as the
• 04:30 - 05:00 ability to assess the current and real state of the project but there's nothing with no drawbacks and the disadvantages of the iterative model include the lack of understanding of project limitations and opportunities during the prolonged time also sometimes the part of work which was done previously might be deprecated during the iterations and the engineers in the project might always get this feeling that everything can be redone or improved later and this might
• 05:00 - 05:30 also affect their performance now to project roles project rols might really vary from Project to project depending on the specific requirements but now we're going to discuss some common project roles that you might face at most of the projects starting with a developer and this is the person who desides en codes the software and who is also involved in box fixing there's also def project manager who monitors and controls the dev team work and there's a Dev project coordinator this person is
• 05:30 - 06:00 involved in contractual and financial discussions with the client as well as work with the resources time and general coordination of the teamwork architect makes key decisions on the internal structure of the application and build integrator is the person who is responsible for completing delivering and configuring project builds of course there's theqa engineer whose work is to test do defect validation create some Tes a and raise bucks there's also QA
• 06:00 - 06:30 project manager who is responsible for qualitative And Timely execution of the testing K project manager develops the testing strategy plans the work manages the tasks controls labor costs and manages the budget the work of QA project coordinator is quite similar to the work of Dev project coordinator was the only difference that this is related to QA team so this is the person responsible for allocating financial and
• 06:30 - 07:00 time resources maintaining contractual relations with de client as well as resolving any disputes and conflict points business analyst investigates the idea and the concept of the project and based on their investigations they create the functional requirements and as for the technical writer this is the person responsible for writing the guides and manuals or in other words creating any type of documentation which accompanies the product now let's move to build
• 07:00 - 07:30 management this is the process of creating organizing and maintaining the build artifacts throughout the Project Life Cycle the standard process of work with the build is the following first Dev and ke project managers determine when the build is ready for testing then built integrator prepares the build built integrator also sends the notification that the build is ready QA manager sends the notification about the beginning of testing then all the pre-planned tests are EX executed and
• 07:30 - 08:00 afterwards QA team send a quality report again there may be some deviations from this process because each project is unique and the processes for each project are set up differently but this is the most General flow that we try to stick to well now we got to the topic test plan and test approach well test plan is a document which defines the goals and scope of testing project as well as test approach test approach in its turn answers to such questions as
• 08:00 - 08:30 what to test when to test how to test it and who is going to test it test plan is usually developed by Q manager at the start of the project and is maintained throughout the duration of the whole project the main sections of test plan include the following listed on the screen and these are project introduction and business issues description of work change management project and features criteria quality control some project metrics it also
• 08:30 - 09:00 includes project glossery and some industry standards to follow if there are any project roles and responsibilities onboarding plan project team expertise feedback request rules risks and their mitigation plan and the test approach now let's discuss each of the sections of test plan in detail let's start with the first section which is Project introduction and business issues the purpose of the section is to provide the brief information about the customer
• 09:00 - 09:30 their business this business goals and objectives as well as skip some information about key project features Milestones or project history in the example on the right you can see some possible description of customer business goals for example reduce release time from 6 months to less or increase sales by 20% also K might have their own goals for example create 100% coverage by Auto tests of regression scope next section is description of the work and here we
• 09:30 - 10:00 want to clarify the project scope and project deadlines for all the activities that will need to be done in the project also we want to document customers expectations and some acceptance criteria which the customer will use to assess our work this section might also contain some valuable points for example how QA team or project manager specifically can be helpful for the customer the section might include some project objectives descript ion
• 10:00 - 10:30 project scope project boundaries or project deliverables change management section establishes the rules and conditions According to which all the changes should take place in the project these might include informing the customer about vacations some rotations or withdrawals of team members or some agreements on overtime work if we speak about changes generally this is about any changes which deviate from Project processes or initial project in in puts
• 10:30 - 11:00 so this section might truly include almost everything from team composition to redefining the scope or deadlines project and features criteria describe all the possible internal and external criteria so that they are shared with all the team members this criteria might be divided into entry criteria when we start testing or exit criteria same criteria for release as I've mentioned entry criteria include the points which indicate that we can start testing this might be installation of all the test
• 11:00 - 11:30 Hardware platforms or creation of test documentation preparation of designs or clarification of all the requirement points all this can also include the preparation of proper test data when we're done with testing there should be some points which can help us assess whether the product is ready for release and this exit criteria might include a certain level of requirements coverage absence of high priority or or high severity bugs full coverage of high risk areas of the project or for example the
• 11:30 - 12:00 lack of budget or time having all this criteria documented can help sync up all the team members and find some workarounds if there are any difficulties speaking about quality control section this is where we have the description of plan tools and some methods that are used by the Q project manager to control the quality of the product processes or the work of the QA team obviously the examples from the table are not finite this is just just to provide you with some overview of
• 12:00 - 12:30 what can be here in this section in respect of product quality we can track the dynamic of changes in number of defects in the new functionality or for example track the amount of failed tests as for process quality something we can evaluate is the quality of knowledge transfer process and the quality of teams work is usually evaluated with the help of some metrics for example the metrix for the M books or the defect description quality project metrix even deserves their own section in the QA
• 12:30 - 13:00 plan and this section describes the approach to collect this metric as well as all the indicators that are used to evaluate the team's performance the product quality and generally the results of teamw work there are numerous metrics that can be gathered in the project and this really depends on the purpose of their Gathering and the project needs besides the metrics for M books there is also the workload distribution metrics this might include the percentage of time spent for test documentation creation the time spent on
• 13:00 - 13:30 test execution or time spent for defect validation in case there are some specific standards that should be followed in the project which can affect the team's work this should be put into the project glossery and Industry standards section even if there are no specific standards to follow most of the projects have their own specific terminology which should also be described and be accessible for all the team members this might include some specific abbreviations some names of modules names of processes
• 13:30 - 14:00 and whatever which will be helpful for the whole team it's not always that you will see all those common roles in the project that we've just discussed this is why it's really helpful to have this roles and responsibilities section which can help you navigate and see who are those people you working with from this section you can obviously learn the responsibilities of the team members as well as get the information about who to contact in case you have any issues from the table below you can see a simple
• 14:00 - 14:30 example of what can be there in this section which might also be extended with the distinct responsibilities or of this or that role training and on boarding plan section is not only helpful for those who are going through this knowledge transfer process this is where you can learn the requirements for the expertise of QA engineers and get acquainted with the plan of knowledge transfer for the on boarding of new Engineers as for team expertise section this is where we have the up toate information on Project teams expertise
• 14:30 - 15:00 on several areas like project functionality expertise processes knowledge some technical knowledge or expertise in the use tools below there is an example of simple expertise metrix where we have the module functionality and the QA engineer and their results feedback request rules is the section describing the procedure for collecting feedback from the customer there might be different ways different terms and different formats of collecting the feedback and all of these
• 15:00 - 15:30 might be depicted here in this feedback request rules section risks and medication section is where we have the identification and description of risks those are the events which might negatively impact the project also in this section we have the mitigation plan which is aimed at preventing those risks below there is just a one line example of the risk Matrix table in which you have the risk itself the reasons why this RIS RIS might occur consequences if
• 15:30 - 16:00 these risks appear and some corrective actions or mitigations and finally we got to test approach this is the part of test plan which regulates the Kea team's work for a specific release sub project or the project as a whole test approach includes the test deliverables something which should be delivered to the client test schedule some test types and test coverage that we're doing in the project test design and test documentation tracking rules requirements regulations
• 16:00 - 16:30 and traceability if we have test Automation in the project then there will be the section test Automation and tools rules for defact reporting and tracking time tracking rules or in other words worklog rules task management some communication info information on reporting quality assessment and test environment test deliverables and acceptance criteria should be discussed and agreed with the customer at the project start and this section describes the the process of obtaining test
• 16:30 - 17:00 results as well as the way to present those results to the customer speaking about functional testing test deliverables can include project product quality report test scenarios the links to defects registered in the system or efforts reports the next section is test schedule and the purpose of it section is to inform the project team about the timelines planned work sequence of the tasks implementation some deadlines and key dates this schedule can be presented in two
• 17:00 - 17:30 forms table and gun chart this is the example of gun chart as you can see here we have the task name start and end dates the amount of calendar days to spend for the task current progress on the task and the amount of work days with the help of this schedule you can see which task should be done first which should be taken next what is the current state and if we are still fitting into deadlines this is another example of test schedule but in table
• 17:30 - 18:00 form an important section is test types and test coverage it provides the information on the types of tests their composition and the test coverage used in the project and although we all know what is smoke test or new feature test it would be quite weird to assume that everyone in the team including the customer or Dev team know the same this is why this section helps to sync up every team member on terminology and make sure that everyone is on the same
• 18:00 - 18:30 page when we speak about this or that test type as you can see from the table below this section might include the name of test type and the short description of what it is quite the same is for test design and tracking rules this helps not only to regulate the way to work with test documentation but also to make sure that everyone in the team and most important the entire QA team is aware about the test documentation and test design used in the project this section might also have some definitions
• 18:30 - 19:00 process description and as an example the rules for creating a test case requirements regulations and traceability can help the whole team sync up on how to work with requirements it allows to track changes in the requirements as well as control the coverage of requirements by tests here we can have the description of requirements life cycle which might include who creates the requirements who is responsible for this or that specific requirement what are the tools for
• 19:00 - 19:30 working with them or what is used to manage the requirements for example traceability metrics in case we do have test Automation in the project then the test Automation and tool section is also necessary this is where we describe the goals and objectives of test automation project describe the general approach for test Automation and also cover the technological stack of the project for example this section might have automation objectives again technology stack CI system some reports or code
• 19:30 - 20:00 design requirements as long as every project is a unique snowflake def reporting in tracking rules might also be different from all your previous experience the project specific information on how to work with defects you might fighting this defect reporting and tracking section this includes the rules of submitting and describing defects determining the severity of them defect life cycle and defect validation rules I'm pretty sure that during your work you will face more more than one time tracking system time tracking rules
• 20:00 - 20:30 section helps to understand what are these systems used in the project and how to work with them again here every project will be different from the previous ones so this section needs to be carefully studied it usually might contain some activity the task ID to log the time category which needs to be used and the rules for comments tasks management section regulates the work with tasks in the project this might be the decryption of Q tasks life cycle for
• 20:30 - 21:00 example the start of work rules on updating the status completion of the task or required task attributes this can also describe the format of comments on tasks Linkin rules and conditions for transition in between statuses here you might also find some project participants who are authorized for task distribution or tools to work with tasks communication section is really helpful for the project newcomers it describes the communication structure some
• 21:00 - 21:30 communication rules or communication channels for example here you might find the list of project meetings with their description rules for written communication some rules of business emails and the response time for the questions from the customer often in the projects reports are one of the key factors which help the customer evaluate the QA team's work this is why there should be the reporting section which describes the structure and formats of reports provided to the client as well as their types regularity recipients and
• 21:30 - 22:00 whatever helpful information here's a small example of report matrics here you can find the person who is responsible for report creation the recipient of this or that report report type specifically frequency how often it's sent or the content the intention of quality assessment section is to provide awareness to the whole QA team on the rules for evaluating product quality build and test types it should
• 22:00 - 22:30 obligatory have the description of the selected quality evaluation for example subjective objective or even both and the list of evaluation criteria which are used in the project as an example there might be the description of build quality marks was the level itself and some clarifications and finally here is test environment section this is where you can find the list of environments some instructions on how to configure this or that environment or some limitations and specific things that you might face when working with it as an example here you
• 22:30 - 23:00 can find the URLs some credentials and environment's purposes and guys this is it for today's video thanks for your attention and see you next time