Change Management in IT Internal/Inhouse Dev

[Angga Hantara]

Dear Semua,

Boleh share bagaimana para PM disini me-manage perubahan scope/schedule yang di kerjakan oleh IT untuk internal perusahaan ?

Contoh : Perubahan scope atau fitur yang berbeda dari scope awal

Karena software yang kita buat untuk membantu internal perusahaan(accounting,sales,etc) seringkali user melakukan banyak request perubahan atau penambahan fitur yang membuat project selalu mundur.

Kita sudah coba menerapkan change request form yang harus membutuhkan approval dari stakeholder, tetapi stakeholder(Direktur or General Manager) di sini selalu melakukan approve atas perbuahan yang terjadi. 

Ada ide atau tips dari para PM di sini untuk "membatasi imajinasi liar"  para user :-) 

[Indra Hartono]

Halo Angga,

Mencoba berbagi pengalaman juga ya.. Banyaknya imajinasi liar dan Change Request sebagian besar disebabkan oleh adanya Requirement Gap antara konsultan dan user. Artinya, bisa jadi user sebenernya belum paham apa yang sebenernya mereka mau dan butuhkan; di satu sisi, konsultan / tim IT banyak bekerja berdasarkan asumsi. 

Beberapa tips yang bisa dicoba antara lain:

1. Preventive: Pada fase requirement gathering, lakukan user requirement elicitation (penggalian) lebih detail lagi, bisa menggunakan metode mock-up, workshop, atau apapun yang membuat user dan konsultan sama2 paham tentang sistem yang akan dibangun. Hal ini akan meminimalisir terjadinya CR di fase2 selanjutnya.

2. Preventive: Sebelum fase UAT, libatkan user dalam pembuatan skenario testing. Terkadang ada skenario2 yang aneh/unik yang terlewatkan oleh konsultan. Hal ini memang bisa men-trigger ide2 liar yang mungkin belum teridentifikasi pada saat requirement gathering. Namun jika dapat di-capture seawal mungkin, maka hal ini juga akan meminimalisir terjadinya CR pada saat UAT. 

3. Preventive: membuat Change Management Matrix dan Policy. Matriks yang dimaksud adalah pengkategorian CR berdasarkan Impact dan Priority. Tujuannya adalah justifikasi CR mana yang memang harus di-deliver (mandatory CR) di dalam project, atau bisa dikerjakan setelah project live (nice to have CR). Setelah kategori tersebut terdefinisi, tinggal dibuat policy terkait implementasinya. Kategori ini juga harus ditambahkan ke dalam CR form yang digunakan.

4. Reaktif: Jika CR memang tak terhindarkan, pastikan seluruh stakeholder paham akan impactnya terhadap schedule dan Cost.. Biasanya kalau sudah berkaitan dengan Cost, top level management akan lebih concern. Artinya Project Manager harus dapat meng-convert / valuasi impact perubahan ke bentuk "Rupiah". Misalkan berapa man-hour yang perlu ditambah, overhead cost, dst. 

Hampir di setiap perusahaan, project internal (yang dikerjakan oleh internal resource) kadang dinomor duakan, karena tidak ada revenue-nya. Sehingga sering kali menjadi "never-ending project". Namun sebenarnya jika dibiarkan berlama-lama, ada opportunity yang hilang. Salah satunya adalah resource yang dialokasikan ke project tersebut tidak dapat "dijual" / di-utilize ke project external yang pastinya menghasilkan revenue.

Namun kembali lagi, CR bukanlah sesuatu yang harus dihindari dalam project; dengan syarat CR tersebut di-manage dengan baik dan realistis; dan di-acknolewdged impact-nya oleh seluruh stakeholder. Dengan kata lain, tidak boleh ada yang dirugikan (Win - Win Solution).

Salam,

-Indra Hartono-

First of His Name, King of the Andals and the First Men, Lord of the Seven Kingdoms, and Protector of the Realm.

--
Anda menerima pesan ini karena berlangganan grup "Manajemen Proyek IT" di Google Grup.
Untuk berhenti berlangganan dan berhenti menerima email dari grup ini, kirim email ke it-project-indon...@googlegroups.com.
Untuk mengeposkan ke grup ini, kirim email ke it-project...@googlegroups.com.
Kunjungi grup ini di http://groups.google.com/group/it-project-indonesia.
Untuk opsi lebih lanjut, kunjungi https://groups.google.com/d/optout.

[Angga Hantara]

Thanks Pak Indra Hartono,

Dari penjelasan yang bapak berikan kami memang belum melakukan no 3 dan no 4 , akan saya coba .

Untuk no 1 dan no 2 sudah kami kerjakan , biasanya kami menggunakan mock up(pencil/balsamiq etc) untuk melakukan presentasi tetapi seringkali user meminta fitur baru setelah tampilan

aplikasi sudah selesai atau setelah mencoba software terlebih dahulu . Jadi ide-ide baru sering muncul setelah Open test ke user .

Kemarin saya kepikiran untuk membuat design tampilan dan fitur awal2  untuk di presentasikan tetapi saya fikir effort untuk me-akomodir perubahan cukup besar

[Endy Muhardin]

Benar katanya pak Indra, CR itu bukan sesuatu yang harus dihindari. 

Terima CR dan dibayar kan bagus, apalagi terus menerus, jadi kita tidak perlu pusing cari kerjaan ;)

Yang harus dihindari itu kalau kita terima change request terus menerus, dan hasilnya adalah:

1. Dimarahi stakeholder karena projectnya molor terus

2. Tidak kunjung dibayar karena belum mencapai milestone, padahal tidak tercapai karena sibuk mengerjakan CR

Itu yang sebenarnya kita hindari.

Nah untuk kasus tim IT internal mengerjakan project internal (tim programmernya tidak terima project dari luar) sebenarnya prinsipnya apa yang dimaui user ya kita harus buatkan.

Biasanya kalau suatu perusahaan sudah punya tim programmer sendiri (tidak outsource ke vendor), maka pastinya kebutuhan aplikasi home-made sudah besar dan kontinu. Umumnya akan banyak divisi yang 'pesan' minta dibuatkan aplikasi.

Dalam perusahaan yang dikelola dengan efisien, biasanya jumlah kerjaan > jumlah pekerja. Demikian juga pasti pesanan software lebih banyak daripada kapasitas produksi tim development. Ini pastinya akan menimbulkan pertanyaan, mana yang akan dikerjakan duluan .

Yang aplikasinya mendapat giliran belakangan tentu tidak sabar dan akan terus menagih. Apalagi kalau projectnya tidak mulai-mulai karena project yang didulukan belum juga selesai.

Nah ini bisa digunakan sebagai 'motivator' bagi manajemen untuk memberlakukan CR dengan benar. 

Serunya menjadi project manager adalah 'mempertemukan' pihak-pihak yang berkepentingan. Kita bisa jelaskan bahwa projectnya divisi B belum bisa dimulai, karena project divisi A tidak kunjung selesai. Nanti akan ada pertanyaan, kenapa tidak selesai? Karena CR terus. Kenapa CR terus? Dan seterusnya. Di sini kita bisa pertemukan manajer A dengan manajer B dengan di-wasit-i atasan keduanya.

Sedangkan untuk tim development sendiri, sebetulnya tidak ada masalah kan? Toh gajian rutin tiap bulan. 

Yang pusing itu kalo gak ada buat gajian bulan depan, gak bisa invoice karena belum mencapai milestone, dan gak akan milestone karena CR tiap hari nambah ;)

Endy Muhardin
http://software.endy.muhardin.com

--

[Ivan Darmawan]

Change request itu keharusan, bila tidak maka software bisa kadaluarsa karena tidak bisa beradaptasi dengan kondisi bisnis. Sekarang tinggal kita bagaimana menghadapi kompleksitas software development yang penuh perubahan sebagai sebuah norma dan peluang bisnis.

Regards,

Ivan Darmawan

[Angga Hantara]

Thanks mas Endy dan Mas Indra Atas Sharenya,

Memang resiko dan pusingnya tidak seberapa, cuma banyak yang menjadi "Never Ending Project" yang membuat kesan tim Divisi IT sebagai Cost Center :D.

[pramudiyan .]

Halo semua nya, ingin sedikit nimbrung nih...
Saya tertarik dari ungkapan terakhir dari Mas Angga yaitu "Never Ending Project".

Salah satu tugas dari seorang PM adalah manage persepsi dan expectation yang mana harus dapat memberikan pemahaman, menjaga harapan dan menunjukkan kepada jajaran management bahwa Project yang dikatakan Never Ending ini sudah mengalamai evolusi (perkembangan) dan akan terus ber-evolusi sampai dengan tidak ada batas. Saya setuju dengan apa yang disampaikan oleh Mas Ivan Darmawan bahwa "Change request itu keharusan, bila tidak maka software bisa kadaluarsa karena tidak bisa beradaptasi dengan kondisi bisnis". Karena software / aplikasi harus bisa mengikuti perkembangan pasar dan bagaimana divisi IT membuat strategi dan langkah - langkah dalam mengikuti perkembangan tersebut.

Dari kondisi tersebut, menurut saya akan menjadi menarik apabila divisi IT dapat memberikan suatu road map apa yang ingin dicapai oleh software atau aplikasi dalam kurun waktu beberapa tahun kedepan kepada jajaran management.

Misalnya : aplikasi saat ini adalah aplikasi dalam bentuk desktop. Lalu dibuatlah road map dalam waktu 2 tahun kedepan software ini akan dapat diakses secara mobile sehingga jajaran management diberikan kemudahan dalam melakukan monitoring kondisi perusahaan. Dan masih banyak lagi.

Yang paling penting bahwa dengan adanya IT maka akan memberikan kenyamanan dan kemudahan dalam menjaga bisnis proses dan informasi.

Terima Kasih,

Pramudiyan

Pada 27 Agustus 2014 16.17, Angga Hantara <angga....@gmail.com> menulis:

Thanks mas Endy dan Mas Indra Atas Sharenya,

Memang resiko dan pusingnya tidak seberapa, cuma banyak yang menjadi "Never Ending Project" yang membuat kesan tim Divisi IT sebagai Cost Center :D.

[Angga Hantara]

Makasih mas Dion, sekarang ini saya sedang mencoba melakukan pembuatan aplikasi menggunakan Roadmap dan Release Plan.

Jadi prinsipnya menjadikan Proyek ini sebuah Product digital(Basecamp, Twitter , etc) yang akan terus release dan update. :D .

[Endy Muhardin]

Never ending development itu bukan suatu masalah. 

Yang masalah itu development terus tapi gak kunjung production ;p

Justru kalau never ending develop - release - develop - release, artinya projectnya bermanfaat (karena dipakai user) dan adaptif mengikuti perkembangan / perubahan bisnis.

Yang penting, ada akuntabilitas apa yang sudah dikerjakan, apa yang akan dikerjakan, dan yang tidak kalah penting apa yang *tidak akan* dikerjakan.

Ini harus jelas dan disepakati semua stakeholder. Jangan usernya mau dikerjakan, tapi developernya tidak mau. Atau user mau developer mau, tapi bosnya gak mau :D

Endy Muhardin
http://software.endy.muhardin.com

2014-08-27 16:17 GMT+07:00 Angga Hantara <angga....@gmail.com>:

Thanks mas Endy dan Mas Indra Atas Sharenya,

Memang resiko dan pusingnya tidak seberapa, cuma banyak yang menjadi "Never Ending Project" yang membuat kesan tim Divisi IT sebagai Cost Center :D.

[Rizky Syaiful]

Justru kalau never ending develop - release - develop - release, artinya projectnya bermanfaat (karena dipakai user) dan adaptif mengikuti perkembangan / perubahan bisnis.

Super like this.

Menambahkan sumber bacaan terkait iterasi develop-release ini -> https://en.wikipedia.org/wiki/Agile_software_development#Iterative_vs._Waterfall

Secara umum, perusahaan-perusahaan di Indonesia masih memiliki 'mindset project' ya untuk mengelola pengembangan software-software mereka? Bagaimana di tempat bapak-ibu sekalian?

On Friday, August 29, 2014 10:38:11 AM UTC+7, Endy Muhardin wrote:

Never ending development itu bukan suatu masalah. 

Yang masalah itu development terus tapi gak kunjung production ;p

Justru kalau never ending develop - release - develop - release, artinya projectnya bermanfaat (karena dipakai user) dan adaptif mengikuti perkembangan / perubahan bisnis.

Yang penting, ada akuntabilitas apa yang sudah dikerjakan, apa yang akan dikerjakan, dan yang tidak kalah penting apa yang *tidak akan* dikerjakan.

Ini harus jelas dan disepakati semua stakeholder. Jangan usernya mau dikerjakan, tapi developernya tidak mau. Atau user mau developer mau, tapi bosnya gak mau :D

Endy Muhardin
http://software.endy.muhardin.com

2014-08-27 16:17 GMT+07:00 Angga Hantara <angga....@gmail.com>:

Thanks mas Endy dan Mas Indra Atas Sharenya,

Memang resiko dan pusingnya tidak seberapa, cuma banyak yang menjadi "Never Ending Project" yang membuat kesan tim Divisi IT sebagai Cost Center :D.

--
Anda menerima pesan ini karena berlangganan grup "Manajemen Proyek IT" di Google Grup.

Untuk berhenti berlangganan dan berhenti menerima email dari grup ini, kirim email ke it-project-indonesia+unsub...@googlegroups.com.

[Endy Muhardin]

2014-08-29 14:30 GMT+07:00 Rizky Syaiful <rizky....@gmail.com>:

Secara umum, perusahaan-perusahaan di Indonesia masih memiliki 'mindset project' ya untuk mengelola pengembangan software-software mereka? Bagaimana di tempat bapak-ibu sekalian?

Hmm ... yang dimaksud 'mindset project' itu seperti apa ya?

Dan kalau ada istilah 'masih memiliki' apakah ada juga 'sudah tidak lagi' ?

Endy Muhardin
http://software.endy.muhardin.com

[Angga Hantara]

Thanks a lot Pak Endy dan Pak Rizky,

Intinya menjadikan Never Ending itu sesuatu yang mempunya value. 

Semakin banyak CR dan Request justru menjadi suatu bukti bahwa produk kita bermanfaat 

Untuk kedepannya memang saya mau menerapkan minor dan major release per berapa bulan , sehingga request user dapat terimplementasikan tanpa membuat manajemen merasa kita selalu telat dalam 

me-delivery project.

Enaknya diskusi manajemen produk di buat thread baru saja mungkin :D.

[Endy Muhardin]

Untuk aplikasi yang digunakan di internal, bisa coba explore Time Based Release seperti yang digunakan project open source misalnya Ubuntu[1], KDE, Gnome[2], dsb.

Kita ambil contoh project yang populer, sudah terbukti sustainable (tidak pernah bolos/delay rilis sejak rilis pertama), dan scalable (skala masif, diikuti umat open source di seluruh dunia) yaitu Ubuntu[0].

Proses development Ubuntu dimulai dari issue tracker, di mana semua user (dari seluruh dunia) menginputkan bug report dan feature request. Semua request ini kemudian akan divoting oleh sesama user untuk menunjukkan seberapa banyak orang yang membutuhkan request tersebut. Request populer tentu ratingnya akan naik.

Selanjutnya, Canonical mengadakan Ubuntu Developer Summit[3]. Pesertanya ada yang datang secara fisik, ada juga yang ikutan secara remote. Eventnya terbuka untuk umum dan semua sesi direkam sehingga semua orang tahu proses pengambilan keputusan yang terjadi[4].

UDS ini akan menghasilkan gambaran umum fitur apa saja yang akan dibuat, bagaimana skala prioritasnya, dan apa saja kira-kira pekerjaan yang harus dilakukan[5].

Tahap selanjutnya adalah coding/development. Semua kontributor bekerja membuat fitur sesuai wilayah masing-masing. Ini dilakukan sampai terjadi freeze (stop penambahan fitur). Ada macam-macam freeze yang bisa dilihat di proses release Ubuntu[0].

Setelah penambahan fitur berhenti, semua orang berkonsentrasi fixing bug, tuning performance, refactoring, membuat dokumentasi, dan kegiatan beres-beres lainnya untuk mengubah barang prakarya menjadi barang production[6]. Ada beberapa milestone di sini yang menunjukkan tingkat kematangan produk, yaitu Alpha, Beta, Release Candidate, sampai akhirnya Stable Release. Proses coding dan testing di berbagai milestone yang biasa kita lakukan di ArtiVisi bisa dibaca di sini[7].

Setelah stable release, kembali ke awal proses, yaitu issue tracker. 

Terakhir, jangan lupa mempertimbangkan masalah kompatibilitas antar rilis seperti yang saya tulis di artikel ini[8].

Semoga bermanfaat.

Referensi:

0 : https://wiki.ubuntu.com/UbuntuDevelopment/ReleaseProcess

1 : https://wiki.ubuntu.com/TimeBasedReleases

2 : https://wiki.gnome.org/ReleasePlanning/TimeBased

3 : http://uds.ubuntu.com/agenda/

4 : http://www.jonobacon.org/2014/02/11/the-next-ubuntu-developer-summit-11-13-march-2014/

5 : https://blueprints.launchpad.net/ubuntu/karmic/+specs

6 : http://software.endy.muhardin.com/manajemen/aplikasi-prakarya-vs-aplikasi-production/

7 : http://software.endy.muhardin.com/java/staged-deployment/

8 : http://software.endy.muhardin.com/manajemen/release-management/

Endy Muhardin
http://software.endy.muhardin.com

--
Anda menerima pesan ini karena berlangganan grup "Manajemen Proyek IT" di Google Grup.

Untuk berhenti berlangganan dan berhenti menerima email dari grup ini, kirim email ke it-project-indon...@googlegroups.com.

[Angga Hantara]

Mantap sharing nya Pak Endy,

Model time based ini sepertinya efiisied untuk manajemen produk ,.

Tapi untuk FeatureFreeze saya masih agak kurang paham ,masih saya coba pelajari.

Apakah FeatureFreeze dilakukan sebelum proses coding attau sebelum kita testing aplikasinya. 

Thanks a lot Pak Endy ,banyak dapat penceraha saya

[Endy Muhardin]

Jawaban sebelumnya sudah saya revisi, improve, dan tambahkan referensi. 

Bisa dicek di http://software.endy.muhardin.com/manajemen/belajar-project-management-dari-ubuntu/

Klik juga link-linknya, ada kok penjelasan tentang Feature Freeze dan berbagai jenis freeze yang lain.

Endy Muhardin
http://software.endy.muhardin.com

--