I am Telecommunication engineer with HW/SW background and good administrative skill. Report Эта статья адресована тем, кто имеет отношение к разработке программного продукта. Понимание принципов управление процессом разработки не менее важно, чем фактические знания технологий программирования. Статья не адресована только тем, кто хочет стать или работает руководителем проекта (Project Manager), Понимание принципов управления принесет пользу на любой должности и в любой команде.

1. Project management development
Based on Risk analysis
Dov Nimratz 2016

2. 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

3. 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

4. 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.

5. 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.

6. 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

7. Input factors
• Project readiness in the customer's head
• Development team specification
• Project characteristics – time and size
• Required quality and reliability.
• Project domain.

8. Life cycle
Design
Detection
Analyze
PriorityPlanning
Reaction
Monitoring
Life cycle elements
Risk management involves
two groups of actions:
• Risk Assessment
• Risk Management
And point to rethink

9. 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

10. Analysis each risk from the list
• Assign 4 levels of
(probability of occurrence) / (severity of the harm) :
– History
– Poker
– Group
– “Devil’s advocate”

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. Project characteristicAgile 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

18. 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.

19. 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

20. 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

21. 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

22. Contacts:
Mail: dovnmr@gmail.com; dnimratz@intellias.com
Skype: dovnmr
Mobile: +308 91 333 33 00