Week 5 Flashcards
Risk formal definition
Uncertain event which, if it occurs, can influence a project objective
Can map risks to a matrix of consequence vs likelihood
Common types of risk
Absenteeism
Time overruns
Unavailable skills
Incomplete project specifications
Mitigation strategies for risks
Accept Minimise Share Transfer Contingency reserves Insurance Workaround Mentoring
Project price components
Cost and profit
Costs (Direct, indirect and contingency)
Direct costs (Materials, labour, equipment)
Indirect costs (Project overhead, G&A overhead
Importance of contingency funding
Recognises future unknowns
Acts as a warning signal that your project is overrunning on its budget
Estimate duration of an activity with beta distribution
TE = (a+4m+b)/6
a = most optimistic time m = most likely time b = most pessimistic time
Estimate activity variance using beta distribution
S**2 = ((b-a)/6) **2
Critical path definition
The critical path is the longest path from end to end in a network diagram which determines the absolute shortest project length
Float values in each node are all 0 usually
Float definition
Difference between the earliest and latest start
Reducing the critical path
Eliminate tasks Parallelise tasks Overlap sequential tasks Shorten the duration on critical path tasks Shorten early/long/easy/cheap tasks
Milestones definition
Events that represent an accomplishment
Agile project management emphasis
Flexibility, evolving customer requirements
Plan the work then work the plan
Importance of evolving customer requirements leads to an incremental iterative planning process
Plan-execute-cycles
Scrum process regognizes: Once you plan a project, you will execute it to said specifications.
However, projects are prone to change
Rolling wave process of continuous “plan-execute-evaluate” cycles
Agile overview/terminology
Each cycle is a sprint, timebox is the length of a given sprint, timebox is agreed in a scrum meeting User stories (Explanation of what the system should do from the end-user perspective) Take user stories and turn them into a product backlog Visualize which user stories need to be completed in each sprint in a burndown chart Work backlog details any business/technical functionality you need to develop Scrum master is the person responsible for moving the project forward
Sprint stages
Sprint planning Daily scrums Development work Sprint review Sprint retrospective
Issues of agile development
Risk of scope creep
Increased cost (testing integrated into development)
Less ability to predict what the final product will resemble
Extra burden on product owners
Requirement of close collaboration between the scrum team and customers
Retrospectives
One of the 12 agile principles
Team steps back, examines the way they work, analyses it and identifies ways they can improve
Occurs at regular intervals
Team designs the changes as they’re best placed to do so
Necessary since learning from experience is not automatic
Never about blaming, naming or shaming
Retrospective benefits
Identify needs for improvements
Build motivation to change work dynamics
Build cross-team alliances
Offer closure (from bad experiences)
Who’s involved in a retrospective?
Must (Team and scrum master)
Good to have (External team members)
No way (Customer and management)
To facilitate retrospective (Professional, scrum master, any team member)
Retrospective questions
What went well?
What didn’t go well?
What are we puzzled about? (Clear up any confusion and recognise/document what the team learnt)
Retrospective times
Occur at the end of the project and after each sprint/milestone
Improvements can be input into the next sprint
Can also be reactive after a project surprise
Goals of retrospectives
Quantify effort expended on a project Ensure everyone knows the whole story Improve processes/procedures/culture Capture collective wisdom (temporary teams so collective wisdom outlives breakup of the team) Repair team damage Enjoy accomplishments
Retrospective structure
Set the stage -> Gather data -> Generate insights -> Decide on action -> Close retrospective
Generating insights
Interpreting causes, effects, strengths and weaknesses
Fishbone diagrams/pareto charts/et al.
Agile/Iron triangle differences
Cannot be both without careful recognition of the risks being taken
Agile methods rely on flexible and ill-defined objectives
Wreak havoc on the iron triangle
Agile accounts for the customer more continuously
Agile works better in low-risk environments where the process has been somewhat standardised
7 Cs for meeting customer expectations
Client Clarity Create Change Confirm Continue Close
Stakeholders in a project
Need to account for suppliers and competitor expectations
Customers are both highly attentive and powerful (Need to be actively cultivated)
Gadflies (High attention, low power)
Sleeping giants (Low attention, high power)
Managing customer expectations
Project risk mitigation Clarify design limits Agree feasible, realistic goals Scope within budget Corroborate the facts before starting
Collaborating with the customers
Helps you out of any problems you might get into during a project as opposed to rigidly focusing on the iron triangle
Establish the facts
Keep customer informed regarding developments such as cost/time/scope
Clearly communicate design limits
Train for safe, effective implementations
Make a feasible design acceptable
Risk throughout the life of a project
Period of highest risk impact throughout the final stage of the project
Opportunity and risk decrease through out project life
Amount at stake increases through out project life
Resource-limited schedule
Start and finish dates reflect expected resource availability
Project control cycle
Setting a goal -> Measuring progress -> Comparing actual with planned -> Taking action and recycling the process
Product owner in agile
Person representing the stakeholders and serving as the “voice of the customer”
Product backlog in agile
A prioritized list of everything that might be needed in a completed product and source of requirements for any changes
