Software process

Get Started. It's Free
or sign up with your email address
Rocket clouds
Software process by Mind Map: Software process

1. HR Management

1.1. Human Resource Planning

1.1.1. determines project roles, responsibilities and reporting relationships

1.1.1.1. PM’s Responsibilities:

1.1.1.1.1. Overall responsibility for the project

1.1.1.1.2. management process

1.1.1.1.3. Manage expectation of project organization

1.1.1.1.4. Develops all deliverables

1.1.1.1.5. Keeping track of schedules and time management

1.1.1.1.6. Executes quality reviews (formal and management)

1.1.1.1.7. Update project data/records following procedures

1.1.1.1.8. Administers change requests and issues

1.1.1.1.9. Keep Project Sponsor and team informed of progress, issues and concerns

1.1.1.2. Team’s Responsibilities

1.1.1.2.1. Contribute to the project management plan (Define and estimate time of task).

1.1.1.2.2. And accomplish work defined in the project scope statement (WO).

1.1.1.2.3. Attend project team meetings

1.1.1.2.4. Process improvement

1.1.1.2.5. Comply with quality and communications plans

1.1.1.2.6. Define the products of project

1.1.1.2.7. Identify and analyze constraints, assumptions, risks

1.1.1.2.8. Define detailed requirements

1.1.1.2.9. Create WBS

1.1.1.2.10. Identify dependencies, provide time and cost estimates

1.1.1.2.11. Log data: timesheet, defects to Fsoft tools

1.1.1.2.12. Produce project performance reports

1.1.1.2.13. Measure project performance

1.1.1.2.14. Close out phases of the project

1.1.2. Main Outputs

1.1.2.1. Roles and Responsibilities (Responsibilities Assignment Matrix)

1.1.2.2. Project Organization Charts

1.1.2.3. Staffing Management Plan

1.1.2.3.1. Describe when and how human resource requirements will be added and released from the project.

1.1.2.4. Resource Histogram

1.2. Human Resource Monitoring

1.2.1. Activities

1.2.1.1. Manage Project Resources

1.2.1.1.1. Main Activities:

1.2.1.1.2. Main outputs:

1.2.1.2. Assess and Refine Project Organization Structure

1.2.1.3. Assess and Refine Team Skill

1.2.1.3.1. Main Activities

1.2.1.3.2. Main outputs:

1.2.1.3.3. Ensure team skills meet competencies

1.2.2. outputs

1.2.2.1. Project Organization

1.2.2.2. Teams: Development team, Test team, Comtor,…

1.2.2.3. Project Organization Structure

1.2.2.4. Team members with effort allocation

1.2.2.5. Effort budget for the project

1.3. Develop project team

1.3.1. “improves the competencies and interactions of team members to enhance project performance”

1.3.2. Improves skills of team members

1.3.3. Improves feeling of trust and cohesiveness

1.3.4. It is CRITICAL to the success of project

1.3.5. Should be conducted early and is an ongoing activity

1.3.6. KEY

1.3.6.1. Team building

1.3.6.1.1. Milestone parties

1.3.6.1.2. Holiday and birthday celebration

1.3.6.1.3. Outside of work trips

1.3.6.1.4. Creating the WBS

1.3.6.1.5. Planning the project by getting everyone involved.

1.3.6.2. Training: in order to perform project

1.3.6.3. or enhance team member performance.

1.3.6.4. Ground rules (establish clear expectations)

1.3.6.5. Co-location (war room)

1.3.6.6. Recognition and rewards (of desirable behavior)

1.3.6.6.1. Team performance Assessment

1.3.6.6.2. Public the rewards

1.4. Manage project team

1.4.1. PM should

1.4.1.1. Observe

1.4.1.2. Use Issue log

1.4.1.3. Keep in touch

1.4.1.4. Actively look for and help resolve conflicts that the team cannot resolve.

1.4.2. Leadership

1.4.2.1. Directing: Tell others what to do

1.4.2.2. Facilitating: Coordinating the input of others

1.4.2.3. Coaching: Instructing others

1.4.2.4. Supporting: Providing assistance along the way

1.4.2.5. Autocratic: Making decisions without input.

1.4.2.6. Consultative: Inviting ideas from others:

1.4.2.7. Consensus: group problem solving.

1.5. Conflict and Resolve Techniques

1.5.1. Conflict from

1.5.1.1. a disagreement between people on substantive

1.5.1.1.1. Goals

1.5.1.1.2. Rewards

1.5.1.1.3. Procedures

1.5.1.1.4. Resources

1.5.1.1.5. Policies

1.5.1.1.6. Job Assignments

1.5.1.2. emotional issues.

1.5.1.2.1. Feelings of anger, distrust, dislike, fear and resentment

1.5.1.2.2. Personality clashes

1.5.2. Resolve

1.5.2.1. 1. Schedules

1.5.2.2. 2. Project priorities

1.5.2.3. 3. Resources

1.5.2.4. 4. Technical opinions

1.5.2.5. 5. Administrative procedures

1.5.2.6. 6. Cost

1.5.2.7. 7. Personality

2. Project Planning

2.1. Project Opening

2.1.1. Initial Project Plan

2.1.1.1. Initialing process group

2.2. Project Planning

2.2.1. Overview

2.2.1.1. Planning Process Group

2.2.2. Steps of project planning

2.3. Project monitoring

2.3.1. Monitoring process group

2.3.1.1. Requirement Management

2.3.1.1.1. Activities:

2.3.1.1.2. Output:

2.3.1.2. Human Resource Management

2.3.1.2.1. Activities:

2.3.1.2.2. Output:

2.3.1.3. Risk Management

2.3.1.3.1. Activities:

2.3.1.3.2. Output:

2.3.1.4. Cost Management

2.3.1.4.1. Activities:

2.3.1.4.2. Output:

2.3.1.5. Payment Management

2.3.1.5.1. Activities: Manage Project Payment

2.3.1.5.2. Output:

2.3.1.6. Process Management

2.3.1.6.1. Activities:

2.3.1.6.2. Output:

2.3.1.7. Stakeholder Management

2.3.1.7.1. Activities: Manage relevant stakeholders

2.3.1.7.2. Output:

2.3.1.8. Schedule Management

2.3.1.8.1. Check and update status in project schedule

2.3.1.8.2. Evaluate deviation and analyze, find, understand cause

2.3.1.8.3. Output : updated project schedule

2.3.1.9. Task Management

2.3.1.9.1. Output

2.3.1.9.2. Activities

2.3.1.10. Quality Management

2.3.1.10.1. Output:

2.3.1.10.2. Activities:

2.3.1.11. Payment Management

2.3.1.11.1. Billing schedule must be conformed to payment deadline: put into project plan.

2.3.1.11.2. Payment Criteria should be addressed clearly

2.3.1.11.3. Being fully paid is a project’s objectives

2.3.1.11.4. All payment criteria are achieved before payment deadline

2.3.1.11.5. Once all criteria is achieved, the acceptance letter is prepared and get customer approved. Actual effort is calculated by PM, if over estimated, should negotiate for extra value.

2.4. Project closing

2.4.1. Closing Process Group

2.4.1.1. Activities:

2.4.1.1.1. Initiate Project Termination

2.4.1.1.2. Obtain Customer Acceptance

2.4.1.1.3. Issue Final Invoice

2.4.1.1.4. Finalize Project Information

2.4.1.1.5. Analyze Project Performance

2.4.1.1.6. Capture Practices/Lessons Learned

2.4.1.1.7. Complete Post-mortem Report

2.4.1.1.8. Conduct Post-Mortem Meeting

2.4.1.1.9. Distribute Post-Mortem Report

2.4.1.1.10. Evaluate Team Performance

2.4.1.1.11. Hand-Over Project Assets

2.4.1.1.12. Complete Internal Acceptance Note

2.4.1.2. Output:

2.4.1.2.1. Post-Mortem Report; Post-Mortem Meeting Minutes

2.4.1.2.2. Project Final Status Report

2.4.1.2.3. Completed Project Acceptance Letter.

2.4.1.2.4. CSS; Invoices

2.4.1.2.5. Project Data

2.4.1.2.6. Written feedback to Project Team member

2.4.1.2.7. Project Asset is archived in Wrap-up Baseline and handed-over to SC QA. Accounting

2.4.1.2.8. Document confirming that no customer-owned IP has been retained

2.5. Case studies

2.5.1. Possible solutions to common issues

2.5.1.1. Training people if they lacks skills

2.5.1.2. Review the priority of tasks and do not accept new tasks if behind schedule

2.5.1.3. Regularly monitoring cost to avoid over-run effort

2.5.1.4. Strictly follow Requirement Change Management workflow since scope keeps changing, many requirements arise.

2.5.1.5. Review Payment schedule & Payment criteria in the Contract/External Work Order

2.5.1.6. Prepare Acceptance Letter and send to customer to obtain customer approval when payment criteria are achieved and payment schedule is reached

2.5.1.7. Issue Invoice and rectify any problem encountered, work with PMs, AF and customer to resolve the problems.

2.5.1.8. Control payment progress until the invoices are fully paid.

3. Quantitative Management

3.1. Purpose

3.1.1. Quantitatively manage the project’s defined process to achieve the project’s establish quality and process performance objectives

3.2. Software Metrics

3.2.1. What

3.2.1.1. It is a measure of quantity of something. Usually a number

3.2.1.2. For example: the water level of Red River

3.2.2. Why

3.2.2.1. Quicker transfer/communication

3.2.2.2. Automation/alerts

3.2.2.3. Filtering (who needs to know what)

3.2.2.4. Consolidate & predict the future (statistical analysis, PCB)

3.2.3. Requirement Metrics:

3.2.3.1. Requirement Completeness (%): Measures percentage of requirement completed against the committed and predict the amount of remain work

3.2.3.1.1. = ∑(Requirement Size x Requirement Completed Rate)*100/Total Committed Requirement Size

3.2.3.2. Requirement Stability (%): Measures stability of requirements, frequency of requirements changed by customer

3.2.3.2.1. = (Total size of change requests / Total size of requirements)*100

3.2.4. Quality Metrics

3.2.4.1. Defect Rate (wdef/size): Measures quality of overall project's products.

3.2.4.1.1. = Total No of weighted Defects of a product/Product Size

3.2.4.2. Product Size could be = Effort usage/KLOC/UCP/FP/Module

3.2.4.3. Defect Removal Efficiency (%):Provides the efficiency of review / test processes

3.2.4.3.1. = (Total No of Project Defect - No of defects detected by Role = Customer)/ Total project defects * 100%

3.2.4.4. Leakage (wdef/size): Measure quality of the product and service after delivery for acceptance test.

3.2.4.4.1. = No of Wdef Defects detected after delivery for acceptance test of a product/Product size

3.2.4.5. Customer Satisfaction (Point): Measures the satisfaction of customer requirements

3.2.5. Cost Metrics:

3.2.5.1. Effort Efficiency (%): Measure efficiency of project effort usage

3.2.5.1.1. = (Billable Effort/ Calendar Effort)*100 (1MM=21Pds)

3.2.5.2. Effort Effectiveness (%): Provides tracking of budgeted effort against actual effort and predict future effort

3.2.5.2.1. = (Last Committed Effort Usage/Actual Effort Usage)*100

3.2.5.3. Quality Cost (%): Provides the cost that project pays for quality and efficiency of quality activities in project

3.2.5.3.1. = Effort spent for quality activities x 100/ total project effort

3.2.5.4. Correction Cost (%): Indicates cost of correcting a defective product and the associated rework/damage costs

3.2.5.4.1. = Effort spent for fixing error x 100/ total project effort

3.2.5.5. Project Management (%)= Effort spent for project management x 100/ total project effort

3.2.6. Productivity Metrics:

3.2.6.1. Productivity (Size/pd) : Provides the measurement about general productivity in project = Product size/Total effort

3.2.6.2. Coding Productivity= Product size / Coding Effort

3.2.6.2.1. Size:

3.2.6.2.2. About LOC , we can use Blue Step Counter and Kazoe-Ciao tool to count actual LOC.

3.2.7. Schedule Metrics:

3.2.7.1. Timeliness (%): Measures the ability to satisfy customer in timeliness.

3.2.7.1.1. = (No of deliverable delivered on time/ Total # of deliverables delivered)*100

3.2.7.2. Schedule Deviation (%): Provides information on project performance with respect to its schedule commitment

3.2.7.2.1. = ((Actual duration- Last committed duration)/ Last committed duration)*100

3.2.8. Process Compliance:

3.2.8.1. Process Compliance (%): Measure the compliance of project activities as with the defined rule/standard/process/regulation

3.2.8.1.1. = SUMPRODUCT(checked items, assessment results)/SUM(checked items). Note: only include checked items with assessment results = 0, 50, 100.

4. Risk Management

4.1. Risk Management Basics

4.1.1. Risk: any uncertain event / condition that might affect your project.

4.1.2. Risk details: source, condition, consequence, probability, impact, priority.

4.1.3. Where to look for risks?

4.1.3.1. Dependencies: HR, tool, equipment, etc.

4.1.3.2. Assumptions: may not actually be true.

4.1.3.3. Project characteristics: objectives, requirement, design, implementation, testability, etc.

4.1.3.4. Activities on the critical path

4.1.3.5. Team spirit and attitude

4.1.3.6. Outside project: organization, policies, rules, standards, …

4.1.4. risk process

4.1.4.1. risk management process

4.2. Risk Planning

4.2.1. Identify project risks:

4.2.1.1. Perform an initial risk assessment

4.2.1.2. Use Template Risk Management Sheet

4.2.1.3. Document defined risks

4.2.2. Analyze each risk:

4.2.2.1. Define the cause and consequence of each risk.

4.2.2.2. Estimate the probability of each risk occurring and the impact of each risk if it does occur (see Guideline for how).

4.2.2.3. Calculate the exposure value for each risk (Risk Exposure = Probability x Impact).

4.2.2.4. exposure value of a risk is the expected value of the loss for the risk

4.2.2.5. Prioritize risks basing on their exposure value

4.2.2.6. Define Risk Exposure threshold to determine which risks (the top few) need mitigation and contingency plans.

4.2.3. Do

4.2.3.1. Create risk mitigation and/or contingency plans for each risk need to be handled. Update Project WBS and Project Schedule accordingly.

4.2.3.2. Define risk triggers

4.2.3.3. Assign owners who will automatically begin executing the risk contingency plan if risk is triggered.

4.3. Risk Monitoring

4.3.1. Activities

4.3.1.1. Recognize new or suspected risks in project

4.3.1.2. Record in Project Risk List, and analyze the risks

4.3.1.3. Define action for risk mitigation and contingency, as appropriate

4.3.1.4. Assign resource to implement the actions and ensure they have sufficient time and resource to complete them

4.3.1.5. Monitor trigger for any contingency plans

4.3.1.6. Initiate contingency plan if triggers are met.

4.3.1.7. Report status on risk status and associated response actions to relevant people

4.3.2. Work products

4.3.2.1. Mitigation and contingency plans for risks

4.3.2.2. Updated Project Risk List with identified risks, risk owners, mitigation plans, and contingency plans

4.3.2.3. Risk information for status reports

4.4. Case Study

4.5. Common Risks

4.5.1. Some apps can not finished because Device not available

4.5.2. Many new members, few time for training, could not keep the productivity

4.5.3. Customer could not keep the plan of UAT

4.5.4. Running Visual studio for load testing has some error in the code Forum’s DLL sent from customer.

4.5.5. Team members have not much experience with IT Spec of PMC process so take more time to create IT Spec (test policy, test viewpoint, function list) [Impact] Effect to schedule of IT (do not keep release date of these products)

4.5.6. There are some change requests from customer so the final release is delayed

4.5.7. The initial version of STS is still the draft version, CRs are expected.

4.5.8. Customer evaluates test environment setting for Phone is difficult -> consider risk test environment

4.5.9. Team spirit is down and many resources are out of project. Inexperience team, lack of resource, not stable.

4.5.10. New PM, no experience in project management

5. Scope Management

5.1. Project scope: is the work to be done to deliver a product, service with specified features and functions.

5.2. Project scope management: the processes to ensure that all required work of project complete successfully.

5.3. Project scope management processes: processes to define/document, manage, verify and control what is or is not included in a project

5.3.1. diagram

5.3.1.1. Collect requirement: define and document stakeholders’ needs to meet the project objectives.

5.3.1.1.1. Project charter

5.3.1.1.2. Stakeholder register

5.3.1.1.3. Indentifying external interfaces

5.3.1.1.4. Analyzing high level requirements

5.3.1.1.5. Studying and Questionnaires

5.3.1.1.6. Meeting with customer for clarifying

5.3.1.1.7. Brainstorming and lateral thinking to decide technical solution

5.3.1.1.8. Prototypes

5.3.1.2. Define scope: develop detailed description of project by breaking the major project deliverables into smaller and more manageable components (Work Breakdown Structure/WBS).

5.3.1.2.1. Project charter

5.3.1.2.2. Requirements documentation

5.3.1.2.3. Organization process assets

5.3.1.2.4. Decomposition in WBS

5.3.1.2.5. Others

5.3.1.2.6. Work breakdown structure (WBS)

5.3.1.3. Verify scope: formalize acceptance of completed project deliverables.

5.3.1.3.1. Input

5.3.1.3.2. Technique

5.3.1.3.3. Output

5.3.1.4. Control scope: monitor status of project scope and manage the changes to scope baseline.

5.3.1.4.1. Input

5.3.1.4.2. Technique

5.3.1.4.3. Output

6. Project Estimation

6.1. WHY

6.1.1. One of the most challenging and important activities in project management

6.1.2. 70-80% of failed projects are due to bad estimation.

6.1.3. Under-estimating a project leads to staff burnout, low quality, missing deadline.

6.1.4. Over-estimating a project leads to resource usage inefficiency, lost opportunities.

6.2. Estimate process

6.2.1. Estimate Size

6.2.1.1. A predominant factor

6.2.1.1.1. in determining how much effort is needed

6.2.1.1.2. used for initial estimation

6.2.1.2. Functional requirements must be defined before using methods

6.2.1.2.1. Work Breakdown Structure (WBS) - popular estimation method

6.2.1.2.2. Line of Code (LOC) - done by experienced people and historical data, no guideline

6.2.1.2.3. Function Points (FPs)

6.2.1.2.4. Use-case Points

6.2.1.3. Verify estimation result using 2 or more than 2 methods

6.2.1.3.1. By Analogy

6.2.1.3.2. By Analysis

6.2.1.4. PM develop own method if standard method not suitable

6.2.1.4.1. Break product down into smaller parts (features, use cases, user stories, etc)

6.2.1.4.2. FP, UCP are suitable

6.2.2. Estimate Effort

6.2.2.1. Top-down approach:

6.2.2.1.1. Use size estimate with historical data of productivity in PCB to derive total estimated project effort

6.2.2.1.2. Convert size to effort by regression analysis of the past data

6.2.2.1.3. Determine effort of various by percentage of the total effort

6.2.2.2. Bottom-up approach:

6.2.2.2.1. easier to prepare in some situations instead of explicit size estimate

6.2.2.2.2. Risk: some important activities may be omitted

6.2.2.2.3. Estimate first for each part of the project then estimate all project, using activity-based or function-based WBS

6.2.2.2.4. Advantage: requires a list of project tasks

6.2.3. Estimate Schedule

6.2.3.1. Determine the project schedule from the effort estimate.

6.2.3.2. Various schedules are possible depending on the number of people needed for the project

6.2.3.3. Remember that effort and months are not fully interchangeable in a software project.

6.2.3.3.1. Refer to Holiday calendar

6.2.3.4. Estimate the project duration in calendar months.

6.2.3.5. Determine starting points, duration and ending point of the project.

6.2.3.6. Tools/Techniques for scheduling: Network Diagram, Grant Chart, Critical Path

6.2.3.6.1. Investigate these techniques in section Time Management

6.2.4. Estimate Human Resource

6.2.4.1. Determine the skills required to accomplish the activities

6.2.4.1.1. Using skill sheet

6.2.4.2. Check for the availability of team members for skills

6.2.4.2.1. Manager need to commit availability

6.2.4.2.2. Functional manager assesses skill set and required effort

6.2.4.3. Estimate overall cost according to the cost that manager of these people inform

6.2.5. Estimate Infrastructure Resource

6.2.5.1. Some methods: historical experience, simulations, prototyping, and analysis

6.2.5.2. Includes: Computer memory capacity, Computer processor use, Communications channel capacity

6.2.5.3. Steps for estimating resources

6.2.5.3.1. PM identifies resources for the project

6.2.5.3.2. PM estimates resources in consistence with the estimates of:

6.2.5.4. Steps for managing resources

6.2.5.4.1. Estimates for the project's infrastructure resources

6.2.5.4.2. Planned computer resources, the system requirements allocated to software

6.2.5.4.3. Available computer resources are allocated to the software components

6.2.5.4.4. Available capacity for the infrastructure resources provides for a specified reserve capacity when the initial estimates are made.

6.2.5.5. Estimating new development projects: use UCP, FP, WBS, LOC.

6.2.6. Verify Estimation

6.2.6.1. Verify quality of the estimation and to get it approved

6.2.6.2. Confirm the software architecture and functional WBS

6.2.6.3. Verify the methods used for deriving the size, schedule and cost estimates

6.2.6.4. Ensure that the assumptions and input data used to develop the estimates are correct

6.2.6.5. Ensure that the estimate is reasonable and accurate given the input data

6.2.6.6. Formally confirm and record the official estimates for the project.

6.2.7. Track and Record Estimates

6.2.7.1. Tracked overtime

6.2.7.2. Re-estimate weekly, at milestones or when the level of uncertainty or project scope is changed.

6.2.7.3. All estimation data, both planned and actual, need to be recorded in the Software Process Database.

6.2.7.4. Historical data is used for estimating for future projects

6.3. Different Kind of Projects

6.3.1. Estimating maintenance & enhancement projects:

6.3.1.1. may have to reverse engineering, rework the architecture, study the existing code, perform regression and integration testing for the whole system etc.

6.3.2. Estimating “new domain” projects:

6.3.2.1. always high risks and under-estimated.

6.3.2.2. make the risks very clear to stakeholders,

6.3.2.3. avoid making commitment to fixed deadlines,

6.3.2.4. suggest POC or prototype, re-estimate when familiar with the domain.

6.3.3. Estimating agile projects:

6.3.3.1. estimate relative size of the backlog items in Story Points

6.3.3.2. Calculate & use team velocity to estimate effort and schedule for each iteration.

6.4. Estimating Tips

6.4.1. If we lengthen the schedule, we can generally reduce the overall cost and use fewer people.

6.4.2. Allow enough time to do a proper project estimate.

6.4.3. Use historical data from our own similar projects in the past where possible.

6.4.4. Use Developer-based estimates.

6.4.5. Use At least one software estimation tool.

6.4.6. Use several different people to estimates and use several estimation techniques to compare the results.

6.4.7. Re-estimate the project several times throughout its life cycle.

6.4.8. Spend some effort on improving your estimation skills by comparing actual to estimate when project is completed.

7. Configuration Management

7.1. CM Facts

7.1.1. Use not latest revision

7.1.2. not comment when commit svn, overwrite others' file

7.1.3. wrong environment

7.2. CM Activities

7.2.1. Configuration Identification

7.2.1.1. work products

7.2.1.1.1. Requirement – URS, SRS

7.2.1.1.2. Design – ADD, DD

7.2.1.1.3. Coding – Software module, Software package

7.2.1.1.4. Test – TP, TC, TR

7.2.1.2. plan documents

7.2.1.2.1. CM plan

7.2.2. Configuration Control

7.2.2.1. Purpose

7.2.2.1.1. Ensure all the changes to the work product are in controlled

7.2.2.2. How

7.2.2.2.1. Need tools to control the changes by following the defined process

7.2.2.2.2. Change request form are introduced and must be filled before

7.2.2.2.3. All the changes must be reviewed

7.2.2.2.4. Manage version

7.2.2.2.5. Permission control

7.2.2.3. Change Request Form

7.2.2.3.1. What

7.2.2.3.2. Why

7.2.2.3.3. When

7.2.2.3.4. How

7.2.2.4. Release management

7.2.2.4.1. Category of CI to release

7.2.2.4.2. Build Release checklist

7.2.2.4.3. Build Release workflow

7.2.3. Configuration Status

7.2.3.1. CM Report

7.2.3.1.1. Purposes

7.2.3.1.2. Types

7.2.3.1.3. Contents

7.2.4. Configuration Audit

7.2.4.1. Purposes

7.2.4.1.1. Track status of changes to CIs in Change Control Report

7.2.4.1.2. Ensure that CM plan is implemented correctly

7.2.4.1.3. Provide CM accounting status

7.2.4.2. How to audit?

7.2.4.2.1. Process Compliance Verification

7.2.4.2.2. Internal Audit (CM)

7.2.4.3. Output

7.2.4.3.1. Process Compliance Verification checklist

7.2.4.3.2. Internal Audit checklist

7.2.4.4. who

7.2.4.4.1. QA

7.2.4.4.2. configuration manager

8. CAR (casual analysis resolution ) process

8.1. correct action

8.1.1. identify

8.1.1.1. defects

8.1.1.2. problems

8.1.1.3. non fulfillment of define processes

8.1.1.4. non conformities

8.1.1.5. customer complaints

8.1.2. analyze

8.2. prevent action

8.2.1. DP plan

8.2.2. Review DP plan

8.2.3. CAR meeting

8.3. Techniques

8.3.1. Pareto Chart:

8.3.1.1. (20% sources that cause 80% problem),

8.3.2. Brainstorming

8.3.2.1. All members must speak out

8.3.2.2. The success of meeting depends on the follow up.

8.3.3. Cause-Effect diagram

8.3.3.1. Fish-bone

8.3.4. 5 –WHY

9. Project Communication Management

9.1. evaluate the level of PM

9.1.1. ask stakeholders what they need from/to

9.1.2. team comminiicate

9.1.2.1. Task assignment & tracking

9.1.2.2. Issue escalation & resolving

9.1.2.3. Evaluation, Information, Motivation,

9.2. important skill of GREAT Project Manager

9.2.1. prevents many potential problems

9.2.2. major key success factor

9.3. 90% time of Project Manager

9.3.1. communicate via phone, emails, meetings

9.3.1.1. GREAT Meeting

9.3.1.1.1. Goal Oriented

9.3.1.1.2. Right People

9.3.1.1.3. Expectations Clarified

9.3.1.1.4. Agenda in Advance

9.3.1.1.5. Time Sensitivity

9.3.1.2. Better Emails

9.3.1.2.1. Avoid the use of slang words

9.3.1.2.2. NOT to use abbreviations

9.3.1.2.3. Steer away from the use of symbols

9.3.1.2.4. Brackets are used to play down words or phrases

9.3.1.2.5. Dashes are generally used for emphasis

9.3.1.2.6. Cliches should be avoided

9.3.1.2.7. Cliches should be avoided

9.3.2. Create Project Communication Plan

9.3.3. Performance Reporting

9.3.3.1. Progress Reports

9.3.3.2. Status Reports

9.3.3.3. Forecast Report

9.3.3.4. Why Report

9.3.3.4.1. Inform sponsor and users

9.3.3.4.2. Inform sponsor and users

9.3.3.4.3. Inform team members

9.3.3.4.4. Communicate changes, issues, risks

9.3.3.4.5. Maintain interest and involvement

9.3.3.4.6. Share the good news, as well as bad

9.4. KEY

9.4.1. Who are you speaking to

9.4.1.1. What are their interests, presuppositions and values?

9.4.1.2. What do they share in common with others?

9.4.1.3. How are they unique?

9.4.2. What do you wish to communicate?

9.4.3. How can you best convey your message?

9.4.4. When

9.4.4.1. Time Sensitivity

9.4.4.1.1. It’s better to be silent than sing a bad tune

9.4.5. Where

9.4.5.1. What is the physical context

9.4.6. Why

9.4.6.1. Why they should listen to you

9.4.6.2. What disposes them to listen?

9.4.6.3. the value or worth or interest of what you are going to say.

9.5. Case studies

9.5.1. Use wrong media to discuss with customer

9.5.2. Forgot to take meeting minutes.

9.5.3. Forgot distribute minutes to customer/end-user to confirm and keep evidence.

10. Time Management

10.1. Definition

10.1.1. process of organizing and planning how to divide your time between specific activities. Good time management enables you to work smarter – not harder

10.1.2. Failing to manage your time

10.1.2.1. Missed deadlines.

10.1.2.2. Inefficient work flow.

10.1.2.3. Poor work quality.

10.1.2.4. A poor professional reputation and a stalled career.

10.1.2.5. Higher stress levels.

10.1.3. What

10.1.3.1. Greater productivity and efficiency.

10.1.3.2. A better professional reputation.

10.1.3.3. Less stress.

10.1.3.4. Increased opportunities for advancement.

10.1.3.5. Greater opportunities to achieve important life and career goals.

10.2. How

10.2.1. Goal Setting

10.2.1.1. How

10.2.1.1.1. SMART

10.2.1.2. Why

10.2.1.2.1. long-term vision and short-term motivation

10.2.1.2.2. measure and take pride in the achievement

10.2.1.2.3. see forward progress

10.2.1.2.4. raise your self-confidence

10.2.1.3. Key Points

10.2.1.3.1. Deciding what you want to achieve in your life.

10.2.1.3.2. Separating what's important from what's irrelevant, or a distraction.

10.2.1.3.3. Motivating yourself.

10.2.1.3.4. Building your self-confidence, based on successful achievement of goals.

10.2.1.4. Achieving Goals

10.2.1.4.1. If you achieved the goal too easily, make your next goal harder.

10.2.1.4.2. If the goal took a dispiriting length of time to achieve, make the next goal a little easier.

10.2.1.4.3. If you learned something that would lead you to change other goals, do so.

10.2.1.4.4. If you noticed a deficit in your skills despite achieving the goal, decide whether to set goals to fix this.

10.2.2. Prioritization

10.2.2.1. What

10.2.2.1.1. what needs to be done is especially important

10.2.2.2. how

10.2.2.2.1. To-Do List

10.2.3. Managing Interruptions

10.2.3.1. what

10.2.3.1.1. phone calls, information requests, questions from employees, and a whole host of events that crop up unexpectedly

10.2.3.2. How

10.2.3.2.1. Keep An Interrupters Log

10.2.3.2.2. Analyze and Conquer Interruptions

10.2.3.2.3. Put Your Phone to Work for You (Not Against You)

10.2.3.2.4. Catch Your Breath

10.2.3.2.5. Learn to Say "No"

10.2.3.2.6. "Available" and "Unavailable" Time

10.2.4. Procrastination

10.2.4.1. What

10.2.4.1.1. In a nutshell, you procrastinate when you put off things that you should be focusing on right now

10.2.4.1.2. procrastination occurs when there’s “a temporal gap between intended behavior and enacted behavior.

10.2.4.2. How

10.2.4.2.1. Recognize That You're Procrastinating

10.2.4.2.2. Work Out WHY You're Procrastinating

10.2.4.2.3. Adopt Anti-Procrastination Strategies

10.2.4.2.4. Key Points

10.2.5. Scheduling

10.2.5.1. Importance

10.2.5.1.1. Understand what you can realistically achieve with your time.

10.2.5.1.2. Make sure you have enough time for essential tasks.

10.2.5.1.3. Add contingency time for "the unexpected."

10.2.5.1.4. Avoid taking on more than you can handle.

10.2.5.1.5. Work steadily toward your personal and career goals.

10.2.5.1.6. Have enough time for family and friends, exercise and hobbies.

10.2.5.1.7. Achieve a good work-life balance.

10.2.5.2. How

10.2.5.2.1. Identify Available Time

10.2.5.2.2. Schedule Essential Actions

10.2.5.2.3. Schedule High-Priority Activities

10.2.5.2.4. Schedule Contingency Time

10.2.5.2.5. Schedule Discretionary Time

10.2.5.2.6. Analyze Your Activities

10.2.5.2.7. Key Points

11. Scrum

11.1. 3 pillars

11.1.1. 1. Transparency

11.1.2. 2. Inspection

11.1.3. 3. Adaption

11.2. ROLEs

11.2.1. 1. Product owner

11.2.1.1. 1. Business Value

11.2.1.2. 2. Prioritize the product backlog

11.2.1.2.1. Product Backlog

11.2.1.3. 3. Final arbiter of the requirements questions

11.2.1.4. 4. Focused more on what rather than how?

11.2.1.5. 5. Vision and boundaries.

11.2.2. 2. Scrum Development Team

11.2.2.1. 1. Cross functional and self Organizing.

11.2.2.2. 2. Attempt to make a "Potentially Shippable Product Increment" Every sprint.

11.2.2.3. 3. Collaborates

11.2.2.4. 4. Have autonomy regarding how to reach commitment.

11.2.2.5. 5. Collocation especially for first few sprints

11.2.2.6. 6. 7+_2

11.2.2.7. 7. Has a leadership role.

11.2.3. 3. Scrum Master

11.2.3.1. 1. No management authority.

11.2.3.2. 2. Moves impediments out of the team.

11.2.3.3. 3. Keeps the team away from other distractions.

11.2.3.4. 4. Doesn't have a Project Manager role.

11.2.3.5. 5. Acts as a facilitator.

11.2.3.6. 6. Gets the team out of the way for natural team self organization.

11.2.3.7. 7. Helps people to train on scrum

11.2.3.8. 8. Promotes improved engineering practices.

11.2.3.9. 9. Enforces time boxes, provides visibility.

11.2.3.10. Time Boxing: Having a limit on time availability for meetings etc.

11.2.3.11. 10. Captures imperical data to adjust forecasts.

11.2.3.12. 11. Makes sure scrum artifacts are available.

11.2.3.13. 12. No decision making authority during the sprints.

11.2.3.14. 13. Increase rigor in the definition of done.

11.3. Meetings

11.3.1. 1. Sprint planning meeting

11.3.1.1. PO and the Scrum Dev team will agree to the Sprint goals and negotiate which items from the product backlog will be committed to the sprint backlog.

11.3.2. 2. Daily Scrum

11.3.2.1. What did I do Yesterday?

11.3.2.2. What will I do today?

11.3.2.3. What impedes me?

11.3.3. 3. Sprint Review Meeting

11.3.3.1. Open to stakeholders

11.3.3.2. Live Product demonstration

11.3.3.3. Product owner will decided if the acceptance criteria for the accepted PBIs have been met as in the Sprint planning meeting and if the goals have been met.

11.3.3.4. Items which are not done will be moved back to the Product backlog.

11.3.3.5. Lastly we will listen to the stakeholders product feedback which may result to new requirements for the PO to prioritize them according to his vision.

11.3.4. 4. Sprint retrospective meeting

11.3.4.1. Inspect how the last Sprint went with regards to people, relationships, process, and tools

11.3.4.2. Identify and order the major items that went well and potential improvements

11.3.4.3. Create a plan for implementing improvements to the way the Scrum Team does its work.

11.3.4.4. Status leveling techniques:

11.3.4.4.1. a)Safety Check:

11.3.4.4.2. b)Focused Conversation Principles:

11.3.4.4.3. c)Basic retrospective

11.3.4.4.4. d) Silent writing: Silent Writing is a technique implemented to hear out all the team members problems and then make decisions.

11.3.4.4.5. e) Timeline retrospective: Write down your recollection of previous

11.3.5. 5. Backlog refinement meeting.