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

Micro-management

Unbearable

Self-Managed, Goal-Driven

teams

Anarchy and confusion

Yes No

Yes

No

Develop Objectives

Specify Means

• 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

Plan-driven N/A

Adaptive / Agile Planning

Agile Planning

Clearly Defined

Objectives

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?

Not Clear

Clearly Defined

Not Clear

Multiple Levels of Planning

………

Release 1

I1 I2 In

M1 M2 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

F1, F2,… Fn

T1, T2, T3,….TnL4: Task list with option to signup for tasks (estimates in hours)

Increasing level of detail

Time

R1 R2 R3 R4

BR1BR2

BR1BR2BR3

BR1BR2BR3

L1: Master Plan

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

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

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

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”

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

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?

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

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

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

Beating Schedule Pressure: Problem With Original Project Estimates

Milestone (Waterfall) Effort & Size ScheduleOptimistic 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

• 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

Estimation Problem Continued

Optimistic PessimisticTIME

PROBABILITY OF COMPLETION

Most LikelyPERT Weighted Average

Impossible schedule

V0.6 V0.7 V0.8 V0.9

Using I&I:• High-priority & risky items targeted early• Generate real data for determining project velocity early

V1.0

Typical developer schedule tends to be optimistic

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

Simple Risk Ranking For A Project

Simple CustomerSmall SizeKnown TechnologyA

Complex CustomerSmall SizeKnown TechnologyD

Complex CustomerSmall SizeNew TechnologyG

Simple CustomerSmall SizeNew TechnologyB

Simple CustomerLarge SizeKnown TechnologyE

Complex CustomerLarge SizeKnown TechnologyH

Simple CustomerLarge SizeKnown TechnologyC

Simple CustomerLarge SizeNew TechnologyF

Complex CustomerLarge SizeNew TechnologyI

Low Medium High

• 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 Likelihood ImpactExposure

= L x IResponse 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.6Start on feature early to allow for more time in performance testing

Impact Of Risk On Major Project Objectives

Project Objective

Low 0.1

Moderate0.2

High0.4

Too High0.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

ScopeMinor 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 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

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 htaqi@sbcglobal.net 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