Patterns And Anti-Patterns Of Project Success

1
Patterns And Anti-Patterns Of Project Success

• Haroon Taqi

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

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

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

5
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

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

8
IT Management Role
Develop Objectives
Yes
No
Micro-management Unbearable
Self-Managed, Goal-Driven teams Anarchy and confusion
Yes
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,
9
Project Planning
Objectives
Clearly Defined
Not Clear
Plan-driven N/A
Adaptive / Agile Planning Agile Planning
Clearly Defined
Means
Not Clear

• 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?

10
Multiple Levels of Planning
Time
11
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

12
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
• sponsor and senior IT management informed of
  planning output but generally do not participate
• Iteration Planning
• User representative(s), Project Manager and team
• Task Planning
• Project Manager and team

13
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

14
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
• Estimates are more accurate
• Allows us to adapt to things that are beyond our
  control
• 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

15
Other Anti-Patterns

• No emphasis on quality / quality compromised in
  the name of efficiency
• We dont 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
• Recipe for disaster as almost all projects
  require some extra effort to succeed
• Hacked solution / Proto-duction /
  Under-engineering
• 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?

16
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 gt 10 days 8
No geographic separation 8
High team morale 7
Jones, Capers. Software Assessments, Benchmarks,
and Best Practices, Addison-Wesley, 2000
17
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
18
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

19
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

20
Test Driven Development (TDD)

• In my experience, Test-Driven Development
  delivered the best quality code on-time and
  on-budget
• 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

21
Peer Reviews Inspections

• Published data from major companies regarding
  Inspections
• HP Measured ROI of 10 to 1
• ATT 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

22
Effective Code Reviews And Pair-Programming

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

23
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

24
Threats To Good Quality Excessive Schedule
Pressure

• Just because people are under pressure does not
  mean that they think faster
• 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
• Bottom-line We should limit the amount of
  overtime needed on a project
• 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

25
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 Effort Size Schedule Schedule
Optimistic Pessimistic Optimistic Pessimistic
Initial Product Concept 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
26
Estimation Problem Continued
PROBABILITY OF COMPLETION
Most Likely
PERT Weighted Average
Optimistic
Pessimistic
TIME
Impossible schedule
Length of graph reflects amount of noise on
project
27
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 II
• 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

28
Risk Management

• A risk is an uncertain event that could, if it
  occurs, positively or negatively impact the
  project
• A problem that has already occurred is not a risk
  
• Forms of risk management
• Identify risk, estimate risk exposure, and
  develop risk response plan
• Mitigation
• Containment
• Avoidance
• Transference
• Acceptance
• Develop Risk Ranking for a project

29
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

30
Risk Response Planning
Risk Description Likelihood Impact Exposure L x I Response Plan
New Technology needed for key feature does not work 0.2 6 1.2 Prototype alternative technology choices Develop backup solution by Date X if primary solution does not work
Delayed delivery of 3rd party solution 0.4 2 0.8 Develop minimal duplicate solution in case of non-delivery by date Y
Poor performance of key feature impacts customer acceptance 0.6 1 0.6 Start on feature early to allow for more time in performance testing
31
Impact Of Risk On Major Project Objectives
Project Objective Low 0.1 Moderate 0.2 High 0.4 Too High 0.8
Cost lt5 cost increase 5-10 cost increase 10-20 cost increase gt 20 cost increase
Schedule lt5 schedule slippage 5-10 schedule slippage 10-20 schedule slippage gt 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 customers perception Customer expectation needs to be managed Breach of customer trust Lose customer
Adapted from PMBOK 2000
32
Recommendations

• Simply identifying risks is not sufficient
• Also identify your risk response strategy
• Regularly perform reviews of current risks and
  your response plans with your team and management
• Develop a risk database for your environment
• 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

33
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!

34
Questions

• Please feel free to contact me at
  htaqi_at_sbcglobal.net if you have any questions

35
Appendix

• More Details From Standish Group On Project
  Success Factors

36
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
37
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
38
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
39
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