dov nimratz, outsource people_2016_minsk
TRANSCRIPT
Project management development Based on Risk analysis
Dov Nimratz 2016
About me
• 30 years in R&D
• 17 years in Israel HighTech
• ECI, Telrad, RAD, Audiocodes companies
• HW, SW, Mechanical design engineer
• Project & Product Manager
• Business developer for EMEA & CIS countries
• 22 publications, US patent
• Counseling & SW development teaching
What do you customer wish?
• Get profit
• Not losing investments
• Before failure symptom appears
«Risk is the potential of gaining or losing something of value» - from Wiki
• Get best performance:
Maximum result for minimum investment in shortest time
• You as the trainer for football team
The 2015 CHAOS Report by the Standish Group
http://www.infoq.com/articles/standish-chaos-2015
The Modern Resolution (OnTime, OnBudget with a satisfactory result) of all software projects from 2011-2015 within the new CHAOS database.
Project management as a project
• SW project management based on Risk analysis is sequence of actions to proactively defining negative events and steps to minimize damage to the project
• Completely get rid of loss-related risk impossible
• But it is possible to identify the most critical and costly risks
• Be prepared for them to control their appearance.
Project domain comparison
Develop protocol according to standard
Develop graphical search engine for mobile app.
Fully described. Required exact implementation
Described briefly
Technical specification in low level
Business overview specification
Business stories only with task priority changes
Business stories with feature changes
Waterfall model Iterative model
Input factors
• Project readiness in the customer's head
• Development team specification
• Project characteristics – time and size
• Required quality and reliability.
• Project domain.
Life cycle
Design
Detection
Analyze
Priority Planning
Reaction
Monitoring Life cycle elements
Risk management involves two groups of actions: • Risk Assessment • Risk Management And point to rethink
Risk identification list
• Social and technological risks
• Risk List should include:
– The condition of the risk and its description
– Symptoms its early detection (if possible)
– What impact event risk (time, money, reputation)
– What happens if the risk becomes an event and we can not resist him
Analysis each risk from the list
• Assign 4 levels of
(probability of occurrence) / (severity of the harm) :
– History
– Poker
– Group
– “Devil’s advocate”
Risk prioritizing
Priority = Probability x Harm
Priority Description Symptom Probability Harm Previous lev Reaction
Risk planning
• Symptoms of the risk
Priority Description Symptom Probability Harm Previous lev Reaction
Defense reaction
Priority Description Symptom Probability Harm Previous lev Reaction
• Avoid or Protect
• Protection expediency:
The effectiveness of the protection =
(Cost of risk before protection - The cost of risk with the protection) / (protection cost)
The effectiveness of the protection ≤ 1
Monitoring
• Once a week or in the end of the sprint
• Change priority - shows critical point over or close in
• Constant exchange of information among team
members, management and the customer
Priority Description Symptom Probability Harm Previous lev Reaction
Waterfall vs Agile
Waterfall Agile
Customer may change development
Very little. Development based on HLD/LLD
Big, between iterations
Solution reliability High, in terms of specification
Low. Mostly idea realization
Resources Big team Small team
Time to market Slow Quick
Architecture accuracy
Sophisticated and analyzed
Sacrificed rapid solution
Percentage of juniors in the team
Can be big under experts supervision
Small - all team members depend on each other
Team qualification by Bam & Tender
Level Characteristic Suitable model
3 In an emergency situation, may revise the development method instructions
Both models. Unit head.
2 Can adapt the method to the situation. With some practice may go in level 3
Agile or Medium Waterfall. Team lead.
1A He has experience in several projects and is able to estimate the resources / small problems risk
Both model under Team Leader supervision
1B The programmer or tester with little experience
Not Recommended in Agile team.
-1 May have the technical knowledge, but bad in the team is working.
Can be used as FreeLancer or consultant, but not as a member of both models
Project characteristic Agile Waterfall
Domain
Target Fast result delivery . Not fully specified.
Architectural accuracy, performance, and reliability.
Size Small project and teams Big project and teams
Environment High variable Stable, Low variable
Management
Client relationship
Focus on customer satisfaction
Focus on the contract implementation
Planning and control
The team target it them self Meeting the requirements described in the plan
Result transfer
In person close communication
Defined by contract
Project characteristic Agile Waterfall
Technically
Requirements Prioritized and presented in the form of stories. They can easily be changed by the customer
Described in spec and rarely changed in accordance with the spec, manly clarification
Development Simple design, small development steps
Extensive design, a big change for the iteration step.
Tests Automatic with reuse and continues development
Documented, usually in the form of "black box” test
Staff
Customer access
Available easily and often Often not available, separated
Team At least 30% level 2 and 3. Almost no 1B
From 10% level 3 and up to 30% 1B
Internal team culture
The team is ready to take responsibility and enjoy the freedom
Freedom and responsibility are restricted by employment contract
Criteria Agile / Waterfall
Factor Agile Waterfall
Team Small team. Each one responsible for all. Personal trust and a collective motivation in the group.
Suitable for large group and project. Relationships are formalized by contract
Product Poor tested and not reliable. Do not documented and often misses the requirements. Effective with prototyping
Suitable for critical products. It is difficult to apply for prototyping
Volatility The simplicity of design and easy to implement. The risk of high costs when moving into a reliable release
Suitable for well-documented products, such as the implementation of the standards.
Team level
There must always be a critical mass of 2-3 level. Harmful use of 1B level
Level 2-3 critical mass required only at the design stage. Applicable staff level 1B
In team culture
High freedom within the group with a collective responsibility
Operating under an employment contract with a high employment security.
Polar diagram
Qualification 1B % / 2-3%
Velocity. Number of changes in
month
Team size Culture. Anarchist
number
Reliability
40 – 15
30 – 20
10 – 30
0 – 35
5 steps for Project management model design
Risk assessment for the Agile and Waterfall models
All risks identified?
Extern experts
Model identified?
Develop by Agile Develop by Waterfall
Pick out Agile parts
Develop iteration Deliver developed
part of product Risk monitoring
Update risk table
No
Yes
Not chosen
Agile Waterfall
Conclusions
• Project management is a project itself
• It needs to be developed
• Agile is good, but Waterfall is not dead
• Risk management is a key for success
• Continues monitoring and modification are required
