Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Egov Projects For Fun Profit


Published on

Published in: Economy & Finance, Technology
  • Be the first to comment

Egov Projects For Fun Profit

  1. 1. E-GOV PROJECTS FOR “FUN” (AND “PROFIT”) Govcamp 2007 Antwerp
  2. 2. Personal Introduction <ul><li>Patrick Debois </li></ul><ul><li>Independant Consultant </li></ul><ul><ul><li>Government Side (RFP, Design) </li></ul></ul><ul><ul><li>IT Supplier Side (Portals, CMS, Identity & Access) </li></ul></ul><ul><li>Also a Belgian Tax Payer </li></ul>
  3. 3. Why this presentation? <ul><li>How did I survive (10 years of E-gov) </li></ul><ul><li>Old Tactics </li></ul><ul><ul><li>Don’t care on the functionality, focussed on technical </li></ul></ul><ul><ul><ul><li>“ We sometimes work for nothing but not for free!” </li></ul></ul></ul><ul><ul><ul><li>“ As a tax payer I’m glad to get (some) tax money back!” </li></ul></ul></ul><ul><ul><li>Concentrated on the right toolset (Hardware, Software) </li></ul></ul><ul><ul><ul><li>Resulted in PROFIT (I got paid) </li></ul></ul></ul><ul><li>New Tactics </li></ul><ul><ul><li>Improve the process : Promote Agile Process Management (e.g. Scrum) </li></ul></ul><ul><ul><li>Change thinking </li></ul></ul><ul><ul><ul><li>Results in FUN & PROFIT (I hope so!) </li></ul></ul></ul>
  4. 4. <ul><li>Late </li></ul><ul><li>Over budget </li></ul><ul><li>A lot of Frustration </li></ul>Your ‘average’ E-gov Project
  5. 5. E-gov Projects Schedule <ul><li>Reality </li></ul>Planned DEADLINE Does not meet the deadline
  6. 6. E-gov Projects Scope Planned DEADLINE Scope Removed Scope Additional Scope Has a change scope, unfinished
  7. 7. Iron Triangle (Restistance if Futile) <ul><li>Breaking the Triangle results in: </li></ul><ul><li>Cancel Project (15%) </li></ul><ul><li>Deliver Later and/or Over Budget (51%) </li></ul><ul><li>Deliver poor quality </li></ul><ul><li>Underdeliver </li></ul>Source Chaos Report Quality Scope (Features, Functionality) Schedule (Time) Resources (Cost, Budget)
  8. 8. Common E-gov Project Tactics <ul><li>Fix the Scope: </li></ul><ul><ul><li>bring in another company for RFP proces (avoid responsability) </li></ul></ul><ul><ul><li>handover part of scope from project to operations (quality) </li></ul></ul><ul><ul><li>change requests </li></ul></ul><ul><li>Fix the Time: </li></ul><ul><ul><li>we’ll be ready when you are (Bluffpoker) </li></ul></ul><ul><ul><li>provide temporary solution </li></ul></ul><ul><ul><li>blame the previous in the chain (Design, Test, Integration, Prod by diffent teams) </li></ul></ul><ul><ul><li>we are 96% ready </li></ul></ul><ul><li>Fix the Price: </li></ul><ul><ul><li>predefine as much as possible (Big Up Front Design) </li></ul></ul><ul><ul><li>penalties are another budget </li></ul></ul><ul><ul><li>borrow from other hidden budget </li></ul></ul><ul><ul><li>promise additional projects to supplier </li></ul></ul>Focus on reduction of changes (the hard way)! = NO FUN!
  9. 9. <ul><li>Abondon Waterfall Model </li></ul><ul><li>Becoming Agile (Embrace change!) </li></ul><ul><li>example using Scrum </li></ul>Changing Tactics
  10. 10. Agile Tactic : Prioritize Functionality High Priority Low Priority Requirements Functionality Each new Requirement is prioritized and added to the stack Requirements may be removed at any time Requirements may be repriorized at any time Modeled in greater detail Modeled in lesser detail Product Backlog Focus on functionality not on components Better view of what is finished
  11. 11. Agile Tactic : Release Often High Priority Low Priority Requirements Modeled in greater detail Modeled in lesser detail Set of Functionality Sprint X Sprint X + 1 Fixed Length Becomes a rythm Set of Functionality Planning becomes predictable if requirements become clear. Most important first. Timeboxed Periods = Sprint
  12. 12. Agile Tactic : Planning as a TEAM Set of Functionality Fuctionality X1 = Fuctionality X2= Fuctionality X3 = Fits Sprint capacity For next Sprint 1 2 3 5 8 13 21 BIG Team thinks it can handle 12 points in a Sprint 3 5 8 50 Team does estimations in group. Relative in Size (StoryPoints) , not in Days Planning Poker Fuctionality X4 = Needs to be split 21
  13. 13. Agile Tactic: Realistic Progress Initial DEADLINE 0 50 100 1 2 3 4 130 5 6 7 8 Product Backlog Burndown Chart 9 10 11 Estimate 1 Estimate 2 Sprint Convergence to an predictable “team” velocity Remember Iron Triangle!
  14. 14. Agile Tactic : Focus High Priority Low Priority Requirements Modeled in greater detail Modeled in lesser detail Set of Functionality Sprint X No need for all design upfront Focus helps getting things done Sprint Backlog Product Owner (PO) Focus = Functionality Scrum Master (SM) Focus = Blockers Team Focus = Build Set Tasks
  15. 15. Agile Tactic : Have things “Done” Planning Analysis Design Coding Testing Architecture Infrastructure Performance User Acceptance Pilot Live <ul><li>TIP: automate as much as possible : </li></ul><ul><li>Automated Deployment </li></ul><ul><li>Automated Testing </li></ul><ul><li>Virtual Machine </li></ul><ul><li>Scripted installations </li></ul>Result of sprint = Real functionality Copyright Jef Sutherland
  16. 16. Agile Tactic : Better Communication <ul><li>Product Backlog meeting (PO & SM) (2 – 4 weeks) </li></ul><ul><ul><li>Focusses on Functionality = what PO understands </li></ul></ul><ul><li>Sprint planning meeting (SM & Team) </li></ul><ul><ul><li>Focusses on Technical = what Team understands </li></ul></ul><ul><li>Daily Scrum Meetings (Team & SM) </li></ul><ul><ul><li>What did I do yesterday </li></ul></ul><ul><ul><li>What will I do today </li></ul></ul><ul><ul><li>What is blocking me </li></ul></ul><ul><li>Sprint Retrospective After Sprint (Team & SM) </li></ul><ul><li>Sprint closing (Team & ScrumMaster & Product Owner) (2 – 4 weeks) </li></ul>
  17. 17. Agile Tactic : Improve Feedback <ul><li>User Feedback </li></ul><ul><ul><li>After every sprint : we build things that are“Done” </li></ul></ul><ul><li>Status Feedback </li></ul><ul><ul><li>Product Backlog </li></ul></ul><ul><li>Financial Feedback </li></ul><ul><ul><li>Timebox +/- Fix Budget (Man Power) </li></ul></ul><ul><li>Deadline </li></ul><ul><ul><li>Product Backlog burndown chart </li></ul></ul>
  18. 18. Summary : Scrum Process Copyright SoftHouse Believe me! It’s more FUN!
  19. 19. Are you up for it? <ul><li>Do you want transparancy? </li></ul><ul><li>Can you take the shared responsability? </li></ul><ul><li>Are you only committed or also involved? </li></ul><ul><li>Will you change your ‘old” tactics? </li></ul><ul><li>Demand Agility in your projects! </li></ul>
  20. 20. References <ul><li>Books </li></ul><ul><ul><li>Agile Project Management with SCRUM (Microsoft Professional) (Ken Schwaber) </li></ul></ul><ul><ul><li>Agile Estimating and Planning (Robert C. Martin) </li></ul></ul><ul><ul><li>User Stories Applied: For Agile Software Development (Mike Cohn) </li></ul></ul><ul><ul><li>Agile Retrospectives, Derby and Larson </li></ul></ul><ul><li>Videos (Google) </li></ul><ul><ul><li>Scrum et Al- Ken Schwaber </li></ul></ul><ul><ul><li>Bay XP Meeting Part 1: Agile Estimation, Mike Cohn </li></ul></ul><ul><ul><li>Competing On The Basis Of Speed – Mary Poppendieck </li></ul></ul><ul><ul><li>Scrum Tuning: Lessons learned from Scrum implementation at Google, Jeff Sutherland </li></ul></ul><ul><li>Mailing Lists </li></ul><ul><ul><li>[email_address] </li></ul></ul><ul><ul><li>[email_address] </li></ul></ul><ul><ul><li>[email_address] </li></ul></ul><ul><ul><li> </li></ul></ul><ul><ul><li>[email_address] </li></ul></ul><ul><li>Websites </li></ul><ul><ul><li> </li></ul></ul>
  21. 21. Thanks for Listening <ul><li>Questions? </li></ul>[email_address]