scrum & budgeting project

[edwin bernadus]

dear all,

saya sedang mencoba start project dengan metode scrum.
belajar sedikit2 , based on ebook dan blog.

yang jadi pertanyaan ,
bagaimana penghitungan budgeting nya ?

dalam metode waterfall , dari awal sudah di set budget yang dibutuhkan.
kalau ada perubahan schedule dan budget , ada "change document".
kalau dikabulkan , akan dikucurkan tambahan dana.

sedangkan pada scrum , iterasi 2 minggu sekali.
dan tidak tahu sampai kapan, target yang diminta oleh user tercapai.
belum lagi flexibilitas , sehingga dapat mengubah scope.
sedangkan budget selalu fixed.

sebagai contoh :
user minta internet banking.
dengan waterfall , 6 bulan selesai.
kalau project masalah , mungkin bisa sampai 7 - 8 bulan.
dengan tambahan budget dan orang.
walaupun project berjalan kacau ,
prediksi schedule sampai goal selalu ada

sedangkan scrum , bagaimana solusi nya ?
belum lagi agile selalu memperbolehkan ada tambahan requirement,
yang diselipkan di iterasi berikutnya.

kalau requirement dikunci , tidak agile.
kalau requirement dibuka , budget nya bagaimana ?

thx,
Edwin

[Eryan Ariobowo]

Konsep scrum memang tidak membahas masalah budgeting, scrum jg bukan project management methodology.

Jika scope dan time tidak fix maka memang sebaiknya budget tidak fix.

Untuk menyeimbangkan scope, schedule dan cost memang perlu pinter negosiasi, untuk itu sangat penting bagi customer untuk aware terhadap hal ini.

Flexibilitas untuk bisa menambahkan requirement terhadap deliverable/product, menurut saya bukan berarti project tidak pernah selesai. Justru karena ada iterasi (daily scrum meeting & sprint planning meeting) maka kita tau kapan deliverable akan terselesaikan. 

Di sprint planning meeting, customer (product owner) dan tim development bisa tau kapan suatu tujuan akhir akan selesai, dengan budget yang kurang atau lebih. Jika kurang jadi bisa dinegosiasikan saat itu misalnya dengan menambah budget atau mengurangi fitur.

2011/1/12 edwin bernadus <bernadu...@gmail.com>

--
Anda menerima pesan ini karena Anda berlangganan grup "Manajemen Proyek IT" dari Grup Google.
Untuk mengeposkan pesan ke grup ini, kirim email ke it-project...@googlegroups.com.
Untuk berhenti berlangganan dari grup ini, kirim email ke it-project-indon...@googlegroups.com.
Untuk opsi selengkapnya, kunjungi grup ini di http://groups.google.com/group/it-project-indonesia?hl=id.

[edwin bernadus]

hmm kalau gitu kendala terbesar nya adalah bagaimana mengubah mind set user.
dari budget project yang besar , menjadi di potong per bagian2.
ada ide untuk sosialisasi konsep ini ke end user ? :)

thx,
Edwin

2011/1/12 Eryan Ariobowo <ery...@gmail.com>:

[Muhammad Fauzil Haqqi]

Ikutan nimbrung..
Rasanya ini mesti ditentukan di awal, si user mau gmn.. mau yg waterfall atau agile. Cm ya gitu, kalo usernya kebangeten awamnya, pasti requirement nya cm:
Deadline tgl xx
Tujuan akhir yy
Budget zz

Susah juga itu.. tergaantung user jg sih..

--
*sent from HTC Desire LeeDroid ROM*

Haqqi
http://haqqi.net
gtalk: m...@haqqi.net

[Eko Kurniawan Khannedy]

lebih sulit lagi kalo usernya langsung bozz, dia langsung pengen jadi :D

--

Anda menerima pesan ini karena Anda berlangganan grup "Manajemen Proyek IT" dari Grup Google.
Untuk mengeposkan pesan ke grup ini, kirim email ke it-project...@googlegroups.com.
Untuk berhenti berlangganan dari grup ini, kirim email ke it-project-indon...@googlegroups.com.
Untuk opsi selengkapnya, kunjungi grup ini di http://groups.google.com/group/it-project-indonesia?hl=id.

--

Eko Kurniawan Khannedy

+6285292775999

echo.khannedy[at]gmail.com

http://eecchhoo.wordpress.com/

[Martinus Wahyudi]

Klo saya, scrum tidak saya pakai buat project. Scrum bisa diterapkan untuk kalangan internal atau pengembangan produk.
Rasanya kurang tepat klo untuk proyek, karena dalam proyek tidak ada iterasi. Kalaupun ada iterasi, pasti dalam bentuk proyek yg berbeda.

Jadi memang klo terima proyek ya harus jelas targetnya. Klo terjadi perubahan, soal biaya dan pengerjaan harus jelas dalam kontrak.

Klo memang sama2 paham, bahwa scrum berupa iterasi, maka biaya bisa saja dirubah menjadi seperti gaji. Keuntungan vendor dimana? Mungkin bisa bagi share keuntungan saat produk berhasil dideliver / diimplementasikan. Selama belum ada yang dipakai / deliver, maka hanya onkos operasional yang wajib dibayar oleh klien.

Thanks & Regards,
Martinus J Wahyudi (Joshua)
Programmer Analyst
IT Bussiness Support
Tel. : +62-21-5299-8888 ext.2008

thx,
Edwin

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

[edwin bernadus]

wah arah kesimpulan nya agile itu jangan digunakan untuk project luar ya ?
karena sulit hitung budget project
dan juga mindset user yang ingin keluar duit yang pasti2 aja.

harus dipahami juga , kalau user minta budget pasti dari tahun lalu.
dan angka nya itu tidak dapat diganti.

jadi agile hanya digunakan khusus untuk keperluan internal

jadi solusi untuk client tetap balik ke waterfall.
mungkin yang diperkuat adalah iterasi dan juga unit test

kira2 , ada yang bisa menambahkan lagi ?

thx,
Edwin

2011/1/12 Martinus Wahyudi <Martinus...@allianz.co.id>:

[Endy Muhardin]

2011/1/12 edwin bernadus <bernadu...@gmail.com>:

> dear all,
>
> saya sedang mencoba start project dengan metode scrum.
> belajar sedikit2 , based on ebook dan blog.
>
> yang jadi pertanyaan ,
> bagaimana penghitungan budgeting nya ?

Untuk metodologi yang feature-set nya open seperti ini, financingnya
juga harus open.
Tidak bisa kita pakai Scrum lantas nilai projectnya fixed ditentukan
di depan pada saat quotation.

Kita ambil analogi renovasi rumah.
Pada waktu kita cari kontraktor (tukang + kenek), biasanya terjadi nego harga.
Ada 2 skema utama yang bisa dipilih : borongan atau harian.
Kalo borongan, kita sebutkan scope pekerjaannya ke kontraktor,
misalnya kita ingin :
- 4 kamar tidur, 1 di lantai 1, 3 di lantai 2
- 2 kamar mandi
- 1 ruang keluarga
- dsb
Nanti si kontraktor akan estimasi cost dan durasi.
Setelah itu nego dan sepakat.
Persis seperti skema project yang biasa kita lakukan.

Ada skema lain, misalnya kita ada banyak item yang mau dikerjakan,
tapi budgetnya mepet.
Biasanya, kita sebagai pemilik rumah akan melakukan prioritas, mana
dulu yang mau dikerjakan.
Setelah itu, kita sewa tukang secara harian.
Begitu uangnya habis, renovasinya udahan.
Begitu ada uang lagi, panggil lagi tukangnya, suruh lanjut.

Borongan juga ada dua variasi, full borongan (tenaga + bahan) atau
tenaga aja, bahan kita yang belanja.

Nah, walaupun secara tingkat pendidikan, para tukang itu umumnya lebih
rendah daripada kuli coding seperti kita,
tapi ya mereka cukup pede aja tuh minta harian.
Tambahan lagi, pekerjaan renovasi rumah itu jauh lebih predictable
daripada bikin software.
Sekali dia ngecor lantai dua, butuh waktu 2 minggu sampe kering, dan 4
minggu sampe bekisting bisa dilepas.
Mau rumahnya gimana bentuknya, mau pake semen merek Indocement,
Holcim, atau apapun, 4 minggu ya 4 minggu.
Lah ini kita bikin software, begitu Hibernate naik versi, yang tadinya
compile sukses jadi warning.
Very very unpredictable.

Ini yang jarang saya temukan di dunia kita.
Startup software development house biasanya tidak mau minta skema
harian, entah apa sebabnya.
Mungkin gak pede, mungkin udah keder duluan takut client gak mau.

Padahal sebetulnya, asal kita confident, clientnya juga mau.
In fact, ArtiVisi mulai 2011 ini tidak lagi terima fixed price project.
Semua mau kita arahkan ke charging per effort.
Dengan demikian, kita tidak perlu lagi otot-ototan setiap kali terjadi
change request.

Intinya, software development itu kegiatan yang sulit diprediksi ujungnya.
Apalagi kalo metodologinya bebas merdeka seperti Scrum dan XP.
Kalo gak disertai skema financing yang baik, ya tutup aja sw housenya.
Mendingan buka warteg, omset udah jelas.

--
Endy Muhardin
http://endy.artivisi.com
y : endymuhardin
g : endy.muhardin
s : endymuhardin
t : endymuhardin
f : http://www.facebook.com/endy.muhardin
-- life learn contribute --

[Endy Muhardin]

2011/1/12 edwin bernadus <bernadu...@gmail.com>:

> wah arah kesimpulan nya agile itu jangan digunakan untuk project luar ya ?
> karena sulit hitung budget project
> dan juga mindset user yang ingin keluar duit yang pasti2 aja.
>
> harus dipahami juga , kalau user minta budget pasti dari tahun lalu.
> dan angka nya itu tidak dapat diganti.

Kalo nilainya udah fixed, maka feature set harus fleksible.
Misalnya, budget 100 juta.
Operational cost tim development (gaji, transport, listrik, internet,
profit vendor, pajak, dsb) per bulan 30 juta.
Ya jangan minta feature set yang estimasinya > 3 bulan.
Bilang aja ke client, dengan nilai segitu, gak bisa 100 fitur, cuma
bisa 25 fitur aja.

Kalo clientnya tetap ngotot 100 juta mau 100 fitur, ya jangan diterima.
Kalo tetap diterima, ya jangan mengeluh kalo tekor.
:D

[iman.nu...@gmail.com]

Well menarik juga kalo ada yang sudah berubah menjadi service oriented, bukan lagi product oriented. Dalam business process mgmt ada konsep activity based costing/managemnt. Ini cocok utk perusahaan jasa yang lebih banyak melakukan aktivtas dibanding penggunaan bahan/material. Tapi apa client mau dicharge utk semua aktivitas project? Belum tentu. Mereka pastinya hanya akan membayar value added activity. Maka seorang PM mestinya punya standard aktivitas apa yg value added bagi customer. Namun saya tetap percaya bagaimana pun product akhir lah yg sebenarnya diinginkan. Kecuali project dlm fase maintenance.

IN

Powered by Odin

-----Original Message-----
From: Endy Muhardin <endy.m...@gmail.com>
Sender: it-project...@googlegroups.com
Date: Wed, 12 Jan 2011 20:33:22
To: <it-project...@googlegroups.com>
Reply-To: it-project...@googlegroups.com
Subject: Re: [Manajemen Proyek IT] scrum & budgeting project

[Yayang]

ga semua klien mau seperti itu, mereka kadang nganggap kita mau nipu mereka,
setelah kerjaan selesai maka akan ada error.
terus terpaksa mereka harus lanjutin lagi proyeknya.(pengalaman pribadi :(( )
dipikir2 kalau emang niat jahat, mau gimanapun proyeknya bisa diakalin
haahhhh (sambil ngurut dada)
wah, kok jadi curcol.... :)

2011/1/12 <iman.nu...@gmail.com>:

--
Yayang

[Endy Muhardin]

2011/1/12 Yayang <yayang...@gmail.com>:

> ga semua klien mau seperti itu, mereka kadang nganggap kita mau nipu mereka,
> setelah kerjaan selesai maka akan ada error.

Nah, di sini pentingnya reputasi dan track record.
Kalo kita sudah dikenal kerjanya bener dan deliverynya bagus, bisa
pake model ini.
Tapi ya namanya software development house memang harusnya
orientasinya adalah membuat SOP sedemikian rupa
sehingga menjamin delivery yang bagus.

Perhatikan bahwa ada beda yang jelas antara project delay karena
delivery yang suck
dengan project delay karena change request tidak terkendali.

Kalo kita sering mengalami yang kedua, sudah saatnya menerapkan tarif harian.