1 / 30

“Budgeting of IT-projects: Standards and best practices for cost and schedule planning.”

“Budgeting of IT-projects: Standards and best practices for cost and schedule planning.”. Galorath Incorporated Daniel D. Galorath blog: www.galorath.com/wp. Cutter Consortium Software Project Survey: 62% overran original schedule by more than 50% 64% more than 50% over budget

waldo
Download Presentation

“Budgeting of IT-projects: Standards and best practices for cost and schedule planning.”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. “Budgeting of IT-projects: Standards and best practices for cost and schedule planning.” Galorath Incorporated Daniel D. Galorathblog: www.galorath.com/wp

  2. Cutter Consortium Software Project Survey: 62% overran original schedule by more than 50% 64% more than 50% over budget 70% had critical product quality defects after release Standish Group CHAOS Report 46% challenged 19% failed 35% successful IT Failures Are Pervasive: And Even Successful Projects May Not Be ~$875 billion spent on IT ~$300 billion spent on IT projects ~$57 billion wasted annually ROI of better planning huge Some suggest 80% of systems NEVER produce a positive ROI

  3. An Estimate Defined • An estimate is the most knowledgeable statement you can make at a particular point in timeregarding: • Effort / Cost • Schedule • Staffing • Risk • Reliability • Estimates more precise with progress • A WELL FORMED ESTIMATE IS A DISTRIBUTION

  4. Human Nature: Humans Are Optimists • Solution - Temper with “outside view”: • Past Measurement Results, traditional forecasting, and statistical parametrics can help • Don’t remove optimism, but balance optimism and realism HBR Article explains this Phenomenon: • Humans seem hardwired to be optimists • We routinely exaggerate benefits and discount costs Delusions of Success: How Optimism Undermines Executives' Decisions (Source: HBR Articles | Dan Lovallo, Daniel Kahneman | Jul 01, 2003)

  5. Estimation Methods 1 of 2

  6. Estimation Methods 2 of 2

  7. Reasons To For Viable / Repeatable Estimates (Adapted from CEBok)

  8. Best Practice: Estimation Process: Consistent Processes = Reliable Estimates • Track Project Throughout Development • Establish Estimate Scope • Document Estimate and Lessons Learned • Establish Technical Baseline, Ground Rules, Assumptions • Generate a Project Plan • Collect Data • Quantify Risks and Risk Analysis • Estimate and Validate Software Size • Review, Verify and Validate Estimate • Prepare Baseline Estimates

  9. Estimate When Project Changes Or Information Is Available Estimates typically become more accurate and less uncertain as the project progresses… The Development Method Is Part Of The Solution Not The Problem • Traditional Estimate Phases • During Feasibility • At Concept • After Requirements • After Design • After Drops if Incremental • Agile Estimate Phases • At Requirements (Use Cases, User Stories, etc.) • Before Each Release

  10. Example: Project Cost Alone Is not The Cost of IT Failure (Source: HBR) • “IT projects touch so many aspects of organization they pose a new singular risk” http://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think/ar/1 • Case Study: Levi Strauss • $5mERP deployment contracted • Risks seemed small • Difficulty interfacing with customers systems • Had to shut down production • Unable to fill orders for 3 weeks • $192.5M charge against earnings on a $5m IT project failure

  11. Manual Estimates: Human Reasons For Error (Metrics Can Help) • Manual Task estimates yield SIGNIFICANT error • Desire for “credibility” motivates overestimate behavior (80% probability?) • So must spend all the time to be “reliable” • Better approach: force 50% probability & have “buffer” for overruns • Technical pride sometimes causes underestimates

  12. Best Practice: Estimate Entire Total Ownership Cost Software Development (SEER-SEM) Software Maintenance (SEER-SEM) IT Infrastructure (SEER-IT) IT Services (SEER-IT)

  13. Minimum Time To Complete (Effort Increases to Reduce Schedule) Work ExpandsTo Fill Time (Effort Increases due to lack of pressure) Minimum Time Effort Months Optimal Effort (Lower Effort for Longer Schedule) Impossible Inefficient Calendar Time Best Practice: Understand & Manage Project Realities For a given Size, Complexity and Technology Effort Increasedue to Longer Schedule

  14. Best Practice: Every Estimate needs to be Substantiated & Benchmarked SEER-SEM Estimate Galorath Benchmark Trend Line Your History Data Your Data Regression Trend Line Why Should We Care: Variances can identify estimation issues. Benchmarking can be path to improvement

  15. Best Practice Probability based Estimates Firm Fixed Price? Feel lucky? What is likely to happen Understand the risk before you commit! 15

  16. Technology People Process Best Practice: Understand What Drives Productivity EffectiveTechnology

  17. Best Practice: Consider Total Cost of Ownership, Not Just Development Why Should We Care: Impacts ROI & development decisions can impact maintenance costs.

  18. Best Practice: Multi-Dimensional Progress Tracking (Earned Value) Track defect discovery and removal rates against expected rates • Heath and Status Indicator shows status and trends from the previous snapshot • Thresholds are user definable Increased defect reporting rate shows a worsening trend Why Should We Care: Catching deviations from plan early allows adjustment or replanning

  19. Best Practice: Relative Estimates For Early Estimates • Generate Sizing even before details are known based on relative analysis • Access corporate knowledge from historical database • Use domain specific analogies • Configurable for Different Needs - estimate any type of variable Why Should We Care: Generate viable estimates even before any requirements analysis. Provide crosschecks & portfolio analysis

  20. Best Practice: Establish A Project Repository

  21. Conclusions Viable Estimates are critical to project success With proper estimation processes and tools estimation should SAVE FAR MORE THAN THEY COST Knowledge is power… Making the appropriate decisions can have a huge return

  22. Backup Slides

  23. Mythical Man-Month Rules (Source: MIT/ Brooks) Models Like SEER Refined The Mathematics… The Phenomena Continues • “Cost varies as product of people and months, progress does not.” • “Hence the man-month as a unit for measuring the size of job is a dangerous and deceptive myth” • The myth of additional manpower (Brooks Law) • “Adding manpower to a late project makes it later” • Communication & Training Cost • Brooks original formula: n(n-1)/2 • 12 month project schedule • 1 person: 12 months • 2 persons = 7 months (2 man-months extra) • 3 persons = 5 months (3 man-months extra

  24. High Quality Estimate Characteristics Accurate (within a viable range) Comprehensive (includes all costs or identifies exclusions) Replicable and Auditable (not just guessss) Traceable (to the source of the requirement) Credible (Believable) Timely (Available when needed)

  25. Estimate Model Components and Characteristics (adapted from CEBOK) • Inputs • Technical and programmatic parameters • Applicable rates • Detail (Model structure) • Varying level of detail depending on need • Applies parametric, analogy, or build-up techniques to inputs • Outputs • Costs, & cost risk • Schedule & schedule risk Groundrules & Assumptions Inputs Methodology Outputs Data

  26. Frederick Brooks Classic Paper “No Silver Bullets” • “There is no single development, in either technology or management technique, which by itself promises even one order-of magnitude improvement within a decade in productivity, in reliability, in simplicity.” • -- Fred Brooks, 1986 • i.e. There is no magical cure for the “software crisis” • Not software measurement • Not better tools • Not ---- (fill in the blank… the current great hope)

  27. COTS Software: Purchased functionality Direct Cost component of COTS integration COTS Cognition: Required functionality within the COTS software that must be understood “Glue” Code: Code written to bind COTS to developmental software Development effort must be captured Customization Key Components Of A Software Project That Uses COTS COTS Software Glue Developmental Software “COTS Cognition”

  28. Process For Combining Estimation, Planning & Control, Measurement & Analysis Prepare Estimate Multi-Dimension Earned Value Effort Progress Baseline Approved Estimate Schedule Progress Size Growth • Snapshot • Point in Time • Progress • Effort • Schedule • Size Growth • Defect Rates Defect Insert/Remove Progress Collect In Progress Data

  29. Packaged Applications Are Costly To Organizations • “Commercial application program or collection of programs developed to meet the needs of a variety of users, rather than custom designed for a specific organization” • Many are enterprise applications • Often allows / requires customization • Examples: SAP; Rational PPM, SEER for Software; Microsoft Excel, CA Clarity, Oracle Business Suite "One-third [of the budget] has to go to testing. Don’t ever short change testing. Everyone always underestimates it, and says it’s the last thing to worry about. Don’t do that!“ - Jim Larson, consultant for communications solutions provider Why should we care: Packages sometimes comprise solutions for parts of complicated systems and can be trouble

  30. Understand Project Total Ownership Costs Up Front • Most Projects Spend Low During Maintenance

More Related