Meet Scope and User Needs


projectmanagement source : thinkitassociation.org/

project management source : thinkitassociation.org/

 

Pada tulisan kali ini, saya mau curhat tentang ‘deal with user’. Atau bagaimana caranya agar kita dan user memiliki satu pandangan yang sama terhadap scope dan requirement. Believe it or not, hal tersebut adalah satu satu indikator proyek akan sukses atau akan gagal. Oh ya, definisi sukses di sini : tepat kualitas (meet client needs), tepat waktu (in time) dan tepat biaya (concern nya manajemen vendor ;p ).

Dulu, di proyek pertama yang diikuti, saya mengalami kegagalan. Kok bisa tahu kalau itu proyek gagal? Pertama, indikator keberhasilan proyek tidak terpenuhi. Kedua, aplikasi yang dibuat tidak digunakan. Nyesek bro! proyek demi proyek diikut, akhirnya semakin memperkuat keyakinan saya bahwa kesuksesan proyek sangat dipengaruhi oleh kesamaan pemahaman scope dan requirement oleh user maupun developer.

Dalam PMBOK (Project Management Body of Knowledge) edisi kelima, terdapat 10 area, dua diantaranya adalah Project Scope Management, dan Project Communication Management.

Project scope management intinya kita dapat mendefinisikan ruang lingkup pekerjaan dengan jelas dan client pun mengkonfirmasi ruang lingkup tersebut. Setidaknya terdapat 5 proses dalam area ini, namun saya akan membahas 3, yaitu :

–          Scope definition

Pendefinisian lebih detail scope yang terdapat pada project charter. Biasanya disajikan dalam bentuk WBS (work breakdown structure)

–          Scope verification

Scope yang sudah didefinisikan perlu diverifikasi oleh user sehingga terjadi kesamaan persepsi dan kesepakatan tentang scope dan kebutuhan. Tim developer akan menjadikan kesepakatan itu sebagai acuan dalam pengerjaan proyek.

–          Scope change controll

Hal yang tidak pernah berubah adalah perubahan itu sendiri. Lho, maksudnya? Apapun itu, termasuk dalam proyek tidak jarang mengalami perubahan. Apakah boleh melakukan perubahan saat proyek sedang berjalan (misal user minta dibuatkan fitur x)? Jawabnya boleh dengan catatan : tidak mengganggu deadline jadwal proyek, effort yang dikeluarkan masih di bawah batas toleransi, dan catatan lainnya. Tentunya setiap project manager memiliki pertimbangan tersendiri dalam menerima, menolak perubahan. Setiap request of change, dan responnya perlu dikelola dan didokumentasikan dengan baik. Karena hal tersebut juga merupakan acuan dalam pengerjaan proyek.

Project communication management berbicara tentang komunikasi yang baik internal tim developer, antar developer dengan user. Setidaknya terdapat 5 proses dalam area ini :

–          Identifikasi stakeholder

Proses ini dilakukan pada saat inisiasi proyek. Kita identifikasi user yang menjadi ‘key’, yaitu user yang menilai proyek ini berhasil atau tidak. Kita identifikasi juga user yang memiliki knowledge yang dapat membantu kita dalam melaksanakan proyek. Salah identifikasi user dapat berakibat fatal lho.

–          Perencanaan komunikasi

Proses ini dilakukan pada saat perencanaan proyek. Kita sepakati dengan user tentang : frekuensi komunikasi, sarana apa yang digunakan dan lain-lain. Misalnya : kita sepakati bahwa call boleh dilakukan hanya di jam kerja. Ada lho kejadian user nelp teman saya di jam-jam subuh, tentu saja mengganggu kehidupan pribadi

–          Pendisitribusian informasi

Proses ini dilakukan pada saat pelaksanaan proyek. Yang perlu kita pahami adalah informasi itu tidak harus selalu disampaikan ke tim atau user.  Sampaikan sesuai dengan kebutuhan dan otoritasnya saja. Misalnya, user tidak perlu tahu jika ada gesekan di dalam tim developer. Namun, project manager harus meredam gesekan tersebut agar proyek tetap berjalan dengan baik.

–          Mengelola ekspektasi user

Proses ini juga dilakukan saat pelaksanaan proyek. Tidak jarang lho user memiliki harapan yang sangat besar padahal scope proyek tidak memfasilitasi harapan tersebut. Misalnya, user di tengah proyek mengharapkan aplikasi tersebut juga dibuat versi mobile. Kalau dituruti, akan membahayakan proyek. Begitu pula kalau diabaikan, user bisa ‘ngambek’ dan proyek bisa kacau. Solusinya adalah kita kelola harapan user sedini mungkin, dan perlu dipahamkan dengan scope yang sudah disepakati sebelumnya

–          Pelaporan performansi proyek

Proses ini dilakukan pada saat monitoring & controlling proyek. Kita perlu melaporkan perkembangan proyek secara periodik kepada user maupun manajemen developer. Dengan demikian, diharapkan terbangun sense of belonging terhadap proyek, dan juga dapat me-mitigasi risiko proyek yang mungkin terjadi.

Kembali ke curhat. Ternyata user itu tidak butuh/don’t care tentang pemodelan apa yang digunakan dalam proyek. Apakah menggunakan UML atau menggunakan BPMN? Don’t care. Kurang tepat kalau kita berkomunikasi dengan user dengan pemodelan tersebut. Bahkan, orang IT aja kadang puyeng liat pemodelan yang kompleks. Termasuk saya, hehehe.. so, solusinya apa? Berdasarkan pengalaman saya, komunikasi visual GUI (graphical user interface) dapat menjadi solusi.

Beberapa bulan yang lalu mendapat  tugas menjadi sistem analis untuk perusahaan minyak dan gas di bilangan sudirman jakarta. Saat membaca proposal proyek, saya bingung, ini proposal proyek paling tidak sinkron yang pernah saya baca. Saya tidak bisa melihat scope, bisnis proses dan sebagainya dari proposal proyek tersebut. Lalu, diundang rapat yang dihadiri oleh tim IT kantor tersebut, user bisnis dan manajemen proyek developer tentunya. Dari rapat tersebut, tidak terlalu banyak informasi yang didapat (tidak semua rapat besar itu efektif). Di tengah-tangah rapat, saya identifikasi user yang memiliki otoritas dan pengetahuan yang dalam terhadap domain proyek tersebut.

“mbak, besok atau lusa bisa diskusi?” saya bertanya kepada user tersebut. Akhirnya kami pun rapat kecil (4 orang: 3 orang dari pihak user dan saya sendiri dari developer). Di rapat kecil pertama itu, kami berdiskusi tentang sistem yang ada seperti apa,kebutuhan mereka apa, dan sebagainya. Kami perdalam hal tersebut. Lalu saya request untuk rapat lagi dua hari kemudian. Rapat kedua ini saya menyajikan alur proses dengan diagram yang sederhana, lalu saya juga sajikan sketsa GUI. Tentu saja itu masih dalam persepsi saya dari hasil rapat kemarin. Dengan diagram alur yang sederhana dan sketsa GUI itu kami dapat berdiskusi apa yang perlu diubah dan apa yang perlu ditambahkan. Sehingga dengan metode seperti itu, kebutuhan user akan cepat terbayang dan kesepakatan/konfirmasi user terhadap rancangan kita dapat terlaksana dengan baik dan efektif.

Tools yang digunakan bisa dengan aplikasi Pencil, Mockup Builder atau Microsoft Visio. Saya merekomendasikan Visio karena mudah dan ringan saat digunakan. Tidak perlu kompleks, yang penting dapat menggambarkan kebutuhan dan solusi yang kita tawarkan.

Demikian curhat tentang pengalaman proyek. Ada kalanya menyedihkan, ada kalanya menyenangkan. Di dalamnya, saya mengambil pelajaran agar dapat menjalankan proyek di kemudian hari lebih baik lagi.

 

Referensi

–          Project Management Institute (PMBOK 2000) – PMP Preparation Worksheet

–          Project Management Professional Exam Study Guide Fifth Edition

 

Nb. Kadang ada keinginan untuk merasakan menjadi pemilik proyek (user), hehe..

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: