Pengelolaan Proyek SI

1. Pengelolaan Proyek SI Project Success S2 UG

2. Maintenance Phase • Phase yang tidak menarik • Kurang antusias • Adanya tekanan untuk segera fix • Untuk masalah produksi • Software dapat menjadi over time S2 UG

3. Maintenance Phase • Membandingkan ke maintain hardware • Tidak mempertahankan kesamaan kondisi, tetapi berubah ke kondisi • Fixes dan meningkat • Kontrol konfigurasi sangat penting • Fixing the “right” version; tracking branches • Manajemen proyek tidak selalu memindahkan ke • Tim yang lebih kecil • Bukan sebuah ‘dedicated team’ • Penggambaran dari pengembang dengan penugasan utama yang lain. S2 UG

4. Maintenance Phase • Contracts, remember those? • Selalu mempertimbangkan phase maintenance disini • Sering lewat sebuah kontrak “labor hours” • waktu & materials didalam sebuah skenario “direct” • Jika tidak lewat “maintenance contract” • Percentage of software license fee • Ex: 20% of original cost per year • Corp. budget if internal/IS projects • Alokasi annual/monthly “maintenance” S2 UG

5. Success Metrics • 1. On schedule • Memerlukan : plan; estimation; control yang baik • 2. dengan budget • Again: planning, estimation & control • 3. menurut keperluan • Pentingnya keperluan yang bagus • Persepsi dan negosiasi yang bagus S2 UG

6. You are not Santa Claus • Belajar berkata “no” • Sopan tapi pasti • Nilai versi • kita akan mengambil bahwa ini phase 2 S2 UG

7. Process Spectrum • Begitu banyak obat yang dapat membunuh pasien Balance adalah hal penting S2 UG

8. Paralysis • Analysis Paralysis / Lumpuh • Over-process • Tidak pernah selesai • 65% dari software profesional mengalami hal ini • Paralysis Paranoia / kecewa berat • Fear of over-process/ rasa takut bila over-proses = process avoidance/menghindari proses S2 UG

9. Miscellaneous • MBWA • Management by Walk About • Memperlihatkan kenyataan sehari-hari • Mengenal secara individual • Berjalan spontan • Dengan cepat masalah personal diketahui S2 UG

10. Delegate • Jangan berkata bahwa kontrol adalah keajaiban • Anda harus menjadi orang terdepan tetapi bukan segala-galanya S2 UG

11. Tingkat kesuksesan • Oleh industri • Terbaik : Retail • Kontrol biaya sangat ketat • Terjelek : pemerintahan • Paling kurang untuk kontrol biaya • Ukuran • Lebih kecil lebih bagus : biaya, waktu, team • Stats S2 UG

12. Continuous Process Improvement Herbsleb, 1994, “Benefits of CMM-Based Software Process Improvement” S2 UG

13. Tools • Project Control Panel S2 UG

14. Risk Management • Manajemen resiko • Tipe resiko : schedule, cost, requirements • Identifikasi resiko • Melibatkan team • Analisa resiko • Risk Exposure (RE = Prob. * Size) • Probability is 15%, size is 10 weeks • .15 * 10w = 1.5w • Prioritas resiko • 80-20 rule; large size or prob. 1st; grouping; ignoring S2 UG

15. Risk Management • Risk Control • Plan • Risk Resolution (5 Types) • Avoidance / penghindaran (ex: scrub) • Assumption / asumsi (just monitor) • Control (contingency) • Knowledge Acquisition (learn/buy/prototype) • Transfer (off project, team, critical path) • Risk Monitoring • Top 10 Risk List (McConnell’s example) S2 UG

16. Requirements • Functional vs. Non-functional (technical) • Functional • Features / istimewa • Non-functional • Reliability / keandalan • Usability / kegunaan • Performance / unjuk kerja • Operations: systems management, installation • Other: legal, packaging, hardware S2 UG

17. Requirements • Requirements teknik pengumpulan • Interviews • Document Analysis • Brainstorming • Requirements Workshops • Prototyping • Use Cases • Storyboards S2 UG

18. Teams • Mulai dengan sasaran • Problem resolution, creativity, tactical execution • Decentralized vs. Centralized • Besarnya team • Menguraikan lewat hirarki kedalam bentuk ukuran yang optimal • Ukuran optimal ? • 4-6 developers • merekrut • Merekrut untuk spesialis – training untuk keahlian S2 UG

19. Team Models • Team bisnis • Pemimpin teknik + team; kompak • Bisa hirarki yang kuat maupun bebas • Chief-programmer team • Team kuat; • Feature team • Interdisciplinary; balanced • SWAT team • Highly skilled/specialized; Ex: security team S2 UG

20. Resource Allocation • Responsibility Assignment Matrix • Siapa dan apa • Skills Matrix • Siapa dan apa keahliannya • Hiring Guidelines / perekrutan • Hire for trait, train for skill • Smart, gets things done • Balance S2 UG

21. Feature Set Control • Minimal Specification • Keperluan penggosokan • Versioned Development • Effective Change Control • Feature Cuts S2 UG

22. Change Control • Rata-rata projek 25 % memerlukan perubahan • Sumber-sumber yang berubah • Perubahan kontrol adalah suatu proses • Spec secara detail atau phase perpanjangan keperluan tidak menjawab • Change Control Board (CCB) • Structure, process S2 UG

23. Configuration Control • Items: code, documents • Change & Version control • Configuration Management Plan • Maintenance S2 UG

24. CMM • Capability Maturity Model • Five levels • Initial • Repeatable • Defined • Managed • Optimizing • Links: Diagram, Levels S2 UG

25. Tools & Languages • Platform yang dipilih dan pilihan bahasa • Staffing requirements • Methodology • Cobol != Java • Tools and infrastructure • Software, hardware • Classic Mistake: sindrome peluru timah • Terlalu percaya / harapan pada keberuntungan alat S2 UG

26. QA & Testing • Testing “Phases” • Unit • Integration • System • User Acceptance Testing • Testing Types • Black-box • White-box S2 UG

27. QA & Testing • Static vs. Dynamic Testing • Automated Testing • Defect tracking • Integration: 2 types • Top down • Bottom up S2 UG

28. Defect Metrics • Open Bugs (outstanding defects) • Diatur dengan kekuatan • Open Rates • Berapa kerusakan baru pada sebuah periode tertentu • Close Rates • Berapa banyak menutupi pada periode yang sama • Ex: 10 bugs/hari • Change Rate • Berapa kali issue yang sama di update • Fix Failed Counts • Fixes that didn’t really fix (still open) • One measure of “vibration” in project S2 UG

29. Migration and Rollout • Migration Strategies • 1. Flash Cut / cepat • A. Immediate Replacement • B. Parallel Operation • 2. Staged / terjadwal • One part at a time S2 UG

30. Exam Review – MS-Project • Effort-driven scheduling • Duration = Work / Units (D = W/U) • Work = Duration * Units (W = D*U) • Units = Work / Duration (U = W/D) S2 UG

31. Resource Leveling • 5 Leveling techniques • Activity shifting / aktivitas penggeseran • Activity splitting / aktivitas pemecahan • Activity stretching / aktivitas meregangkan • Resource substitution / sumber penggantian • Allocating overtime / mengalokasikan kelebihan waktu S2 UG

32. Migration • Perencanaan migrasi • Importance of 2-way communication • Menemukan kata kunci • Minimasikan gangguan • Perencanaan mundur • Konversi data S2 UG

33. Migration • Flash-Cut Migration / cepat • Immediate Replacement • Parallel Operation • Staged Migration / terjadwal S2 UG

34. Other Final Steps • Roll-Out • Melepaskan daftar periksa • Training • More than just end-users • Users, systems ops, maintenance developers, sales • Documentation • Many types: End-user, sales & marketing, operations, design S2 UG

35. Project Recovery • 3 pendekatan • 1. mengurangi ukuran software • 2. menambah proses produktivitas • 3. memasukkan schedule, proceed dengan kontrol kerusakan • People Steps / langkah manusia • Morale; focus; re-assign • Process Steps / langkah proses • Kesalahan yang klasik, kejutan kecil • Product Steps / langkah produksi • Stabilize; trim features; membuang sampah S2 UG

36. Post Project Reviews • Focused on process not people • Steps • Prepare survey form • Email team with survey and schedule meeting • Gather data • Conduct meeting • Prepare PPR report S2 UG

37. karikatur • Kejadian dengan sebuah proyek S2 UG

38. NHS chaos exposed by new e-mails A COMPUTER project costing £6.2 billion that is central to Tony Blair’s National Health Service reforms is in “grave” danger of being “derailed”, leaked Whitehall e-mails reveal. The warning has been issued by Richard Granger, the £250,000-a-year civil servant in charge of what has been billed as the world’s biggest civil information technology project. The scheme is central to the government’s plans to give patients wider choice by allowing GPs to book hospital appointments online with consultants throughout the country. The problems have already caused a year-long delay in the booking system and now threaten to add millions to the cost of the project. To date the system has made only about 20,000 appointments for patients. It was supposed to have made 250,000 by December 2004. When it is fully operational the system is meant to be capable of making up to 9.5m first hospital appointments a year. In the e-mail exchanges in September, Granger blames a senior civil servant in the Department of Health for the fiasco, criticising her repeated last-minute changesand failure to heed his advice. Granger censures Margaret Edwards, the department’s director for access and patient choice, for adding numerous new specifications to the booking programme, known as Choose and Book. Granger writes: “Choose and Book’s £20m IT build contract is now in grave danger of derailing (not just destabilising) a £6.2 billion programme.” He concludes: “Unfortunately, your consistently late requests will not enable us to rescue the missed opportunities and targets.” Sir Nigel Crisp, the NHS chief executive, was forced to admit to the Commons health select committee two weeks ago that the booking system was at least a year behind schedule. However, he failed to mention that the delay was having a serious impact on the entire project. The National Audit Office has identified changes to specifications after the award of IT contracts as a key reason for regular delays and overspends on government projects. Granger’s comments were triggered by an e-mail on September 9 from Edwards marked “Restricted — Policy” which begins: “We have a problem!” The e-mail reveals that patients and their GPs still cannot book treatment at any of the country’s 32 foundation trust hospitals by computer because they are not on its “choice menu”. The 10 private sector treatment centres, set up by the government to reduce waiting lists, are also absent from the official list on the computer. Edwards warns that the treatment centres and foundation trusts will not be on the “choice menu” until next summer. The delay places hospitals at a financial disadvantage. Under the government’s payment-by-results regime, they are supposed to compete with other NHS hospitals for patients. Edwards admits: “We haven’t yet told ministers that there is a problem.” Granger was incensed by the implied criticism of the booking system and fired off a trenchant 11-point reply. Although Edwards’s original e-mail was encrypted and her password protected, Granger decrypted it, sent it out with his reply and widened the distribution. Granger complains that the project has been allowed to change beyond recognition from the original specification. “The original request from your predecessor and yourself was for an Electronic Booking System. The change of this to Choose and Book occurred in (the second quarter of) 2003. This was the first of what are now recurrent major changes in your requirements.” The booking system has been dogged with difficulties since its inception. GPs have refused to use it and early pilot schemes identified fundamental software design flaws. Last week Granger, who insists that the booking system now works, broke civil service protocol and publicly blamed policy officials in the Department of Health for failing to get GPs to use the system. In an interview with Computing Magazine, he said: “Low usage is not something I can do anything about.” Both the health department and Granger’s spokesman refused to comment on the leaked e-mails. Jonathon Carr-Brown, The Sunday Times, November 13, 2005 http://www.timesonline.co.uk/article/0,,2087-1869851,00.html S2 UG

39. No Change! • We are already running late. • I need to meet my date. • We worked hard to prevent change at the start. Cost of change Edwards - Customer Granger – big cheese Promised date S2 UG

40. No Change! • We are already running late. • I need to meet my date. • We worked hard to prevent change at the start. Change & Rework happens at the most expensive time Cost of change Edwards - Customer Granger – big cheese Promised date Spec signed off here S2 UG

41. Change! • Our spec was a guess • We learn by doing the project • We need the best product Learning Curve Edwards - Customer Granger – big cheese Promised date Spec signed off here S2 UG

42. Change! • Our spec was a guess • We learn by doing the project • We need the best product Out of hundreds of projects,there is no case in which requirements remained stable throughout the design - Reinertson (1998) on Product Development A typical software project experiences a 25% change in requirements - Boehm and Papaccio (1988) on Software Development Medium to Large projects (1000+ function points) experience 25 – 35% requirements change - Jones (1997) on Software Development Learning Curve This learning causes change Edwards - Customer Granger – big cheese Promised date Spec signed off here Conclusion: We can’t successfully prevent change S2 UG

43. Successful Project Meet Schedule Best Product No Change! Change! Conflict* * See my MBA dissertation “The Project Managers Conflict” http://www.clarkeching.com/2004/04/my_mba_disserta.html The Project Managers Conflict: Edwards - Customer Granger – big cheese S2 UG

44. Who’s to blame? • The customer? • The project manger? • The way we build software? Successful Project Meet Schedule Best Product No Change! Change! Conflict* The Project Managers Conflict: Edwards - Customer Granger – big cheese S2 UG