1. CAR (casual analysis resolution ) process
1.1. 2 .correct action
1.1.1. identify
1.1.1.1. defects
1.1.1.2. problems
1.1.1.3. non fulfillment of define processes
1.1.1.4. non conformities
1.1.1.5. customer complaints
1.1.2. analyze
1.2. 1. prevent action
1.2.1. make Development Plan
1.2.2. Review DP plan
1.2.3. CAR meeting
1.3. 2.1 Techniques
1.3.1. Pareto Chart:
1.3.1.1. (20% sources that cause 80% problem),
1.3.2. Brainstorming
1.3.2.1. All members must speak out
1.3.2.2. The success of meeting depends on the follow up.
1.3.3. Cause-Effect diagram
1.3.3.1. Fish-bone
1.3.4. 5 –WHY
2. Project Communication Management
2.1. evaluate the level of PM
2.1.1. ask stakeholders what they need from/to
2.1.2. team comminiicate
2.1.2.1. Task assignment & tracking
2.1.2.2. Issue escalation & resolving
2.1.2.3. Evaluation, Information, Motivation,
2.2. important skill of GREAT Project Manager
2.2.1. prevents many potential problems
2.2.2. major key success factor
2.3. 90% time of Project Manager
2.3.1. communicate via phone, emails, meetings
2.3.1.1. GREAT Meeting
2.3.1.1.1. Goal Oriented
2.3.1.1.2. Right People
2.3.1.1.3. Expectations Clarified
2.3.1.1.4. Agenda in Advance
2.3.1.1.5. Time Sensitivity
2.3.1.2. Better Emails
2.3.1.2.1. Avoid the use of slang words
2.3.1.2.2. NOT to use abbreviations
2.3.1.2.3. Steer away from the use of symbols
2.3.1.2.4. Brackets are used to play down words or phrases
2.3.1.2.5. Dashes are generally used for emphasis
2.3.1.2.6. Cliches should be avoided
2.3.1.2.7. Cliches should be avoided
2.3.2. Create Project Communication Plan
2.3.3. Performance Reporting
2.3.3.1. Progress Reports
2.3.3.2. Status Reports
2.3.3.3. Forecast Report
2.3.3.4. Why Report
2.3.3.4.1. Inform sponsor and users
2.3.3.4.2. Inform sponsor and users
2.3.3.4.3. Inform team members
2.3.3.4.4. Communicate changes, issues, risks
2.3.3.4.5. Maintain interest and involvement
2.3.3.4.6. Share the good news, as well as bad
2.4. KEY
2.4.1. Who are you speaking to
2.4.1.1. What are their interests, presuppositions and values?
2.4.1.2. What do they share in common with others?
2.4.1.3. How are they unique?
2.4.2. What do you wish to communicate?
2.4.3. How can you best convey your message?
2.4.4. When
2.4.4.1. Time Sensitivity
2.4.4.1.1. It’s better to be silent than sing a bad tune
2.4.5. Where
2.4.5.1. What is the physical context
2.4.6. Why
2.4.6.1. Why they should listen to you
2.4.6.2. What disposes them to listen?
2.4.6.3. the value or worth or interest of what you are going to say.
2.5. Case studies
2.5.1. Use wrong media to discuss with customer
2.5.2. Forgot to take meeting minutes.
2.5.3. Forgot distribute minutes to customer/end-user to confirm and keep evidence.
3. Risk Management
3.1. Risk Management Basics
3.1.1. Risk: any uncertain event / condition that might affect your project.
3.1.2. Risk details: source, condition, consequence, probability, impact, priority.
3.1.3. Where to look for risks?
3.1.3.1. Dependencies: HR, tool, equipment, etc.
3.1.3.2. Assumptions: may not actually be true.
3.1.3.3. Project characteristics: objectives, requirement, design, implementation, testability, etc.
3.1.3.4. Activities on the critical path
3.1.3.5. Team spirit and attitude
3.1.3.6. Outside project: organization, policies, rules, standards, …
3.1.4. risk process
3.1.4.1. risk management process
3.2. Risk Planning
3.2.1. Identify project risks:
3.2.1.1. Perform an initial risk assessment
3.2.1.2. Use Template Risk Management Sheet
3.2.1.3. Document defined risks
3.2.2. Analyze each risk:
3.2.2.1. Define the cause and consequence of each risk.
3.2.2.2. Estimate the probability of each risk occurring and the impact of each risk if it does occur (see Guideline for how).
3.2.2.3. Calculate the exposure value for each risk (Risk Exposure = Probability x Impact).
3.2.2.4. exposure value of a risk is the expected value of the loss for the risk
3.2.2.5. Prioritize risks basing on their exposure value
3.2.2.6. Define Risk Exposure threshold to determine which risks (the top few) need mitigation and contingency plans.
3.2.3. Do
3.2.3.1. Create risk mitigation and/or contingency plans for each risk need to be handled. Update Project WBS and Project Schedule accordingly.
3.2.3.2. Define risk triggers
3.2.3.3. Assign owners who will automatically begin executing the risk contingency plan if risk is triggered.
3.3. Risk Monitoring
3.3.1. Activities
3.3.1.1. Recognize new or suspected risks in project
3.3.1.2. Record in Project Risk List, and analyze the risks
3.3.1.3. Define action for risk mitigation and contingency, as appropriate
3.3.1.4. Assign resource to implement the actions and ensure they have sufficient time and resource to complete them
3.3.1.5. Monitor trigger for any contingency plans
3.3.1.6. Initiate contingency plan if triggers are met.
3.3.1.7. Report status on risk status and associated response actions to relevant people
3.3.2. Work products
3.3.2.1. Mitigation and contingency plans for risks
3.3.2.2. Updated Project Risk List with identified risks, risk owners, mitigation plans, and contingency plans
3.3.2.3. Risk information for status reports
3.4. Case Study
3.5. Common Risks
3.5.1. Some apps can not finished because Device not available
3.5.2. Many new members, few time for training, could not keep the productivity
3.5.3. Customer could not keep the plan of UAT
3.5.4. Running Visual studio for load testing has some error in the code Forum’s DLL sent from customer.
3.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)
3.5.6. There are some change requests from customer so the final release is delayed
3.5.7. The initial version of STS is still the draft version, CRs are expected.
3.5.8. Customer evaluates test environment setting for Phone is difficult -> consider risk test environment
3.5.9. Team spirit is down and many resources are out of project. Inexperience team, lack of resource, not stable.
3.5.10. New PM, no experience in project management
4. Project Planning
4.1. Project Opening
4.1.1. Initial Project Plan
4.1.1.1. Initialing process group
4.2. Project Planning
4.2.1. Overview
4.2.1.1. Planning Process Group
4.2.2. Steps of project planning
4.3. Project monitoring
4.3.1. Monitoring process group
4.3.1.1. Requirement Management
4.3.1.1.1. Activities:
4.3.1.1.2. Output:
4.3.1.2. Human Resource Management
4.3.1.2.1. Activities:
4.3.1.2.2. Output:
4.3.1.3. Risk Management
4.3.1.3.1. Activities:
4.3.1.3.2. Output:
4.3.1.4. Cost Management
4.3.1.4.1. Activities:
4.3.1.4.2. Output:
4.3.1.5. Payment Management
4.3.1.5.1. Activities: Manage Project Payment
4.3.1.5.2. Output:
4.3.1.6. Process Management
4.3.1.6.1. Activities:
4.3.1.6.2. Output:
4.3.1.7. Stakeholder Management
4.3.1.7.1. Activities: Manage relevant stakeholders
4.3.1.7.2. Output:
4.3.1.8. Schedule Management
4.3.1.8.1. Check and update status in project schedule
4.3.1.8.2. Evaluate deviation and analyze, find, understand cause
4.3.1.8.3. Output : updated project schedule
4.3.1.9. Task Management
4.3.1.9.1. Output
4.3.1.9.2. Activities
4.3.1.10. Quality Management
4.3.1.10.1. Output:
4.3.1.10.2. Activities:
4.3.1.11. Payment Management
4.3.1.11.1. Billing schedule must be conformed to payment deadline: put into project plan.
4.3.1.11.2. Payment Criteria should be addressed clearly
4.3.1.11.3. Being fully paid is a project’s objectives
4.3.1.11.4. All payment criteria are achieved before payment deadline
4.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.
4.4. Project closing
4.4.1. Closing Process Group
4.4.1.1. Activities:
4.4.1.1.1. Initiate Project Termination
4.4.1.1.2. Obtain Customer Acceptance
4.4.1.1.3. Issue Final Invoice
4.4.1.1.4. Finalize Project Information
4.4.1.1.5. Analyze Project Performance
4.4.1.1.6. Capture Practices/Lessons Learned
4.4.1.1.7. Complete Post-mortem Report
4.4.1.1.8. Conduct Post-Mortem Meeting
4.4.1.1.9. Distribute Post-Mortem Report
4.4.1.1.10. Evaluate Team Performance
4.4.1.1.11. Hand-Over Project Assets
4.4.1.1.12. Complete Internal Acceptance Note
4.4.1.2. Output:
4.4.1.2.1. Post-Mortem Report; Post-Mortem Meeting Minutes
4.4.1.2.2. Project Final Status Report
4.4.1.2.3. Completed Project Acceptance Letter.
4.4.1.2.4. CSS; Invoices
4.4.1.2.5. Project Data
4.4.1.2.6. Written feedback to Project Team member
4.4.1.2.7. Project Asset is archived in Wrap-up Baseline and handed-over to SC QA. Accounting
4.4.1.2.8. Document confirming that no customer-owned IP has been retained
4.5. Case studies
4.5.1. Possible solutions to common issues
4.5.1.1. Training people if they lacks skills
4.5.1.2. Review the priority of tasks and do not accept new tasks if behind schedule
4.5.1.3. Regularly monitoring cost to avoid over-run effort
4.5.1.4. Strictly follow Requirement Change Management workflow since scope keeps changing, many requirements arise.
4.5.1.5. Review Payment schedule & Payment criteria in the Contract/External Work Order
4.5.1.6. Prepare Acceptance Letter and send to customer to obtain customer approval when payment criteria are achieved and payment schedule is reached
4.5.1.7. Issue Invoice and rectify any problem encountered, work with PMs, AF and customer to resolve the problems.
4.5.1.8. Control payment progress until the invoices are fully paid.
5. Time Management
5.1. Definition
5.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
5.1.2. Failing to manage your time
5.1.2.1. Missed deadlines.
5.1.2.2. Inefficient work flow.
5.1.2.3. Poor work quality.
5.1.2.4. A poor professional reputation and a stalled career.
5.1.2.5. Higher stress levels.
5.1.3. What
5.1.3.1. Greater productivity and efficiency.
5.1.3.2. A better professional reputation.
5.1.3.3. Less stress.
5.1.3.4. Increased opportunities for advancement.
5.1.3.5. Greater opportunities to achieve important life and career goals.
5.2. How
5.2.1. Goal Setting
5.2.1.1. How
5.2.1.1.1. SMART
5.2.1.2. Why
5.2.1.2.1. long-term vision and short-term motivation
5.2.1.2.2. measure and take pride in the achievement
5.2.1.2.3. see forward progress
5.2.1.2.4. raise your self-confidence
5.2.1.3. Key Points
5.2.1.3.1. Deciding what you want to achieve in your life.
5.2.1.3.2. Separating what's important from what's irrelevant, or a distraction.
5.2.1.3.3. Motivating yourself.
5.2.1.3.4. Building your self-confidence, based on successful achievement of goals.
5.2.1.4. Achieving Goals
5.2.1.4.1. If you achieved the goal too easily, make your next goal harder.
5.2.1.4.2. If the goal took a dispiriting length of time to achieve, make the next goal a little easier.
5.2.1.4.3. If you learned something that would lead you to change other goals, do so.
5.2.1.4.4. If you noticed a deficit in your skills despite achieving the goal, decide whether to set goals to fix this.
5.2.2. Prioritization
5.2.2.1. What
5.2.2.1.1. what needs to be done is especially important
5.2.2.2. how
5.2.2.2.1. To-Do List
5.2.3. Managing Interruptions
5.2.3.1. what
5.2.3.1.1. phone calls, information requests, questions from employees, and a whole host of events that crop up unexpectedly
5.2.3.2. How
5.2.3.2.1. Keep An Interrupters Log
5.2.3.2.2. Analyze and Conquer Interruptions
5.2.3.2.3. Put Your Phone to Work for You (Not Against You)
5.2.3.2.4. Catch Your Breath
5.2.3.2.5. Learn to Say "No"
5.2.3.2.6. "Available" and "Unavailable" Time
5.2.4. Procrastination
5.2.4.1. What
5.2.4.1.1. In a nutshell, you procrastinate when you put off things that you should be focusing on right now
5.2.4.1.2. procrastination occurs when there’s “a temporal gap between intended behavior and enacted behavior.
5.2.4.2. How
5.2.4.2.1. Recognize That You're Procrastinating
5.2.4.2.2. Work Out WHY You're Procrastinating
5.2.4.2.3. Adopt Anti-Procrastination Strategies
5.2.4.2.4. Key Points
5.2.5. Scheduling
5.2.5.1. Importance
5.2.5.1.1. Understand what you can realistically achieve with your time.
5.2.5.1.2. Make sure you have enough time for essential tasks.
5.2.5.1.3. Add contingency time for "the unexpected."
5.2.5.1.4. Avoid taking on more than you can handle.
5.2.5.1.5. Work steadily toward your personal and career goals.
5.2.5.1.6. Have enough time for family and friends, exercise and hobbies.
5.2.5.1.7. Achieve a good work-life balance.
5.2.5.2. How
5.2.5.2.1. Identify Available Time
5.2.5.2.2. Schedule Essential Actions
5.2.5.2.3. Schedule High-Priority Activities
5.2.5.2.4. Schedule Contingency Time
5.2.5.2.5. Schedule Discretionary Time
5.2.5.2.6. Analyze Your Activities
5.2.5.2.7. Key Points
6. HR Management
6.1. Human Resource Planning
6.1.1. determines project roles, responsibilities and reporting relationships
6.1.1.1. PM’s Responsibilities:
6.1.1.1.1. Overall responsibility for the project
6.1.1.1.2. management process
6.1.1.1.3. Manage expectation of project organization
6.1.1.1.4. Develops all deliverables
6.1.1.1.5. Keeping track of schedules and time management
6.1.1.1.6. Executes quality reviews (formal and management)
6.1.1.1.7. Update project data/records following procedures
6.1.1.1.8. Administers change requests and issues
6.1.1.1.9. Keep Project Sponsor and team informed of progress, issues and concerns
6.1.1.2. Team’s Responsibilities
6.1.1.2.1. Contribute to the project management plan (Define and estimate time of task).
6.1.1.2.2. And accomplish work defined in the project scope statement (WO).
6.1.1.2.3. Attend project team meetings
6.1.1.2.4. Process improvement
6.1.1.2.5. Comply with quality and communications plans
6.1.1.2.6. Define the products of project
6.1.1.2.7. Identify and analyze constraints, assumptions, risks
6.1.1.2.8. Define detailed requirements
6.1.1.2.9. Create WBS
6.1.1.2.10. Identify dependencies, provide time and cost estimates
6.1.1.2.11. Log data: timesheet, defects to Fsoft tools
6.1.1.2.12. Produce project performance reports
6.1.1.2.13. Measure project performance
6.1.1.2.14. Close out phases of the project
6.1.2. Main Outputs
6.1.2.1. Roles and Responsibilities (Responsibilities Assignment Matrix)
6.1.2.2. Project Organization Charts
6.1.2.3. Staffing Management Plan
6.1.2.3.1. Describe when and how human resource requirements will be added and released from the project.
6.1.2.4. Resource Histogram
6.2. Human Resource Monitoring
6.2.1. Activities
6.2.1.1. Manage Project Resources
6.2.1.1.1. Main Activities:
6.2.1.1.2. Main outputs:
6.2.1.2. Assess and Refine Project Organization Structure
6.2.1.3. Assess and Refine Team Skill
6.2.1.3.1. Main Activities
6.2.1.3.2. Main outputs:
6.2.1.3.3. Ensure team skills meet competencies
6.2.2. outputs
6.2.2.1. Project Organization
6.2.2.2. Teams: Development team, Test team, Comtor,…
6.2.2.3. Project Organization Structure
6.2.2.4. Team members with effort allocation
6.2.2.5. Effort budget for the project
6.3. Develop project team
6.3.1. “improves the competencies and interactions of team members to enhance project performance”
6.3.2. Improves skills of team members
6.3.3. Improves feeling of trust and cohesiveness
6.3.4. It is CRITICAL to the success of project
6.3.5. Should be conducted early and is an ongoing activity
6.3.6. KEY
6.3.6.1. Team building
6.3.6.1.1. Milestone parties
6.3.6.1.2. Holiday and birthday celebration
6.3.6.1.3. Outside of work trips
6.3.6.1.4. Creating the WBS
6.3.6.1.5. Planning the project by getting everyone involved.
6.3.6.2. Training: in order to perform project
6.3.6.3. or enhance team member performance.
6.3.6.4. Ground rules (establish clear expectations)
6.3.6.5. Co-location (war room)
6.3.6.6. Recognition and rewards (of desirable behavior)
6.3.6.6.1. Team performance Assessment
6.3.6.6.2. Public the rewards
6.4. Manage project team
6.4.1. PM should
6.4.1.1. Observe
6.4.1.2. Use Issue log
6.4.1.3. Keep in touch
6.4.1.4. Actively look for and help resolve conflicts that the team cannot resolve.
6.4.2. Leadership
6.4.2.1. Directing: Tell others what to do
6.4.2.2. Facilitating: Coordinating the input of others
6.4.2.3. Coaching: Instructing others
6.4.2.4. Supporting: Providing assistance along the way
6.4.2.5. Autocratic: Making decisions without input.
6.4.2.6. Consultative: Inviting ideas from others:
6.4.2.7. Consensus: group problem solving.
6.5. Conflict and Resolve Techniques
6.5.1. Conflict from
6.5.1.1. a disagreement between people on substantive
6.5.1.1.1. Goals
6.5.1.1.2. Rewards
6.5.1.1.3. Procedures
6.5.1.1.4. Resources
6.5.1.1.5. Policies
6.5.1.1.6. Job Assignments
6.5.1.2. emotional issues.
6.5.1.2.1. Feelings of anger, distrust, dislike, fear and resentment
6.5.1.2.2. Personality clashes
6.5.2. Resolve
6.5.2.1. 1. Schedules
6.5.2.2. 2. Project priorities
6.5.2.3. 3. Resources
6.5.2.4. 4. Technical opinions
6.5.2.5. 5. Administrative procedures
6.5.2.6. 6. Cost
6.5.2.7. 7. Personality
7. Quantitative Management
7.1. Purpose
7.1.1. Quantitatively manage the project’s defined process to achieve the project’s establish quality and process performance objectives
7.2. Software Metrics
7.2.1. What
7.2.1.1. It is a measure of quantity of something. Usually a number
7.2.1.2. For example: the water level of Red River
7.2.2. Why
7.2.2.1. Quicker transfer/communication
7.2.2.2. Automation/alerts
7.2.2.3. Filtering (who needs to know what)
7.2.2.4. Consolidate & predict the future (statistical analysis, PCB)
7.2.3. Requirement Metrics:
7.2.3.1. Requirement Completeness (%): Measures percentage of requirement completed against the committed and predict the amount of remain work
7.2.3.1.1. = ∑(Requirement Size x Requirement Completed Rate)*100/Total Committed Requirement Size
7.2.3.2. Requirement Stability (%): Measures stability of requirements, frequency of requirements changed by customer
7.2.3.2.1. = (Total size of change requests / Total size of requirements)*100
7.2.4. Quality Metrics
7.2.4.1. Defect Rate (wdef/size): Measures quality of overall project's products.
7.2.4.1.1. = Total No of weighted Defects of a product/Product Size
7.2.4.2. Product Size could be = Effort usage/KLOC/UCP/FP/Module
7.2.4.3. Defect Removal Efficiency (%):Provides the efficiency of review / test processes
7.2.4.3.1. = (Total No of Project Defect - No of defects detected by Role = Customer)/ Total project defects * 100%
7.2.4.4. Leakage (wdef/size): Measure quality of the product and service after delivery for acceptance test.
7.2.4.4.1. = No of Wdef Defects detected after delivery for acceptance test of a product/Product size
7.2.4.5. Customer Satisfaction (Point): Measures the satisfaction of customer requirements
7.2.5. Cost Metrics:
7.2.5.1. Effort Efficiency (%): Measure efficiency of project effort usage
7.2.5.1.1. = (Billable Effort/ Calendar Effort)*100 (1MM=21Pds)
7.2.5.2. Effort Effectiveness (%): Provides tracking of budgeted effort against actual effort and predict future effort
7.2.5.2.1. = (Last Committed Effort Usage/Actual Effort Usage)*100
7.2.5.3. Quality Cost (%): Provides the cost that project pays for quality and efficiency of quality activities in project
7.2.5.3.1. = Effort spent for quality activities x 100/ total project effort
7.2.5.4. Correction Cost (%): Indicates cost of correcting a defective product and the associated rework/damage costs
7.2.5.4.1. = Effort spent for fixing error x 100/ total project effort
7.2.5.5. Project Management (%)= Effort spent for project management x 100/ total project effort
7.2.6. Productivity Metrics:
7.2.6.1. Productivity (Size/pd) : Provides the measurement about general productivity in project = Product size/Total effort
7.2.6.2. Coding Productivity= Product size / Coding Effort
7.2.6.2.1. Size:
7.2.6.2.2. About LOC , we can use Blue Step Counter and Kazoe-Ciao tool to count actual LOC.
7.2.7. Schedule Metrics:
7.2.7.1. Timeliness (%): Measures the ability to satisfy customer in timeliness.
7.2.7.1.1. = (No of deliverable delivered on time/ Total # of deliverables delivered)*100
7.2.7.2. Schedule Deviation (%): Provides information on project performance with respect to its schedule commitment
7.2.7.2.1. = ((Actual duration- Last committed duration)/ Last committed duration)*100
7.2.8. Process Compliance:
7.2.8.1. Process Compliance (%): Measure the compliance of project activities as with the defined rule/standard/process/regulation
7.2.8.1.1. = SUMPRODUCT(checked items, assessment results)/SUM(checked items). Note: only include checked items with assessment results = 0, 50, 100.
8. Scope Management
8.1. Project scope: is the work to be done to deliver a product, service with specified features and functions.
8.2. Project scope management: the processes to ensure that all required work of project complete successfully.
8.3. Project scope management processes: processes to define/document, manage, verify and control what is or is not included in a project
8.3.1. diagram
8.3.1.1. Collect requirement: define and document stakeholders’ needs to meet the project objectives.
8.3.1.1.1. Project charter
8.3.1.1.2. Stakeholder register
8.3.1.1.3. Indentifying external interfaces
8.3.1.1.4. Analyzing high level requirements
8.3.1.1.5. Studying and Questionnaires
8.3.1.1.6. Meeting with customer for clarifying
8.3.1.1.7. Brainstorming and lateral thinking to decide technical solution
8.3.1.1.8. Prototypes
8.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).
8.3.1.2.1. Project charter
8.3.1.2.2. Requirements documentation
8.3.1.2.3. Organization process assets
8.3.1.2.4. Decomposition in WBS
8.3.1.2.5. Others
8.3.1.2.6. Work breakdown structure (WBS)
8.3.1.3. Verify scope: formalize acceptance of completed project deliverables.
8.3.1.3.1. Input
8.3.1.3.2. Technique
8.3.1.3.3. Output
8.3.1.4. Control scope: monitor status of project scope and manage the changes to scope baseline.
8.3.1.4.1. Input
8.3.1.4.2. Technique
8.3.1.4.3. Output
9. Configuration Management
9.1. CM Facts
9.1.1. Use not latest revision
9.1.2. not comment when commit svn, overwrite others' file
9.1.3. wrong environment
9.2. CM Activities
9.2.1. Configuration Identification
9.2.1.1. work products
9.2.1.1.1. Requirement – URS, SRS
9.2.1.1.2. Design – ADD, DD
9.2.1.1.3. Coding – Software module, Software package
9.2.1.1.4. Test – TP, TC, TR
9.2.1.2. plan documents
9.2.1.2.1. CM plan
9.2.2. Configuration Control
9.2.2.1. Purpose
9.2.2.1.1. Ensure all the changes to the work product are in controlled
9.2.2.2. How
9.2.2.2.1. Need tools to control the changes by following the defined process
9.2.2.2.2. Change request form are introduced and must be filled before
9.2.2.2.3. All the changes must be reviewed
9.2.2.2.4. Manage version
9.2.2.2.5. Permission control
9.2.2.3. Change Request Form
9.2.2.3.1. What
9.2.2.3.2. Why
9.2.2.3.3. When
9.2.2.3.4. How
9.2.2.4. Release management
9.2.2.4.1. Category of CI to release
9.2.2.4.2. Build Release checklist
9.2.2.4.3. Build Release workflow
9.2.3. Configuration Status
9.2.3.1. CM Report
9.2.3.1.1. Purposes
9.2.3.1.2. Types
9.2.3.1.3. Contents
9.2.4. Configuration Audit
9.2.4.1. Purposes
9.2.4.1.1. Track status of changes to CIs in Change Control Report
9.2.4.1.2. Ensure that CM plan is implemented correctly
9.2.4.1.3. Provide CM accounting status
9.2.4.2. How to audit?
9.2.4.2.1. Process Compliance Verification
9.2.4.2.2. Internal Audit (CM)
9.2.4.3. Output
9.2.4.3.1. Process Compliance Verification checklist
9.2.4.3.2. Internal Audit checklist
9.2.4.4. who
9.2.4.4.1. QA
9.2.4.4.2. configuration manager
10. Project Estimation
10.1. WHY
10.1.1. One of the most challenging and important activities in project management
10.1.2. 70-80% of failed projects are due to bad estimation.
10.1.3. Under-estimating a project leads to staff burnout, low quality, missing deadline.
10.1.4. Over-estimating a project leads to resource usage inefficiency, lost opportunities.
10.2. Estimate process
10.2.1. Estimate Size
10.2.1.1. A predominant factor
10.2.1.1.1. in determining how much effort is needed
10.2.1.1.2. used for initial estimation
10.2.1.2. Functional requirements must be defined before using methods
10.2.1.2.1. Work Breakdown Structure (WBS) - popular estimation method
10.2.1.2.2. Line of Code (LOC) - done by experienced people and historical data, no guideline
10.2.1.2.3. Function Points (FPs)
10.2.1.2.4. Use-case Points
10.2.1.3. Verify estimation result using 2 or more than 2 methods
10.2.1.3.1. By Analogy
10.2.1.3.2. By Analysis
10.2.1.4. PM develop own method if standard method not suitable
10.2.1.4.1. Break product down into smaller parts (features, use cases, user stories, etc)
10.2.1.4.2. FP, UCP are suitable
10.2.2. Estimate Effort
10.2.2.1. Top-down approach:
10.2.2.1.1. Use size estimate with historical data of productivity in PCB to derive total estimated project effort
10.2.2.1.2. Convert size to effort by regression analysis of the past data
10.2.2.1.3. Determine effort of various by percentage of the total effort
10.2.2.2. Bottom-up approach:
10.2.2.2.1. easier to prepare in some situations instead of explicit size estimate
10.2.2.2.2. Risk: some important activities may be omitted
10.2.2.2.3. Estimate first for each part of the project then estimate all project, using activity-based or function-based WBS
10.2.2.2.4. Advantage: requires a list of project tasks
10.2.3. Estimate Schedule
10.2.3.1. Determine the project schedule from the effort estimate.
10.2.3.2. Various schedules are possible depending on the number of people needed for the project
10.2.3.3. Remember that effort and months are not fully interchangeable in a software project.
10.2.3.3.1. Refer to Holiday calendar
10.2.3.4. Estimate the project duration in calendar months.
10.2.3.5. Determine starting points, duration and ending point of the project.
10.2.3.6. Tools/Techniques for scheduling: Network Diagram, Grant Chart, Critical Path
10.2.3.6.1. Investigate these techniques in section Time Management
10.2.4. Estimate Human Resource
10.2.4.1. Determine the skills required to accomplish the activities
10.2.4.1.1. Using skill sheet
10.2.4.2. Check for the availability of team members for skills
10.2.4.2.1. Manager need to commit availability
10.2.4.2.2. Functional manager assesses skill set and required effort
10.2.4.3. Estimate overall cost according to the cost that manager of these people inform
10.2.5. Estimate Infrastructure Resource
10.2.5.1. Some methods: historical experience, simulations, prototyping, and analysis
10.2.5.2. Includes: Computer memory capacity, Computer processor use, Communications channel capacity
10.2.5.3. Steps for estimating resources
10.2.5.3.1. PM identifies resources for the project
10.2.5.3.2. PM estimates resources in consistence with the estimates of:
10.2.5.4. Steps for managing resources
10.2.5.4.1. Estimates for the project's infrastructure resources
10.2.5.4.2. Planned computer resources, the system requirements allocated to software
10.2.5.4.3. Available computer resources are allocated to the software components
10.2.5.4.4. Available capacity for the infrastructure resources provides for a specified reserve capacity when the initial estimates are made.
10.2.5.5. Estimating new development projects: use UCP, FP, WBS, LOC.
10.2.6. Verify Estimation
10.2.6.1. Verify quality of the estimation and to get it approved
10.2.6.2. Confirm the software architecture and functional WBS
10.2.6.3. Verify the methods used for deriving the size, schedule and cost estimates
10.2.6.4. Ensure that the assumptions and input data used to develop the estimates are correct
10.2.6.5. Ensure that the estimate is reasonable and accurate given the input data
10.2.6.6. Formally confirm and record the official estimates for the project.
10.2.7. Track and Record Estimates
10.2.7.1. Tracked overtime
10.2.7.2. Re-estimate weekly, at milestones or when the level of uncertainty or project scope is changed.
10.2.7.3. All estimation data, both planned and actual, need to be recorded in the Software Process Database.
10.2.7.4. Historical data is used for estimating for future projects
10.3. Different Kind of Projects
10.3.1. Estimating maintenance & enhancement projects:
10.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.
10.3.2. Estimating “new domain” projects:
10.3.2.1. always high risks and under-estimated.
10.3.2.2. make the risks very clear to stakeholders,
10.3.2.3. avoid making commitment to fixed deadlines,
10.3.2.4. suggest POC or prototype, re-estimate when familiar with the domain.
10.3.3. Estimating agile projects:
10.3.3.1. estimate relative size of the backlog items in Story Points
10.3.3.2. Calculate & use team velocity to estimate effort and schedule for each iteration.
10.4. Estimating Tips
10.4.1. If we lengthen the schedule, we can generally reduce the overall cost and use fewer people.
10.4.2. Allow enough time to do a proper project estimate.
10.4.3. Use historical data from our own similar projects in the past where possible.
10.4.4. Use Developer-based estimates.
10.4.5. Use At least one software estimation tool.
10.4.6. Use several different people to estimates and use several estimation techniques to compare the results.
10.4.7. Re-estimate the project several times throughout its life cycle.
10.4.8. Spend some effort on improving your estimation skills by comparing actual to estimate when project is completed.
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.