1. BAB 6
Memperkirakan
Memperkirakan seperti menjadi kaya: semua orang ingin cara mudah untuk melakukannya.
Kegagalan itu, estimasi dapat dilakukan dengan mudah menggunakan alat canggih seperti yang
digambarkan.Mencari dari halaman di dinding di depan Anda. Berapa lama waktu yang Anda butuhkan
untuk melukis dinding? Apa perkiraan Anda? Dua puluh menit? Beberapa jam? Anda punya pekerjaan.
Karena kita 'melukis dinding' tugas tentu saja termasuk:
setuju warna dengan pasangan Anda (2 bulan tugas di dalam dirinya sendiri?)
membeli cat dari pabrik cat butik di Faro, Portugal
mempersiapkan permukaan merapikan Jadi dua jam pekerjaan kita sebenarnya lebih seperti pekerjaan
bulan dua atau tiga.
Hal ini terjadi, biasanya dengan mesin kopi: "Saya harus pergi ke pertemuan, Anda dapat
memberikan gambaran kasar berapa lama yang dibutuhkan untuk ...?" dan di bawah tekanan Anda
berkata: "sekitar dua jam?" Tetapi ketika Anda mencari tahu apa yang benar-benar terlibat itu lebih
seperti 3 bulan kerja. Jadi pesan pertama dari bab ini adalah: jangan menebak. Kami akan lihat nanti
bagaimana kita bisa menolak tekanan untuk menghasilkan angka acak.
Apa cara terburuk untuk memperkirakan berapa banyak proyek akan biaya? Dapatkan satu
orang junior yang tidak pernah diperkirakan sebelumnya untuk memiliki menebak dan kemudian kita
semua menjadi berkomitmen untuk menebak itu. Kita akan lihat nanti bagaimana kita bisa membawa
pengalaman untuk menanggung tugas sulit untuk memperkirakan biaya proyek.
Misalkan kita berada pada awal dari proyek jangka tahun, kita bisa memperkirakan biaya secara
akurat? Hampir pasti tidak, ada begitu banyak diketahui. Sampai kami telah menetapkan persyaratan
rinci dan dilakukan desain sangat sulit untuk mengatakan apa yang mungkin biaya membangun. Ketika
kita berada di tahap definisi proyek kita bisa menyimpulkan kita hanya bisa memperkirakan dengan
jenis akurasi Tahap 1: Persyaratan dan User Desain Fungsi.
Jadi, kami akan melakukan tugas, rinci oleh tugas, bawah ke atas perkiraan untuk Tahap 1 dan
perkiraan, jauh lebih lembut top down untuk Tahap 2. Ketika kita mendekati akhir Tahap 1 dan
memiliki desain yang dilakukan kita kemudian akan memperkirakan Tahap 2 tugas dengan tugas,
bawah ke atas, dan memberikan perkiraan yang akurat untuk itu (kami berharap!).
Top down memperkirakan semakin baik ide yang kami bisa dari biaya total proyek dan bottom up
memperkirakan semakin perkiraan yang tepat untuk tahap proyek kita akan dimulai.
Mari kita mempertimbangkan beberapa teknik untuk meningkatkan akurasi estimasi top down.
Baik proyek definisi
Kami mil dengan estimasi proyek lukisan dinding karena kita tidak memahami ruang lingkup proyek -
kami tidak memiliki definisi proyek yang telah disepakati. Lingkup kristal proyek yang jelas
merupakan prasyarat yang jelas ke atas ke bawah baik memperkirakan.
Sertakan semua biaya
Mintalah seseorang dari TI apa proyek mungkin biaya dan mereka akan berpikir tentang biaya
pemrograman dan - jika Anda beruntung - biaya ini, tambahkan dua bersama-sama dan memberikan
hasil sebagai biaya proyek. Namun dalam kenyataannya itu hanyalah puncak gunung es biaya. Bahkan
jika perkiraan untuk biaya pemrograman dan pengujian adalah tempat di, itu apa yang ditinggalkan
yang membuat cara perkiraan keseluruhan keluar.

2. Bagaimana kita mengatasi masalah itu? Memiliki daftar dari semua kemungkinan biaya proyek
mungkin terjadi: definisi proyek, analisis persyaratan, desain, dokumentasi, tim rapat, perubahan,
manajemen proyek, kontingensi, perjalanan, ditambah daftar yang sangat panjang et ceteras. Hal ini
membuat lebih kecil kemungkinannya item biaya akan diabaikan.
Sebuah daftar periksa yang baik termasuk biaya perifer juga: itu semua dengan sangat baik
mengutip $ 50K untuk mengembangkan sistem baru sedikit tetapi jika tiga sistem lain harus
dimodifikasi untuk antarmuka untuk itu, biaya tersebut harus dimasukkan di suatu tempat. Dan
misalkan sebuah konversi data akan diperlukan untuk mendapatkan data lama ke dalam bentuk yang
dapat digunakan oleh sistem kecil baru kami - adalah bahwa biaya dalam estimasi proyek $ 50K?
Sebuah daftar periksa yang baik membuat Anda berpikir sangat luas tentang semua biaya yang
berkaitan dengan proyek, bukan hanya biaya pengembangan sempit.
Daftar-pembanding ini relatif mudah untuk mengembangkan dengan melihat di mana waktu dan
uang melanjutkan proyek-proyek sebelumnya. Jika informasi yang tidak tersedia, duduk dengan dua
orang lainnya selama satu jam untuk menyusun semacam checklist: Anda akan kagum pada apa yang
Anda berakhir dengan dalam daftar itu yang akan diabaikan ketika melakukan perkiraan.
Bila Anda memiliki semacam checklist, cobalah ini. Mintalah seseorang untuk dari atas estimasi kepala
untuk proyek kecil. Kemudian memberikan checklist dan kembali sepuluh menit kemudian untuk
perkiraan revisi mereka: Anda akan terkejut melihat perbedaan.
Pemecahannya.
Jangan pernah menerima sosok global tunggal sebagai perkiraan untuk apa pun. Selalu
mendapatkannya dipecah oleh langkah-langkah utama proyek ini akan melewati.
Jika seseorang datang kepada Anda dengan rincian untuk proyek software baru-membangun dan
mengatakan upaya TI akan sebagai berikut, apakah Anda percaya perkiraan?
Bekerja dengan pengguna untuk menetapkan persyaratan 8 orang bulan
Mengembangkan Desain Pengguna Fungsi 8 orang bulan
TI Teknis desain 2 orang bulan
Membangun dan Test 2 orang bulan
Jumlah total biaya bulan pria 20 TI usaha. Pria 18 bulan untuk sampai ke akhir desain langkah
kemudian 2 bulan manusia untuk melakukan semua pemrograman dan pengujian untuk membangun
sebuah proyek software baru - apakah itu terdengar rasio kan? Jika biayanya 18mm untuk melakukan
persyaratan dan desain apa yang menurutmu membangun dan uji mungkin biaya - dalam pengalaman
Anda, berapa persen dari usaha TI dihabiskan dalam langkah-langkah membangun dan uji membangun
sebuah proyek software baru?
Misalkan di masa lalu perangkat lunak proyek baru membangun usaha TI yang sebenarnya biasanya
telah didistribusikan sebagai berikut:
persyaratan 15%
Pengguna Fungsi Desain 15%
TI Teknis Desain 10%
Membangun dan Unit Test 40%
Sistem dan User Uji 20%

3. Apakah Anda sekarang percaya perkiraan 20mm dalam contoh di atas? Paling tidak Anda akan perlu
banyak meyakinkan mengapa saat ini distribusi kerja akan sangat berbeda secara dramatis.
Perusahaan Anda mungkin memiliki sejumlah model seperti - tolok ukur terhadap yang
membandingkan perkiraan masa depan. Sebagai contoh, dalam proyek modifikasi paket kerja IT
distribusi mungkin
lebih seperti ini:
persyaratan 20%
Pengguna Fungsi Desain 20%
TI Teknis Desain 15%
Membangun dan Unit Test 15%
Sistem dan User Uji 30%
Sebagian besar jenis proyek melalui sejumlah langkah seperti ini. Sebagai masalah prinsip,
tidak pernah menerima sejumlah global tunggal, selalu mendapatkannya dipecah oleh langkah-langkah
yang relevan proyek akan melalui dan membandingkan pengalaman masa lalu sebagai pemeriksaan
kewajaran. Benchmark seperti ini bekerja hanya, namun, jika proyek menerapkan pengembangan
proses (manufaktur) konsisten: jika beberapa proyek dilakukan pengguna benar rinci dan lengkap
desain fungsi tetapi proyek-proyek lain jangan UFD pada tidak disebutkan secara jelas banyak, tingkat
yang lebih tinggi dengan rincian upaya jelas akan berbeda dari proyek untuk proyek.
Berikut adalah kuis untuk Anda.
Pada awal proyek digambarkan di sebelah kanan, manajer proyek mengatakan, biaya total akan
menjadi hari pria 1000: 400 hari pria di Tahap 1 dan hari orang 600 dalam Tahap 2. Dia tahu bahwa
dalam, proyek-proyek masa lalu serupa telah dikeluarkan 40% dari usaha mereka dalam Tahap 1 dan
60% pada Tahap 2.
Tahap 1 baru saja selesai. Ini sebenarnya biaya 800 - dua kali lipat seperti yang diperkirakan.
Jadi, perkiraan asli untuk proyek ini adalah 1000, 800 telah dihabiskan sejauh ini - apa yang akan Anda
katakan biaya proyek yang tersisa akan? Jawaban paling mungkin adalah 1200 hari manusia. Tapi apa
yang akan beberapa manajer proyek katakan? Biaya yang tersisa akan menjadi 200: 1000 anggaran,
menghabiskan 800, biaya yang tersisa 200. Ada perbedaan lebih besar antara 1200 dan 200! Selalu
melihat apa yang sebenarnya telah menghabiskan begitu jauh dan menggunakan rasio masa lalu
meramalkan kemungkinan ke depan untuk mendapatkan gambaran yang lebih realistis dari apa yang
sisa dari proyek ini adalah mungkin untuk biaya.
Aturan praktis
Bayangkan ini. Pengembang Anda memperkirakan proyek di 49 bulan orang usaha, yaitu satu
orang bisa melakukannya dalam 49 bulan (sekitar 4 tahun) atau akan mengambil 2 orang 24,5 bulan (2
tahun) atau 4 orang per tahun, dll
Hari berikutnya Anda mengatakan sponsor itu bulan pria 49 usaha dan apa pun yang ada di uang. Dia
bilang dia mampu membelinya tetapi ingin proyek selesai dalam 3 bulan mulai dari ... SEKARANG.
Dapatkah Anda melakukannya? Ingatlah proyek belum dimulai sehingga dengan tidak ada definisi dari
tim yang ada belum. Anda mengatakan Anda tidak yakin jadi sponsor menawarkan dana tak terbatas

4. dan akses ke konsultan IT - apapun yang Anda butuhkan. Dapatkah Anda melakukannya? Ketika Anda
ragu-ragu sponsor menunjukkan bahwa dalam bisnis mereka melayani 1000 pesanan sehari dengan 10
penangan pesanan dan jika mereka mendapat pesanan 2000 sehari mereka akan menggunakan 20
penangan pesanan dan masih melakukannya dalam sehari. Jadi, sponsor mengatakan, kenapa tidak
Anda mendapatkan pada 49 TI kontraktor di hari Senin pagi dan melakukan proyek dalam sebulan?
Ketika Anda melihat tak percaya dia mengatakan: "OK, memberi tahu Anda apa:? Melakukannya
dalam 4 bulan, OK" Dan jika Anda tidak memiliki alasan untuk menyanggah sarannya Anda mungkin
menemukan 4 bulan sekarang 'komitmen' Anda.
Ini adalah satu lagi perbedaan antara proses berbasis pemikiran dan berbasis proyek berpikir.
Untuk kegiatan operasional Anda cukup meningkatkan jumlah orang - hampir tak terbatas - sebagai
orang yang bekerja independen. Tapi dalam proyek menambahkan terlalu banyak orang hanya
menyebabkan kekacauan, dan kita semua tahu kita tidak bisa tiba-tiba menggunakan sejumlah besar
besok - mereka tidak ada hubungannya. Dalam proyek kita harus mulai dengan beberapa, membangun
dan kemudian turun ke nol di akhir.
Jadi berapa lama proyek pria 49 bulan ambil? Ada aturan praktis dikenal sebagai aturan akar kuadrat.
Ekspresikan usaha proyek dalam beberapa bulan pria, 49, dan mengambil akar kuadrat dari angka
tersebut. Sekarang Anda tahu mengapa kami memilih 49. Itu akan menyarankan waktu yang telah
berlalu dari sekitar 7 bulan. Ini bekerja baik sebagai panduan kasar untuk waktu yang telah berlalu
minimal TI proyek pembangunan. Bisakah kita melakukan proyek dalam 6 bulan? Mungkin, jika kita
melarang hari libur dan akhir pekan kerja. Tapi ada batasnya. Dan jika proyek mencakup Agustus
mungkin diperlukan waktu 8 bulan dalam kondisi normal karena hari libur. Tentunya jika Anda
memilih untuk tidak menggunakan orang sebanyak yang Anda bisa, proyek ini akan memakan waktu
lebih lama dari aturan praktis akan menyarankan.
Jika semua orang tahu aturan akar kuadrat, termasuk sponsor proyek, segera setelah Anda
mengatakan itu bulan 100 orang mereka tahu itu akan memakan waktu sekitar 10 bulan untuk
menyelesaikannya. Hal ini dapat mengakibatkan proyek lebih sedikit mencoba untuk melakukan hal
yang mustahil. Tentu saja, jika tim Anda senang untuk membawa tempat tidur perkemahan mereka ke
kantor dan bekerja 20 jam sehari Anda mungkin dapat secara substansial melanggar aturan akar
kuadrat. Tapi apakah tim Anda melakukan itu?
Aturan akar kuadrat kadang-kadang dikenal sebagai aturan emas persegi: ukuran tim rata-rata kurang
lebih sama dengan waktu yang telah berlalu di bulan.
Perhatikan bahwa aturan akar kuadrat memberikan ukuran rata-rata tim bukan ukuran tim yang
maksimal. Dengan demikian, dalam proyek 49mm kami, tim mulai dari 0, mungkin 2 atau 3 pada tahap
awal, mungkin mencapai puncaknya pada 12 selama tahap konstruksi kemudian turun ke beberapa
menjelang akhir sebelum kembali ke 0 di akhir.
Dalam program dari beberapa sub-proyek Anda akan menerapkan aturan akar kuadrat dengan sub-
proyek terbesar untuk mendapatkan gambaran kasar tentang durasi program.
Ini bukan rumus ajaib yang memberitahu Anda persis berapa lama proyek akan memakan waktu -
banyak faktor dapat mempengaruhi durasi proyek. Hal ini hanya panduan kasar untuk durasi terpendek
ada kemungkinan untuk melakukan proyek masuk

5. Pengguna usaha
Dalam pengalaman Anda, yang memperkirakan berapa jam usaha pengguna akan diminta untuk
"TI" proyek? Jika kita jujur kadang-kadang jawabannya adalah bahwa tidak ada yang melakukan. Jika
Anda adalah manajer SDM dan tidak ada yang memberitahu Anda berapa banyak pekerjaan yang akan
dibutuhkan dari orang-orang Anda apa yang akan Anda menganggap dalam perencanaan Anda? Sebuah
nol bulat besar. Apa pun lebih baik dari asumsi default dari nol.
Misalkan pada proyek-proyek masa lalu hubungan antara TI upaya dan usaha pengguna telah sebagai
berikut:
Upaya TI Upaya Pengguna
Persyaratan 1 1
Pengguna Fungsi Desain 2 1
TI Teknis Desain 3 1
Membangun dan Unit Test 4 1
Sistem dan User Uji 2 1
Jadi, dalam persyaratan masuk untuk setiap hari orang TI upaya telah terjadi hari seorang pria
dari upaya pengguna. Pada langkah fungsi pengguna desain untuk setiap 2 hari orang TI upaya telah
ada 1 orang hari usaha pengguna. Setelah diperkirakan upaya TI per langkah Anda bisa setidaknya
mendapatkan ide yang sangat kasar dari upaya pengguna per langkah. Jika Anda dapat memperkirakan
waktu pengguna lebih akurat Anda harus, tapi apa pun lebih baik dari perkiraan nol waktu pengguna
yang diasumsikan karena tidak ada nomor lain telah disebutkan.
Di atas adalah ilustrasi tentang bagaimana esensi yang bisa didapatkan dari proyek masa lalu untuk
menghasilkan aturan praktis yang akan di manajer panduan setidaknya proyek untuk stadion baseball
yang tepat ketika melakukan top down memperkirakan.
Realisme
Dalam pengalaman Anda jangan proyek berakhir biaya kurang dari estimasi awal atau lebih dari
estimasi awal? Lebih? Mengapa? Mengapa orang cenderung meremehkan di awal? Karena mereka
misalnya:
• ingin proyek untuk terbang
• tidak memungkinkan untuk perubahan
• tidak memungkinkan untuk kegiatan pengelolaan
• tidak termasuk kegiatan pemeriksaan kualitas
• tidak termasuk kontingensi
Mengapa manajer proyek kadang-kadang meninggalkan hal-hal ini? Rasa bersalah.
Misalkan pada usaha proyek masa lalu sebenarnya dikeluarkan sebagai berikut:
Mengubah 15%
Merencanakan, mengendalikan, mengawasi 10%
kualitas pemeriksaan 15%
terencana tugas 10%

6. Hanya masuk akal untuk mengasumsikan pengeluaran serupa pada proyek serupa berikutnya
dan karena itu termasuk hal-hal ini estimasi proyek berikutnya. Tapi harap menambahkan mereka
persentase sampai - apa yang harus mereka datang ke? Sekitar 50%. Sekarang Anda harus pergi ke
sponsor Anda atau Direksi dengan rincian perkiraan Anda, 50% yang merupakan perubahan, kualitas,
kontingensi ... Pada titik ini bahkan manajer proyek yang paling berpengalaman mulai merasa bersalah
bahwa mereka pelapis perkiraan dan apa yang mereka lakukan? Menutup mata mereka berharap hal-hal
akan pergi dan meninggalkan mereka keluar dari perkiraan. Jika Anda meninggalkan semua hal-hal di
luar proyek akan biaya sekitar dua kali lipat perkiraan Anda.
Bagaimana kita membuat manajer proyek harus realistis dan termasuk faktor-faktor yang sesuai
dalam perkiraan mereka? Membuat mereka secara pribadi bertanggung jawab atas perkiraan mereka
berikan pada awal setiap tahap. Pada akhir panggung secara independen mengukur biaya aktual dan
dekat itu adalah untuk perkiraan yang lebih besar berikutnya membayar manajer proyek naik - dan kita
bahkan mungkin membayar bonus. Dan jika sebenarnya jauhnya dari perkiraan ...
Dalam budaya agak keras bermata akan Anda termasuk persentase yang relevan dalam perkiraan Anda?
Anda akan. (Kebetulan, persentase untuk hal-hal seperti perubahan dan kontingensi biasanya akan lebih
rendah bagi perusahaan kecil, proyek-proyek sederhana, tapi bisa jadi lebih tinggi untuk besar, proyek-
proyek kompleks).
Jadi, Anda melakukan pekerjaan profesional memperkirakan dan termasuk persentase yang sesuai.
Anda kemudian menyajikan rincian biaya Anda untuk sponsor, bahkan Direksi. Mereka ngeri biaya dan
meminta anda untuk memangkas estimasi Anda. Apa yang akan Anda lakukan? Tawarkan untuk
mengurangi ruang lingkup proyek mungkin. Tapi tidak, mereka ingin ruang lingkup penuh, hanya
perkiraan yang lebih rendah.
Anda membenarkan angka dengan menampilkan actuals proyek masa lalu tetapi mereka tidak
mau tahu. Mereka hanya meminta anda untuk mengurangi perkiraan Anda. Apakah Anda menyerah?
Tidak, Anda mengatakan sesuatu seperti ini: "Inilah yang saya pikir akan biaya Jika Anda dapat
menemukan manajer lain proyek yang akan melakukannya untuk perkiraan Anda, harap Tetapi jika
Anda ingin saya untuk mengelolanya ini adalah estimasi... "
Apakah Anda akan mengambil risiko dengan mengatakan bahwa Anda kepada Dewan Direksi? Ya, tapi
resiko yang sangat kecil memang dibanding dengan risiko yang alis-dipukuli hingga menyetujui angka
yang lebih rendah dan kemudian gagal spektakuler. Contoh lain yang baik mengapa tidak mudah
menjadi seorang manajer proyek dan mengapa harus menjadi pekerjaan yang dibayar dengan baik.
Hal ini sangat benar dan tepat bahwa manajer senior dimasukkan ke dalam tantangan sulit untuk nomor
Anda: "Lima belas persen pada kualitas Tentunya yang harus 5% tidak boleh itu?" Sekarang dia
mungkin tidak punya petunjuk apa yang seharusnya - dia mencari reaksi Anda. Jika Anda segera gua
dan mengatakan Anda akan mengubahnya ke 5% seluruh kredibilitas Anda keluar jendela. Tetapi jika
Anda dengan tenang menjelaskan mengapa 15% dan tampaknya memiliki alasan yang baik sponsor,
Dewan atau siapa pun Anda sedang melakukan presentasi untuk jauh lebih mungkin untuk menerima
sisa nomor Anda. Tes tantangan acak apakah Anda baru saja membuat beberapa nomor atau apakah
Anda benar-benar tahu apa yang Anda bicarakan.
Jadi, karena Anda bertanggung jawab atas akurasi perkiraan, Anda ingin mendapatkan yang benar tapi
bagaimana Anda memperkirakan apa tahap akan dikenakan biaya?

7. Bottom up memperkirakan
1. Identifikasi kiriman dari panggung. Terdengar jelas, tetapi secara sadar berhenti dan berpikir:
apa yang harus disampaikan dari panggung? Jika kita memperkirakan Tahap 1, kiriman mungkin
dokumen persyaratan, UFD, kasus biaya revisi manfaat, Tahap 2 merencanakan dan perjanjian,
dokumen strategi pengujian, segulung rencana ... dan mungkin beberapa hal lain juga.
2. Menulis daftar yang sangat panjang dari semua tugas pekerjaan karena itu Anda perlu lakukan
di Tahap 1 agar dapat memberikan hal-hal.
3. Perkirakan berapa jam kerja setiap tugas akan mengambil, menggunakan catatan berapa lama
tugas serupa mengambil proyek-proyek masa lalu. Pikirkan setiap tugas proyek yang Anda suka
itu sudah dilakukan sebelumnya pada proyek sebelumnya. Jika Anda tahu berapa lama waktu
Anda tidak akan perlu menebak.
4. Memungkinkan untuk 'investasi'. Hal-hal seperti perencanaan, pencatatan waktu, pertemuan tim,
pengawasan, pembinaan.
5. Menyesuaikan tingkat keterampilan. Jika terakhir kali tugas mengambil 1 hari tetapi dilakukan
oleh seorang ahli, pemula mungkin mengambil dua, tiga atau bahkan empat hari untuk
melakukan tugas yang sama. Jelas, jam tugas akan tergantung pada siapa Anda memberikannya
kepada.
6. Mengembangkan rencana tahap konsep. Sketsa yang mungkin melakukan tugas-tugas dan
kapan. Hal ini biasanya akan mengungkapkan tugas-tugas tambahan yang harus dilakukan tetapi
yang tidak ada dalam daftar.
7. Menilai risiko. Kita tahu kira-kira yang akan melakukan apa dan kapan. Sekarang adalah waktu
untuk melihat rinci pada risiko panggung. Hal ini dapat mengakibatkan menambahkan tugas
pengurangan risiko ke dalam rencana (ingat serah terima tugas bagi mereka yang mungkin
meninggalkan?) Ditambah dengan jumlah usaha / uang untuk hal lain yang mungkin muncul
yang mungkin berarti tugas harus ditambahkan ke rencana sekali panggung sedang berlangsung
- di kontingensi kata lain.
8. Validasi perkiraan. Jangan pernah menggunakan hanya satu orang untuk melakukan estimasi
atau hanya satu teknik. Gunakan banyak orang dan datang pada perkiraan dalam banyak cara
yang Anda bisa: top down, bottom up, harga pihak ketiga, dibandingkan dengan proyek-proyek
masa lalu, aturan praktis, dll
Apakah Anda punya buku telepon berguna? Coba ini. Memperkirakan dan menuliskan berapa
banyak nama menurut Anda tercantum di dalamnya - hanya top down angka perkiraan.
Sekarang memperkirakan dan menuliskan ini 3 angka:
• berapa banyak halaman ada dalam buku ini (tidak mengintip!)
• berapa banyak kolom nama ada pada setiap halaman
• berapa banyak nama yang tercantum dalam setiap kolom
Sekarang kalikan 3 angka bersama untuk memberikan sesuatu yang mirip dengan bawah ke atas
perkiraan.

8. Berikutnya, melihat sampul buku telepon (tidak membuka buku). Ia mengatakan bidang
apa buku ini meliputi. Perkirakan berapa banyak rumah-rumah ada di daerah itu kemudian
kurangi persentase menurut Anda mungkin mantan direktori. Jika buku telepon termasuk bisnis
memperkirakan berapa banyak dari mereka ada di daerah tersebut dan menambahkannya.
Anda sekarang harus memiliki 3 perkiraan yang berbeda untuk jumlah nama dalam buku ini.
Sekarang, dengan tiga perkiraan menjadi pertimbangan, membentuk penilaian revisi berapa
banyak nama yang ada di buku dan menuliskannya (dan ingat kenaikan gaji berikutnya
tergantung pada akurasi perkiraan ini!).
Sekarang buka buku dan kalikan jumlah sebenarnya dari halaman x jumlah kolom per halaman
x jumlah nama per kolom. (Anda mungkin perlu melakukan perhitungan terpisah untuk bagian
perumahan dan bisnis direktori).
Perkiraan akhir Anda harus banyak lebih dekat dengan jawaban yang benar dari atas ke
bawah angka perkiraan awal Anda. Bottom up perkiraan (halaman x kolom x nama per kolom)
mungkin akan menjadi yang paling dekat dari awal Anda tiga perkiraan.
Latihan sedikit tidak selalu bekerja, tapi itu tidak menunjukkan biasanya ada beberapa cara
untuk sampai pada perkiraan untuk sesuatu. Gunakan banyak metode dan banyak orang,
mempertimbangkan hasil dalam putaran dan tiba pada perkiraan yang lebih tepat.
Mari kita kembali ke pertemuan itu dengan mesin kopi ketika Anda ditekan untuk menebak apa
yang mungkin biaya proyek. Katakanlah: "Aku tidak tahu, aku akan kembali kepada Anda."
Jika itu adalah bagian kecil dari karya mengumpulkan beberapa rekan putaran meja Anda,
melalui sesuatu yang mirip dengan latihan buku telepon, zip melalui checklist Anda
memperkirakan (jika Anda tidak punya satu, mulai mengumpulkan satu!) Kemudian sampai
pada memperkirakan. Angka itu mungkin akan sangat berbeda dari yang Anda akan diberikan di
samping mesin kopi. Tentu saja, jika Anda telah diminta untuk memperkirakan proyek besar itu
bisa mengambil hari atau bahkan berminggu-minggu kerja untuk sampai pada sesuatu yang
mendekati perkiraan yang akurat: menggunakan aturan praktis, konsultasi catatan proyek
terakhir, konsultasi pakar, berbicara dengan anggota tim potensial , mendapatkan harga
eksternal, dll Waktu yang diperlukan untuk menghasilkan estimasi yang wajar jelas berkaitan
dengan ukuran dan kompleksitas proyek.
Wajib tinjauan
Banyak perusahaan mandat yang telah menghasilkan perkiraan menggunakan apapun teknik
yang sesuai, manajer proyek harus mendapatkan rekan perkiraan terakhir sebelum mengutip
perkiraan kepada sponsor / klien / tim penjualan / manajemen senior.
Manajer proyek berbicara melalui perkiraan mereka dengan seseorang dari dukungan proyek.
(Catatan, pembicaraan melalui ini bukan latihan kotak-berdetik di mana Anda mengirim
dokumen ke seseorang yang memeriksa Anda telah mengisi formulir tertentu..) Manajer proyek
menjelaskan bagaimana mereka tiba di perkiraan - siapa yang terlibat, masa lalu yang proyek
perkiraan telah diturunkan dari atau dibandingkan dengan, dll dukungan Proyek akan
mengajukan pertanyaan seperti:???? "Di mana anggaran perubahan Mengapa hanya 5
kontingensi% Mana waktu pelatihan pengguna Berapa banyak waktu yang ada di sana untuk
jaminan kualitas Mengapa tidak ada perjalanan biaya? " Dan lain-lain
Terus terang sangat mudah bagi seorang manajer proyek untuk con sponsor (apa sponsor tahu
tentang apa yang harus disertakan dalam perkiraan?), Tetapi Anda tidak bisa menarik wol atas
mata dukungan proyek orang itu: dia sudah ada melihatnya dan melakukannya (lihat bab
tentang dukungan proyek). Tidak lagi dapat manajer proyek lolos dengan menebak, mereka
harus menunjukkan seseorang independen bahwa mereka telah tiba di perkiraan profesional.
(Kau tidak ragu berpikir bahwa Anda akan tentu saja sampai pada perkiraan Anda secara

9. menyeluruh dan profesional tanpa seperti cek Tentu Anda akan.. Cek seperti ini bukan untuk
Anda, mereka adalah untuk orang rekan dari Anda yang dinyatakan mungkin akan tergoda
hanya menebak ...)
Setelah orang mendukung proyek mulai melihat beberapa perkiraan proyek dia cepat
akan menyetel ke kesalahan orang yang paling sering membuat dan ia kemudian dapat masalah
pedoman untuk manajer proyek. Sebagai contoh: jangan lupa untuk memasukkan waktu untuk
pertemuan tim yang biasanya sekitar x% dari jam kerja total proyek.
Dibutuhkan mungkin setengah jam untuk melewati perkiraan dengan dukungan proyek - lebih
untuk proyek yang sangat besar jelas - tetapi jika tinjauan perkiraan wajib diletakkan di tempat
dapat mengakibatkan peningkatan dramatis dalam semalam dan akurasi estimasi.
Warisan perkiraan
Apakah Anda pernah mewarisi perkiraan dan harus mengelola sebuah proyek untuk itu? Apakah
itu pengalaman yang menyenangkan? Satu-satunya orang yang harus diizinkan untuk mengutip
perkiraan adalah orang yang akan mengelola proyek. Itulah satu-satunya orang dengan insentif untuk
mendapatkan estimasi yang tepat.
Jika Anda mengambil alih proyek dan perkiraan terlampir, dalam meninjau semua minggu pertama dan
jika perkiraan adalah salah berteriak keras (dan dengan implikasi menyalahkan pendahulunya Anda).
Jika Anda membiarkannya lebih dari seminggu atau jadi salah Anda, Anda menyebabkannya. Tidak
adil, tetapi yang akan menjadi persepsi.
Saran terbaik dari semua adalah: tidak pernah mengambil alih cara setengah (besar) proyek melalui -
Anda tidak pernah tahu apa yang Anda mengambil, Anda tidak pernah tahu apa batu telah terlewat
yang menyembunyikan kejutan. Pergi berlibur, pensiun, hamil - apa pun. Tapi jika ada jalan keluar dan
anda terpaksa mengambil proyek di atas, dalam minggu pertama mengangkat semua batu, bahkan
mendapatkan tinjauan independen (lihat bab dukungan proyek). Mungkin Anda akan beruntung,
semuanya baik-baik saja. Tetapi, mengapa para manajer proyek sebelumnya pergi?
Mengapa orang mendapatkan perkiraan yang salah
Ada banyak alasan orang mendapatkan perkiraan yang salah:
• Lebih dari optimisme - tidak akan salah
• Meremehkan hal-hal seperti
o kontrol
o pembinaan
o pengawasan
o proyek pertemuan
o waktu pelatihan
o komunikasi waktu
o pengguna upaya
• Kurangnya pemahaman tentang lingkup proyek
• Mengabaikan kenyataan - dengan asumsi tidak akan ada perubahan, tidak ada yang tak terduga akan
menggigit Anda
• Hanya menebak
• Mampu lolos tanpa validasi independen
• Memperkirakan bukan merupakan aktivitas dikelola

10. Saran untuk mendapatkan itu benar
Memecah program yang besar menjadi sub-proyek, siaran, tahap. Memperkirakan setiap bit secara
terpisah dan menambahkannya semua kembali.
Jauhkan rilis pertama ke fungsi penting. Hal ini membantu dalam dua cara. Release 1 jelas lebih kecil
dari semuanya akan menjadi lebih mudah dan karena itu inheren untuk diperkirakan, tetapi Anda akan
cenderung untuk menempatkan barang-barang itu ke Rilis 1 yang yang paling baik dipahami dan
karenanya lebih mudah untuk diperkirakan. Tinggalkan semua hal yang tidak jelas sampai siaran yang
kemudian oleh waktu satu berharap ini akan menjadi lebih jelas.
Jangan mengutip rentang sempit. Jika seseorang memberitahu Anda sebuah proyek yang akan menelan
biaya antara 100 dan 120 nomor yang akan kau dengar? Mungkin 100. Tapi estimator yang dipikirkan
itu akan dikenakan biaya 120. Segera salah komunikasi.
Kutip rentang yang sangat luas untuk menunjukkan tingkat ketidakpastian. "Saya sudah mencari Anda,
saya harus pergi ke pertemuan Dewan - bisa Anda ceritakan kira-kira apa proyek yang harus
dilakukan ... akan biaya?" "Ya saya bisa Ini jelas. Akan dikenakan biaya antara £ 10.000 dan sepuluh
juta pound." "Apa kau tidak bisa lebih tepat dari itu?" "Tidak, bukan pada apa yang telah Anda
mengatakan kepada saya sejauh ini." (Seorang manajer proyek dilakukan sepasang dadu untuk acara-
acara seperti Dia akan melempar dadu dan jika mereka menunjukkan, katakanlah, sembilan ia akan
berkata:. "Proyek ini akan menelan biaya sembilan." "Sembilan apa" "Saya tidak tahu? , Anda
memutuskan. ")
Jangan faktor dalam tabungan dari alat-alat baru. Penggunaan pertama mungkin akan meningkatkan
biaya karena kurva belajar.
Memiliki anggaran tetap. Ini dapat sangat memberdayakan manajer proyek untuk berkata 'tidak'
untuk non-esensial fungsi. "Saya ingin melakukannya untuk Anda tapi aku takut itu tidak akan masuk
ke dalam anggaran." Jika Anda pernah menjalankan proyek Anda akan tahu bahwa beberapa hal akan
menjadi mudah dilakukan, hal lain yang hanya tahu akan menyebabkan kesulitan. Setiap alasan untuk
tidak menyertakan hal seperti itu jika mereka tidak penting berguna.
Mencobai mereka yang datang kepada Anda dengan perkiraan: "Bagaimana peluang pekerjaan akan
biaya kurang dari perkiraan ini?" Jika orang itu sekarang mulai tertawa tak berdaya apa artinya itu? Ini
akan biaya banyak lebih dari perkiraan mereka. Minta mereka untuk mencoba lagi dan kembali dengan
angka revisi dan memberitahu mereka harus ada kesempatan 50% pekerjaan akan biaya kurang dari
perkiraan.
Periksa kehidupan estimator di dunia nyata. Beberapa orang hidup di dunia fantasi di mana tak
seorang pun membuat kesalahan, tidak ada perubahan pikiran mereka, tidak ada yang memiliki hari
libur atau pergi sakit ... Mereka memperkirakan apa proyek harus biaya. Angka itu tidak berguna bagi
manusia maupun hewan. Kami ingin tahu apa proyek yang akan menelan biaya di dunia nyata.
Memang, beberapa manajer proyek yang berpengalaman tidak pernah meminta siapa pun untuk
'perkiraan', mereka tidak pernah menggunakan kata itu. Mereka mengajukan pertanyaan seperti ini:
"Silahkan Anda akan pergi dan berhasil untuk saya berapa banyak Anda pikir ini bagian dari pekerjaan
benar-benar benar-benar akan berakhir biaya kami?" Dan mereka mengatakan jika Anda mengajukan
pertanyaan dengan cara itu Anda akan mendapatkan angka yang lebih realistis daripada jika Anda
minta 'perkiraan'.
Hindari alat memperkirakan otomatis. Alat memperkirakan meminta Anda beberapa ratus pertanyaan.
Beberapa pertanyaan yang tidak Anda pahami, sehingga Anda menebak makna dan memberikan
jawaban. Alat ini memberikan jawaban yang sangat tepat namun sangat salah - sampah, keluar sampah!
Ketika top down memperkirakan, dan Anda tidak tahu siapa yang akan berada dalam tim, Anda harus

11. mengasumsikan tingkat keterampilan rata-rata. Tapi ingat Anda mungkin akan memiliki orang-orang
yang lebih junior dari orang-orang senior sehingga tingkat keterampilan rata-rata tidak setengah jalan
ke bawah, itu lebih rendah dari itu. Jika ragu bertanggung anothers akan memiliki keterampilan peserta
pelatihan mentah.
Sketsa rencana / jadwal sebelum mengutip estimasi. Jika Anda membuat daftar semua tugas yang Anda
pikir Anda harus melakukan, ukuran masing-masing dan menambahkan itu Anda akan mendapatkan
perkiraan. Tapi ketika Anda mulai membangun
rencana Anda akan menemukan Anda harus menambahkan tugas tambahan untuk membuat
semuanya cocok bersama-sama benar. Mereka tidak di daftar Anda.
Ketika bottom up memperkirakan mendapatkan anggota tim untuk menyetujui perkiraan untuk tugas-
tugas mereka.
Masukan perkiraan Anda secara tertulis, yang menyatakan asumsi yang menjadi dasarnya. Jika
penaksir dinding-lukisan proyek kami telah berkata: "Nah, dengan asumsi tembok dipersiapkan dan ada
pot cat dan roller sana dan saya harus memberikan satu mantel itu akan memakan waktu dua jam", itu
akan sudah jelas kami memiliki pemahaman sangat berbeda dari lingkup proyek.
Menyadari kecenderungan beberapa individu. Beberapa akan memberikan perkiraan macho: "Aku I
bisa melakukan itu dalam satu hari mudah.?" Lainnya adalah sangat pesimis: "Ooh, yang bisa
memakan waktu berminggu ..." Mungkin meminta mereka berapa lama waktu yang dibutuhkan orang
lain untuk melakukan pekerjaan: "Saya bisa melakukannya dalam satu hari tetapi dia Sekitar
seminggu?"
Rahasia sesungguhnya dari Penaksiran baik adalah rekaman pada proyek-proyek saat ini berapa
banyak jam kerja setiap tugas proyek benar-benar membutuhkan waktu sehingga berikutnya kita
memiliki bukti kuat dan tidak harus menebak. Lebih lanjut tentang ini pada bab berikutnya.
Jika Anda memperkirakan dengan benar dan memungkinkan untuk semua yang kami telah
menyarankan artinya semua perkiraan Anda akan terlalu tinggi dan semua proyek akan mulai datang
dengan cara di bawah perkiraan? No Jika Anda termasuk dalam segala sesuatu memperkirakan bahwa
pada kenyataannya akan dikenakan biaya waktu dan uang hanya perkiraan akan lebih akurat. Jika Anda
menemukan bahwa semua proyek datang di bawah perkiraan kemudian mulai khawatir bahwa orang
merupakan perkiraan padding. Tapi risiko biasanya cara lain: orang cenderung meremehkan. Dalam
setengah teori proyek harus datang sedikit di atas perkiraan dan sedikit di bawah setengah sehingga
seluruh organisasi itu saldo keluar.
Kesimpulannya:
• definisi proyek yang baik adalah kunci
• Dokumen asumsi
• Gunakan sejarah
• Jangan menebak
• Mengelola proses yang menghasilkan perkiraan
• Memiliki validasi independen wajib
Actuals Rekam • pada proyek-proyek saat ini untuk memungkinkan perkiraan lebih baik di masa
"Orang yang mengatakan proyek ini akan mengambil terpanjang dan biaya yang paling adalah
orang hanya dengan petunjuk bagaimana untuk melakukannya."
"Tidak mungkin bagi orang yang tidak harus melakukannya."