World of though, through share and action..

Sangat menarik dengan fenomena "freezing the scope of work" dan perubahan-perubahan yang terjadi dalam proses eksekusinya.

Definited Scope (Freezed Scope).
Apakah scope of work harus benar-benar dibekukan (freeze) setelah mendapatkan Approve for Execuiton / Expenditure, ataukah memang masih bisa dilakukan penambahan-penambahan SOW dalam rangka penyempurnaan (continues improvement?).
Lalu kira-kira apa ada yang salah dari proses yang yang kita ketahui melalui PMBOK dan standard-standar yang ada dan yang kita lakukan selama ini, tentang Scope Definition dan hal-hal yang harus dilakukannya?

Seperti yang diketahui, seperti yang dituliskan PMI dalam PMBOK mengenai project phasing, mengenai pentahapan proyek. Sebelum proyek masuk ke phase eksekusi, selalu ada phase yang disebut Planning (perencanaan), yang biasamya selalu diikuti proses-proses dari:
Opprtunity (with Options) kemudian feasibilty study: selected Option, define the option, menentukan option yang terpilih dan menentukan scope yang terdefinisikan dengan jelas, (Scope definition) yang kemudian akan dilakukan dalam sebuah proyek.
Namun rupanya setelah semua fase itu dilalui, masih saja ada options atau bahkan sesuatu yang baru masuk kedalam SOW yang telah diapprove bersama. Menganalisa hal ini ada beberapa hal yang menjadi kemungkinan.

Overlook dan under estimate.
Overlook dan Under Estimate mungkin bisa jadi yang menjadi salah satu (atau dua) permasalahan besar dalam mendefinisikan suatu proyek.
Kemampuan mengestimasi dan mengkritisi terhadap hal-hal yang detail menjadi salah satu kuncinya.
Seperti yang sering disebut: "The Evil is in the detail..." Artinya dalam perecanaan pun diperlukan pendetailan rencana (dalam tingkatan tertentu, tergantung kesiapan data dan Informasi)
Masalah Overlook ini, atau bahasa lainnya "terlewatkan", merupakan istilah yang sering terjadi pada design dan estimasi dalam masa planning ini. Kejadian ini bisa jadi karena semata ketidak telitian atau mungkin faktor-faktor manusia yang lain.
UnderEstimate, atau memandang rendah atau estimasi yang terlalu kecil terhadap suatu aktifitas / equipments yang akan dipasang.


Lalu bagaimana menyikapinya?
Overlook ini dapat diminimalisir dengan Penerapan Quality assurance dalam proses Feasibilty Study / Engineering study ini.Artinya proses check dan re-check dalam setiap deliverable yang dihasilkan dalam phase perencanaan ini mempunyai kualitas yang baik.
Untuk UnderEstimate dapat di kurangi dengan selalu update dan reknosolidasi data base dan informasi. Market intelegent dan perencanaan kerja yang telah di definisikan dengan baik dapat membantu estimasi yang lebih tepat.
Artinya permasalahan itu dapat diminimalisir, dengan membuka chanel KOMUNIKASI sebesar-sebesarnya pada saat planning phase, dalam artian proses untuk review, check dan re-check dari semua stakeholder, sehingga semua informasi dapat tertangkap dengan baik selama proses ini.

Sehingga semua Risk, baik Known, known unknown dapat diantisipasi baik secara biaya (cost) maupun jadwal pekerjaan (schedule). Sehingga diharapakan didapatkan contigency yang mencukupi untuk menghandle semua known (identified) risks yang muncul.
Yang kemudian apabila resiko unknown-unknown adalah resiko yang sama sekali tidak diantisipasi, sehingga bisa jadi menjadi show stopper, atau pernyataan proyek dapat berhenti.
Dan kemudian selanjutnya "mempersempit" chanel komunikasi untuk terjadinya perubahan, dengan filter SOW yang telah disepakati bersama. Mempersempit dalam artian membatasi ke semua stakeholder bahwa perubahan yang terjadi dapat mengganggu kinerja proyek secara keseluruhan.


Namun bila perubahan itu tetap masih ada...
Sampai batas mana perubahan dapat diakomodir dalam sebuah defined scope (freeze scope)?
Saya kira sebuah perubahan,yang apabila memang tak dapat dihindari, apalagi kalau memang perubahan itu merupakan perubahan yang dapat mengakibatkan kegagalan proses dalam sebuah end result sebuah proyek. Bisa jadi perubahan itu meerupakan hal yang sangat significant, sehingga apabila memang perubahan itu tidak dilakukan dapat mengganggu kinerja end product sebuah hasil proyek.
Seperti yang disarankan oleh PMI dalam PMBOKnya, keputusan ini (seharusnya) dilakukan oleh Change Board, atau pihak-pihak yang berhak melakukan keputusan perubahan dan bukan Project Manager dan/atau PMT.
ChangeBoard ini sangatlah penting keberadaannya, karena dengan adanya CB ini, akan memindahkan responsibilty terhadap perubahan dari PM/PMT kepada CB.
PM/PMT tidak dapat disalahkan apabila memang ternyata dalam kenyataannya perubahan itu memang harus dilakukan.