1 / 44

ICT Project Management

ICT Project Management. A survival guide Dr Christopher O’Mahony Head – Centre for Information Technology St Ignatius’ College, Riverview. In summary.

mendel
Download Presentation

ICT Project Management

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. ICT ProjectManagement A survival guide Dr Christopher O’Mahony Head – Centre for Information Technology St Ignatius’ College, Riverview

  2. In summary • This presentation shares some examples of IT projects in schools, and hopefully shares some tips on how to survive the IT Project battleground. • Good News and Bad News • Some wider context • A cynical view • Key learnings • A sample case study • Some useful links

  3. The presenter • Christopher O’Mahony • Head – Centre for IT, St Ignatius’ College, Riverview • In school IT management roles since 1997 • PhD research in school management information systems, IT evolution, IT evaluation, organisational culture • Involved in various IT projects such as • Management information systems • Library systems • Voice-over-IP • SAN / DDT • ISP • Reprographics

  4. The good news • The fact that this conference is happening, and that this topic is included, is indicative of the growing professionalism among school IT management. • Most of us, during our tenure in these positions, will be involved to a greater or lesser extent in IT projects. • Increasingly in schools, other organisational units are looking to IT managers for robust methodologies and discipline, rigour and objectivity in capital projects. • BUT ………

  5. The bad news • In the 1990’s, the average life span of a senior IT manager was about 900 days. • A common cause of IT manager casualty is failed IT projects. • Aalders, R., & Hind, P., (2002) “The IT Manager’s Survival Guide”, Chichester, UK; John Wiley & Sons. • Industry analysis tells that MOST IT projects fail • For example: • UK NHS – 4 years over time, GBP 10 billion over budget • Australian Customs – 4 weeks container processing backlog on implementation

  6. Defining project failure • Project abandonment • Cost overruns • Time overruns • Incomplete implementation / functionality • Major causes: • Degree of user involvement • Executive management support • Project management experience

  7. (Courtesy: Information Age, 2005) Smaller initiatives fare better at reaching goals than larger projects do.

  8. (Courtesy: Information Age, 2005)

  9. (Courtesy: Information Age, 2005)

  10. (Courtesy: Information Age, 2005)

  11. A cynical view Project Management Truths • “Never underestimate the ability of senior management to buy a bad idea, and fail to buy a good idea.” • “Quantitative project management is for predicting cost and schedule overruns well in advance.” • “Project meetings are events where minutes are kept, and hours are lost.” • “We build systems like the Wright brothers built airplanes – build the whole thing, push it off a cliff, let it crash, and then start all over again.”

  12. A cynical view Project Management Truths • Projects happen in two ways: (a) Planned and then executed or (b) Executed, stopped, then planned and executed. • “Good project management is not so much knowing what to do and when, as knowing what excuses to give and when.” • “Some projects finish on time in spite of project management best practices.” • “Users don’t know what they want until they get it. Then they know what they DON’T want.”

  13. Key learnings • Successful projects have demonstrable discipline, rigour and objectivity • Link all IT projects to the IT Strategic Plan – avoid unplanned projects • Different leadership types on a project team (eg Business, IT, Academic) have different dynamics, and these need to be ‘managed’ • Engage senior management in all major projects

  14. Key learnings • There is rarely a pure ‘IT’ project • Clarify who’s driving • Be wary of resourcing assumptions • Prioritise your projects • Build in plenty of milestones and progress meetings • Avoid scope creep • Talk straight • Learn how to say “No”

  15. One Case Study – School MIS project • The case for change • Building project approval • Governance and team structure • Internal stakeholder consultation • External enquiries • The Tender • Phase 1 - evaluations • Phase 2 - presentations • Phase 3 – Selection and contract • Conversion and trial • Go live • Post implementation

  16. The case for change • 2004 • Business Office driving the call for change • Areas requiring review: • Fees & Billing • Registrations & Admissions • Foundation and OIU • School shop • Facilities • Assets

  17. Project approval • Early 2004 • Business Case presented to: • IT Committee • Finance Committee • College Council • Initial ‘rule-of-thumb’ budget approved • Project Team established • External support from industry professionals

  18. Evaluation Governance & Team Structure IT Steering Committee Project Steering Committee Ongoing Support Business Requirements Implementation Plan Price Commercial G Conlon C O’Mahony L Holden (P2) B Peatman (P2) K Corbett (P2) G Conlon C O’Mahony G Conlon C O’Mahony G Conlon K Corbett G Conlon K Corbett

  19. Stakeholder consultation • Term 1 2004 • Questionnaires to all stakeholders • Focus Group meetings • What have we got that must be retained? • What have we got that must be dumped? • What have we NOT got that we must have? • What have we NOT got that we’d like to have? • Broad email enquiries to other ADAPE members

  20. Evaluation from ADAPE members

  21. The Tender • Stakeholder consultation in Term 1 informed Requirements Specification • Clear expectations of tender respondents • Closed tender • Incumbent invited to respond

  22. Longlist to Shortlist • Make your tender document self-scoring • Use quantitative analysis to justify selection / rejection • Score each dimension • Weight each dimension • Consider price last • Remember to include items such as: • Conversion costs (export as well as import) • Customisation / configuration costs • Training costs

  23. Evaluation Phases Short-listed Suppliers Phase 1 Assessment of compliance and evaluation against evaluation criteria Phase 2 Discussions, clarification, negotiations and reference checks with short-listed Suppliers. Update evaluation. Phase 3 Finalise contract with preferred supplier, including further discussions and negotiations as appropriate Preferred Supplier Signed Contract

  24. Evaluating Proposals Evaluation Methodology Evaluation Criteria Weightings Scoring Rules Evaluating Price

  25. Evaluation Criteria & Weightings (excl. Price)

  26. Phase 1 Evaluation Results • Business Requirements • Implementation Plan • Ongoing Services • Commercial • Price

  27. Business Requirements Comparison-1

  28. Business Requirements Comparison-2

  29. Implementation Plan Comparison

  30. Ongoing Services Comparison

  31. Commercial Comparison

  32. Phase 1 Summary (excl Price)

  33. Price per Point of Value Approach • Lowest price per point of value score = highest ranked supplier • The service providers response must meet Riverview’s minimum requirements on each of the non-price evaluation criteria “Price per Point of Value” Score NPV for Supplier = Weighted Score for Supplier

  34. Financial Comparison - 1

  35. Financial Comparison - 2

  36. Narrowing the field • Vendor presentations • We drove the agenda, not the vendor • Important to use real-life scenarios / scripts • Level playing field for all presentations • No second chance • Reference site checking • Vendor recommendations • Plus our own enquiries

  37. Selection and Contract • From two down to one: • Keep #1 and #2 keen right to the very end • Contracts: • Don’t simply accept the ‘standard’ contract • Make the extra effort to ensure the contract matches your needs • Always make sure your school legal advisers review the contract

  38. Conversion and trial • If converting data from old system to new system: • Do your best to retain support from outgoing vendor. • Allocate plenty of time and resources to test the converted data. • Worth considering at least two iterations of the conversion-and-trial cycle. • Ensure robust change request procedure is in place during this phase.

  39. Go live! • November 2004 – Conversion-&-Trial #1 • January 2005 – Conversion-&-Trial #2 • March 2005 – Go Live! Train! Train! Train! Support! Support! Support!

  40. Post implementation • March 2005 was chosen for implementation as it had the least impact on our daily business. • By Term 2, we were ready to use the new system for the second billing run. • We’ve now been working with the new system for over one year. • Every month / term that goes by things get easier, smoother, more second-nature. • The old system is still available for reference, which is helping to mop up inconsistencies. • We have also been building communication channels with other schools using the system, which is helping to inform the vendor of future improvements.

  41. Other Project Applications • At Riverview, we have been using essentially the same methodology for about three years, for projects such as: • Internet Service Provision • Storage solution (SAN/DDT) • Reprographics refresh • Integrated Library Management System

  42. Useful links • There is an increasing requirement for IT Project Managers to have formal accreditation • AIPM – Australian Institute of Project Management • www.aipm.com.au • Endorsed courses: • www.aipm.com.au/html/aipm_endorsed_courses_act_nsw.cfm • Sydney University – Project Management Graduate Programme (PMGP) • www.pmgp.usyd.edu.au • PRINCE2 • http://www.ogc.gov.uk/prince2/

  43. In Conclusion • Good ICT projects must be informed by robust research and well-exercised methodology; • Good ICT projects must be continuously evaluated and reviewed; • Good ICT projects lead to improved organisational agility and effectiveness.

  44. Contact Details • Dr Christopher O’Mahony • Head – Centre for Information Technology • Saint Ignatius’ College, Riverview • Tambourine Bay Road, Riverview, NSW 2066 • Phone (02) 9882 8222 Fax (02) 9882 8588 • Web www.riverview.nsw.edu.au Email cdomahony@riverview.nsw.edu.au

More Related