Anda di halaman 1dari 21

NAMA : MUHAMMAD ANDI MUBAROK

NIM : 19/447788/PEK/25089

MATAKULIAH : TECHNOLOGY & INFORMATION SYSTEM (TOM)

KELAS : EKS A 46 A

HAL : RESUME PERTEMUAN KE-6

- System Development Managing Project & Program (HRM 3


& TVW 13)

1. HRM Chapter 3, The Importance of Project Management

Proyek yang membutuhkan waktu berbulan-bulan atau bertahun-tahun untuk menyelesaikannya


biasanya dikembangkan di luar normal sistem produksi. Organisasi proyek dalam perusahaan
dapat dibentuk untuk menangani pekerjaan semacam itu dan sering dibubarkan ketika proyek
selesai. Pada kesempatan lain, manajer menemukan proyek hanya sebagian dari pekerjaan
mereka. Manajemen proyek melibatkan tiga fase :

1. Perencanaan : Fase ini mencakup penetapan tujuan, mendefinisikan proyek, dan


organisasi tim.
2. Penjadwalan : Fase ini menghubungkan orang, uang, dan persediaan dengan kegiatan dan
hubungan tertentu kegiatan satu sama lain. P
3. Pengendalian : Di sini perusahaan memantau sumber daya, biaya, kualitas, dan anggaran.
Itu juga merevisi atau mengubah rencana dan menggeser sumber daya untuk memenuhi
tuntutan waktu dan biaya.

Project Planning

Untuk perusahaan dengan banyak proyek besar, seperti perusahaan konstruksi, organisasi proyek
adalah cara yang efektif untuk menugaskan orang dan sumber daya fisik yang dibutuhkan. Ini
adalah struktur organisasi sementara yang dirancang untuk mencapai hasil dengan menggunakan
spesialis dari seluruh perusahaan. Organisasi proyek mungkin sangat membantu ketika:

1. Tugas kerja dapat didefinisikan dengan tujuan dan tenggat waktu tertentu.
2. Pekerjaan itu unik atau agak asing bagi organisasi yang ada.
3. Pekerjaan itu berisi tugas-tugas kompleks yang saling terkait yang membutuhkan
keterampilan khusus.
The Project Manager

Ethical Issues Faced in Project Management

Manajer proyek tidak hanya punya visibilitas tinggi tetapi mereka juga menghadapi keputusan
etis setiap hari. Bagaimana mereka bertindak menetapkan kode etik untuk proyek tersebut.
Manajer proyek sering berurusan dengan :

1. Penawaran hadiah dari kontraktor


2. Tekanan untuk mengubah laporan status untuk menutupi realitas keterlambatan
3. Laporan palsu untuk biaya waktu dan biaya
4. Tekanan untuk mengkompromikan kualitas untuk memenuhi bonus atau menghindari
hukuman terkait dengan jadwal.

Work Breakdown Structure

Tim manajemen proyek memulai tugasnya dengan baik sebelum pelaksanaan proyek sehingga a
rencana dapat dikembangkan. Salah satu langkah pertama adalah dengan hati-hati menetapkan
tujuan proyek, kemudian memecah proyek menjadi beberapa bagian yang dapat dikelola.
Struktur rincian kerja ini (WBS) mendefinisikan proyek dengan membaginya menjadi
subkomponen utama (atau tugas), yang kemudian dibagi lagi menjadi komponen yang lebih
rinci, dan akhirnya menjadi serangkaian kegiatan dan biaya terkait. Itu pembagian proyek
menjadi tugas yang lebih kecil dan lebih kecil bisa sulit, tetapi sangat penting untuk mengelola
proyek dan untuk menjadwalkan keberhasilan. Persyaratan kotor untuk orang, persediaan, dan
peralatan juga diperkirakan dalam fase perencanaan ini. Struktur rincian kerja biasanya
berkurang ukurannya dari atas ke bawah dan diberi indentasi seperti ini:

Tingkatan

(1) Proyek

(2) Tugas utama dalam proyek

(3) Subtugas dalam tugas utama

(4) Kegiatan (atau "paket kerja") harus diselesaikan


Project Scheduling

Untuk meringkas, apa pun pendekatan yang diambil oleh manajer proyek, penjadwalan proyek
berfungsi beberapa tujuan:

1. Menunjukkan hubungan masing-masing kegiatan dengan orang lain dan dengan seluruh
proyek.
2. Mengidentifikasi hubungan diutamakan di antara kegiatan.
3. Mendorong pengaturan perkiraan waktu dan biaya yang realistis untuk setiap kegiatan.
4. Membantu memanfaatkan orang, uang, dan sumber daya material dengan lebih baik
dengan mengidentifikasi hal-hal penting kemacetan di proyek.

Project Controlling

Kontrol proyek, seperti kontrol sistem manajemen apa pun, melibatkan pemantauan ketat sumber
daya, biaya, kualitas, dan anggaran. Kontrol juga berarti menggunakan loop umpan balik untuk
merevisi rencana proyek dan memiliki kemampuan untuk mengalihkan sumber daya ke tempat
yang mereka butuhkan paling. Laporan dan grafik PERT / CPM yang terkomputerisasi tersedia
secara luas saat ini dari skor dari perusahaan perangkat lunak yang bersaing. Beberapa yang
lebih populer dari program ini adalah Oracle Primavera (oleh Oracle), MindView (oleh Match
Ware), Proyek HP (oleh Hewlett-Packard), Jalur Cepat (oleh Perangkat Lunak MEA), dan
Microsoft Project (oleh Microsoft Corp.), yang kami ilustrasikan dalam bab ini.

Project Management Techniques: PERT and CPM

Kerangka PERT dan CPM PERT dan CPM keduanya mengikuti enam langkah dasar:

1. Tentukan proyek dan siapkan struktur rincian pekerjaan.


2. Mengembangkan hubungan antar kegiatan. Putuskan kegiatan mana yang harus didahului
dan yang harus mengikuti yang lain.
3. Gambar jaringan yang menghubungkan semua kegiatan.
4. Tetapkan perkiraan waktu dan / atau biaya untuk setiap kegiatan.
5. Hitung jalur waktu terlama melalui jaringan. Ini disebut jalur kritis.
6. Gunakan jaringan untuk membantu merencanakan, menjadwalkan, memantau, dan
mengendalikan proyek.

Network Diagrams and Approaches

Langkah pertama dalam jaringan PERT atau CPM adalah membagi seluruh proyek menjadi
kegiatan yang signifikan sesuai dengan struktur rincian pekerjaan. Ada dua pendekatan untuk
menggambar jaringan proyek: activity on node (AON) dan activity on arrow (AOA).

Activity-on-node (AON) Diagram jaringan tempat node menunjuk aktivitas.

Activity-on-arrow (AOA) Diagram jaringan tempat panah menunjuk aktivitas.


Perbedaan mendasar antara AON dan AOA adalah bahwa node dalam diagram AON mewakili
aktivitas. Dalam jaringan AOA, node mewakili waktu awal dan akhir suatu kegiatan dan juga
disebut peristiwa. Jadi node di AOA tidak memakan waktu maupun sumber daya.

Activity-on-Node Example

Ketika ada banyak kegiatan dalam proyek dengan prioritas yang cukup rumit, sulit bagi individu
untuk memahami kompleksitas proyek dari hanya informasi tabular. Dalam kasus seperti itu,
representasi visual dari proyek, menggunakan jaringan proyek, nyaman dan bermanfaat. Jaringan
proyek adalah diagram dari semua kegiatan dan hubungan diutamakan yang ada antara kegiatan
ini dalam suatu proyek. Contoh 2 menggambarkan bagaimana membangun jaringan proyek AON
untuk Milwaukee Paper Manufacturing.

Activity-on-Arrow Example

Dalam jaringan proyek AOA kita dapat mewakili aktivitas dengan panah. Node mewakili suatu
peristiwa, yang menandai waktu mulai atau selesai suatu kegiatan. Kami biasanya
mengidentifikasi suatu peristiwa (simpul) dengan angka.

Determining the Project Schedule

Setelah jaringan proyek ini telah ditarik untuk menunjukkan semua kegiatan dan hubungan
diutamakan mereka, langkah selanjutnya adalah menentukan jadwal proyek. Artinya, kita perlu
mengidentifikasi waktu mulai dan berakhir yang direncanakan untuk setiap kegiatan.

Untuk mengetahui berapa lama proyek akan berlangsung, kami melakukan analisis jalur kritis
untuk jaringan. Suatu proses yang membantu menentukan jadwal proyek.

Seperti yang disebutkan sebelumnya, jalur kritis adalah jalur waktu terpanjang melalui jaringan.
Untuk menemukan jalur kritis, kami menghitung dua waktu awal dan akhir yang berbeda untuk
setiap aktivitas. Ini didefinisikan sebagai berikut:

Awal yang paling awal (ES) = waktu paling awal di mana suatu kegiatan dapat dimulai, dengan
asumsi semua pendahulu telah selesai sehingga tidak menunda waktu penyelesaian seluruh
proyek Selesai terakhir (LF) = waktu terbaru dimana suatu kegiatan harus selesai sehingga tidak
menunda waktu penyelesaian seluruh proyek

Kami menggunakan proses dua lintasan, yang terdiri dari lintasan maju dan lintasan mundur,
untuk menentukan jadwal waktu ini untuk setiap aktivitas. Waktu mulai dan selesai awal (ES dan
EF) ditentukan selama umpan maju. Waktu mulai dan selesai yang terlambat (LS dan LF)
ditentukan selama pass mundur.
Forward Pass

Untuk menunjukkan dengan jelas jadwal kegiatan pada jaringan proyek, kami menggunakan
notasi yang ditunjukkan pada Gambar 3.9. ES dari suatu aktivitas ditampilkan di sudut kiri atas
node yang menunjukkan aktivitas itu. EF ditampilkan di sudut kanan atas. Kali terakhir, LS dan
LF, ditunjukkan masing-masing di sudut kiri bawah dan kanan bawah

Aturan Waktu Mulai Awal

Sebelum suatu kegiatan dapat dimulai, semua pendahulunya harus segera selesai:

◆ Jika suatu kegiatan hanya memiliki satu pendahulu langsung, ES-nya sama dengan EF
pendahulunya.

◆ Jika suatu kegiatan memiliki beberapa pendahulu langsung, ES-nya adalah maksimum dari
semua nilai EF pendahulunya. Yaitu: ES = Max {EF dari semua pendahulu langsung}

Aturan Waktu Selesai yang Paling Awal

Waktu selesai paling awal (EF) dari suatu kegiatan adalah jumlah dari waktu mulai yang paling
awal (ES) dan waktu aktivitasnya. Yaitu: EF = ES + Waktu aktivitas

Meskipun forward pass memungkinkan kita untuk menentukan waktu penyelesaian proyek
paling awal, itu tidak mengidentifikasi jalur kritis. Untuk mengidentifikasi jalur ini, kita sekarang
perlu melakukan backward pass untuk menentukan nilai LS dan LF untuk semua kegiatan.

Backward Pass

Sama seperti pass maju dimulai dengan aktivitas pertama dalam proyek, pass mundur dimulai
dengan aktivitas terakhir dalam proyek. Untuk setiap aktivitas, pertama-tama kita menentukan
nilai LF-nya, diikuti oleh nilai LS-nya. Dua aturan berikut digunakan dalam proses ini.

Aturan Waktu Selesai Terbaru Aturan ini sekali lagi didasarkan pada fakta bahwa sebelum suatu
kegiatan dapat dimulai, semua pendahulunya harus diselesaikan:

◆ Jika suatu kegiatan adalah pendahulu langsung untuk hanya satu aktivitas, LF-nya sama
dengan LS dari aktivitas yang segera mengikutinya.

◆ Jika suatu kegiatan merupakan pendahulu langsung untuk lebih dari satu kegiatan, LF-nya
adalah minimum dari semua nilai LS dari semua kegiatan yang segera mengikutinya. Itu adalah:

LF = Min {LS dari semua kegiatan berikut yang segera}


Aturan Waktu Mulai Terbaru Waktu mulai terbaru (LS) dari suatu aktivitas adalah perbedaan
waktu selesai terakhir (LF) dan waktu aktivitasnya. Itu adalah:

LS = LF - Waktu aktivitas

Menghitung Waktu Kendur dan Mengidentifikasi Jalur Kritis

Setelah kami menghitung waktu paling awal dan terbaru untuk semua aktivitas, adalah masalah
sederhana untuk menemukan jumlah waktu luang yang dimiliki setiap aktivitas. Slack adalah
lamanya waktu suatu kegiatan dapat ditunda tanpa menunda seluruh proyek. Secara matematis:

Slack = LS - ES atau Slack = LF – EF

Aktivitas dengan zero slack disebut aktivitas kritis dan dikatakan berada di jalur kritis. Jalur
kritis adalah jalur berkelanjutan melalui jaringan proyek yang:

◆ Mulai pada aktivitas pertama dalam proyek (Mulai dalam contoh kami).

◆ Berakhir pada aktivitas terakhir dalam proyek (H dalam contoh kita).

◆ Hanya mencakup aktivitas penting (mis., Aktivitas tanpa waktu sepi).

Total Slack Time Lihat lagi di jaringan proyek pada Overlay 3 pada Gambar 3.10.
Pertimbangkan kegiatan B dan D, yang masing-masing kendur 1 minggu. Apakah itu berarti
bahwa kita dapat menunda setiap kegiatan dengan 1 minggu, dan masih menyelesaikan proyek
dalam 15 minggu? Jawabannya adalah tidak.

Mari kita asumsikan bahwa aktivitas B tertunda selama 1 minggu. Ini telah menghabiskan slack-
nya selama 1 minggu dan sekarang memiliki EF dari 4. Ini menyiratkan bahwa aktivitas D
sekarang memiliki ES dari 4 dan EF dari 8. Perhatikan bahwa ini juga merupakan nilai LS dan
LF masing-masing. Artinya, aktivitas D juga tidak memiliki waktu kendur sekarang. Pada
dasarnya, kelonggaran 1 minggu yang dimiliki aktivitas B dan D adalah, untuk jalur itu, dibagi di
antara mereka. Menunda salah satu aktivitas dalam 1 minggu tidak hanya menyebabkan aktivitas
itu, tetapi juga aktivitas lainnya, menjadi kendur. Jenis waktu kendur ini disebut sebagai jumlah
kendur. Biasanya, ketika dua atau lebih kegiatan non-kritis muncul berturut-turut di jalur, mereka
berbagi total kendur.

Variabilitas dalam Waktu Aktivitas

Dalam mengidentifikasi semua waktu awal dan terbaru sejauh ini, dan jalur kritis terkait, kami
telah mengadopsi pendekatan CPM dengan mengasumsikan bahwa semua waktu aktivitas
diketahui dan tetap konstan. Artinya, tidak ada variasi dalam waktu aktivitas. Namun, dalam
praktiknya, kemungkinan waktu penyelesaian aktivitas bervariasi tergantung pada berbagai
faktor.
Misalnya, membangun komponen internal (aktivitas A) untuk Milwaukee Paper Manufacturing
diperkirakan selesai dalam 2 minggu. Jelas, masalah rantai pasokan seperti keterlambatan
kedatangan bahan, tidak adanya personel kunci, dan sebagainya dapat menunda kegiatan ini.
Misalkan aktivitas A sebenarnya berakhir memakan waktu 3 minggu. Karena A berada di jalur
kritis, seluruh proyek sekarang akan ditunda 1 minggu hingga 16 minggu. Jika kami
mengantisipasi penyelesaian proyek ini dalam 15 minggu, kami jelas akan melewatkan tenggat
Hari Bumi kami.

Meskipun beberapa kegiatan mungkin relatif kurang rentan terhadap keterlambatan, yang lain
mungkin sangat rentan terhadap keterlambatan. Misalnya, aktivitas B (modifikasi atap dan
lantai) bisa sangat tergantung pada kondisi cuaca. Mantra cuaca buruk dapat secara signifikan
mempengaruhi waktu penyelesaiannya.

Ini berarti bahwa kita tidak dapat mengabaikan dampak variabilitas dalam waktu aktivitas ketika
memutuskan jadwal untuk suatu proyek. PERT membahas masalah ini.

Tiga Perkiraan Waktu dalam PERT

Dalam PERT, kami menggunakan distribusi probabilitas berdasarkan tiga perkiraan waktu untuk
setiap aktivitas, sebagai berikut:

Waktu optimis (a) = waktu yang akan diambil suatu kegiatan jika semuanya berjalan sesuai
rencana. Dalam memperkirakan nilai ini, seharusnya hanya ada probabilitas kecil (katakanlah,
1/100) bahwa waktu aktivitas akan menjadi <a.

Waktu pesimis (b) = waktu suatu kegiatan akan mengambil asumsi kondisi yang sangat tidak
menguntungkan. Dalam memperkirakan nilai ini, seharusnya juga hanya ada probabilitas kecil
(juga 1/100) bahwa waktu aktivitas akan> b.

Kemungkinan besar waktu (m) = perkiraan paling realistis dari waktu yang diperlukan untuk
menyelesaikan suatu kegiatan.

Saat menggunakan PERT, kami sering menganggap bahwa estimasi waktu aktivitas mengikuti
distribusi probabilitas beta (lihat Gambar 3.11). Distribusi berkelanjutan ini sering tepat untuk
menentukan nilai yang diharapkan dan varians untuk waktu penyelesaian kegiatan.

Artinya, waktu yang paling mungkin (m) diberikan empat kali berat sebagai waktu optimis (a)
dan waktu pesimistis (b). Taksiran waktu yang dihitung dengan menggunakan Persamaan (3-6)
untuk setiap aktivitas digunakan dalam jaringan proyek untuk menghitung semua waktu yang
paling awal dan yang terbaru.

Untuk menghitung dispersi atau variasi waktu penyelesaian aktivitas, kami menggunakan rumus:

Varians = [(b - a) ∕ 6]2


Kemungkinan Penyelesaian Proyek

Analisis jalur kritis membantu kami menentukan bahwa waktu penyelesaian proyek yang
diharapkan Milwaukee Paper adalah 15 minggu. Julie Ann Williams tahu, bagaimanapun, bahwa
ada variasi yang signifikan dalam perkiraan waktu untuk beberapa kegiatan. Variasi dalam
aktivitas yang berada di jalur kritis dapat memengaruhi waktu penyelesaian proyek secara
keseluruhan — mungkin menundanya. Ini adalah satu kejadian yang sangat mengkhawatirkan
manajer instalasi.

PERT menggunakan varians dari aktivitas jalur kritis untuk membantu menentukan varians dari
keseluruhan proyek.

Menentukan Waktu Penyelesaian Proyek untuk Tingkat Kepercayaan Yang Diberikan

Mari katakanlah Julie Ann Williams khawatir bahwa hanya ada 71,57% kemungkinan
pengendalian polusi peralatan dapat ditempatkan dalam 16 minggu atau kurang. Dia berpikir
mungkin memohon dengan dewan direksi untuk lebih banyak waktu. Namun, sebelum dia
mendekati papan, dia ingin mempersenjatai diri dengan informasi yang cukup tentang proyek
tersebut. Secara khusus, dia ingin temukan tenggat waktu di mana ia memiliki peluang 99%
untuk menyelesaikan proyek.

Dia berharap bisa menggunakannya analisisnya untuk meyakinkan dewan untuk menyetujui
tenggat waktu yang diperpanjang ini, meskipun dia sadar dari kerusakan hubungan masyarakat
keterlambatan akan menyebabkan. Jelas, tanggal jatuh tempo ini akan lebih dari 16 minggu.
Namun, berapa nilai tepatnya tanggal jatuh tempo baru ini? Untuk menjawab pertanyaan ini, kita
kembali menggunakan asumsi bahwa Milwaukee Waktu penyelesaian proyek kertas mengikuti
distribusi probabilitas normal dengan rata-rata 15 minggu dan standar deviasi 1,76 minggu.

Variabilitas dalam Waktu Penyelesaian dari Jalur Non-kritis

Dalam diskusi kami sejauh ini, kami telah memfokuskan secara eksklusif pada variabilitas dalam
waktu penyelesaian kegiatan pada yang kritis jalan. Ini tampaknya logis karena kegiatan ini,
menurut definisi, adalah kegiatan yang lebih penting dalam jaringan proyek. Namun, ketika ada
variasi dalam waktu aktivitas, itu penting bahwa kami juga menyelidiki variabilitas dalam waktu
penyelesaian kegiatan di jalur nonkritis.

Pertukaran Biaya Waktu dan Penghancuran Proyek

Saat mengelola suatu proyek, tidak jarang seorang manajer proyek juga dihadapkan dengan hal
itu (atau keduanya) dari situasi berikut: (1) proyek terlambat, dan (2) dijadwalkan waktu
penyelesaian proyek telah dipindahkan ke depan. Dalam situasi apa pun, sebagian atau semua
kegiatan yang tersisa perlu dipercepat (biasanya dengan menambahkan sumber daya) untuk
menyelesaikan proyek dengan tanggal jatuh tempo yang diinginkan. Proses dimana kami
mempersingkat durasi proyek di cara termurah yang mungkin disebut crash proyek.
CPM adalah teknik di mana setiap aktivitas memiliki waktu normal atau standar yang kami
gunakan di kami perhitungan. Terkait dengan waktu normal ini adalah biaya normal aktivitas.
Namun, waktu lain dalam manajemen proyek adalah waktu mogok, yang didefinisikan sebagai
durasi terpendek diperlukan untuk menyelesaikan suatu kegiatan. Terkait dengan waktu
kerusakan ini adalah biaya kerusakan aktivitas. Biasanya, kami dapat mempersingkat aktivitas
dengan menambahkan sumber daya tambahan (mis., Peralatan, orang) ke dalamnya. Oleh karena
itu, logis untuk biaya kecelakaan suatu kegiatan lebih tinggi dari biaya normalnya.

Jumlah di mana suatu kegiatan dapat dipersingkat (yaitu, perbedaan antara normalnya waktu dan
waktu mogok) tergantung pada aktivitas yang dimaksud. Kami mungkin tidak dapat
mempersingkat beberapa kegiatan sama sekali. Misalnya, jika casting perlu dipanaskan di tungku
selama 48 jam, menambah lebih banyak sumber daya tidak membantu mempersingkat waktu.
Sebaliknya, kita mungkin bisa mempersingkat beberapa kegiatan secara signifikan (mis.,
membingkai rumah dalam 3 hari, bukan 10 hari dengan menggunakan tiga sebanyak pekerja).

Demikian juga, biaya menabrak (atau memperpendek) suatu kegiatan tergantung pada sifat dari
kegiatan tersebut. Manajer biasanya tertarik untuk mempercepat proyek dengan biaya tambahan
setidaknya. Karenanya, saat memilih kegiatan mana yang akan mogok, dan seberapa banyak, kita
perlu memastikan hal-hal berikut:

◆ Jumlah di mana suatu kegiatan terhenti, pada kenyataannya, diizinkan

◆ Secara bersamaan, durasi aktivitas yang diperpendek akan memungkinkan kami untuk
menyelesaikan proyek dengan

batas waktu

◆ Biaya total kecelakaan adalah sekecil mungkin

Kritik terhadap PERT dan CPM

Sebagai kritik terhadap diskusi kami tentang PERT, berikut adalah beberapa fiturnya tentang
operasi mana manajer harus sadar:

1. Sangat berguna saat menjadwalkan dan mengendalikan proyek-proyek besar.

2. Konsep sederhana dan tidak rumit secara matematis.

3. Jaringan grafis membantu menyoroti hubungan antara kegiatan proyek.

4. Analisis jalur kritis dan waktu sepi membantu menunjukkan aktivitas yang perlu dilakukan
secara cermat

menyaksikan.
5. Dokumentasi dan grafik proyek menunjukkan siapa yang bertanggung jawab untuk berbagai
kegiatan.

6. Berlaku untuk berbagai proyek.

7. Berguna dalam memantau tidak hanya jadwal tetapi juga biaya

2. TVW, Chapter 13: Project Mangement & SDLC

Ketika sebagian besar perusahaan mengembangkan atau membangun produk, layanan, pasar,
sistem perusahaan, atau aplikasi baru, mereka menggunakan pendekatan manajemen proyek.
Manajemen proyek adalah metodologi terstruktur untuk merencanakan, mengelola, dan
mengendalikan penyelesaian suatu proyek sepanjang siklus hidupnya.

Proyek adalah serangkaian tugas berurutan yang direncanakan dengan baik untuk mencapai
hasil. Proyek memiliki awal dan akhir yang jelas, ruang lingkup, sumber daya, dan anggaran.
Proyek disetujui sebelum didanai dan dialokasikan sumber daya.

Postmortem adalah metode untuk mengevaluasi kinerja proyek, mengidentifikasi pelajaran yang
dipetik, dan membuat rekomendasi untuk proyek masa depan

OPENING CASE : Keeping Your Project on Track, Knowing When It Is Doomed, and DIA
Baggage System Failure

Suatu proyek yang sedang berjalan dapat mengalami satu atau lebih dari hasil berikut:

- Melebihi anggaran
- Terkirim terlambat
- Diluncurkan dengan lebih sedikit fitur atau fungsi dari yang direncanakan
- Dihentikan sebelum selesai
- Selesai, tetapi gagal

Berikut adalah tiga pelajaran yang dipetik untuk menjaga proyek tetap pada jalurnya :

1. Set Realistic and Detailed Project Plans With Adequate Time and Resources, menetapkan
rencana proyek yang realistis dan detail dengan waktu dan sumber daya yang memadai
2. Encourage Timely Feedback and Be Willing to Listen, pastikan karyawan tahu bahwa
mereka tidak akan dihukum karena menyampaikan kekhawatiran, bahkan jika anggota
proyek lain menyangkal ada masalah. Ketakutan menghalangi aliran informasi yang
berguna.
3. Manage Risk with Regular Project Status Reviews, untuk sebagian besar, tidak ada yang
suka ulasan proyek formal, tetapi mereka diperlukan untuk mengidentifikasi dan
mengatasi masalah saat ini,

Berikut adalah daftar tanda merah yang menunjukkan masalah proyek IT. Bendera merah ini
berkaitan dengan perencanaan yang buruk — dan tidak bergantung pada umpan balik dari
anggota tim:

1. Project Has Launched Without Senior Buy-In, Proyek telah diluncurkan tanpa dukungan
dari senior. Situasi ini dapat terjadi jika kepribadian yang kuat di perusahaan memiliki ide
hebat dan mulai merencanakan pertemuan dan mengalokasikan sumber daya tanpa
menunggu keterlibatan manajemen senior.
2. No Detailed Project Plan Exists, Tidak Ada Rencana Proyek Detil

Setiap proyek dengan perkiraan durasi lebih dari dua atau tiga minggu memerlukan rencana
proyek rasional yang terperinci.

1. Meetings Are Scheduled Ignoring Team Members’ Availability, Ketersediaan Anggota


Tim yang bertentangan dengan pertemuan penting berarti bahwa anggota tim yang vital
tidak hadir, akan mengurangi efektivitas pertemuan tersebut.
2. Users Have Had Little or No Early Involvement, Pengguna Memiliki Sedikit atau Tidak
Ada Keterlibatan. Semakin banyak keterlibatan Anda dari user, semakin besar peluang
Anda untuk sukses. Jika proyek Anda mencakup banyak departemen, pastikan untuk
memiliki perwakilan user dari masing-masing departemen.
3. No Detailed Testing Plan Exists, Tidak Ada Rencana Pengujian Detail

Pengujian sangat penting untuk keberhasilan proyek. Pengujian unit menguji satu sisi sistem;
pengujian terintegrasi menguji semua komponen dan antarmuka pengguna.

1. No Training Budget, Tidak Ada Anggaran Pelatihan

Ketika terjadi kelebihan anggaran, anggaran untuk pelatihan seringkali dikorbankan. Bersiaplah
untuk menunda proyek jika pelatihan yang tepat tidak diberikan.

BAGGAGE HANDLING SYSTEM PROJECT AT DENVER INTERNATIONAL AIRPORT

Kasus klasik yang digunakan untuk menggambarkan bencana proyek adalah proyek sistem
penanganan bagasi (Gambar 13.2) untuk Bandara Internasional Denver (DIA) yang baru. Proyek
ini adalah untuk menciptakan penanganan otomatis terotomatisasi paling canggih,
mengintegrasikan ketiga concourses ke dalam satu sistem. Istilah "paling canggih, otomatis, dan
terintegrasi" dengan jelas menunjukkan bahwa sistem akan menjadi sangat kompleks, berisiko,
dan mengalami penundaan. Jadwal yang tidak realistis direncanakan dan disetujui meskipun
penundaan apa pun juga akan memaksa penundaan pembukaan DIA. Faktanya, DIA yang baru
selesai tetap menganggur selama 16 bulan sementara para insinyur menangani kompleksitas
sistem bagasi. Penundaan itu menambah $ 560 juta untuk biaya DIA. Biaya untuk
mempertahankan bandara yang kosong dan biaya bunga atas pinjaman konstruksi menelan biaya
$ 1,1 juta untuk kota Denver selama penundaan.

Project Scaled Down; Scrapped a Decade Later,

Proyek ini diperkecil dari rencana semula. Hanya penanganan bagasi pada penerbangan keluar
untuk satu concourse yang otomatis. Bagasi ke / dari concourses lain ditangani menggunakan
sistem tug-and-troli manual yang dibangun dengan cepat ketika para pemain kunci akhirnya
mengakui bahwa sistem otomatis tidak akan pernah mencapai tujuannya. Sepuluh tahun
kemudian, pada bulan Agustus 2005, sistem otomatis dihapuskan karena masih tidak berfungsi
dengan benar dan biaya perawatannya $ 1 juta per bulan.

Project Management Mistakes

Sistem penanganan bagasi DIA adalah komponen penting dalam rencana kota Denver untuk
membangun bandara mutakhir yang akan memposisikan Denver sebagai pusat transportasi
udara. Dengan mengotomatiskan penanganan bagasi, waktu perputaran pesawat akan dikurangi
hingga 30 menit. Perputaran yang lebih cepat berarti maskapai penerbangan dapat
meminimalkan waktu darat, yang akan menjadi keunggulan kompetitif DIA. Di bawah ini adalah
timeline kejadian utama dan kesalahan manajemen proyek:

- November 1989: pekerjaan konstruksi DIA dimulai.Ignored Expert, Ahli yang


diabaikan. Pada tahun 1990, Kota Denver menyewa Breier Neidle Patrone Associates
untuk melakukan analisis kelayakan membangun sistem bagasi terintegrasi. Laporan
menyarankan bahwa kompleksitas membuat proyek tidak layak.
- Musim panas 1991: Tim manajemen proyek DIA meminta penawaran untuk sistem
penanganan bagasi otomatis.
- Underestimated complexity, Kompleksitas yang diremehkan. Musim Gugur 1991:
Dari 16 perusahaan yang termasuk dalam proses penawaran, hanya 3 yang
merespons. Tidak ada yang bisa menyelesaikan proyek tepat waktu untuk
pembukaan Oktober 1993.
- Poor planning and impossible expectations, Perencanaan yang buruk dan harapan
yang tidak mungkin. Pada bulan April 1992, DIA pergi ke kontrak dengan BAE
Systems untuk menyelesaikan proyek tepat waktu untuk pembukaan Oktober 1993 -
mengabaikan bukti ahli bahwa timeline tidak mungkin untuk dicapai.
- Lack of due diligence, Kurangnya uji tuntas. Ketentuan kontrak antara DIA dan BAE
dan spesifikasi proyek diselesaikan hanya dalam tiga pertemuan. Terburu-buru untuk
kontrak mengabaikan analisis kelayakan.
- Excluded key stakeholders, Pemangku kepentingan utama yang dikecualikan. BAE
dan tim manajemen proyek bandara mengecualikan pemangku kepentingan utama —
maskapai penerbangan yang telah menandatangani kontrak dengan DIA — selama
negosiasi
- Scope creep, 1992-1993: Sejumlah perubahan dalam lingkup proyek dibuat. Sebagai
contoh, Continental Airlines meminta fasilitas penanganan peralatan ski ditambahkan
ke ruang kerjanya.
- Ignored interface design, Sistem penanganan bagasi harus terhubung dengan
bandara. Yaitu, karena desain bangunan dimulai sebelum desain sistem bagasi
diketahui, perancang bangunan fisik hanya memberikan kelonggaran umum ke mana
mereka pikir sistem bagasi akan pergi.

Kasus ini mewakili setiap kesalahan manajemen proyek yang mungkin terjadi. Sejak awal,
keputusan untuk melanjutkan dengan sistem terintegrasi tunggal di DIA mengetahui bahwa
tenggat waktu tidak dapat dipenuhi dan keputusan irasional yang diikuti oleh orang-orang yang
tidak memiliki manajemen proyek dan keahlian teknik yang diperlukan berkontribusi pada
kegagalan proyek.

PROJECT MANAGEMENT CONCEPTS

Perusahaan menghadapi tantangan dalam memutuskan investasi mana yang akan dibuat dan
bagaimana mengalokasikan sumber daya yang langka untuk proyek-proyek yang bersaing.
Biasanya manajer senior menyusun kasus bisnis yang mengidentifikasi peluang, masalah, atau
kebutuhan dan hasil bisnis yang diinginkan dari proyek. Karena tidak semua proyek layak dan
tidak semua proyek dapat didanai, kasus bisnis ditinjau. Dalam proses peninjauan, proyek
bersaing untuk mendapatkan persetujuan dan pendanaan.

PPM (Project Portfolio Management) menetapkan jalur dari konsep melalui penyelesaian proyek
yang berhasil. Tanpa data yang diperlukan, manajemen tidak mampu membuat keputusan
berdasarkan informasi untuk menyetujui proyek baru yang "benar" dan menutup proyek tanpa
harapan untuk sukses:

• Memetakan proyek yang diusulkan ke strategi organisasi

• Menilai nilai yang dibawa proyek yang diusulkan kepada perusahaan

• Menilai kompleksitas proyek yang diusulkan

• Prioritaskan proposal proyek untuk pemilihan proyek

Sebuah proyek adalah serangkaian tugas untuk menghasilkan satu atau lebih hasil. Hasil kerja
adalah barang yang diberikan kepada klien atau manajemen untuk ditinjau dan disetujui dan
harus diproduksi untuk menyelesaikan proyek atau bagian dari proyek. Proyek memiliki tanggal
mulai dan tanggal selesai yang menentukan yang menentukan durasi, ruang lingkup, sumber
daya, dan anggaran proyek.

The Triple Constraint

1. Scope adalah Lingkup proyek adalah definisi dari apa yang seharusnya dicapai oleh
proyek — hasil atau hasil proyek. Lingkup diukur dari ukuran, tujuan, dan persyaratan
proyek
2. Time adalah durasi proyek meluas dari tanggal mulai tugas pertama hingga tanggal
selesai tugas terakhir.
3. Cost adalah perkiraan jumlah uang yang akan dibutuhkan untuk menyelesaikan proyek.
Biaya itu sendiri meliputi berbagai hal, seperti sumber daya, tingkat tenaga kerja untuk
kontraktor, perkiraan risiko, dan tagihan bahan, dan lain-lain. Semua aspek proyek yang
memiliki komponen moneter dibuat bagian dari struktur biaya keseluruhan. Proyek
disetujui dengan biaya mereka.

Scope Creep

Selama proyek, hampir dijamin bahwa permintaan akan dibuat yang mengubah ruang lingkup.
Cakupan creep mengacu pada pertumbuhan proyek, yang mungkin tampak tidak penting —
setidaknya bagi orang yang meminta perubahan itu. Cakupan creep adalah penumpukan
perubahan kecil yang dengan sendirinya dapat dikelola tetapi secara agregat signifikan.

Manajer proyek perlu menegosiasikan ulang durasi dan anggaran proyek untuk fungsionalitas
tambahan, pengujian, dan pelatihan pengguna, memastikan bahwa setiap perubahan yang
diminta, sekecil apa pun, didokumentasikan dan disertai dengan persetujuan. Pendekatan standar
untuk mengelola proyek memberikan manfaat berikut:

• Ini menetapkan aturan dasar dan harapan untuk tim proyek.

• Ini menyediakan manajer proyek, manajer fungsional, dan staf operasional dengan bahasa
umum yang memudahkan komunikasi dan membantu memastikan bahwa semua orang ada di
halaman yang sama.

• Manajer dapat dengan cepat menentukan mana yang berjalan dengan lancar dan mana yang
tidak ketika semua proyek mengikuti proses dan pendekatan yang sama dan menggunakan
metrik yang sama untuk mengukur kinerja proyek.
Project Planning, Execution, and Budget

Proyek dimulai dengan sebuah ide yang dijelaskan dalam kasus bisnis. Jika kasus bisnis
diterima, pernyataan kerja (SOW - statement of work) disiapkan. SOW ditulis sebagai
pernyataan definitif, yang berarti ia mendefinisikan rencana proyek tetapi tidak menawarkan opsi
atau alternatif dalam ruang lingkup. Proyek rencana dalam SOW ditinjau, keputusan go atau no-
go dibuat, jika keputusan go dibuat, proyek dimulai.

PROJECT BUSINESS CASE

Manajer proyek, eksekutif senior, atau sponsor menyiapkan kasus bisnis yang meyakinkan untuk
dipertimbangkan. Berikut adalah contoh komponen dari kasus bisnis.

STATEMENT OF WORK

Garis besar SOW ditunjukkan pada Tabel 13.2. SOW adalah kontrak hukum yang digunakan
untuk mendokumentasikan perjanjian antara para pihak setelah persyaratan bisnis yang berlaku
diterima dan keputusan go dibuat. Keputusan go / no-go adalah keputusan formal yang dibuat
oleh manajer proyek, sponsor, dan eksekutif serta pemangku kepentingan yang tepat

WORK BREAKDOWN STRUCTURE

Setelah tujuan dan ruang lingkup proyek telah ditentukan, langkah selanjutnya adalah
mengidentifikasi semua pekerjaan atau kegiatan yang perlu dilakukan, jadwal kerja, dan siapa
yang akan melakukan pekerjaan. Ini dilakukan dengan membuat struktur rincian kerja (WBS -
work breakdown structure) seperti yang ditunjukkan pada Gambar 13.5. Gambar 13.6
menunjukkan tangkapan layar WBS (kiri sisi) dikembangkan menggunakan Microsoft Project.
Sumber daya proyek dikelola sesuai ke WBS.

Milestones

WBS memecah proyek menjadi tugas atau kegiatan yang harus dilakukan dan urutannya
bagaimana, untuk menghasilkan hasil pada setiap milestone. Milestone adalah perangkat
penjadwalan dan status yang sangat penting karena memungkinkan proyek manajer untuk
mengukur kemajuan ketika proyek berlanjut melalui siklus hidup yang direncanakan. Kurangnya
milestone telah menjadi faktor penyebab banyak kegagalan proyek. Setiap milestone biasanya
merupakan hasil kerja (100 persen selesai), tetapi mungkin juga menandakan persen selesai,
seperti 50 persen selesai.

Milestone Example

Asumsikan Anda adalah manajer proyek untuk klien yang ingin memposting proyek kreatif di
Kickstarter.com untuk mengumpulkan dana menggunakan crowdfunding. Kamu mengunjungi
Kickstarter.com dan lakukan analisis persyaratan. Anda menentukan bahwa Anda perlu
melakukannya menghasilkan lima hasil: (1) video, (2) satu set foto dan ilustrasi, (3) sebuah skrip
yang menjelaskan mengapa proyek kreatif layak mendapatkan dana, (4) seperangkat janji
kategori dan hadiah untuk pendukung, dan (5) situs terakhir dengan semua hasil diunggah ke
Kickstarter.com dan diuji. Setiap hasil kerja merupakan milestone dalam rencana proyek Anda.
Anda kemudian bergantung pada jadwal milestone Anda untuk memverifikasi itu proyek berada
di jalurnya atau untuk memperingatkan perlunya tindakan korektif. Milestone harus alami, titik
kontrol penting dalam proyek dan mudah untuk semua orang untuk mengenali.

Cost Estimations

Meskipun biaya bukan bagian dari WBS, perkiraan biaya proyek dapat dihitung dari WBS.
Setiap tugas atau kegiatan memiliki tanggal dan durasi mulai, yang menentukan tanggal selesai.
Misalnya, jika tugas dimulai pada hari Senin, 2 November, dan memakan waktu delapan hari
kerja (tidak termasuk hari akhir pekan) untuk menyelesaikan, tanggal selesai adalah Rabu, 11
November. Asumsikan sumber daya — manusia, peralatan, dan bahan — dibutuhkan untuk
menyelesaikan tugas dan biayanya diketahui. Perangkat lunak manajemen proyek menghitung
biaya proyek berdasarkan waktu kerja (durasi) dari setiap tugas di WBS dan biaya tenaga kerja
atau sumber daya lainnya.

Responsibility Matrix

Matriks tanggung jawab menunjukkan siapa yang memiliki tanggung jawab utama dan siapa
yang memiliki dukungan tanggung jawab untuk kegiatan yang tercantum dalam WBS. Tabel
13.3 adalah contoh dari sebuah matriks tanggung jawab.

Gantt Chart

Gantt chart adalah diagram batang yang menunjukkan garis waktu dari jadwal proyek, sebagai
ditunjukkan di sebelah kanan Gambar 13.6. Pada bagan Gantt, tanggal mulai dan selesai dari
semua tugas dan milestone muncul sebagai bilah yang panjangnya mewakili durasinya. Gantt
bagan adalah alat visualisasi multiguna yang digunakan untuk perencanaan, penjadwalan dan
sekilas laporan status.
Project Baseline

Ketika rencana proyek diselesaikan dan diterima, rencana yang diterima menjadi baseline, atau
master plan. Baseline digunakan untuk memonitor dan mengendalikan. Apa saja perubahan pada
baseline adalah penyimpangan, atau varian, ke rencana — dan itu perlu didokumentasikan.
Menggunakan perangkat lunak manajemen proyek, Anda dapat menyimpan WBS sebagai
baseline. Sejak saat itu, penyimpangan akan secara otomatis didokumentasikan sebagai varian
dari baseline, seperti yang ditunjukkan pada Gambar 13.7.

Pemantauan, Kontrol, dan Penutupan Proyek

Proses pemantauan dan kontrol dilakukan secara terus-menerus. Proses-proses ini, dijelaskan
pada Gambar 13.8, Output dari setiap proses terus memberi tahu tim proyek tentang status
proyek dan membantu mengatasi tantangan yang dihadapi.

Kunjungan langsung, laporan, dan catatan juga merupakan metode pemantauan. Kontrol proyek
tergantung pada sistem dan aturan keputusan untuk mengelola varians antara ruang lingkup
proyek, biaya, jadwal, dan kualitas dan realitas implementasi proyek.

KONTROL PERUBAHAN TERPADU

Perubahan cenderung memiliki efek tetesan turun karena ketergantungan tugas dan sumber daya
bersama. Proses kontrol perubahan terpadu membantu mengelola gangguan yang dihasilkan dari
perubahan yang diminta dan tindakan korektif di seluruh siklus hidup proyek. Proses kontrol
perubahan terpadu selalu didokumentasikan dan disimpan jika terjadi kegagalan proyek atau
tuntutan hukum terkait dengan kegagalan tersebut. Dokumen-dokumen ini diperlukan untuk
mempertahankan keputusan, seperti :

• Permintaan perubahan yang disetujui

• Menolak permintaan perubahan

• Pembaruan pada rencana proyek

• Pembaruan untuk ruang lingkup

• Tindakan korektif dan preventif yang disetujui

• Perbaikan cacat yang disetujui

• Perbaikan cacat yang divalidasi


Critical Path

Semua proyek memiliki jalur kritis yang memperpanjang masa proyek dimana tugas atau
aktifitasnya disebut aktifitas kritis.. Perangkat lunak manajemen proyek menunjukkan jalur kritis
pada Gantt chart, seperti pada Gambar 13.9.

Walaupun mungkin tampak bahwa menambahkan orang baru ke proyek adalah solusi yang jelas,
pada awalnya memperlambatnya. Jika ada tugas nonkritis tertunda, maka bisa berubah menjadi
kritis, sehingga jalur kritis dan nonkritis perlu dipantau.

KAPAN MENGHENTIKAN PROYEK YANG KELUAR DARI PENGENDALIAN

Kontrol proyek juga digunakan untuk mengidentifikasi proyek yang gagal dan menghentikannya.
Berikut ini adalah skenario umum: Proyek ini terlambat. Lingkupnya berubah hampir setiap hari.
Ada terlalu sedikit tonggak yang diidentifikasi selama tahap perencanaan untuk dapat memantau
kemajuan. Sumber daya dialokasikan secara keseluruhan. Anggota tim tidak berkomunikasi
karena mereka tahu bahwa proyek tersebut sedang dalam kondisi menjelang batas titik
terrendahnya dan takut untuk mengatakannya.

Terkadang, cara untuk memperbaiki proyek adalah dengan membatalkannya. Jika suatu proyek
menderita dari satu atau lebih kondisi yang tercantum dalam skenario, ia telah mencapai titik di
mana kelayakannya harus dikaji ulang secara kritis. Uang yang sudah dihabiskan untuk proyek,
atau biaya hangus, tidak boleh dipertimbangkan dalam keputusan. Satu-satunya biaya yang
relevan, dari sudut pandang keuangan, adalah apakah nilai total dari melanjutkan lebih besar dari
total biaya untuk melakukannya.

PENUTUPAN DAN POSTMORTEM PROYEK

Tinjauan pasca proyek, atau pascamortem, mengidentifikasi alasan mengapa proyek itu berhasil
atau tidak, kekuatan dan kelemahan rencana proyek, bagaimana masalah terdeteksi dan
diselesaikan, dan bagaimana proyek itu berhasil. Agar mendapatkan pemahaman yang lebih baik
tentang apa yang berhasil dan tidak berhasil untuk jadi panduan proyek-proyek di masa depan.
SYSTEM DEVELOPMENT LIFE CYCLE (SDLC)

Siklus hidup pengembangan sistem (SDLC) adalah metode pengembangan sistem untuk proyek
TI besar, seperti infrastruktur TI atau sistem perusahaan. SDLC adalah kerangka kerja terstruktur
yang terdiri dari serangkaian proses berurutan, seperti yang ditunjukkan pada Gambar 13.10.

Dimulai dengan ide awal, proses SDLC adalah analisis kebutuhan, analisis dan desain sistem,
pengembangan dan pengujian, implementasi, dan pemeliharaan. Prosesnya berulang, yang
artinya direvisi ketika informasi atau kondisi baru membuat revisi menjadi hal yang baik untuk
dilakukan. Iterasi tidak berarti bahwa pengembangan sistem harus sesuai dengan revisi yang tak
terbatas.

Desain IS sangat rentan terhadap cakupan creep karena berbagai alasan. Pengguna yang dituju
meminta fitur tambahan. Orang yang bukan pengguna yang dituju meminta untuk dimasukkan.
Teknologi berubah dari saat kasus bisnis ditulis dan pengembangan sistem dimulai. Tindakan
pesaing, pemasok, atau badan pengatur memicu permintaan tambahan untuk fungsionalitas.
Kontrol-kontrol ini membantu mencegah proyek yang tidak terkendali, biasanya dengan
kerugian moneter yang besar.

LANGKAH SDLC

Metodologi SDLC mengikuti langkah-langkah berikut :

Analisa Kebutuhan

Kekurangan dalam sistem yang ada diidentifikasi dan digunakan untuk menentukan persyaratan
fungsional dan data dari sistem baru. Analisis persyaratan sangat penting untuk keberhasilan
proyek. Semakin banyak waktu dalam menganalisis sistem, masalah bisnis, atau peluang dan
memahami masalah yang mungkin terjadi selama pengembangan, semakin besar probabilitas
bahwa IS akan sukses.

Analisis Sistem dan Studi Kelayakan

Rencana disusun mengenai konstruksi fisik, perangkat keras, perangkat lunak, media, dasbor,
sistem operasi, pemrograman, konektivitas, dan masalah keamanan. Kelayakan desain diuji.
Studi kelayakan menentukan probabilitas keberhasilan proyek yang diusulkan dan memberikan
penilaian kasar terhadap kelayakan teknis, ekonomi, organisasi, dan perilaku proyek. Berbagai
analisis kelayakan juga memberikan para pemangku kepentingan kesempatan untuk memutuskan
metrik apa yang akan digunakan untuk mengukur bagaimana sistem yang diusulkan memenuhi
tujuan mereka.
• Kelayakan teknis. Kelayakan teknis menentukan apakah teknologi yang dibutuhkan,
infrastruktur TI, struktur data, analitik, dan sumber daya dapat dikembangkan dan / atau
diperoleh untuk menyelesaikan masalah bisnis dan mencapai tujuan kinerja proyek.

• Kelayakan ekonomi. Kelayakan ekonomi menentukan apakah proyek merupakan risiko


keuangan yang dapat diterima dan apakah perusahaan mampu membayar biaya dan waktu yang
dibutuhkan untuk menyelesaikan proyek. Kelayakan ekonomi menjawab dua pertanyaan utama:
Apakah manfaatnya lebih besar daripada biaya proyek? Bisakah proyek diselesaikan sesuai
jadwal? Manajemen dapat menilai kelayakan ekonomi dengan menggunakan analisis biaya-
manfaat dan teknik keuangan seperti nilai waktu uang, laba atas investasi (ROI), nilai sekarang
bersih (NPV), dan analisis titik impas.

• Kelayakan hukum dan organisasi. Apakah ada alasan hukum, peraturan, atau lingkungan
mengapa proyek tidak dapat atau tidak boleh dilaksanakan? Analisis ini melihat kebijakan dan
politik perusahaan, termasuk dampak pada distribusi daya dan hubungan bisnis.

• Kelayakan perilaku. Kelayakan perilaku mempertimbangkan masalah manusia. Semua proyek


pengembangan sistem memperkenalkan perubahan, dan orang umumnya menolak perubahan.
Resistansi berlebihan dari karyawan dapat berupa sabotase sistem baru. Kelayakan perilaku
berkaitan dengan menilai keterampilan dan pelatihan yang diperlukan untuk menggunakan IS
baru. Kelayakan perilaku adalah tentang “bisakah mereka menggunakannya” seperti halnya
“apakah mereka akan menggunakannya.”

Setelah analisis kelayakan, keputusan untuk lanjut atau tidak dapat tercapai. Sponsor proyek dan
manajer proyek menandatangani keputusan tersebut. Jika keputusan tidak jalan, proyek ditunda
sampai kondisinya lebih baik, atau proyek dihentikan. Jika keputusan itu "lanjut," maka proyek
pengembangan sistem melanjutkan.

PENGEMBANGAN DAN PENGUJIAN SISTEM

Pengembang sistem menggunakan spesifikasi desain untuk memperoleh perangkat lunak yang
dibutuhkan sistem untuk memenuhi tujuan fungsionalnya dan menyelesaikan masalah bisnis.
Pengujian memverifikasi bahwa aplikasi, antarmuka, transfer data, dan sebagainya, berfungsi
dengan benar dalam semua kondisi yang memungkinkan.
PENERAPAN

Implementasi, atau penyebaran, adalah proses konversi dari sistem lama ke sistem baru. Empat
strategi konversi adalah paralel, pemutusan langsung, uji coba, dan bertahap. Dalam konversi
paralel, sistem lama dan sistem baru beroperasi secara bersamaan untuk periode waktu tertentu.
Yaitu, kedua sistem memproses data yang sama pada saat yang sama, dan hasilnya
dibandingkan. Jenis konversi ini adalah yang paling mahal tetapi paling tidak berisiko. Dalam
konversi langsung, sistem lama terputus dan sistem baru dihidupkan pada titik waktu tertentu.
Jenis konversi ini adalah yang paling murah, tetapi paling berisiko jika sistem baru tidak
berfungsi seperti yang direncanakan. Konversi percontohan memperkenalkan sistem baru di satu
lokasi untuk mengujinya. Setelah sistem baru bekerja dengan benar, itu diluncurkan. Konversi
bertahap memperkenalkan komponen sistem baru, seperti modul individu, secara bertahap.
Setiap modul dinilai, dan ketika berfungsi dengan baik, modul lainnya diperkenalkan hingga
seluruh sistem baru beroperasi.

PEMELIHARAAN

Setelah operasi sistem baru distabilkan, audit dilakukan selama operasi untuk menilai
kemampuan sistem dan menentukan apakah hal itu digunakan dengan benar. Pemeliharaan harus
dijaga dengan ketat setiap saat. Pengguna sistem harus selalu terbarui tentang modifikasi dan
prosedur terbaru.

Anda mungkin juga menyukai