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 squareof 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 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 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. R1 R2 R3 R4 L1: Master Plan BR1 BR2 BR3 BR1 BR2 BR3 BR1 BR2 Release 1 …… L2: Release plan comprising features, estimates (2-15 days) and some milestones to track progress I1 In I2 … M1 M2 Mn Increasing level of detail L3 Iteration plan with features based on client priorities and features risks F1, F2,… Fn L4: Task list with option to signup for tasks (estimates in hours) T1, T2, T3,….Tn 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 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!” allthe 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 Jones, Capers. Software Assessments, Benchmarks, and Best Practices, Addison-Wesley, 2000

17. Relative Impact on Productivity of Negative Adjustment Factors 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 • 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

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

26. 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 V0.7 V0.8 V0.9 V1.0 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 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

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

31. Impact Of Risk On Major Project Objectives 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@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