IT Project Management

7053T - IT Project Management

LECTURE NOTES

LINGKUP PENGELOLAAN PROYEK TI

Managing IT Project Scope

Bachtiar H. Simamora, M.Sc., Ph.D

[email protected]


TUJUAN PEMBELAJARAN

1. Memahami pentingnya project scope management yang baik

2. Mendiskusikan metode untuk mengumpulkan dan mendokumentasikan kebutuhan agar

dapat terpenuhi antara kebutuhan dan harapan dari stakeholder

3. Menjelaskan ruang lingkup proses definisi dan menjelaskan isi dari project scope

management

4. Mendiskusikan proses untuk membuat suatu struktur rinci kerja menggunakan

pendekatan analogi, top-down, bottom-up, dan mind-mapping

5. Menjelaskan pentingnya memeriksa ruang lingkup dan bagaimana hubungannya dalam

penentuan dan kontrol ruang lingkup

6. Memahami pentingnya melakukan kontrol ruang lingkup dan pendekatan untuk

mencegah timbulnya masalah yang berhubungan dengan ruang lingkup terkait proyek-

proyek teknologi informasi

7. Menggambarkan bagaimana piranti lunak dapat membantu project scope management

OUTLINE MATERI :

- Scope definition process - Process for creating a work breakdown structure - Verifying & controlling scope - Project scope management tools


ISI

APAKAH PROJECT SCOPE MANAGEMENT?

Seperti dibahas pada bab 1, ada beberapa faktor yang berhubungan dengan proyek yang

sukses. Banyak dari faktor-faktor ini seperti keterlibatan user, tujuan bisnis yang jelas,

mempersempit lingkup atau ruang lingkup yang jelas, dan kebutuhan dasar adalah elemen-

elemen dari project scope management

Satu aspek yang paling penting dan paling sulit dari manajemen proyek adalah

menentukan ruang lingkup proyek. Ruang lingkup mengarah pada semua pekerjaan yang

terdapat dalam proyek dan proses yang digunakan. Istilah penyampaian (deliverable)

menggambarkan produk yang dihasilkan adalah bagian dari proyek. Deliverables bisa berupa

produk seperti suatu hardware, software, atau proses yang berkaitan seperti dokumen

perencanaan atau notula rapat. Stakeholder proyek harus menyetujui pada apa yang dihasilkan

proyek dan sampai batas tertentu, bagaimana mereka harus menetapkan semua hasil.

Project scope management berisi suatu proses yang melibatkan penetapan dan kendali suatu

pekerjaan termasuk proyek atau bukan. Hal ini memastikan tim proyek dan stakeholder memiliki

pengetahuan yang sama akan apa yang dihasilkan dari proyek dan proses mana yang akan

digunakan. Ada 5 proses utama dalam project scope management, yaitu:

1. Pengumpulan kebutuhan, meliputi penetapan fitur dan fungsi dari produk yang dihasilkan

dalam proyek juga proses yang digunakan untuk membuatnya. Sebagai hasil

pengumpulan kebutuhan, tim proyek membuat dokumentasi kebutuhan stakeholder,

kebutuhan perencanaan manajemen, kebutuhan matrik ketertelusuran.

2. Penetapan ruang lingkup, meliputi peninjauan project charter, dokumen kebutuhan dan

proses aset organisasional untuk membuat pernyataan lingkup. Membangun persyaratan

persetujuan penambahaan informasi dan permintaan perubahan. Keluaran utama definisi

lingkup adalah pernyataan lingkup proyek dan memperbarui dokumen proyek.

3. Pembuatan WBS, meliputi pembagian proyek utama ke dalam proyek yang lebih kecil

dalam komponen yang dapat diatur. Keluaran proses ini meliputi WBS, WBS dictionary,

lingkup dasar, dan memperbarui dokumen proyek.


4. Verifikasi lingkup, meliputi formalisasi penerimaan dari hasil (deliverable) proyek.

Stakeholder proyek, yaitu pelanggan dan sponsor, memeriksa lalu secara resmi menerima

hasil-hasil selama proses ini. Jika hasil tidak diterima, maka biasanya pelanggan atau

sponsor meminta perubahan. Keluaran utama proses ini adalah hasil diterima dan

permintaan perubahan.

5. Kendali lingkup, meliputi pengendalian perubahan lingkup proyek pada masa proyek

berlangsung (tantangan pada banyak proyek IT). Perubahan lingkup proyek sering

berpengaruh pada kemampuan tim untuk menyesuaikan waktu dan biaya proyek, jadi

manajer proyek harus hati-hati pada kenaikan biaya dan keuntungan pada perubahan

lingkup. Keluaran utama proses ini adalah permintaan perubahan, pengukuran

perfomance kerja, dan memperbaruia proses aset organisasional, perencanaan manajemen

proyek, dan dokumen-dokumen proyek.

Gambar berikut adalah ringkasan proses, keluaran, dan memperlihatkan kapan mereka terjadi

dalam proyek.

Gambar 1

PENGUMPULAN KEBUTUHAN


Tahap pertama dalam project scope management seringnya merupakan yang paling sulit:

mengumpulkan kebutuhan. Konsekuensi utama jika tidak menetapkan kebutuhan dengan baik

adalah mengulang pekerjaan, yang dapat menghabiskan separuh biaya proyek, terutama pada

proyek-proyek pembuatan software. Sebagai gambaran (lih. Gb. 2), hal tersebut membutuhkan

biaya lebih banyak untuk memperbaiki sebuah software cacat yang baru diketahui diakhir tahap

pembuatan dari pada diperbaiki saat tahap penetapan kebutuhan.

Bagian yang sulit adalah umumnya sering tidak konsisten dalam penetapan kebutuhan,

bagaimana mengumpulkannya, dan bagaimana mendokumentasikannya.

Apa itu kebutuhan?

Berdasarkan IEEE 1990 Glosari Standar Terminologi Rekayasa Software kebutuhan

ditetapkan sebagai berikut:

1. Suatu keadaan atau kemampuan yang dibutuhkan oleh user untuk memecahkan masalah

atau mengarsip tujuan.

2. Suatu keadaan atau kemampuan yang harus sesuai atau dimiliki oleh sistem atau

komponen sistem yang memenuhi kontrak, standar, spesifikasi, atau dokumen-dokumen

lain yang secara resmi diberlakukan

3. Suatu dokumentasi gambaran dari keadaan atau kemampuan pada poin 1 atau 2.

Gambar 2

Pada PMBOK Guide, edisi 4, mendefinisikan suatu kebutuhan hampir mirip dengan poin

2 di atas. Dikatakan, ”suatu suatu keadaan atau kemampuan yang harus sesuai atau dimiliki oleh


sistem, produk, jasa, hasil, atau komponen untuk memenuhi kontrak, standar, spesifikasi, atau

dokumen resmi lainnya.” Adalah penting untuk mendokumentasikan kebutuhan dengan cukup

detil sehingga dapat diukur selama pelaksanaan proyek. Dengan demikian pemenuhan lingkup

tujuan sering kali berdasar pada kebutuhan yang terdokumentasi.

Untuk beberapa proyek IT, adalah sangat membantu untuk memecah kebutuhan

pengembangan ke dalam kategori seperti perolehan, analisis, spesifikasi, dan validasi. Kategori

ini termasuk semua aktifitas yang melibatkan pengumpulan, evaluasi, dan dokumentasi

kebutuhan suatu software atau produk yang mengandung sofrware. Penting juga menggunakan

pendekatan interaktif untuk mendefinisikan kebutuhan karena sering kali kurang jelas di awal

proyek.

Bagaimana Anda mengumpulkan kebutuhan?

Ada beberapa jalan untuk mengumpulkan kebutuhan. Wawancara satu per satu dengan

stakholder adalah yang paling efektif, namun juga akan menjadi sangat mahal dan membutuhkan

waktu. Biasanya lebih efektif dan lebih murah dengan mengumpulkan fokus grup, membuat

workshop, dan menggunakan kreatifitas grup dan teknik penetapan keputusan untuk

mengumpulkan kebutuhan. Kuesioner dan survei bisa lebih efisien asalkan disiapkan dengan

baik dan teliti. Observasi juga merupakan teknik yang baik dalam pengumpulan kebutuhan,

terutama pada proyek yang melibatkan perbaikan langkah kerja dan prosedure. Pembuatan

prototype adalah yang teknik paling umum digunakan dalam pengumpulan kebutuhan untuk

proyek pengembangan software. Beberapa software yang tersedia di pasaran dapat membantu

dalam pengumpulan dan mengatur kebutuhan.

Ukuran, kompleksitas, pentingnya proyek dan faktor lain sering mempengaruhi besar

usaha yang diperlukan dalam pengumpulan kebutuhan. Sebagai contoh, sebuah tim yang bekerja

dalam proyek yang memperbarui seluruh sistem akunting dalam perusahaan multinasional

dengan lebih dari 50 lokasi akan lebih membutuhkan waktu dibanding dengan sebuah tim yang

mengerjakan proyek untuk perusahaan kecil dengan hanya 5 karyawan.


Bagaimana Anda mendokumentasikan kebutuhan?

Ada beberapa cara untuk mengumpulkan dan mendokumentasikan kebutuhan. Tim

proyek pertama-tama harus meninjau project charter karena dapat berisi kebutuhan penting yang

merujuk pada dokumen lain yang juga memiliki kebutuhan. Tim juga harus meninjau daftar

stakeholder dan memastikan bahwa semua anggota stakeholder telah memberikan ketentuan

kebutuhan. Format untuk mendokumentasi kebutuhan stakeholder dapat berupa suatu daftar

kebutuhan dalam selembar kertas atau dicatat penuh dalam satu buku. Dokumen kebutuhan yang

dibuat menggunakan software dan melibatkan catatan, gambar, rekaman suara, video, diagram,

dan bentuk-bentuk lain. Kebutuhan juga sering dipisahkan lagi ke dalam beberapa kategori,

seperti kebutuhan fungsi, kebutuhan layanan, kinerja, kualitas, pelatihan dan lain-lain.

Sebagai tambahan dalam mempersiapkan pencatatan kebutuhan stakeholder dalam

pengumpulan kebutuhan, tim proyek membuat suatu rencana pengelolaan kebutuhan dan suatu

matrik kebutuhan yang dapat ditelusur kembali.

Rencana pengelolaan kebutuhan menggambarkan bagaimana kebutuhan proyek dianalisa,

dicatat dan dikelola. Sedangkan matrik kebutuhan yang dapat ditelusur kembali adalah suatu

tabel daftar kebutuhan dengan bermacam ciri dan sifat kebutuhan, serta statusnya untuk dapat

memastikan bahwa semua kebutuhan telah ditempatkan dengan benar (addressed).

Tabel contoh matrik kebutuhan yang dapat ditelusur kembali

PENETAPAN RUANG LINGKUP

Tahap selanjutnya dalam project scope management adalah menetapkan ruang lingkup yang

lebih detil atau perkerjaan yang dibutuhkan dalam proyek. Penetapan ruang lingkup yang baik

sangat penting dalam menentukan suksesnya proyek karena membantu memperbaiki ketepatan


waktu, biaya dan perkiraan sumber daya. Hal itu menjadi dasar pengukuran kinerja dan kendali

proyek, juga membantu menjelaskan kewajiban-kewajiban kerja.

Kunci dari persiapan pernyataan ruang lingkup (scope statement) proyek meliputi project

charter, dokumentasi kebutuhan, dan modal organisasi seperti kebijakan dan prosedur yang

berhubungan dengan pernyataan ruang lingkup. Demikian juga perlu persiapan file-file dan

pelajaran yang ada pada proyek yang sama sebelumnya.

Meskipun bermacam-macam, project scope statement harus meliputi minimal suatu

product scope description, product user acceptance criteria, dan informasi detil pada semua hasil

proyek. Akan sangat membantu jika mendokumentasikan juga ruang lingkup lain yang masih

terkait seperti batas-batas proyek, konstrain dan asumsi-asumsi. Project scope statement

harusnya juga memberi petunjuk dokumen-dokumen pendukung seperti spesifikasi produk, yang

berpengaruh pada produk-produk apa yang akan dibuat atau dibeli, atau kebijakan perusahaan

yang berpengaruh pada bagaimana produk atau layanan dihasilkan.

CREATING THE WORK BREAKDOWN STRUCTURE (WBS)

WBS ialah kelompok kerja yang berorientasi pada hasil (deliverable) yang terlibat dalam

sebuah proyek yang mendefenisikan total lingkup proyek.

WBS merupakan dokumen yang memberikan dasar untuk perencanaan dan pengelolaan

jadwal proyek, biaya, sumberdaya, dan perubahan.

Input utama untuk membuat WBS ialah project scope statement, stakeholder

requirements documentation, dan organizational prosess assets.

Decomposition: pengelompokan deliverable proyek menjadi potongan kecil

Work package: tugas pada tingkat terendah WBS

Manfaat Work Breakdown Structure (WBS)

• Mengurangi kompleksitas

• Fasilitas penjadwalan dan pengendalian

• Estimasi Biaya (Cost Estimation)


• Penyusunan anggaran (Cost Budgeting)

• Perencanaan manajemen Risiko

• (Risk Management Planning)

• Identifikasi aktivitas(Activity Definition)

Pada prinsipnya Work Breakdown Structure (WBS) adalah pemecahan atau pembagian

pekerjaan ke dalam bagian yang lebih kecil (sub-kegiatan), alasan perlunya WBS adalah :

o Pengembangan WBS di awal Project Life Cycle memungkinkan diperolehnya pengertian

cakupan proyek dengan jelas, dan proses pengembangan WBS ini membantu semua anggota

untuk lebih mengerti tentang proyek selama tahap awal.

o WBS membantu dalam pengawasan dan peramalan biaya, jadwal, dan informasi mengenai

produktifitas yang meyakinkan anggota manajemen proyek sebagai dasar untuk membuat

perundingan.

Figure 5-3. Sample Intranet WBS Organized by Product

Output dari WBS ialah: WBS itu sendiri, WBS dictionary, scope baseline, dan project

document updates


Figure 5-4. Sample Intranet WBS Organized by phase

Figure 5-5. Intranet WBS and Gantt Chart in Microsoft Project


Approaches to Developing WBSs Information Technology Project

Management

Using guidelines : beberapa organisasi, seperti: Department Of Defence (DOD)

menyediakan guidelines untuk mempersiapkan

Analogy approach : meninjau WBS dari proyek yang mirip dan menyesuaikan dengan

proyek yang sedang dikerjakan

Top-down approach : mulai dari item terbesar dari proyek dan kemudian dipecah ke poin –

poin detail

Bottom-up approach : mulai dengan tugas – tugas tertentu dan kemudian dijabarkan ke

level yang lebih tinggi

Mind-mapping approach : teknik yang menggunakan cabang yang memancar keluar dari

ide inti untuk struktur pikiran dan ide-ide

Figure 5-6. Sample Mind-Mapping Approach for Creating a WBS


The WBS Dictionary and Scope Baseline

Banyak tugas-tugas dari WBS yang tidak jelas dan harus dijelaskan lebih detail sehingga

orang tahu apa yang harus dilakukan dan dapat memperkirakan berapa lama waktu yang

diperlukan dan berapa biaya untuk melakukan pekerjaan

WBS dictionary adalah sebuah dokumen yang menjelaskan informasi rinci tentang

setiap item WBS

Persetujuan pada project scope statement, WBS dan and WBS dictionary berasal dari

scope baseline, yang digunakan untuk mengukur kinerja dalam lingkup tujuan pertemuan

Table 5-5 Sample WBS dictionary entry

SARAN UNTUK MEMBUAT WBS DAN KAMUS WBS

Seperti yang dinyatakan sebelumnya, membuat WBS yang baik bukanlah tugas yang

mudah dan biasanya memerlukan beberapa kali perulangan. Seringkali, yang terbaik untuk

menggunakan kombi nasi pendekatan untuk membuat proyek WBS. Ada beberapa prinsip

dasar, yang berlaku untuk menciptakan setiap WBS yang baik dan kamus WBS nya.


1. Sebuah unit kerja hanya akan muncul pada satu tempat di WBS

2. Sebuah item WBS memuat sejumlah item WBS dibawahnya

3. Item WBS hanya merupakan tanggung jawab seseorang, meskipun banyak orang yang

turut mengerjakannya

4. Isi WBS harus konsisten dengan cara pelaksanaan pekerjaan yang sebenarnya

5. Anggota tim proyek harus terlibat dalam pengembangan WBS untuk memastikan

konsistensi

6. Setiap item WBS harus didokumentasikan dalam WBS dictionary untuk memastikan

pemahaman akurat tentang lingkup pekerjaan yang termasuk dan tidak termasuk dalam

item

7. WBS harus menjadi alat yang fleksibel untuk mengakomodasi perubahan yang tak

terelakkan, walaupun mempertahankan pengawasan konten pekerjaan dalam proyek

sesuai dengan scope statement

Peran WBS Dalam Perencanaan Proyek

WBS merupakan pondasi untuk perencanaan proyek. WBS dibuat sebelum

ketergantungan diidentifikasi dan lamanya aktifitas pekerjaan diestimasi. WBS juga dapat

digunakan untuk mengidentifikasi tugas-tugas dalam model perencanaan proyek. Oleh karena

itu, idealnya rancangan WBS sendiri harusnya telah diselesaikan sebelum pengerjaan

perencanaan proyek (project plan) dan penjadwalan proyek (project schedule).

Dengan memanfaatkan daftar pekerjaan pada WBS, akan dapat diperkirakan lamanya

waktu yang dibutuhkan untuk menyelesaikan setiap pekerjaan tersebut. Perkiraan bisa dilakukan

dengan mempertimbangan beberapa hal, antara lain ketersediaan sumber daya dan kompleksitas.

Selanjutnya dilakukan penjabaran dalam kalender (flow time). Beberapa model pendekatan bisa

digunakan untuk menghitung perkiraan waktu yang diperlukan :

• Most optimistic : Merupakan waktu ideal untuk menyelesaikan pekerjaan, diasumsikan

segala sesuatunya berjalan lancar, dan sempurna.

• Most likely : Merupakan waktu yang dibutuhkan pada kondisi kebanyakan, tipikal dan

normal.

• Most pessimistic : Merupakan waktu yang dibutuhkan ketika keadaan paling sulit terjadi.


Selanjutnya, estimasi waktu dilakukan dan dibagi dalam unit (misal 8 jam/hari). Estimasi

waktu untuk suatu proyek Intranet (seperti contoh diatas) lebih sulit dari proyek pengembangan

aplikasi lainnya. Hal ini karena masih sedikit proyek yang dapat digunakan sebagai patokan

menghitung waktu pelaksanaan.

Dalam mengestimasi waktu ini juga harus dipertimbangkan beberapa hal, misal

pengalaman teknologi server yang digunakan, keahlian Perl, CGI, Java, HTML, browser, dan

juga bekerja dalam lingkungan TCP/IP.

Setelah WBS berhasil disusun dan perkiraan lama waktu pelaksanaan telah dihitung,

selanjutnya dilakukan penyusunan jadwal kerja. Pada dasarnya ada dua jenis model deskripsi

penjadwalan, yaitu :

• Bar Chart : Yang hanya menerangkan flow time dari setiap pekerjaan dan tanpa keterkaitan

antar pekerjaan. Deskripsi ini paling baik digunakan pada presentasi

• Network diagram : Yang menunjukkan keterkaitan antar tugas dan mengidentifikasi saat

kritis pada jadwal.

VERIFIKASI RUANG LINGKUP

Membuat cakupan ruang lingkup/ scope sebuah project beserta WBS (Work Breakdown

Structure) adalah hal yang sulit dilakukan. Dan menjadi lebih sulit ketika melakukan verifikasi

ruang lingkup/ scope poject tersebut dan sebisa mungkin meminimalisasi perubahan ruang

lingkup projectnya. Sering kali terjadi kasus bahwa dari awal project sudah di ketahui ruang

lingkup / scope kurang begitu jelas, maka dalam hal ini pelaksana project harus melakukan

proses verifikasi cakupan ruang lingkup yang harus memenuhi kebutuhan dari project itu sendiri.

harus ada prosedur yang bisa menjamin klien mendapatkan apa yang mereka inginkan dan

pelaksana project mempunyai waktu dan uang untuk membuat project sukses.

Banyak IT project yang gagal di karenakan scope creep. Scope creep adalah

kecenderungan ruang lingkup project menjadi besar dan semakin besar.

Stakeholders juga memegang peranan penting dalam verifikasi ruang lingkup project ini.

Para stakeholders ini harus memberikan dukungan secara formal terhadap ruang lingkup project

yang telah dipaparkan. Dukungan ini biasanya dicapai ketika klien atau customer sudah


melakukan inspeksi dan melakukan sign off hasil yang telah dicapai. Biasanya pelaksana proyek

membuat dokumentasi dari apa hasil/ prduct yang telah dihasilkan dan atau prosedur atau

langkah-langkah sudah sesuai dengan yng seharusnya dan juga benar. Dari pembahasan di Bab 4

tersirat adalah sangat penting utnuk selalu membuat dokumentasi tentang fungsi dan karateristik

fisik dari produk yang di hasilkan di projek, mencatat dan melaporkan setiiap perubahan, dan

melakukan pemeriksaan terhadap produk untuk memverifikasi kesesuaian dengan kebutuhan.

Karena itulah untuk meminimalisasi perubahan ruang lingkup adalah sangat penting untuk

melakukan dengan benar management konfigurasi dan memverifikasi ruang lingkup proyek.

Hal utama yang bisa di kategorikan sebagai input di verfikasi Ruang Lingkup adalah

Rencana manajemen proyek, dokumentasi, matrik penelusuran, dan hasil yang di harapkan dari

proyek itu sendiri. Untuk melakukan verifikasi ruang lingkup dapat dilakukan dengan inspeksi

dari klien/pelanggan, sponsor, dan pengguna. Hasil utama verifikasi Ruang lingkup yang di

inginkan adalah hasil yang dapat di terima, dan dokumen project yang berubah.

MENGENDALIKAN RUANG LINGKUP

Perubahan dalam proyek adalah sesuatu yang tak terelakkan, khususnya proyek IT.

Kendali Ruang lingkup melibatkan pengendalian perubahan di dalam ruang lingkup proyek.

Pengguna/user biasanya tidak begitu yakin bagaimana tampilan yang benar benar mereka

inginkan atau fungsi apa yang benar benar mereka butuhkan untuk meningkatkan performa

bisnis. Para pengembang juga tidak begitu yakin bagaimana menerjmahkan kemauan

user/pengguna.

Tujuan dari pengendalian ruang lingkup ini adalah untuk berpengaruh terhadap factor

yang menyebabkan perubahan ruang lingkup, memastikan perubahan dilakukan sesuai dengan

pembuatan prosedur sebagai bagian dari integrasi kendali perubahan, dan mengelola perubahan

ketika terjdi lagi. Kita tidak bisa melakukan pengendalian poyek dengan baik jika pada awal

mula kita tidak baik juga melakukan proses pengumpulan kebutuhan proyek, penentuan definisi

proyek, dan verifikasi ruang lingkup. Bagaimana kita bisa melakukan pencegahan trehadap

Scope Creep jikalau kita tidak setuju dengan pekerjaan yang sudah berjalan dan sponsor anda

tidak melakukan verifikasi pekerjaan yang di usulkan yang di telah di terima. Stakeholders


seharusnya berani untuk memberikan saran perubahan yang akan memberikan keuntungan /

benefit terhadap keseleuruhan proyek.

Hal utama yang bisa di kategorikan sebagai input di verfikasi Ruang Lingkup adalah

Rencana manajemen proyek, dokumentasi, matrik penelusuran, dan hasil yang di harapkan dari

proyek itu sendiri. tool yang cukup penting untuk melakukan pengendalian ruang lingkup adalah

analisa varian. Varian adalah perbendaan antara rencana dan yang sebenarnya terjadi. Sebagai

contoh jika supplier seharusnya mengirimkan lima keyboard, namun kita hanya menrima 4

keyboard, maka varian nya adalah satu keyboard. Output dari pengendalian ruang lingkup

adalah satunya rencana perubahan manajemen proyek dan perubhan di dokumen proyek.

Beberapa perusahan bisa mengikuti best practice berikut di bawah ini untuk menghindari

permasalahan ruang lingkup yang besar, antara lain :

1. Pastikan ruang lingkup dari proyek ini tetap reaslistis. Jangan membuat sebuah proyek

begitu besar sehingga tidak bisa di penuhi. Pecahlah project yang besar iru menjadi

beberapa project kecil

2. Libatkan pengguna/user di dalam ruang lingkup manajemen proyek. Tunjuklah pengguna

yang mahir menjadi pengguna kunci dan berikan mereka tanggung jawab untuk

mendefenisikan kebutuhan dan verifikasi ruang lingkup

3. Penggunan hardware dan software terbaru bila memungkinkan. Kebanyakan orang orang

IT menikmati menggunakan teknologi terbaru, tapi untuk hal ini harus mengikuti aturan,

kebutuhan bisnis bukan kebutuhan teknologi, jadi kebutuhan bisnis harus mejadi proiritas

4. Ikuti manajemen proyek proses yang bagus.

Memanage ruang lingkup dari pegembangan sebuah software adalah sangat sulit, tapi

framework sperti IBM Rational Unified Process (RUP) bisa membantu. RUP medeskripsikan

karakteristik pembuatan, dan evolusi sebuah software sebagai berikut:

• Menyesuaikan dengan proses

• Menyeimbangkan prioritas stake holder yang ingin bersaing


• Kolaborasi di dalam team

• Menunjukkan nilai iterative

• Menaikkan tingkat pemisahan

Table 1-2 dari bab 1di atas adalah sepuluh factor kesuksesan proyek IT. Empat dari

sepuluh factor adalah berhunungan dengan verifikasi ruang lingkup dan pengendalian ruang

lingkup, yaitu : keterlibatan user, tujuan bisnis yang jelas, ruang lingkup yang jelas, dan

kebutuhan perusahaan. Untuk menghindari kegagalan proyek maka adalah sangat penting bagi

Proyek manager dan keseluruhan tim untuk bekerja meningkatkan user input dan mengurangi

ketidaklengkapan dan perubahan kebutuhan dan spesifikasi.

Saran dan anjuran untuk peningkatan user input

Berikut adalah saran dan anjuran untuk peningkatan user input

• Membangun proses seleksi proyek yang bagus. Menekankan bahwa semua proyek

memiliki sponsor atau dukungan dari user/pemakai di organisasi. Dukungan ini

seharusnya bukan berasal dari seseorang yang berasal dari departemen IT atau

pendukung proyek ini juga tidak boleh menjadi project manager.


Membuat informasi proyek termasuk project charter, rencana manajemen proyek,

• User di libatkan sebagai anggota tim. Beberapa organisasi membutuhkan manager proyek

yangmemiliki pengetahuan lebih di area bisnis proyek dibandingkan dengan dari grup IT.

Beberapa organisaasi menetapkan co-project manager , satu dari dengan latar belakang IT

dan satunya diambilkan dari bisnis utama grup.

• Secara regular diadakan meeting dengan agenda yang jelas. Pertemuan secara berkala ini

berguna untuk memastikan tidak ada informasi atau komunikasi yang mandeg. Seringkali

kita terjebak dengan asumsi kita mengethaui apa yang pengguna butuhkan tanpa

mendengerkan keluhan mereka.

• Kirimkan “sesuatu” ke pengguna dan sponsor secara berkala. Jika berkaitan dengan

hardware, pastikan hal tersebut sudah berjalan.

• Jangan memberikan janji untuk menghasilkan sesuatu yang kemungkinan tidak bisa jadi

tepat waktu. Pastikan jadwal proyek memberikan waktu yang cukup untuk mencaai hasil

yang di inginkan

• Satukan pengguna dan pengembang. Tempatkan dalam satu ruang yang sama. Orang

biasanya akan saling mengetahui satu sama lain ketika ada kedekatan.

Saran untuk mengurangi ketidaklengkapan dan perubahan kebutuhan

Beberapa perubahan kebutuhan adalah hal yang wajar dan mutlak dalam proyek IT, tapi banyak

proyek yang terlalu banyak melakukan perubahan kebutuhan, terutama biasa terjadi ketika

memasuki tahap lanjut dari lifecycle sebuah proyek, dimana ini menjadikan lebih sulit untuk di

implementasi. Di bawah ini adalah beebrapa saran untuk mengatasi hal tersebut:

• Membangun dan mengikuti kebutuhan manajemen proyek yang termasuk di dalamnya

adalah prosedur untuk penentuan kebutuhan awal

• Menggunakan beberapa teknik seperti, Prototyping, menggunakan case model, dan Joint

Application design


Prototyping melibatkan pembangunan replika dari sebuah system atau sebagia aspek dari

system. Prototyping sangat efektif untuk menggali dan memahami kebutuhan,

Menggunakan Case modeling adalah sebuah proses untuk mengidentifikasi dan

membuat pemodelan kegiatan bisnis, siapa yang mencetuskan idenya, dan bagaimana

system seharusnya meresepon nya. Ini efektif di gunakan untuk mengetahui dan

memahami kebutuhan untuk pembuatan system informasi

Joint Application System (JAD) menggunakan workshop yang terorganizir untuk

mengumpulkan Stakeholder proyek ( Sponsor, pengguna/user, bisnis analis,

programmer,dsb) untuk menetapkan dan merancang system informasi.teknik ini juga

membantu pengguna untuk menjadi lebih aktif dalam menentukan kebituhan system.

• Pastikan semuah kebutuhan tertulis dan tersedia kapanpun di ingin di butuhkan

• Membuat sebuah database untuk kebutuhan dokumentasi dan pengendalian kebutuhan

• Menyediakan secara cukup testing untuk verifikasi bahwa produk dari proyek bekerja

sesuai kemauan

• Gunakan proses untuk melihat ulang permintaan perubahan kebutuhan dari sudut

pandang system.

• Menekan kan tanggal penyelesaian

• Alokasi sumberdaya terutama untuk menangani permintahan perubahan

MENGGUNAKAN SOFTWARE UNTUK MEMBANTU PROJECT SCOPE

MANAGEMENT

Manajer proyek dan anggota tim nya dapat menggunakan beberapa software untuk membantu di

manajamen ruang lingkup projek

Microsoft Word atau software pengolah kata lain nya yg dapat di gunakan untuk

dokumentasi terkait dengan ruang lingkup proyek

Spreadsheets yang bisa membantu peritungan financial dan bisa membuat charts dan

graphs.


Software Communication software, contohnya seperti e-mail, sangan membantu

kejelasan informasi ruang linkgup.

Project management software untuk membuat WBS, the basis for tasks on a Gantt chart

.manajemen ruang ingkup proyek adalah sanat penting terutama untuk projek projek IT. Setelah

memilih project, oranisasi harus mencari kebutuhan dan menentukan ruang lingkup pekerjaan,

pemecaha pekerjaan menjadi bagian kecil yang lebih mudah di manage, verifikasi ruang

lingkup, dan juga mengatur perubahan dari ruang lingkup projek.


SIMPULAN

• Lingkup manajemen proyek mencakup proses-proses yang diperlukan untuk memastikan bahwa proyek mencakup semua pekerjaan yang diperlukan, dan hanya pekerjaan yang dibutuhkan untuk menyelesaikan proyek tersebut dengan berhasil.

• Proses utama meliputi:

o Mengumpulkan persyaratan

o Tentukan lingkup

o Membuat WBS

o Verifikasi lingkup

o Pengendalian lingkup


DAFTAR PUSTAKA

1. Schwalbe, Kathy. (2009). Information Technology Project Management. Sixth edition. Course Technology. Augsburg. ISBN: 978-0324786927.

2. Marchewka, Jack T. (2006). Information Technology Project Management: Providing

Measurable Organizational Value. Second edition. Wiley. Illinois. ISBN: 978-0471715399.

IT Project Management

Documents

Transcript of IT Project Management