Transcript Patterns And Anti-Patterns Of Project Success Haroon Taqi

Patterns And Anti-Patterns Of
Project Success
Haroon Taqi
The Challenge of Software
Development

Start with a fuzzy picture





We do not always understand well what the
customer wants
Customers do not always know what they want
Requirements shift over time
IT is perceived to be slow to deliver value
and does so at a high cost
How do we deliver value given the “fuzzy”
situation and changing requirements?
The Constraint




IT budgets are tighter than they
used to be
Requests for IT support are not
lower but higher
Expectation remains that projects
be on-time, on-budget and satisfy
customer needs
How do we deliver value while
operating on a lean budget?
Questions

How do we succeed in such an
environment?




What are the factors that influence
project success?
What are the obstacles that we have to
overcome to succeed?
What factors improve software
development productivity?
How do achieve efficiency without
compromising quality?
Project Success Factors

Observation: Project success rate increased
100% in last 10 years [Standish Group, 2004]


Primary factor: use of iterative processing over
waterfall method
My Experience

Pattern: Regular cycle of delivery of working
software to the customer (or proxy-customer)




Major releases every 2-4 months
Anti-pattern: No delivery to customer for 6+
months
Anti-Pattern: Requirements, planning, design,
testing etc. seen as sequential phases instead of
activities carried out at various times
Recommendation:


Break up large projects into smaller subprojects
Before launching a major project, do a small pilot
project that validates the assumptions
Top 5 Project Success Factors
(Standish Group)





User Involvement
Executive Management Support
Experienced Project Managers
Clear Business Objectives
Reduced Scope
The Standish Group, CHAOS Report, 2003
Project / Process Anti-Patterns That
Reduce Efficiency


Confusion, chaos, and constant
firefighting
Rigid plans and schedule





Problem of uncertainty in new product
development
 In a specification with only 2 degrees of
freedom, uncertainty rises with square of time
Average requirements change ≈25% per
project
Handed-down plans
Micro-management / no management
Questions: What role should management
play to be effective? What is the
appropriate level of planning?
IT Management Role
Develop Objectives
Yes
Yes
Micromanagement
Unbearable
No
Self-Managed,
Goal-Driven
teams
Anarchy and
confusion
Specify
Means
•
•
•
•
No
Focus team on objectives and protect it from distractions
Provide support via resources, training, and mentoring
Trust team to deliver and track progress via tangible milestones
What level of planning needed?
Adapted from Harvard Business Essentials, “Managing Projects Large and Small”,
Project Planning
Objectives
Clearly
Defined
Not
Clear
Clearly
Defined
Plan-driven
N/A
Not
Clear
Adaptive / Agile
Planning
Agile Planning
Means
• Balance adaptive and plan-driven methods based on the situation
• Focus more on steering and adapting, less on keeping the
scheduling system updated
• Question: How do we balance adaptive and predictive planning?
Multiple Levels of Planning
Time
L1: Master
Plan
R1
R2
BR1
BR2
BR3
Release 1
I1
I2
M2
F1, F2,… Fn
L4: Task list with option to
signup for tasks (estimates
in hours)
R4
BR1
BR2
BR3
In
……
M1
Increasing
level of
detail
R3
…
Mn
L2: Release plan comprising
features, estimates (2-15 days)
and some milestones to track
progress
L3 Iteration plan with features
based on client priorities and features
risks
T1, T2, T3,….Tn
BR1
BR2
Planning

Master Plan acts as a roadmap



Major release every quarter
Define resource shifts, training needs, purchase
requirements, identify project risks, technology
choices
Release Plan

Intermediate milestones to determine progress




Milestones may change based on changes coming from
iteration results / shifting priorities
Use delivery of working code as tangible milestones
Can include planning for deployment, beta testing
etc.
Iteration and Task Planning


2 week iterations preferred
Team members sign up for tasks
Who Participates In Planning

Master Planning


Sponsor, senior IT management, user
representative(s), Project Manager, some team
input for estimation
Release Planning

User representative(s), Project Manager and team


Iteration Planning


sponsor and senior IT management informed of
planning output but generally do not participate
User representative(s), Project Manager and team
Task Planning

Project Manager and team
Common Questions

What if Release 3 requires features that
are too big to develop in one release
cycle?


Break up features into sub-features that are
delivered across multiple releases
What if Release 4 requires a feature that
is absolutely business critical?

Not a problem since we are using priority and
risk based scheduling
 Business critical functionality can be started as
part of an earlier release cycle
 Work with user representative(s) to define
priorities, as indicated earlier
Benefits



Keeps focus on the most important priorities
Team gets into the rhythm of regular delivery
early in the project
Time to planning horizon is short


Allows us to adapt to things that are beyond our
control





Estimates are more accurate
Does not create unnecessary baggage that limits
our agility
Easier to estimate project velocity and forecast
completion date
Regular feedback from customer
Application used in customer environment
“Plans are useless, planning is everything”
Other Anti-Patterns

No emphasis on quality / quality compromised in the
name of “efficiency”


“We don’t have time for quality / process”
Unrealistic / overly optimistic schedule


“We have to make the schedule or else….”
Some projects rely on mandatory overtime to succeed


Hacked solution / “Proto-duction” / Underengineering


“We need something right now!” all the time
Over-Engineering / Over-Design
Solution needed today compromised by potential
needs of tomorrow
 Usually an issue with good, advanced developers
Questions: What are the factors that influence
software development productivity? What is the
cost of quality?


Recipe for disaster as almost all projects require some extra
effort to succeed
Relative Impact on Productivity of
Positive Adjustment Factors
Reuse of high quality deliverables
350
High management experience
65
High staff experience
55
Effective methods / processes
35
Use of formal inspections
15
Low project complexity
13
Moderate schedule pressure
11
Annual training > 10 days
8
No geographic separation
8
High team morale
7
Jones, Capers. Software Assessments, Benchmarks, and Best Practices, Addison-Wesley, 2000
Relative Impact on Productivity of
Negative Adjustment Factors
Reuse of poor-quality deliverables
-300
Management inexperience
-90
Staff inexperience
-87
No use of inspections
-48
Ineffective methods / processes
-41
High project complexity
-35
Excessive schedule pressure
-30
Geographic separation
-24
No annual training
-12
Poor team morale
-6
Jones, Capers. Software Assessments, Benchmarks, and Best Practices, Addison-Wesley, 2000
The Cost Of Quality

Cost of Quality includes cost of:





Internal & External Product Failure
Quality appraisals
Defect prevention
Cost of rework accounts for 40-60% of
cost of quality (based on several studies
in different companies)
Cost of Poor Quality


Poor quality is one of the most common
reasons for schedule overruns
Poor quality implicated in half of all canceled
projects
How Do We Achieve Quality

Build quality into your daily
activities




High quality does not necessarily mean
tons of documentation
Focus on activities that add value
Emphasize Lean Thinking
Recommendations


Consider the use of Test-Driven
Development
Organizing effective Peer Reviews
Test Driven Development (TDD)

In my experience, Test-Driven Development
delivered the best quality code on-time and onbudget



Convert use-cases / user-stories into acceptance
tests
Write automated unit-test before you write code
Refactor to improve your design (constant design
improvement)





Tests act as safety net during refactoring
Prevents design from degrading over time
Testing each unit of code independently (method /
class / component ) forces decoupling of each unit
Writing unit-test code first forces developers to
write less application code (prevents developer
gold-plating)
TDD is not a substitute for using the best people
Peer Reviews & Inspections

Published data from major companies
regarding Inspections




HP: Measured ROI of 10 to 1
AT&T Bell Labs: Reduced cost of finding
errors by a factor of 10
IBM: Each hour of inspection saved 10 hours
of testing and 82 hours of rework
My experience

Code reviews (if conducted at all) were mostly
 Ineffective as they were seen as a formality
 Found little more than styling problems
 Conducted too late in the development cycle
Effective Code Reviews And PairProgramming

How do we make code reviews
effective?


Should be conducted frequently and
regularly from Day One
Focus on defect detection and
prevention, removing code opacity, and
less on styling issues
Use checklist of commonly found
problems
 Use tools for generating code metrics


Long methods, too many local variables,
cyclomatic complexity, efferent / afferent
coupling etc.
Pair-Programming (PP)


Two developers, one workstation
Improved code ownership and team
communication





Very positive developer feedback
Facilitates defect prevention and reduced code
opacity
Initial studies indicate PP appears to add about
10-15% effort to project (and not double the
effort)
Impact to quality appears to be comparable to
using inspections
In my experience, PP with rotating pairs is the
best safeguard against programmer turnover
Threats To Good Quality: Excessive
Schedule Pressure

Just because people are under pressure does not
mean that they think faster




Bottom-line: We should limit the amount of
overtime needed on a project



Up to 4 times the number of normal defects
reported in products developed under excessive
schedule pressure
Most significant cause of creation of extremely
costly error-prone modules
40% of defects found to be caused by high stress
Try alternative means (scope reduction, risk
management, improved planning) before creating
unnecessary schedule pressure
Give people time off to compensate for high-stress
periods
Develop better estimates to avoid creating such a
problem in first place
Beating Schedule Pressure: Problem
With Original Project Estimates
• Estimates are approximate at best and error in estimation
increases with time
• Recommend using PERT estimates during estimation
• Estimated duration = ( O + 4 * E + P ) / 6
• The following are general rules of thumb in estimation
Milestone (Waterfall)
Effort & Size
Schedule
Optimistic
Pessimistic
Optimistic
Pessimistic
0.25
4.0
0.60
1.6
Approved Product Concept
0.5
2.0
0.8
1.25
Requirements Specification
0.67
1.5
0.85
1.15
Product Design Specification
0.80
1.25
0.90
1.10
Detailed Design Specification
0.90
1.10
0.95
1.05
Initial Product Concept
Estimation Problem Continued
PROBABILITY OF
COMPLETION
Most Likely
Typical
developer
schedule
tends to be
optimistic
Using I&I:
• High-priority & risky items
targeted early
• Generate real data for
determining project velocity
early
V0.6
Optimistic
Impossible
schedule
PERT Weighted
Average
V0.7
V0.8
V0.9
TIME
V1.0
Pessimistic
Length of graph reflects amount of noise on project
Dealing With Unrealistic Users /
Managers



Ideally, we should deliver what we promise
Initial estimates are problematic if seen as
promises
So we try to under-promise & over-deliver


Under-promising can be seen as lack of
commitment
So what do we do when we have to accept an
unrealistic schedule?





Build credibility and relationship with users by
delivering value to them early and regularly by
adopting I&I
Understand and respect users and management
needs
Educate users and managers about good practices
and project risks
Engage in brainstorming sessions focusing on
mutual gain instead of simply pushing back
Easier to ask for forgiveness under those
circumstances
Risk Management

A risk is an uncertain event that could, if
it occurs, positively or negatively impact
the project


Forms of risk management


A problem that has already occurred is not a
risk
Identify risk, estimate risk exposure, and
develop risk response plan
 Mitigation
 Containment
 Avoidance
 Transference
 Acceptance
Develop Risk Ranking for a project
Simple Risk Ranking For A Project
Low
Medium
High
Simple Customer
Small Size
Known Technology
A
Complex Customer
Small Size
Known Technology
D
Complex Customer
Small Size
New Technology
G
Simple Customer
Small Size
New Technology
B
Simple Customer
Large Size
Known Technology
E
Complex Customer
Large Size
Known Technology
H
Simple Customer
Large Size
Known Technology
C
Simple Customer
Large Size
New Technology
F
Complex Customer
Large Size
New Technology
I
• A = Lowest Risk, H = Highest Risk
• Assign experienced staff to high-risk, high-value projects
• Create Risk Reserve for High-Risk Projects
Risk Response Planning
Risk Description
New Technology
needed for key
feature does not
work
Delayed delivery of
3rd party solution
Poor performance of
key feature impacts
customer
acceptance
Likelihood
0.2
0.4
0.6
Impact
6
2
1
Exposure
=LxI
Response Plan
1.2
Prototype alternative
technology choices;
Develop backup
solution by Date X if
primary solution does
not work
0.8
Develop minimal
duplicate solution in
case of non-delivery
by date Y
0.6
Start on feature early
to allow for more time
in performance testing
Impact Of Risk On Major Project
Objectives
Project
Objective
Low
0.1
Moderate
0.2
High
0.4
Too High
0.8
Cost
<5% cost
increase
5-10% cost
increase
10-20% cost
increase
> 20% cost
increase
Schedule
<5%
schedule
slippage
5-10%
schedule
slippage
10-20%
schedule
slippage
> 20%
schedule
slippage
Scope
Minor areas
of scope
affected
Major areas of
scope affected
Scope reduction
unacceptable to
client
End Product
effective
useless
Quality
Only very
demanding
features
affected
Reduction
requires client
approval
Reduction
Unacceptable to
Client
End Product
effectively
useless
Customer
Satisfaction
Minimal
impact on
customer’s
perception
Customer
expectation
needs to be
managed
Breach of
customer trust
Lose customer
Adapted from PMBOK 2000
Recommendations

Simply identifying risks is not sufficient



Regularly perform reviews of current risks
and your response plans with your team
and management
Develop a risk database for your
environment


Also identify your risk response strategy
Can be a simple list of commonly occurring
risks on your projects
Communicate across projects to see how
other teams are dealing with similar
issues and risks
Summary





Invest in experienced staff (
Management, PM, Technical Staff)
Adopt I & I using a client-driven,
risk-driven approach
Consider the use of Test-Driven
Development
Institute effective peer reviews
Use common sense!
Questions
Please feel free to contact me at
[email protected] if you have any
questions
Appendix
More Details From Standish Group On
Project Success Factors
User Involvement


Skilled primary users key to success
A skilled primary user:



Has good, realistic expectations of project
(most important) and its result
Acts as evangelists for project
Has fair understanding of technology




Too little or too high understanding of
technology had negative effect
Has good understanding of project
management processes
Possesses solid understanding of business
operations
Is good at explaining business processes to IT
organization
The Standish Group, CHAOS Report, 2001
Project Sponsor (Executive
Management)


Skills of sponsor key to success
A sponsor should:







Personally accountable for success of project
Act as project champion
Possess fair understanding of technology
 Too little or too high understanding of
technology had negative effect
Possess a global view of project
Be responsive to needs of project
Have good understanding of expected project
results
Have good understanding of project
management processes
The Standish Group, CHAOS Report, 2001
Experienced Project Managers

Important skills in a Project
Manager:





Clear understanding of business
objectives
Good grasp of technology
Good organizational, communication
and decision making skills
Project management and process skills
Attention to details
The Standish Group, CHAOS Report, 2001
Recommendations



Institute project management training
program for project managers, key users,
sponsors and managers
Educate key users and sponsors about
expectations attached to their roles
Gradually ease project managers into
more difficult / risky projects, not based
merely on who is available