Q7503, Summer 2002*Software Project ManagementSession 7: Risk and Change Management

Q7503, Summer 2002

Q7503, Summer 2002*TodayExam ReviewRisk ManagementFeature Set ControlChange ControlConfiguration Management

Q7503, Summer 2002

Q7503, Summer 2002*Session 6 ReviewThe examMS-ProjectA fuller, slower review next week

Q7503, Summer 2002

Q7503, Summer 2002*Exam Review1. PhasesA reference modelMany other models are just as good or valid2. Tradeoff TriangleDependency of 3 sidesDetermining which is fixed or most important to customerBalanceGive-and-takeOften choose two

Q7503, Summer 2002

Q7503, Summer 2002*Exam Review3. Project & ProgramPMI definitionTemporary endeavor undertaken to create a unique product or serviceProgram as set of related projectsNot just a continuous process, that could be manufacturing

Q7503, Summer 2002

Q7503, Summer 2002*Exam Review4. Methodology/ContextSome iterative processSpiral MethodologyRisk reductionEvolutionary PrototypingEarly, active user feedbackTradeoffsSpeed vs. AccuracyRisksUncertainty, code-and-fix, lack of scope clarity

Q7503, Summer 2002

Q7503, Summer 2002*Exam Review5. Man-MonthPeople & months are not interchangeable12 months / 2 people != 6 monthsCommunications overhead, ex: n(n-1)/2Software not like bricklayingAdding to late makes laterPouring gas on the fireAlso: Optimism, gutless estimating

Q7503, Summer 2002

Q7503, Summer 2002*Exam Review6. Requirements ImportanceWhere the real scope of project definedDefects introduced here are very costly to fix laterIssuesDeveloper-Customer conflictUncertaintyLack of supportForgotten requirements

Q7503, Summer 2002

Q7503, Summer 2002*Exam Review7. Waterfall riskNo visible product until late in processRigid phasesHeavy reliance on documentationDifficulty in identifying all requirements up front8. Pro/Con 2 other methodologiesSpiral, Prototyping, V-ModelWaterfall variations: modifiedXP, RUP, Sashimi (modified waterfall)

Q7503, Summer 2002

Q7503, Summer 2002*Exam Review9. Organizational TypesFunctional, project, matrixPros & ConsWhat it means to a PM

Q7503, Summer 2002

Q7503, Summer 2002*Ulasan Pemeriksaan10. Menetapkan krisis path + sumber penghasilanUrutan aktivitas terpanjangHasil yang menurunMasalah sumber penghasilanKonflik dan DependensiKekuatan melakukan perhitungan ulang dari pathGagal tidak dapat memasukan metode CPM

Q7503, Summer 2002

Q7503, Summer 2002*Ulasan Pemeriksaan11. Konsep eksplorasi dokumenSOWLebih detailDapat digunakan didalam kontrakProject CharterLevel peninjauan lebih luasLainnya: RFP

Q7503, Summer 2002

Q7503, Summer 2002*Ulasan Pemeriksaan12. Estimasi praktek terbaikQ12: Sumber dari beberapa kegagalan, saya meningkatkan ketenangan (dan diizinkan keluar kerja dengan Q15)Estimasi yang iteratifMengetahui teknik presentasiQ3, +/- 2 bulan, 90% kemungkinanKerusakan hirarki di aktivitas utamaTidak ada dependensi, jangka waktu

Q7503, Summer 2002

Q7503, Summer 2002*Ulasan Pemeriksaan13. Tiga tipe WBS ProsesProdukCampuranLainnya: Geografis, Organisatoris

Q7503, Summer 2002

Q7503, Summer 2002*Ulasan Pemeriksaan14. Pelacakan cepat dan sungguh-sungguhBebicara sungguh-sungguh, lebih buruk dari itu adalah3 cara diskusiMenambah sumber penghasilan, batas kebutuhan, merubah urutan tugasPelacakan cepatTumpang tindih dari aktivitas

Q7503, Summer 2002

Q7503, Summer 2002*Ulasan Pemeriksaan15. Teknik ukuran estimasiKeputusan ahliAnalogiParametrikFP, LOCDelphi

Q7503, Summer 2002

Q7503, Summer 2002*Ulasan Pemeriksaan16. DependensiPerintah: sulit, dev. sebelum QAEksternal: vendor atau clientDiscretionary: menentukan PM, mudahSumber penghasilanTidak tentu FS, SF, SS, FF

Q7503, Summer 2002

Q7503, Summer 2002*Ulasan Pemeriksaan18. Grup Proses PMIA: C, Directing is *not* one of the five19. Struktur Organisasi dan kemampuan PMA: A, Perencanaan (2nd is B, matriks kuat)20. Resiko meningkatA: C, Pelacakan cepat(tumpang tindih tugas = resiko)21. Krisis jaringan diagram pathA: D, A/B/D/F/K: 14 hari22. Penurunan hasilA: D, 5 hari

Q7503, Summer 2002

Q7503, Summer 2002*Manajemen ResikoMasalahnya bahwa tidak mempunyai namun terjadiKenapa sulit?Beberapa waspada dengan pemberitaan yang salahTidak ada orang yang ingin menjadi pengabarAtau terlihat seperti seorang yang cemasAnda dapat menentukan strategi lebih awal di proyek anda

Q7503, Summer 2002

Q7503, Summer 2002*Manajemen ResikoIdentifikasi, Analisis, KontrolTujuan: menghindari suatu krisisPerbedaan:Manajemen Resiko vs. Manajemen ProyekUntuk suatu spesifikasi vs. Semua proyekProaktif vs. reaktif

Q7503, Summer 2002

Q7503, Summer 2002*Resiko ProyekCiri-cirinya:Ketidaktentuan (0 < kemungkinan< 1)Kerugian yang terkait (uang, hidup, reputasi, dll)Dikelola beberapa tindakan dapat dikontrolPencahayaan resikoKemungkinan dari produk dan kerugian yang terkaitMasalahSebuah resiko dapat terjadi

Q7503, Summer 2002

Q7503, Summer 2002*Tipe ResikoResiko JadwalJadwal pengalihan (pelanggan, pemasaran, dll.)Resiko BiayaAnggaran yang berlebihan/keterlaluanResiko PersyaratanTidak tepatTidak lengkapTidak terangTidak konsisten

Q7503, Summer 2002

Q7503, Summer 2002*Tipe ResikoKualitas ResikoOperasional ResikoLebih dari Kesalahan klasikKesalahan klasik lebih sering dibuat

Q7503, Summer 2002

Q7503, Summer 2002*Proses Manajemen ResikoSoftware Risk Management, Boehm, 1989

Q7503, Summer 2002

Q7503, Summer 2002*Identifikasi ResikoTim anda dapat terlibat dalam proses tersebutJangan menjalankan sendiriMenghasilkan sebuah daftar dari resiko dengan mengganggu potensi jadwal proyek andaGunakan sebuah checklist atau sumber yang mirip untuk memcahkan resiko yang tepat

Q7503, Summer 2002

Q7503, Summer 2002*Analisis ResikoMenentukan dampak dari masing-masing resikoPencahayaan Resikoa.k.a. Dampak ResikoRE = kemungkinan kerugian * ukuran kerugianContoh: Resiko Fasilitas yang tidak siap tepat waktuKemungkinan adalah 25%, lamanya 4 minggu, RE 1 mingguContoh: Resiko Desain tidak memadai wajib desain ulangKemungkinan adalah 15%, lamanya 10 minggu, RE 1.5 mingguMenurut statistik mendapatkan nilai-nilai yang diharapkanDitambah semua RE untuk mendapatkan serbuan yang diharapkanYang mana adalah pra manajemen resiko

Q7503, Summer 2002

Q7503, Summer 2002*Analisis ResikoEstimasi ukuran kerugianKerugian lebih mudah dilihat dibanding kemungkinanAnda dapat berhenti kebawah sampai potong (seperti WBS)Estimating probability of lossUse team member estimates and have a risk-estimate reviewUse Delphi or group-consensus techniquesUse gambling analogy how much would you betUse adjective calibration: highly likely, probably, improbable, unlikely, highly unlikely

Q7503, Summer 2002

Q7503, Summer 2002*Risk PrioritizationRemember the 80-20 ruleOften want larger-loss risks higherOr higher probability itemsPossibly group related risksHelps identify which risks to ignoreThose at the bottom

Q7503, Summer 2002

Q7503, Summer 2002*Types of UnknownsKnown UnknownsInformation you know someone else hasUnknown UnknownsInformation that does not yet exist

Q7503, Summer 2002

Q7503, Summer 2002*Kontrol ResikoPerencanaan Manajemen ResikoDapat membuat 1 paragraph per resikoContoh dari McConnell

Q7503, Summer 2002

Q7503, Summer 2002*Risk ResolutionRisk AvoidanceDont do itScrub from systemOff-load to another partyMcConnell: design issue: have client designRisk AssumptionDont do anything about itAccept that it might occurBut still watch for it

Q7503, Summer 2002

Q7503, Summer 2002*Risk ResolutionProblem controlDevelop contingency plansAllocate extra test resourcesSee McConnell pg. 98-99Risk TransferTo another part of the project (or team)Move off the critical path at leastKnowledge AcquisitionInvestigateEx: do a prototypeBuy information or expertise about itDo research

Q7503, Summer 2002

Q7503, Summer 2002*Risk MonitoringTop 10 Risk List RankPrevious RankWeeks on ListRisk NameRisk Resolution StatusA low-overhead best practiceInterim project post-mortemsAfter various major milestonesMcConnells example

Q7503, Summer 2002

Q7503, Summer 2002*Risk CommunicationDont be afraid to convey the risksUse your judgment to balanceSky-is-falling whiner vs. information distribution

Q7503, Summer 2002

Q7503, Summer 2002*Miniature MilestonesA risk-reduction techniqueUse of small goals within project scheduleOne of McConnells Best Practices (Ch. 27)Fine-grained approach to plan & trackReduces risk of undetected project slippageProsEnhances status visibilityGood for project recoveryConsIncrease project tracking effort

Q7503, Summer 2002

Q7503, Summer 2002*Miniature MilestonesCan be used throughout the development cycleWorks with will hard-to-manage project activities or methodsSuch as with evolutionary prototypingReduces unpleasant surprisesSuccess factorsOvercoming resistance from those managedStaying true to miniature natureCan improve motivation through achievements

Q7503, Summer 2002

Q7503, Summer 2002*Miniature MilestonesRequires a detailed schedule Have early milestonesMcConnell says 1-2 daysLonger is still good (1-2 weeks)Encourages iterative developmentUse binary milestonesDone or not done (100%)

Q7503, Summer 2002

Q7503, Summer 2002*Feature-Set ControlClass mistake avoidanceEarly Stages1. Minimal Specification2. Requirements Scrubbing3. Versioned DevelopmentMid-ProjectEffective change controlLate-ProjectFeature cuts

Q7503, Summer 2002

Q7503, Summer 2002*Traditional Specs Drive for traditional specsNecessityDownstream cost avoidanceFull control over all aspectsAs McConnell notes: But the goal is not to build exactly what you said you would at the beginning. It is to build the best possible software within the available time.Idealistic but worth remembering

Q7503, Summer 2002

Q7503, Summer 2002*Minimal SpecificationThis is not XP (extreme programming)Tradition spec. issuesWasted effortToo much detailObsolescenceLack of efficacy -- details do not guarantee successOverly constrained designUser assumption that costs are equal (UI ex.)

Q7503, Summer 2002

Q7503, Summer 2002*Syarat MinimalManfaatMeningkatkan moral dan motivasiMenghemat oportunistikTahap persyaratan singkatBiaya dan resikoKelalaian merupakan kunci persyaratanJelas atau tujuan utamaHasil gemilangDigunakan untuk alasan yang salahMalas mengganti unutk melakukan peersyaratan yang baikFaktor KeberhasilanHanya digunakan ketika persyaratan telah disesuaikanMenangkap hal-hal yang penting; melibatkan orang senagai pengaman

Q7503, Summer 2002

Q7503, Summer 2002*Persyaratan terpentingMembuang ciri dari produkMenghentikan semua usaha: spesifikasi, desain, dev., tes, dokumen.Lebih cepat lebih baikTelah menyelesaikan atau sebelum perstyaratanResiko kurang dari spesifikasi minamalTujuanMenghentikan semua namun perlu persyaratan yang pastiMemudahkan semua masalah persyaratanPembelian item lebih murah

Q7503, Summer 2002

Q7503, Summer 2002*Pengembangan versiMenghentikan versi dari versi sebeumnyaMelanjutkan pengembangan versi ke 1.1Kamu akan berkata Ya, buka TidakMelanjutkan daftar revisi merubah semuanyaKesenangan saya

Q7503, Summer 2002

Q7503, Summer 2002*Ciri Proyek Pertengahan MenjalarRata-rata proyek telah dirubah 25% dari persyaratan selama pengembanganPenghasilan yang berubahPemasaran: Ingin membuat daftar pertemuan dengan pembeliPengembang: Ingin melakukan defini r1 dengan sempurnaPengguna: Ingin fungsional lebih atau mengetahui apa yang mereka inginkan sekarangMereka akan mencoba semua untuk memasukan kedalam definisi mereka

Q7503, Summer 2002

Q7503, Summer 2002*Mid-Project Feature-CreepThe devil is in the detailsMcConnells example: trivial feature can have +/- weeks of impactDevelopers can insert things when youre not lookingNo spec. can cover all details. You must.Programmer ideal: flip switch- Word -> ExcelUp to 10-1 differences in prog. size w/same specs.

Q7503, Summer 2002

Q7503, Summer 2002*Change Control Board (CCB)McConnell best practiceStructure: representatives from each stakeholder partyDev., QA, Marketing, Mgmt., Customer supportPerform change analysisImportance, priority, cost, benefitTriageAllocating scare resourcesSome will not receive treatmentLife-critical to the projectWill say No more than YesWatch for bureaucracy

Q7503, Summer 2002

Q7503, Summer 2002*Change ControlQuality Software Project Management, Futrell, Shafer, Shafer

Q7503, Summer 2002

Q7503, Summer 2002*Configuration Control A management support functionIncludesProgram code changesRequirements and design changesVersion release changesEssential for developed itemsCode, documentation, etc.ExampleThe case of the code that used to workBut didnt in time for the demo

Q7503, Summer 2002

Q7503, Summer 2002*Configuration Control TerminologySoftware Configuration Control Item (SCCI)a.k.a. Source Item (SI)Anything suitable for configuration controlSource code, documents, diagrams, etc.Change Control: process of controlling changesProposal, evaluation, approval, scheduling, implementation, trackingVersion Control: controlling software version releasesRecording and saving releasesDocumenting release differencesConfiguration Control: process of evaluating, approving and disapproving, and managing changes to SCCIs.

Q7503, Summer 2002

Q7503, Summer 2002*SCMSoftware Configuration ManagementFormal engineering disciplineMethods and tools to identify & manage software throughout its use

Q7503, Summer 2002

Q7503, Summer 2002*Configuration Control NeedsEstablish clearly defined mgmt. AuthoritySetup control standards, procedures and guidelinesAll team members must be aware of theseRequires appropriate tools and infrastructureConfiguration Management Plan must be produced during planning phaseOften part of Software Development Plan

Q7503, Summer 2002

Q7503, Summer 2002*MaintenanceSCM is very important during all phases starting with RequirementsContinues to be important during Maintenance

Q7503, Summer 2002

Q7503, Summer 2002*HomeworkMcConnell: 11 Motivation, 13 Team StructureSchwalbe: 8 Project Human Resource Management Earned Value URL: See class web siteTop 10 Risk List for your project

Q7503, Summer 2002

Q7503, Summer 2002*Questions?

Q7503, Summer 2002

**No lab todayMore lab in later term*