Transcript Software Project Management

Pengelolaan Proyek SI
Project Success
S2 UG
1
Maintenance Phase
• Phase yang tidak menarik
• Kurang antusias
• Adanya tekanan untuk segera fix
– Untuk masalah produksi
• Software dapat menjadi over time
S2 UG
2
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
3
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
4
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
5
You are not Santa Claus
• Belajar berkata “no”
– Sopan tapi pasti
• Nilai versi
– kita akan mengambil bahwa ini phase 2
S2 UG
6
Process Spectrum
• Begitu banyak obat yang dapat membunuh pasien
Process
Spectrum
Bureauracracy
Chaos
• Balance adalah hal penting
S2 UG
7
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
8
Miscellaneous
• MBWA
– Management by Walk About
•
•
•
•
Memperlihatkan kenyataan sehari-hari
Mengenal secara individual
Berjalan spontan
Dengan cepat masalah personal diketahui
S2 UG
9
Delegate
• Jangan berkata bahwa kontrol adalah
keajaiban
• Anda harus menjadi orang terdepan tetapi
bukan segala-galanya
S2 UG
10
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
11
Continuous Process Improvement
Herbsleb, 1994, “Benefits of CMM-Based Software Process Improvement”
S2 UG
12
Tools
• Project Control Panel
S2 UG
13
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
14
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
15
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
16
Requirements
• Requirements teknik pengumpulan
–
–
–
–
–
–
–
Interviews
Document Analysis
Brainstorming
Requirements Workshops
Prototyping
Use Cases
Storyboards
S2 UG
17
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
18
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
19
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
20
Feature Set Control
•
•
•
•
•
Minimal Specification
Keperluan penggosokan
Versioned Development
Effective Change Control
Feature Cuts
S2 UG
21
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
22
Configuration Control
•
•
•
•
Items: code, documents
Change & Version control
Configuration Management Plan
Maintenance
S2 UG
23
CMM
• Capability Maturity Model
• Five levels
–
–
–
–
–
Initial
Repeatable
Defined
Managed
Optimizing
• Links: Diagram, Levels
S2 UG
24
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
25
QA & Testing
• Testing “Phases”
–
–
–
–
Unit
Integration
System
User Acceptance Testing
• Testing Types
– Black-box
– White-box
S2 UG
26
QA & Testing
•
•
•
•
Static vs. Dynamic Testing
Automated Testing
Defect tracking
Integration: 2 types
– Top down
– Bottom up
S2 UG
27
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
28
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
29
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
30
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
31
Migration
• Perencanaan migrasi
• Importance of 2-way communication
– Menemukan kata kunci
• Minimasikan gangguan
• Perencanaan mundur
• Konversi data
S2 UG
32
Migration
• Flash-Cut Migration / cepat
– Immediate Replacement
– Parallel Operation
• Staged Migration / terjadwal
S2 UG
33
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
34
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
35
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
36
karikatur
• Kejadian dengan sebuah proyek
S2 UG
37
NHS chaos exposed by new e-mails
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”.
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 lastminute 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.
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.
S2 UG
Jonathon Carr-Brown, The Sunday Times, November 13, 2005
http://www.timesonline.co.uk/article/0,,2087-1869851,00.html 38
No Change!
•We are already running late.
•I need to meet my date.
•We worked hard to prevent
change at the start.
Edwards - Customer
Granger – big cheese
Promised
date
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.
Change &
Rework
happens at
the most
expensive
time
Edwards - Customer
Granger – big cheese
Promised
date
Spec signed
off here
S2 UG
40
Change!
•Our spec was a guess
•We learn by doing the project
•We need the best product
Edwards - Customer
Granger – big cheese
Promised
date
Spec signed
off here
S2 UG
41
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
Change!
•Our spec was a guess
•We learn by doing the project
•We need the best product
This learning
causes change
Edwards - Customer
Granger – big cheese
Medium to Large projects
(1000+ function points)
experience 25 – 35%
requirements change Jones (1997) on Software
Development
Promised
date
Spec signed
off here
S2 UG
Conclusion: We can’t successfully
prevent change
42
The Project Managers Conflict:
Successful
Project
Meet
Schedule
Granger – big cheese
No
Change!
Best
Product
Change!
Edwards - Customer
Conflict*
* See my MBA dissertation “The
Project Managers Conflict”
http://www.clarkeching.com/2004/04/
my_mba_disserta.html
S2 UG
43
Who’s to blame?
-The customer?

The Project Managers Conflict: 
-The project manger?
Successful -The way we build software? 
Project
Meet
Schedule
Granger – big cheese
No
Change!
Best
Product
Change!
Edwards - Customer
Conflict*
S2 UG
44