Patterns And AntiPatterns Of Project Success Haroon Taqi

Patterns And Anti-Patterns Of Project Success Haroon Taqi

The Challenge of Software Development ¡ Start with a fuzzy picture l l ¡ ¡ ¡ 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? l l 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] l ¡ Primary factor: use of iterative processing over waterfall method My Experience l Pattern: Regular cycle of delivery of working software to the customer (or proxy-customer) ¡ l l ¡ 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: l l 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 l l ¡ ¡ ¡ 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 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 Clearly Defined Plan-driven N/A Not Clear Adaptive / 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 L 1: Master Plan R 1 R 2 BR 1 BR 2 BR 3 Release 1 I 2 M 2 F 1, F 2, … Fn L 4: Task list with option to signup for tasks (estimates in hours) R 4 BR 1 BR 2 BR 3 In …… M 1 Increasing level of detail R 3 … Mn L 2: Release plan comprising features, estimates (2 -15 days) and some milestones to track progress L 3 Iteration plan with features based on client priorities and features risks T 1, T 2, T 3, …. Tn BR 1 BR 2

Planning ¡ Master Plan acts as a roadmap l l ¡ Major release every quarter Define resource shifts, training needs, purchase requirements, identify project risks, technology choices Release Plan l Intermediate milestones to determine progress ¡ l l ¡ 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 l l 2 week iterations preferred Team members sign up for tasks

Who Participates In Planning ¡ Master Planning l ¡ Sponsor, senior IT management, user representative(s), Project Manager, some team input for estimation Release Planning l User representative(s), Project Manager and team ¡ ¡ Iteration Planning l ¡ sponsor and senior IT management informed of planning output but generally do not participate User representative(s), Project Manager and team Task Planning l Project Manager and team

Common Questions ¡ What if Release 3 requires features that are too big to develop in one release cycle? l ¡ Break up features into sub-features that are delivered across multiple releases What if Release 4 requires a feature that is absolutely business critical? l 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 l ¡ Allows us to adapt to things that are beyond our control l ¡ ¡ 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” l ¡ “We don’t have time for quality / process” Unrealistic / overly optimistic schedule l l “We have to make the schedule or else…. ” Some projects rely on mandatory overtime to succeed ¡ ¡ Hacked solution / “Proto-duction” / Underengineering l ¡ “We need something right now!” all the time Over-Engineering / Over-Design Solution needed today compromised by potential needs of tomorrow l Usually an issue with good, advanced developers Questions: What are the factors that influence software development productivity? What is the cost of quality? l ¡ 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: l l l ¡ ¡ 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 l l 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 l l l ¡ High quality does not necessarily mean tons of documentation Focus on activities that add value Emphasize Lean Thinking Recommendations l l 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 l l l Convert use-cases / user-stories into acceptance tests Write automated unit-test before you write code Refactor to improve your design (constant design improvement) ¡ ¡ l l l 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 l l l ¡ 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 l 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? l l 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 ¡ l 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 l ¡ ¡ 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 l l l ¡ Bottom-line: We should limit the amount of overtime needed on a project l l ¡ 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 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 V 0. 6 Optimistic Impossible schedule PERT Weighted Average V 0. 7 V 0. 8 V 0. 9 TIME V 1. 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 l ¡ Under-promising can be seen as lack of commitment So what do we do when we have to accept an unrealistic schedule? l l l Build credibility and relationship with users by delivering value to them early and regularly by adopting I&I Understand 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 forgiveness under those circumstances

Risk Management ¡ A risk is an uncertain event that could, if it occurs, positively or negatively impact the project l ¡ Forms of risk management l ¡ 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 3 rd party solution Poor performance of key feature impacts customer acceptance Likelihood 0. 2 0. 4 0. 6 Impact 6 2 1 Exposure =Lx. I 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 l ¡ ¡ Regularly perform reviews of current risks and your response plans with your team and management Develop a risk database for your environment l ¡ 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 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: l l l Has good, realistic expectations of project (most important) and its result Acts as evangelists for project Has fair understanding of technology ¡ l l l 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: l l l l 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: l l l 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