Archive for October, 2007

08
Oct
07

(Lagi) Lima Alasan Mengapa Proyek PL Gagal

Ada dua pertanyaan mendasar yang sering muncul dan mengganggu dalam proyek perangkat lunak (software). Pertama, mengapa para profesional software yang cukup berkompeten menyetujui begitu saja tanggal penyelesaian proyek, ketika mereka sendiri tidak punya ide mencari titik temunya? Kedua,  mengapa para eksekutif yang cukup rasional langsung  menerima komitmen jadwal, ketika para insinyurnya tidak menunjukkan tanda-tanda bisa memenuhi komitmen tersebut? Selanjutnya, kemana software akan dikonsentrasikan, bila para eksekutifnya bersikeras menerima perjanjian yang samar-samar dan perencanaan yang tidak lengkap? Sementara, bila pihak manajemen tidak disiplin melakukan pendekatan pada komitmen jadwal, bisa membawa dampak   pada salah satu dari lima penyebab kegagalan yang biasa terjadi pada proyek perangkat lunak berikut ini.    

A. Unrealistic Schedules

Jangan dikira bahwa dengan menekan jadwal secara membabi buta akan mempercepat selesainya pekerjaan, tapi justru akan menundanya. Ketika menghadapi jadwal yang tidak realistis, anggota tim teknik sering berperilaku tidak rasional.  Mereka tergesa-gesa mengerjakan ‘requirement’, menghasilkan desain yang dangkal dan melakukan coding secara buru-buru. Perjuangan yang gila untuk membangun sesuatu dipastikan akan menghasilkan  produk PL berkualitas rendah dan berfungsi salah, sangat tidak sempurna dan mengalami keterlambatan waktu.

B. Inappropriate Staffing                            

Hanya ada cara untuk menyelesaikan proyek teknik dengan cepat dan efisien yaitu dengan menempatkan sejumlah orang yang tepat dan kemudian memproteksinya dari banyaknya interupsi dan gangguan. Hal ini bisa membangun motivasi dan teamwork yang efektif, yang diperlukan untuk mendapatkan hasil yang berkualitas. Karena bila manajer gagal memberikan  waktu yang tepat, sumberdaya yang layak dan cukup terlatih, proyek tersebut  biasanya akan gagal. 

C. Changing Requirements During Development

Ketika mulai mendesain dan membangun produk, tim teknik harus mengetahui produk apa yang mereka buat. Sayangnya pihak manajemen, pemasaran dan bahkan para pengguna sering tidak mengetahui apa yang mereka inginkan. Lebih parah lagi, mereka pikir mereka mengetahuinya dan kemudian mengubahnya sebagian lewat pekerjaannya. Padahal, ketika ada perubahan kebutuhan (atau tujuan) di tahap awal pekerjaan, biasanya akan ada sesuatu  yang pada akhirnya ikut berubah. Hal ini bisa dikatakan sebagai pemborosan waktu dan biaya dan bisa mengacaukan pekerjaan

D. Poor-QualityWork

Ketika eksekutif menerapkan jadwal yang tidak realistis, proyek PL bahkan tidak hanya mengalami keterlambatan dalam pengiriman hasil produk namun hasil produknya juga tidak bisa bekerja. Ada sebuah ungkapan tentang kualitas PL “ bila tidak ada hal yang harus dikerjakan, kita bisa membuatnya sangat cepat”. Tetapi sistem akan mengalami bencana, karena setiap saat tidak bisa dipastikan perubahan  apa yang dibuat dalam produk atau ketika penggabungan produk

E.  Believing in Magic

Commercial off-the-shelf software (COTS)  merupakan cara yang menarik untuk menghemat waktu dan biaya pengembangan proyek. Tetapi COTS bukanlah sebuah peluru perak. Jika ia tidak dikelola dengan baik, bisa menimbulkan bencana. Produk COTS bisa bekerja secara sempurna untuk keperluan “demo”, misalnya bila terjadi benturan ketika diterapkan pada konfigurasi perangkat keras yang berbeda, laju data yang lebih tinggi atau bahkan bila ada kesalahan memasukkan data. Harusnya dilakukan pengujian yang cukup untuk menyingkap kondisi yang tidak pernah dicoba sebelumnya. Jika ternyata program tersebut menyusahkan pada saat dilakukan uji coba, hampir bisa dipastikan akan menemui banyak kendala ketika digunakan dalam produksi.

08
Oct
07

Langkah-Langkah Perencanaan Proyek Menggunaka Project KickStart4

d.JPG

    1.  Name Your Project

Nama proyek. Setiap proyek memiliki nama. Untuk memulai perencanaan proyek, berilah nama yang singkat namun mewakili deskripsi proyek.

k1.JPG 

  

2. Type each phase in your project

Tulis setiap tahapan dalam proyek. Untuk memulai memikirkan sesuatu, pertimbangkan bagaimana proyek tersebut akan dirinci dalam aktifitas-aktifitas utama atau tahapan-tahapan. Tulis tahapan-tahapan tersebut baris demi baris atau klik tombol “Phases Library” dan tarik tahapan-tahapan tersebut pada daftar.

k2.JPG

        3.  Type your goals for the project

Tulis semua tujuan proyek . Tujuan adalah apa yang bisa diharapkan dari penyelesaian proyek tersebut. Bisa juga dengan cara  klik tombol “ Goals Library” dan tarik contoh-contoh tujuan ke dalam daftar. Klik tombol “Advisor” untuk mendapatkan tip-tip dalam tujuan pengembangan.

k3.JPG

 

 4.  Select any similar projects

Pilih  beberapa proyek yang mirip. Proyek kadang-kadang memiliki tugas yang bersifat umum. Hal ini merupakan kesempatan meminjam gugus tugas dari proyek-proyek terdahulu dalam membantu merencanakan proyek kita. Klik semua proyek yang mungkin berisi tugas-tugas yang berhubungan dengan persoalan proyek kita.  Untuk mencari proyek pada folder lain bisa klik tombol “Browse”.

k4.JPG

 

        5.  Type the name of the people working on your project

Ketik nama orang-orang yang bekerja dalam proyek. Buat daftar individual atau kelompok yang mungkin  bisa menyediakan sumber daya dalam proyek, termasuk diri kita sendiri. Daftar tersebut bisa disimpan dalam “People Library”. Harapannya, para pengguna bisa memanfaatkan kontak yang ada di “People Library  tersebut.

k5.JPG

 

           6.   List the obstacles in your project

Buat daftar hambatan-hambatan yang bisa terjadi dalam proyek.  Setiap proyek memiliki  hambatan-hambatan, namun hal tersebut bisa diatasi bila telah diantisipasi sebelumnya. Buatlah daftar hambatan-hambatan yang bisa muncul dalam proyek atau klik “Obstacles Library” dan tarik contoh-contoh hambatan ke dalam daftar yang dibuat.

k6.JPG

           7.   Assign tasks to people

Menetapkan tugas masing-masing orang yang terlibat dalam proyek. Klik pada “phase or task” di sebelah kiri. Kemudian klik pada masing-masing orang yang diinginkan mengerjakan tugas tersebut. “Ctrl-click” pada  beberapa tugas untuk menetapkannya sebagai sebuah group. Beri tanda cek pada tugas-tugas sebagai tanda bahwa tugas telah diberikan.

k7.JPG

           8.   Review and edit your Task List

Tinjau kembali dan edit daftar tugas tersebut bila perlu. Bisa menggunakan “icon” yang tersedia untuk mengurutkan tugas, membuat sub-tugas dan menambahkan catatan dan  lampiran.

k8.JPG

            9.   Adjust your project schedule in the Gantt chart 

Susun jadwal proyek dalam Gant chart. Untuk memudahkan penjadwalan, untuk proyek baru dibuka dengan “starter schedule” . Kita dapat mengubah tanggal pada bagian kiri. Atau rentangkan dan gerakkan “taskbars” pada sebelah kanan. Hasilnya akan bisa dilihat secara otomatis

   k9.JPG

08
Oct
07

Project Management Software “Project KickStart 4”

4.JPG 

Project KickStart mempunyai kemampuan yang luar biasa dan mudah digunakan sebagai program manajemen proyek pekerjaan sehari-hari.  Programnya meliputi perencanaan sebuah proyek dan pembuatan jadwal dalam bentuk “Gantt chart”.

Project Planning Wizard

Project KickStart dipandu melalui 6 tahap manajemen proyek untuk merencanakan dan mengorganisasi detail proyek. Proses perencanaan  memfokuskan perhatian pada struktur proyek, tujuan, sumber daya, resiko dan isu-isu strategis yang berpengaruh langsung pada kesuksesan proyek.  Garis besarnya proyek akan dimasukkan pada bagian Phases, Tasks, Subtasks, Assigment  dan informasi level tinggi lainnya.     

11.JPG

Create  Gantt Chart Schedule

Rencana proyek secara otomatis akan terdisplay dalam Gantt chart dan siap dilakukan penjadwalan, dimana kita bisa menambahkan tanggal dalam jadwal. Juga bisa menambahkan besarnya biaya untuk suatu pekerjaan tertentu, catatan-catatan dan prosentase pekerjaan dalam Gantt chart.   Ada 3 pilihan model Gantt chart dan bentuk laporan yang tersedia. Laporan juga bisa dicetak bervariasi, misalnya untuk anggota team, manajemen ataupun vendor. Tampilan data proyek bisa dibuat dalam berbagai cara. Pada Project KickStart 4.0 dilakukan perbaikan pada antar muka pengguna (user interface), tampilan GANNT charts, menambah warna , menambah kolom biaya, prosentase pekerjaan, kolom catatan mengikuti  attaching links” dari pekerjaan.

Create  a Gantt Chart Schedule

Export to Microsoft Office and Other Applications

 Jadwal proyek bisa dibuat dalam program Project KickStart  itu sendiri atau bisa juga mengambil datanya dari Microsoft Outlook, Word, Excel, PowerPoint, Microsoft Project, MindManager dan ACT!  Gunakan MindManager dan WBS Chart untuk mendapatkan detail laporan, lembar kerja dan slide presentasi. Sedangkan untuk track progress bisa dalam Outlook dan ACT. Jika proyek menghendaki fitur tracking yang lebih banyak lagi bisa menggunakan Microsoft Project.Features and benefits

  • Easy-to-use project management program
  • Work with any size project — up to 1000 tasks and 100 resources.
  • Project planning wizard gets project details organized quickly.
  • Drag and drop Libraries of typical phases, tasks, goals and obstacles.
  • Multi-line cut and paste. 10 levels of subtasking
  • Gantt chart scheduling and tracking.
  • Print a variety of Task Reports and 3 styles of Gantt chart schedules.
  • Save As HTML — post project plans on your Intranet.
  • Interoperability– Hot link to Outlook, Word and Excel — include project plans in proposals and business plans.
  • Hot link to Microsoft Project, SureTrak, P3, FastTrack Schedule, Project Scheduler, Milestones, WBS Chart, PowerPoint, MindManager, ACT! — great for novice users.
  • Includes a variety of Sample projects.
  • FREE technical support.

System Requirements

  • Windows Me / NT / 2000 / XP / And Now Vista
  • 128 MB RAM, 25 MB free disk space
  • Can also be installed on a network. Check out Tech FAQs for more details.

3

01
Oct
07

Kriteria Keberhasilan Proyek Perangkat Lunak

Standish Group telah melakukan penelitian parameter keberhasilan proyek perangkat lunak dengan mengidentifikasi alasan-alasan yang menyebabkan kegagalan proyek perangkat lunak. Untuk keperluan tersebut, proyek PL diklasifikasikan ke dalam 3 tipe resolusi yaitu resolusi tipe 1 untuk proyek sukses, resolusi tipe 2 untuk proyek challenged dan resolusi tipe 3 untuk proyek yang rusak (gagal).

Proyek dikatakan sukses (success), bila proyek tersebut bisa diselesaikan tepat waktu, biaya tidak berubah dengan fitur dan fungsi seperti yang direncanakan semula. Sementara yang termasuk tipe proyek challenged bila proyek tersebut mampu diselesaikan, namun biaya operasionalnya melebihi perkiraan, waktu penyelesaiannya menjadi molor serta menawarkan fitur dan fungsi yang lebih sedikit dari yang direncanakan. Sedangkan proyek impaired, bila proyek tersebut dibatalkan karena ada beberapa hal yang terjadi selama masih dalam proses pengembangan.

Aspek yang paling penting dari penelitian yang dilakukan Standish Group adalah menemukan sebab-sebab mengapa proyek gagal. Untuk keperluan ini jajak pendapat dilakukan pada manajer eksekutif IT untuk ditanyai pendapatnya tentang mengapa proyek bisa sukses. Ada tiga alasan utama yang bisa menyebabkan proyek PL sukses, yaitu keterlibatan pengguna (user involvement), dukungan manajemen eksekutif (executive management support) dan pernyataan jelas dari kebutuhan (a clear statement of requirement). Memang ada beberapa kriteria yang lain, namun jika tiga elemen tersebut sudah pada tempatnya, maka kesempatan poyek akan sukses jauh lebih besar. Sebaliknya, bila hal tersebut tidak terpenuhi potensi gagal bisa meningkat tajam.

Tabel 1. Kriteria Proyek Suksesk10.JPG

Dalam jajak pendapat tersebut, responden juga diminta pendapatnya tentang faktor apa saja yang menyebabkan proyek challenged, hasilnya seperti terlihat dalam tabel 2.

                                  Tabel 2. Kriteria Proyek Challanged   

           k11.JPG

Hasil jajak pendapat tentang opini mengapa proyek menjadi rusak dan terancam dibatalkan, faktor terbesar dikarenakan daftar kebutuhan yang kurang lengkap serta terlalu sedikitnya keterlibatan pengguna.

                                      Tabel 3. Kriteria Proyek Impaired

         k12.JPG

01
Oct
07

3 Kunci Sukses Proyek Perangkat Lunak

          Ada tiga faktor yang umumnya mempengaruhi keberhasilan sebuah proyek perangkat lunak (PL). Masing-masing merupakan faktor kunci yang membentuk sebuah tripod dari suatu proyek, sehingga ketiga kakinya harus berada dalam posisi yang benar agar tripod tersebut dapat berdiri kokoh. Kaki-kaki tersebut merupakan konotasi dari ketiga faktor kritis yang berperan dalam kesuksesan sebuah proyek  PL yaitu  top management support, a sound  methodology dan solid technical leadership.

Top Management Support

Dukungan manajemen puncak dianggap sebagai faktor sukses yang paling penting. Tanpa komitmen penuh dari menejemen puncak, ketika timbul masalah dalam proyek (musibah yang tidak bisa dielakkan) bisa menyebabkan kolaps. Personil manajemen dalam organisasi yang mengerjakan proyek sistem harus berada di barisan paling depan untuk mengatasi penyimpangan yang terjadi secara serius. Mereka perlu dipersiapkan untuk menemukan sebab-sebab yang tampak maupun yang tidak tampak dibalik kemunduran sebuah  proyek atau  yang sedang mengalami masalah. Manajemen puncak harus benar-benar berada dibelakang sebuah proyek dan begitupun bila akhirnya proyek tersebut menjadi sukses.

Ada perbedaan antara proyek sistem dengan gedung perkantoran. Ketika sebuah gedung baru dikerjakan separohnya, maka sudah ada sesuatu yang bisa dilihat. Sementara jika Proyek PL masih  setengah jadi, hanya  sedikit sekali (bahkan tidak ada sama sekali) yang bisa dilihat. Manajer perlu mengetahui apa yang dapat mereka harapkan dan kapan hal tersebut bisa terjadi. Mereka tidak bisa begitu saja berasumsi bahwa proyek yang telah berjalan 50% berarti  juga telah menghabiskan biaya  50%.

Seorang manajer seringkali  tidak memahami desain sebuah sistem, sehingga mereka jarang memberikan nasihat teknis. Manajer tersebut sebaiknya membawa auditor obyektif  agar manajemen bisa tahu bahwa mereka sedang tidak tertipu atau proyek tidak sedang mengalami mismanajemen. Bila mereka tidak memiliki kemampuan menilai situasi, solusinya cukup sederhana yaitu dengan memiliki technical audit yang bisa mensyahkan tindakan tim pengembangan dan memberikan informasi yang diperlukan untuk kelanjutan proyek.

Development Methodology

Banyak sistem yang dibangun dengan sedikit memikirkan proses. Segera setelah informasi yang diperoleh cukup memadai, pekerjaan coding langsung dimulai. Lambatnya perhatian pada proses sebenarnya bisa membunuh sistem itu sendiri. Kesalahan terbesar biasanya disebabkan adanya kebutuhan user yang diabaikan. Akibatnya sejumlah besar kode perlu ditulis ulang, karena tidak ditemukan dalam user requirement. Dampak lanjutan dari kesalahan tersebut, meskipun pada akhirnya proyek bisa selesai, namun sistem menjadi tidak efisien dengan testing yang tidak mencukupi pula. Dengan kata lain, tanpa memikirkan proses secara baik, sebuah proyek hanya memiliki sedikit kesempatan bisa diselesaikan dengan baik. Kalaupun bisa sukses, mungkin hanya menuliskan ulang bagian-bagian substansial dengan biaya yang membengkak.

Ini mungkin mengejutkan bila ada pendapat yang mengatakan bahwa metodologi tidak perlu diseleksi, tetapi kenyataannya hal tersebut bisa benar adanya. Apa yang terjadi bila ada beberapa metodologi? Tidak ada kajian jelas yang menggambarkan suatu metodologi lebih baik dari yang lain. Yang paling penting bahwa  proyek dikelola dengan cara-cara yang konsisten, fokus serta sejak awal telah berpikir lewat kerangka proses secara hati-hati.  

Technical Leadership

Bukan hanya bangunan saja yang membutuhkan arsitek, namun sistem informasi juga memerlukan pimpinan teknik. Agar sukses, arsitek ataupun pimpinan teknik harus berada dalam satu kendali arsitektur proyek yang sama, yang disebut model data atau desain aplikasi. Kendali level ini harus dikenali dan dimengerti oleh setiap orang yang terlibat dalam proyek. Sebaliknya, bila setiap bagian sistem dikonstruksi secara berbeda  maka potongan-potongan tersebut tidak akan cocok bila digabungkan di kemudian hari. 

01
Oct
07

Faktor-Faktor Yang saling Mempengaruhi Kesuksesan Proyek Perangkat Lunak

Interdependent Factors 

Dalam setiap proyek sistem perangkat lunak, terdapat  empat faktor yang saling berpengaruh satu sama lain, yaitu :           

§         Harga (Cost)

§         Kualitas (Quality)

§         Kecepatan (Speed)

§         Resiko (Risk).

Namun tidak mungkin mendapatkan hasil terbaik keempat faktor tersebut secara bersamaan. Terutama, tidak  akan bisa membangun sistem dengan biaya murah, berkualitas tinggi, diselesaikan secara cepat dengan sedikit atau bahkan tanpa resiko kegagalan sama sekali. Kebanyakan hanya tiga faktor pertama saja yang mungkin bisa direalisasikan,  yaitu membangun sistem berkualitas tinggi secara cepat, biaya yang relatif murah dengan jalan memotong bagian-bagian tertentu dan hanya melakukan sedikit atau bahkan tanpa pengujian (testing) sama sekali. Bagaimanapun juga, resiko kegagalan sistem tersebut akan meningkat secara dramatis.  

 Dalam setiap proyek, dari keempat faktor tersebut hanya dua saja yang mungkin berhasil, sedang dua sisanya harus diatur. Dari keempat faktor tersebut, dua yang paling penting adalah resiko dan kualitas. Sistem yang dibuat harus mampu bekerja dan memenuhi kebutuhan user.  Hal ini menyisakan kecepatan (waktu) dan biaya (uang) sehingga harus diatur menyesuaikan. Bila proyek menuntut waktu pengembangan yang cepat atau biaya rendah, maka kualitas dan resiko akan digeser menyesuaikan. Jika ada yang mengatakan bahwa dengan menggunakan produk X dan metodologi Y maka  sistem dapat dibangun cepat  dengan biaya murah, rasanya hal tersebut kurang realistis. Jika dipaksakan pada resiko rendah dan berkualitas tinggi, harus bisa menerima kenyataan bahwa waktu dan biaya harus diatur agar dapat mencapai maksud tersebut. 

Migrasi Data Dan Implementasi 

Dua faktor tambahan yang juga menentukan sukses atau gagalnya proyek adalah migrasi data dan implementasi proyek itu sendiri. Namun kenyataanya kedua faktor tersebut sering dilupakan. Migrasi data seharusnya direncanakan lebih awal pada setiap proyek. Ironisnya, migrasi data seringkali dianggap sebagai proyek terpisah. 

Meskipun telah berkeahlian baik, didokumentsikan dengan baik dan desain telah dibuat dengan teliti, sebuah sistem masih berpotensi gagal 10-20% (dari waktu), dikarenakan implentasi yang tidak bisa ditangani secara baik. Hal ini dapat disebabkan pelatihan user yang kurang memadai, lemahnya transisi dari sistem lama ke yang baru dan kurangnya dukungan user ke sistem baru.

01
Oct
07

Faktor-Faktor Penyebab Kegagalan Proyek Perangkat Lunak

Hampir semua proyek perangkat lunak (PL) dapat dikatakan mengalami kegagalan, walaupun hanya di bagian tertentu saja. Hal ini dikarenakan, hanya sedikit saja proyek yang dapat memenuhi semua target yang ditetapkan baik dari sisi harga, jadwal waktu penyelesaian, kualitas maupun kebutuhan yang diinginkan pengguna (user).        

Hanya saja yang masih menyisakan pertanyaan, mengapa kebanyakan  proyek yang gagal tidak pernah dikaji lebih lanjut, bahkan oleh lembaga yang mengalaminya sendiri ? Seandainya hal tersebut dilakukan mungkin akan dianggap sebagai suatu petualangan yang tidak akan membuahkan hasil (pemborosan), sehingga sedikit yang mau menginvestasikan waktu dan uangnya untuk mengumpulkan data dan menganalisanya. Bahkan data yang telah berhasil dikumpulkannya mungkin juga hanya berhasil disusun saja, kemudian disembunyikan untuk melindungi karir dan reputasi lembaga tersebut. Walhasil pemilik informasi tentang kegagalan-kegagalan proyek sering kali berat untuk mempublikasikannya walau untuk tujuan tertentu (yang baik).       

Sekali lagi, yang dimaksud dengan kegagalan disini adalah proyek perangkat lunak yang mengalami pembengkakan harga, penyelesaiannya molor atau kualitasnya bermasalah (challenged project) maupun yang mengalami pembatalan secara tiba-tiba (failed project).  Dan uraian berikut ini akan menjelaskan beberapa penyebab kegagalan yang sering terjadi dalam pengembangan proyek perangkat lunak. 

 1.  Poor User Input

 Masukan penting yang diperlukan untuk membangun perangkat lunak (PL) adalah bagaimana sistem yang dibuat tersebut akan dipakai di lapangan. Sedangkan yang berkompeten memberikan masukan dalam hal ini adalah klien (user) itu sendiri. Hanya saja yang sering terjadi , bahwa user kurang terbuka dalam menyatakan kebutuhannya, padahal hal itu sangat berdampak pada pekerjaan software developer. Akibatnya, pihak developer harus bekerja keras untuk memahami apa saja yang menjadi bisnis user, sehingga bisa memprediksi fasilitas apa saja yang diperlukan. Hal tersebut sering berkelanjutan hingga proses development selesai. 

  2.  Stakeholder Conflichts

 Stakeholder bekerja di bawah ilusi bahwa semua orang harus mendapatkan apa yang mereka inginkan. Akibatnya sejumlah alternatif yang berbeda dipersiapkan untuk mengakomodasi semua permintaan yang mungkin timbul. Perbedaan tersebut selanjutnya diekspos oleh developer dan mengakibatkan sistem menjadi ambigu. Konflik dalam stakeholder ini bisa menjadi biang utama kegagalan sebuah proyek, karena pihak developer tidak dapat memahami apa yang sesungguhnya diinginkan oleh stakeholder.  

3.  Vague Requirement

Perlu bekerja keras untuk mempelajari apa yang akan terjadi ketika sebuah proyek mulai dikerjakan pada saat kebutuhan yang diinginkan belum jelas. Bisa jadi untuk setiap step yang diambil kemudian perlu mundur tiga langkah ke belakang. Biaya proyek dan kualitas hasil yang berubah cepat bisa lepas dari kontrol, sehingga perusahaan bisa dipersalahkan bahkan bisa kehilangan kontrak untuk menyelesaikan proyek tersebut.Seperti yang sering terjadi pada sejumlah proyek gagal, bahwa lingkup permasalahan yang tidak cukup sempit tidak bisa memberi peluang yang masuk akal untuk sukses. Oleh karenanya perlu memastikan kebutuhan yang diinginkan user sebelum pekerjaan tersebut dimulai. Kendati demikian, kenyataannya perkembangan kebutuhan masih saja terjadi. Permasalahan ini bisa diatasi bila arsitektur dan prosesnya dibuat mampu mengakomodasi perubahan atau setidaknya dibuat ketentuan jelas bagaimana dan kapan requirement bisa ditambahkan, dilepas dan diimplementasikan, termasuk siapa yang akan menanggung biaya perubahan tersebut. 

4.  Poor Cost and Schedule Estimation  

Sebenarnya tidak fair menuduh setiap proyek PL pasti mengalami kegagalan, jika tidak mengaitkan antara biaya yang dikeluarkan dengan tujuan yang diinginkan. Sama seperti yang lain, setiap proyek PL juga memiliki jadwal dan biaya minimal yang dapat dicapai. Permasalahan bisa muncul kapan saja manakala orang  yang membuat jadwal tidak mendengarkan masukan orang yang biasa mengerjakannya. Misalnya untuk menyelesaikan sebuah program biasanya diperlukan 5 orang selama setahun, jelas berbeda seandainya hanya dikerjakan 4 orang selama 8 bulan, baik dilihat dari sisi desain maupun quality-check-nya.   

  5.  Skills That Do Not Match The Job

Pengerjaan proyek dengan teknologi tinggi memerlukan seorang manajer dengan kemampuan teknik yang hebat. Penanggung jawab proyek harus bisa menempatkan orang yang memahami dampak dari resiko teknik yang diambil. Namun demikian, seorang teknolog yang baik tidak perlu diseimbangkan dengan manager yang baik, karena kemampuan manajemen dan pemrograman tidak bisa dipertukarkan.Pada proyek yang lebih besar membutuhkan orang-orang yang cakap dalam planning, oversight, organization dan communication skill; sementara seorang teknolog yang brilian tidak perlu memiliki keahlian tersebut.Sebuah team yang beranggotakan orang-orang dengan gaji lebih besar namun memiliki kemampuan spesialisasi yang baik, akan lebih pantas dipilih daripada sebuah kelompok yang terdiri dari orang-orang dengan gaji rendah yang masih memerlukan berminggu-minggu bahkan berbulan-bulan untuk mempelajari sebuah proses atau teknologi baru sebelum mereka mulai mengerjakannya. 

6.  Hidden Cost of  Going “Lean and Mean”

Sejumlah kegagalan akan dipandang sebagai hasil langsung dari kinerja yang buruk, meskipun sesungguhnya kinerja yang buruk tidak menunjuk pada faktor yang signifikan dalam kegagalan pada kebanyakan proyek. Kegagalan sebuah proyek tidak bisa terlepas dari rencana tujuan yang ingin dicapai.  Hal lain yang juga pantas dicermati adanya perbedaan kecenderungan yang terjadi dalam sebuah organisasi. Pada level yang lebih rendah, seorang developer akan sibuk menghitung pengeluaran mereka yang mahal, hasil kerja pegawai, update software dan pekerjaan-pekerjaan lainnya, sedangkan pada tingkatan yang lebih tinggi hal tersebut akan dikerjakan oleh seorang spesialis yang memadai. Kebanyakan software developer akan menghabiskan setengah dari jam kerja mereka untuk berlama-lama dalam mengerjakan tugas yang diberikan dengan tanpa melakukan apapun terhadap pekerjaan tersebut. Orang-orang demikian ini sangat tidak berkemampuan dan menjadi isu produktifitas yang sangat serius. 

7.  Failure to Plan

Banyak orang bekerja keras, tapi tak seorangpun yang memiliki rencana, karena tidak ada yang merasa perlu membuat rencana. Seorang manajer proyek sering tidak membuat rencana, karena banyak rencana yang diserahkan bersamaan dengan berlalunya waktu.  Mereka mengira waktunya akan habis untuk melakukan hal-hal seperti planning, design, requirement dan inspection.   Kebanyakan dari mereka berpendapat bahwa hal-hal tersebut bisa dilakukan bersamaan dengan pekerjaan sesungguhnya, seperti pada saat coding dan testing. Pandangan ini umumnya datang dari kalangan programmer yang mengisukan bahwa hal tersebut dapat dilakukan ketika perangkat lunak diimplementasikan, padahal jelas ada perbedaan antara speed dan progress. Kita perlu memberi penghargaan pada orang-orang yang tidak menganut pandangan itu sehingga terlepas dari misi bunuh diri tersebut. 

 8.  Communication Breakdown

Sejumlah problema yang timbul pada proyek berskala besar biasanya jika orang yang mengerjakannya berasal dari bagian yang berbeda. Dalam banyak kasus proyek yang bermasalah, tidak ada seorang pun yang memiliki pandangan yang menyeluruh pada proyek tersebut, khususnya bila proyeknya berskala besar. Untuk itu perlu kiranya menginvestasikan waktu tambahan secara periodik agar semua orang di setiap posisi bersedia mempelajari gambaran besar proyek tersebut. Hal ini sejalan dengan sementara orang yang berpendapat bahwa seorang yang mengerjakan kepingan-kepingan kecil sebuah puzzle perlu mengetahui bagaimana sebuah keping bisa masuk ke dalam arsitektur gambar keseluruhan.   

9.  Poor Architecture

 Desain perangkat lunak sebaiknya dapat dikonfigurasi ulang untuk mendukung sebuah fungsi baru. Sebuah arsitektur PL seharusnya bisa mengikuti organisasi dan misi yang berubah, setidaknya harus memperhitungkan keterbatasan jangka panjang, tingkat kesulitan dan harganya. Arsitektur PL harus dipandang seperti bangunan rumah, dimana penambahan pipa dan kabel  harus bisa dilakukan untuk fasilitas yang belum terpikirkan sebelumnya. Begitupun ketika sebuah PL mengalami perubahan kebutuhan atau bisnis yang tidak diantisipasi sebelumnya, harus dapat ditambah atau dimodifikasi tanpa harus membuat PL yang baru. 

10    Late Failure Warning Signals

Lamanya waktu penyelesaian dan besarnya biaya pembuatan PL sangat dipengaruhi oleh  sinyalemen orang yang mana kita takut mengatakan “tidak” kepadanya. Kedengarannya hal ini tidak baik secara politik dikarenakan  mengatakan atau menunjukkan perkiraan yang jauh dari yang dapat dijalankan. Memang kenyataannya tak seorangpun bisa mengetahui bencana yang mendekat karena sering kali tak terlihat gejala awalnya. Dalam dunia nyata, sama seperti orang yang levelnya lebih rendah dapat meyakinkan manajer level atasnya bahwa proyek tersebut sesungguhnya tidak dapat dikerjakan sedemikian rupa hingga jatuh kepadanya.  




Follow

Get every new post delivered to your Inbox.