1 / 35

Ch 6: Managing Projects

Ch 6: Managing Projects. AJ Raven. Agenda. Why IT projects become business failures. Three antidotes. The art of lean project management. Non-IT managers: Where and how. Jargon Decoder. IT project failure : Botched execution (flunks cost, schedule, or quality targets)

suzannao
Télécharger la présentation

Ch 6: Managing Projects

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. Ch 6: Managing Projects AJ Raven

  2. Agenda Why IT projects become business failures Three antidotes The art of lean project management Non-IT managers: Where and how

  3. Jargon Decoder • IT project failure: • Botched execution (flunks cost, schedule, or quality targets) • Cannot deliver promised business benefits • Triple constraint: Cheap, fast, and good<- Pick any two • 80/20 rule: 80% business needs are met by 20% of project features • Causes of failure: • Imprecise business intent • Unnecessary complexity • Lack of explicittradeoffs • Antidotes to failure: • Discovering latent business needs • Curbing scope • Explicit accountability for business benefits • Lean principles: Business involvement, rapid iteration, and less code • Rollout strategy: How a completed project is rolled out to users; abruptly replace, run in parallel, or chunk rollout

  4. A Dismal Track Record • Two of three IT projects fail • Half never deliver intended business benefits • Larger projects are 5-10 times worse • Afflicts small and large firms, non-profits, and governments worldwide • Problems that derail IT projects are often predictable and preventable $700 Billion $4,000 Billion/ Year = Cost of running MIT for 200 years

  5. Consequences Worsening • Business penalties worsening because • Larger projects • Touch more parts of firms • Baked into more products and services • Most rigorous testing leaves half the bugs undetected • Malfunctioning products, stalled operations, failed firms, even deaths • How IT is developed failing to keep pace with its growing complexity • Handcrafted, painstakingly • Error prone: 100-150 mistakes in every thousand lines of code

  6. déjà vu, Again • Timeless lessons from projects with • Massive scale • Uncertainty • Bickering stakeholders • Railroads, the electric grid, highways, moon landings, and Hoover • Making new mistakes repeating old mistakes

  7. Can You Guess What this is? • Massive infrastructure project that promised to • Speed the global flow of goods • Mark the death of distance in global commerce • Wipe out inefficiencies • Make a fortune for all investors and stakeholders • But… • Completed six years behind schedule • Cost twice as much • Promised payoff a hundred years behind schedule

  8. Suez Canal (1854-) Mediterranean 101 miles Red Sea Original route 12,000 miles Africa Shorter route 7,000 miles

  9. Today… • 17,000 ships • 1,000 million tons of cargo each year • Egypt’s share: $6 billion a year Lessons for IT projects: • “Obvious” technical merits on paper don’t get a project used • Suez: Pirate-free, shorter, cheaper trip • Expect no payoff until it’s used

  10. London Electrobus (circa 1907) I

  11. London Electrobus II • 100 years before Telsa… • Well engineered, 38-mile range, and ingenious battery swaps • Gas engine was not yet inevitable; competition was horse buggies • The buses were… • 300% over budget, 3,000-pound battery, and 30/50 never completed • Cost, quality, and schedule  flunked all three Lessons for IT projects: • Simultaneously counting on too many unproven technologies risky • Clever technology does not guarantee success • A project must outdo its real competitionnot always obvious • Electrobus: Not the automobile but the horse • Doomed without complements (then and now, charging stations)

  12. Hoover Dam (1930s) • Completed two years early and under budget • Managers created master plan but gave engineers discretion over their work • Lesson for IT projects: Micromanage what but not how

  13. Why Non-IT Managers Matter • Good IT project management increasingly indistinguishable from good business management • Invariably has an IT element • Any strategic move • Business model tweak • Process improvement • IT project managers skilled at managing technical risks • Only non-IT managers can prevent their business failure • Under-delivering intended business benefits • IT project managers ill-equipped to tackle this • Non-IT managers’ contributions  the right system faster and cheaper

  14. Business Failure from 3x Preventable Mistakes • Ambiguity of purpose  wrong system • Unnecessary complexity • Non-IT managers silent on the triple constraint

  15. #1: Ambiguity of Purpose • Poor biz-IT communication = the wrong system • Rarely faulty execution • Business benefits—not technical features—define value • Latent needs • <Instructor: Describe the RAID story here> • Need that’s present but not yet visible • IT cannot build what you don’t ask for • Leads to feature-bloated, kitchen-sink over-engineering • antidote comes solely from non-IT managers • The cardinal sin is non-IT managers not articulating a business goal

  16. #2: Unnecessary Complexity • Cause: Ballooning scope one system tries to do too much • As a project gets larger… • Defects rise in proportion • Integration problems compound • Becomes incomprehensible to any one person Costly endeavor without realistic benefits Double whammy More viable 1 4 High risk Titanic gamble High Prioritize requirements Complexity Rudderless boat Low Low risk 2 3 Low Solution searching for problem High Requirements clarity

  17. #3: Not Explicitly Choosing Tradeoffs Fast Pick any two Good Cheap • A failure to make one tradeoff—fast, cheap, or good—explicit • Trying to achieve all three often achieves none • Non-IT managers must pick one to give up • Driven by a project’s business objectives • If time and money are scarce, curb scope

  18. 2 Risks Beyond Non-IT Managers’ Control • Use of immature technology in a project • Uncertainty  ambiguity • PM only tackles ambiguity but uncertainty requires real options thinking • Underestimation of time and money • Initial estimates define project success, yet often underestimated • Common because… • Smaller commitments more likely to be approved • Often build insufficient slack in schedules • Overpromising leads to under-delivering • Estimation is more an art than science • Project interdependencies multiply (90% in four pieces = 65% overall) • Heuristics don’t extrapolate across contexts and novel • T-shirt sizing rule (S/M/L) • Roughly right is better than precisely wrong • Triangulate person-hours effort needed

  19. Antidotes to Business Failure of IT Projects • Discover a project’s true business purpose • Curbing scope creep • Accountability without micromanagement

  20. Antidote #1: Discovery of Purpose “Waterfall” Approach Years Gather Requirements 1 • Business needs change • Competitors actions • Tech evolves • Regulations change Design Latent needs Code Flawed requirements Window of Isolation Test 2 Roll out

  21. Lean Discovery of Business Needs Assumes: • Business users can’t articulate an IT project’s requirements • Success only in their eyes Three foundational principles of all lean methods: • Active business participation • Short iterations • Less code

  22. Lean Idea #1: Active Business Participation C-R-A-C-K Business Team Members • Collaborative • Representative of biz users • Authorized to decide • Committed to business value • Knowledgeable Integrally participate throughout Business users IT unit Domain Knowledge Technical Knowledge Converge IKEA effect Reduces resistance Prioritized requirements

  23. Lean Idea #2: Short Iterations • Series of iterative sprints, 2-6 weeks apart • Each iteration hands users a crude but functioning system with small subset of functionality • Integrally engage business users in a two-way conversation • Marathon  many sprints • Clears misunderstandings earlier  cheaper to fix • Uncovers latent needs • Zaps wasteful overengineering and gold-plated functionality Zero feedback opportunities Jan Feb Apr June Feb May Single iteration Monthly iteration 5 feedback opportunities

  24. Lean Idea #3: Less Code Every line of code explicitly justified with business objectives Bakes in quality and curbs costs in two ways: • Software with more code is buggier • 100-150 errors/KLOC + 50% best-case bug squashing during testing • Translation: A small (1 mil LOC) app with have 5,000+ bugs • Bug fixing is 100 times costlier after deployment • Toyota’s $10 billion braking software glitch • Lesser code lowers upfront development costs ($15-$40/ LOC) • Implemented using the 80/20 rule and short iterations Other lean-enabling ideas • Constant automated testing • Continuous integration–reduces integration glitches at the end

  25. Lean Payoffs: Better, Faster, Cheaper Build the right system Cheaper and faster Bake quality in Active business involvement Short iterations Less code

  26. Lean or Waterfall? • Stable requirements • Proven technologies • e.g., infrastructure Success triples if made smaller Larger projects always more challenged Small projects Large projects

  27. Antidote #2: Curb Scope #1 threat: Attempting too much, with too little or too fast • Tame scope using 80/20 rule • Which 20%? – • MoSCoW rule applied to requirements by non-IT managers: • Must-have • Should-have • Could-have, but not critical • Wont-have this time, but maybe later • ~ Must-do versus may-do in real options lingo

  28. Antidote #3: Accountability without Micromanagement Non-IT managers must hold team accountable for delivering business benefits ~ a project’s measurableorganizational value (MOV) must come the business side • Must balance what’s ideal and realistic • Collaborative, involving all project stakeholders • Ensures IT folks are evaluated first as business people • Ask: how does this project further our operational strategy? Four elements: • Intended impact: Operational, strategic, or financial • Promise: Will it help do something better, faster, or cheaper? • Change metric: dollars, percentages, or time? • Time to impact after project completion (years/ months) What’s wrong here? Project PixieDust will… …create ubiquitous new channels to target mobile customers through real time analytics …will strengthen our ability to deliver an industry leading experience to customers …will lower distribution costs by 10% …will lower IT costs by 10% by rationalizing our global platform …will implement the Obamacare law Tweet test?

  29. Rollout Strategies  Widespread impact of glitches Avoid for mission-critical IT Rollout date  Direct cutover Old System New System  Safety net for glitches Prolongs rollout period Old System  Parallel rollout New System  Business pressures Old System  Phased rollout New System Chunk 2 Chunk 1 Chunk 3 Bad choice hurts receptivity jeopardizing payoffs

  30. Summary • IT projects have dismal success rates • Trifecta is amplifying business penalties • Technical successes can still be dismal business failures • 3x causes: Ambiguous business goals, unneeded complexity, and silent non-IT managers • 3x antidotes: Discover latent business needs, curb scope, and accountability without micromanagement • Lean beats waterfall…unless requirements are precise • 80/20 rule <-- use MoSCoW rules

  31. Figure 6-1 from the book

  32. Original prospectus for the Electrobus shares from archives in London

  33. Postage stamp issued in Egypt to celebrate the success of the Suez Canal

  34. Suez Color map from Library of Congress

More Related