S2 UG 1 Pengelolaan Proyek SI Project Success. S2 UG 2 Maintenance Phase Phase yang tidak menarik Kurang antusias Adanya tekanan untuk segera fix –Untuk.

Presentasi berjudul: "S2 UG 1 Pengelolaan Proyek SI Project Success. S2 UG 2 Maintenance Phase Phase yang tidak menarik Kurang antusias Adanya tekanan untuk segera fix –Untuk."— Transcript presentasi:

1 S2 UG 1 Pengelolaan Proyek SI Project Success

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

3 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.

4 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”

5 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

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

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

8 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

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

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

11 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

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

13 S2 UG 13 Tools Project Control PanelPanel

14 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. 1 st ; grouping; ignoring

15 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)example

16 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

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

18 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

19 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

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

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

22 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)CCB –Structure, process

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

24 S2 UG 24 CMM Capability Maturity Model Five levels –Initial –Repeatable –Defined –Managed –Optimizing Links: Diagram, LevelsDiagramLevels

25 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

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

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

28 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

29 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

30 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)

31 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

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

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

34 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

35 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

36 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

37 S2 UG 37 karikatur Kejadian dengan sebuah proyek

38 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 changes and 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. Jonathon Carr-Brown, The Sunday Times, November 13, 2005 http://www.timesonline.co.uk/article/0,,2087-1869851,00.html 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.

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

40 S2 UG 40 Granger – big cheese Edwards - Customer Cost of change Promised date 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 Spec signed off here

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

42 S2 UG 42 Promised date Change! Our spec was a guess We learn by doing the project We need the best product Granger – big cheese Edwards - Customer 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 Conclusion: We can’t successfully prevent change Learning Curve Spec signed off here This learning causes change

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

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