Patterns And Anti-Patterns Of Project Success - PowerPoint PPT Presentation

Loading...

PPT – Patterns And Anti-Patterns Of Project Success PowerPoint presentation | free to download - id: 6780e7-NDA1O



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Patterns And Anti-Patterns Of Project Success

Description:

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 ... – PowerPoint PPT presentation

Number of Views:70
Avg rating:3.0/5.0
Slides: 40
Provided by: Haroo2
Learn more at: http://www.iconatg.com
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com