The End of Projects & what to do about it

693 views

Published on

The problems projects create, why we should dispense with projects and some ideas on what to do instead

Published in: Business, Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
693
On SlideShare
0
From Embeds
0
Number of Embeds
133
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • Public domain image, http://commons.wikimedia.org/wiki/File:Sausage_making-H-3.JPG
  • The End of Projects & what to do about it

    1. 1. The End of Projects… and what happens next (Aka Beyond Projects) Allan Kelly allan@softwarestrategy.co.uk http://www.softwarestrategy.co.uk Twitter: @allankelly.net BCS PROMS-G, London, February 2014
    2. 2. Allan Kelly…  Consulting on software development & strategy  Training for Agile Author – Changing Software Development: Learning to be Agile (2008, Wiley) – Business Patterns for Software Developers (2012, Wiley - ISBN: 978-1119999249) – Xanpan: Reflections on agile (work in progress) https://leanpub.com/xanpan Chapters in… • Business Analysis and Leadership, Pullan & Archer 2013 • 97 Things Every Programmer Should Know, Henney, 2010 • Context Encapsulation in Pattern Languages of Program Design, vol #5, 2006
    3. 3. Audience participation How many of you … • Adequately identify & quantify project benefits? • Know someone who overstates the benefits of a project to obtain funding? • Think project review & evaluation is adequate?
    4. 4. • 70% believe they are failing to identify and quantify the benefits adequately • 38% openly admit they overstate the benefits in order to obtain funding • 80% report that the review and evaluation of completed projects is also inadequate • due to the focus on whether the project achieved cost, time and quality objectives and not on whether the intended benefits were realized. Survey of 100 IT/IS & Business managers in UK and Benelux, 2006 Delivering value from IS and IT investments, John Ward, Cranfield School of Management, 2006 http://www.som.cranfield.ac.uk/som/dinamiccontent/research/documents/deliveringvaluereport.pdf
    5. 5. Successful software doesn’t stop • Successful software continues to change • Only dead software has an end-date
    6. 6. Successful software? Moodle 1) If they use it, it will change Weekly downloads: 23,239 Last update: 3 days (16 Jan) Web Torrent Weekly downloads: 0 Last update: 17 April 2013 2) Only Dead Software Stops changing PerlLORD Weekly downloads: 0 Last update: 25 May 2013 Data from SourceForge search for “WebBrowser” 19 Jan 2014
    7. 7. A Project is… “A temporary organization that is needed to produce a unique and predefined outcome or result at a pre-specified time using predetermined resources.” PRINCE2 definition of project
    8. 8. Temporary Organization? • • • • • Storming Norming Forming Performing Destroying } Takes time & money! Yes! Why destroy performing teams? Why spend that money? Why loose knowledge?
    9. 9. Corporate Psychopathy Process by which corporations disband performing teams and release staff • • • • Stop killing performing teams Keep the team together Flow the work to the team The Team is the Capability
    10. 10. Pre-determined resources? • In the ideal world… – You get the resources you ask for? – They are dedicated to your project? And stay? • Back in the real world… – Resourcing allocation is politics ‘Nuff said
    11. 11. Pre-defined outcome? • Requirements change • The world changes The observed rate of change in the US is about 2% per calendar month Capers Jones, 2008 Compound to ~27% per annum
    12. 12. Pre-specified time? • Pre-specified time is not chosen rationally • When does it start? • When does it end? – Last bug fixed? – Last CR done? – Thrown over last wall? Capers Jones, 2008 In the US more than half of the large projects … predetermined end date is selected, and it is forced on the project by arbitrary decree. Among the most difficult … measurement of project & task schedules. The initial difficulty… is… identifying the start point of any given project!
    13. 13. End Date considered harmful • Late requirements considered inferior • Quality cut to meet date When will it be – Harder to maintain – Harder to fix bugs – Harder to enhance – Harder to live • Goal deferment – The End done?
    14. 14. Work with no end • Work to short term goal & deadline – Human’s are good with deadlines – (Very bad with estimation) • Work to deliver value • Work as if this is your last goal – But: Work to be ready for another round • Do work you will be proud of
    15. 15. Focus on Value not The End Ask not, “When will the software be done?” But ask: “When will the software deliver value next?” Think: Stream of Value (which might stop one day) Not: An end date
    16. 16. The End of Projects • Projects are accounting codes • Finished Software is Dead Software – Living software changes – Living software doesn’t end • Project thinking kills software
    17. 17. What next? • Putting the jigsaw together
    18. 18. Software development… • Does NOT have economies of Scale • Development has DISECONOMIES of scale Therefore • Stop thinking BIG • Start thinking SMALL
    19. 19. Batch Size Wait Build this! Wait Deliver this! Make lots of this!
    20. 20. Ask not, “What is the end date?” But ask: “When is the next delivery?”
    21. 21. Waterfall 2.0 Continuous Flow Jonathon’s Run Fall, Pennsylvania by Hubert Stoffels (http://flickr.com/photos/22195940@N00) Creative Commons License
    22. 22. Continuous flow • Work in the small • Get good at doing small things – Deliver small increments of value – And evaluate results • Go fast • Don’t stop • Value seeking
    23. 23. What to do about it… • • • • • Keep teams together Flow work to the teams Work in the small Work continually Demonstrate value
    24. 24. Think Product • Products go on – and on – and on • Think multiple releases • Think continuity
    25. 25. Constraints Resources (People) Features Cost = Resources x Time Quality = free Fixed over short run (Brooks Law) Time All the action Time boxed 28
    26. 26. Functionality, the only flex • Negotiate features – Deliver, Evaluate – Repeat (every 2 weeks or less) • Keep quality high – Cutting quality slows work – Cutting quality increase cost – Cutting quality upsets customers Time fixed
    27. 27. Change Governance • Base Governance on actual delivered benefits – Not milestones completed – Not documents – Not budgets • Align work with strategy Picture from Picasa - Creative Commons License http://commons.wikimedia.org/wiki/File:House_of_Parliment_6_201 2-07-08.jpg What have you delivered for me lately?
    28. 28. Change the Start • Start small • Overlap discovery & development – From Day-1 • Fail fast, Fail cheap • Grow the successful
    29. 29. Active Portfolio Management • • • • Start, Stop, Shrink, Grow work teams/streams Balance risk/reward Sustaining/Innovative CLOSE UNDER PERFORMING WORK
    30. 30. The End of Project Management? • Projects are for accountants • Organize work by – Work streams and/or – Products – Manage queues • Aim for stable teams, continuity – Occasional personnel changes – Living, changing code bases
    31. 31. Management work to do • • • • “Manager” -> More authority to fix Dealing with fuzzy world Keep team runing effectively Supplier / Client relationships – Contracts to discuss & police – Role shoot out • Stuff “they have an B manager so we need an B manager” – Admin, reporting, Line Management
    32. 32. John Smith Project Manager (Aries Project) Payments Manager Big Corporation John.smith@bigcorp.com Tel: +123 456 7890 • “Project Manager” becomes: – First Line Manager, Junior Manager, Development Manager, Team Manager, Team Leader, or or or • You have continuity – Projects end; Products don’t
    33. 33. How do you manage work? People… Theory X • Inherently dislike work • Must be controlled and directed • Shun responsibility • Have little ambition • Want security People… Theory Y • Work leads to satisfaction • Can exercise selfdirection • Committed to objectives when rewards are valued • Seek responsibility From McGregor, D. 1960. The human side of enterprise
    34. 34. Remember • It ain’t ever over • BAU is not a dirty work allan kelly www.softwarestrategy.co.uk www.allankelly.net allan@allankelly.net Twitter: @allankellynet http://leanpub.com/xanpan (c) Allan Kelly http://www.softwarestrategy.co.uk 39

    ×