Module 6: Executing the Project 🏃🏼♀️➡️ Flashcards
work performance data
This data includes raw observations and measurements from project activities (work completed/ being completed), like:
- Percentage of work completed
- Quality and technical performance measures
- Start and finish dates of tasks
- Number of change requests and defects
- Actual costs and project durations
This data is typically stored in your project management software and project documents.
Work performance reports
take this information and present it in a clear format, like status reports, memos, or dashboards. These reports are used to make informed decisions, identify issues, and keep stakeholders informed.
work performance information
considers the bigger picture and relationships between different project areas. Examples include:
- Status of deliverables(Are they on track?)
- Implementation status of change requests(How are approved changes progressing?)
- Forecasts to complete the project(Will we meet the deadline?)
change request
formal proposal to modify the project, such as taking corrective actions, preventive actions, or fixing defects. This ensures changes are well-considered and approved by stakeholders.
Osmotic Communication
Informal knowledge sharing that happens through everyday interactions-I remember this term by thinking of osmosis. Osmosis is absorption-when you are having others speak or working alongside someone you are going to absorb that knowledge
Explicit Knowledge
Documented information that can be easily shared and transferred-this is fact based knowledge that’s documented-so your lesson learned, processes and procedures things like that
Tacit Knowledge
Experience-based knowledge that’s harder to capture and communicate. This is more of someone explaining something to you from their perspective and it can include things like emotions, their emotions, their experiences. their ability, things you can learn from shadowing or conversations .
Technical Lessons Learned
these lessons focus on the technical aspects of the project, think about technical pieces from your industry. If you work in tech software design considerations, coding considerations, integration dependencies are all technical. If you work in construction, building codes, zoning, machinery considerations are all technical pieces that you may write lessons learned about
Project Management Lessons Learned
Insights on how you managed the project itself (scheduling, communication, etc.).
Organizational Lessons Learned
Broader learnings about your company’s approach to projects (approval processes, resource allocation).
Manage Quality activities
- Brainstorming to think about POTENTIAL ISSUES and leveraging data from Control Quality.
- Developing preventive actions such as training, quality control procedures, or acquiring necessary equipment.
- Creating test and evaluation plans to catch issues early.
- FOLLOWING/ CARRYING OUT QUALITY MGMT PLAN NOT EVALUATING DELIVERABLES YET
Control Quality activities
- Discovering flaws in project deliverables
- Gathering performance data andverifying deliverables.
- Identifying any deviations from the plan.
- Feeding this data back into Manage Quality for continuous improvement.
Manage quality
Translating the quality management plan (from planning) into executable tasks (like creating testing plans). We are NOT ACTUALLY DOING THE TESTING OR CHECKING of thePRODUCT/service/resultIN THIS PROCESS. We are checking and applying PROCESSES (like are we using the right methodology or following company processes). We are not evaluating project deliverables – we evaluate deliverables in control quality.Remember for the exam: If a project is beingaudited to ensure compliance with organizational policies…manage quality is being conducted.Because that is PROCESS related.
Control quality
the process thatrecords deliverable results and ensures the project outputs (actual project deliverables) are correct. We useQuality control to analyze and evaluate the project deliverables against the requirements.Control quality is assessing the physical product/services to ensure it meets the quality metrics defined. In control quality you will discover flaws in project deliverables. Basically comparing actual quality to planned quality to see if they “passed”. If not, you use tools and techniques to fix what went wrong. Essentially you’re then going back to manage quality after changes has been made.
Quality Checklist
Helps project teams and quality teams ensure consistency in tasks performed regularly during things like product assembly. It’s just a checklist of items that need to be completed, tested, or checked to ensure quality
Design for X
The Design for X (DfX) guidelines are guidelines used to design products that are safe, reliable, and easy to use (they are not specifically designed to ensure consistency in tasks though, that is what a checklist does).
Pareto Principle/ chart
also known as the 80/20 rule, states that 80% of a project’s results come from 20% of the work, and that 80% of consequences come from 20% of causes. This basically means that a small percentage of causes can have a large effect on the project outcomes. Think about a project you did really well, but then maybe somewhere along the way one day you missed a crucial step. Even though 80% of the time you did everything perfectly, the ONE delay had a HUGE impact on the results.. thats the 80/20 rule/ Pareto principle.
The PARETO CHART is a tool that shows which elements are impacting the key metrics. It highlights which issues are the most critical and should be addressed first
Quality Reports
Documents summarizing project quality activities and findings.
Test and Evaluation Documents
Documents outlining testing procedures and results.
Project Management Plan Updates
Updates to project documents based on quality findings.
statistical control
Run Chart, Pareto Chart, and Control Chart.
Control chart
used to determine whether or not a process is stable or has predictable performance.
Definition of Done (DoD)
shared understanding of what it means for work to be finished and ensures that the Increment is meeting the quality requirements for the product.
Definition of Ready (DoR)
checklist of what needs to be done to a product backlog item before the team can start implementing it in the next sprint. It defines the quality criteria for the creation of any User Story, Business Epic, Product (Release) to ensure that any backlog item being considered for work is actually ready to be worked on and to be moved into the next sprint. The DoR is the little cousin of the DoD.
