RSS

Seputar Manajemen Proyek TI (bag.2)

14 Sep

Alhamdulillah, bisa nge-blog lagi. Kali ini saya mencoba melanjutkan tulisan sebelumnya di bagian pertama.
Jika di bagian sebelumnya, saya membahas Q & A seputar ManPro TI. Kini saya mencoba menjelaskan hal yang paling mendasar dari Manajemen Proyek IT itu sendiri.

Apa sih Manajemen Proyek? Kita mengetahui manajemen ya melakukan dan mengatur (doing and control), namun bagaimana dengan proyek? apa hal yang bisa dikatakan itu sebagai proyek? adakah kunci atau point-point utama dalam proyek itu sendiri?

Proyek TI sendiri memiliki ciri-ciri utama yaitu : direncanakan, memiliki batasan (biaya dan waktu), tujuan atau target (goal), tindakan (implementasi dan control), bersifat sementara (dalam satu garis waktu; timeline. Kalo seumur hidup, itu bukan proyek namanya :p ), ada aktornya (pihak eksekutif, client/sponsor, vendor/tenaga pelaksana yang terangkum dalam deliveriable), dan yang terakhir mengandung kata “business”.

Manajemen Proyek ini dipimpin oleh seorang Manager, yang tentunya sudah tentu memiliki skill manajemen yang bagus dan memiliki jam terbang yang tinggi di dalam dunia perproyekan. Lantas apakah bisa seseorang yang baru bergabung dalam ManPro bisa menjadi manager? bisa iya, bisa tidak. Jika, ia memiliki karakter pemimpin, mampu mangatur setiap tindakan yang ada dalam proyek, termasuk bertindak cepat tentunya. Bisa dijadikan sebagai manajer (namun masih junior), dan itu perlu didampingi oleh yang senior.

Managers do things right, leaders do the right thing

Pengelolaan proyek TI harus seimbang antara Scope (Lingkup Pekerjaan), Cost (biaya), Resource (sumber daya) dan Time (Waktu). Dan peran pengelolaan dipegang oleh seorang Manajer Proyek TI tersebut.

Adapun goal yang harus dicapai oleh pihak vendor, terutama oleh si Manajer adalah mampu memenuhi kebutuhan dan memuaskan pihak client. Bentuk kepuasan itu terletak pada :

      • Scope atau Lingkup Pekerjaan. Apakah proyek yang sudah dikerjakan sesuai dengan cakupan yang diminta pihak client? Jangan sampai kurang, jangan sampai lebih, diusahakan pada tingkat yang pas. Jika kekurangan, tentu akan mengganggu kestabilan software yang dibangun, ntah itu fiturnya tidak lengkap, atau kurang bagusnya code/design, dan sebagainya. Atau kelebihan? misal : konsumen meminta kepada tukang jahit untuk dibuatkan celana dengan bahan yang sudah ditentukan, kemudian tukang jahit melihat bahannya masih banyak sisa, kemudian bahan sisa tersebut ditambahkan ke celana yang sudah jadi dengan motif bunga-bunga misalnya. Kan jadi gak sesuai scope😛 Ya, dalam industri TI juga demikian, ketika pihak vendor meminta dibuatkan web untuk perusahaannya, harus pas sesuai yang diminta (requirement), jangan dilebihkan dengan hal-hal yang tidak perlu. Di awal, client akan bercerita (user stories) apa dan kapan yang ia butuhkan, dan apa yang tersedia dan yang perlu disediakan. Inilah yang menjadi kunci awal untuk menjadi milestone yang dipegang pihak vendor TI, tentang apa saja yang dikerjakan pada tahap execution project tersebut.

Tahapan project itu biasanya : opening Project>brainstorming (kick-off meetings bahas concept; user stories) > planning > execution > control > closing Project.

      • Time atau waktu. Bila disiplin dengan metode pengembangan software yang sudah ditentukan, biasanya bisa ontime. Namun, terkadang luput dari sasaran yang sudah ditentukan. Bisa banyak sebab, bisa jadi karena Resource-nya yang kurang. Ntah itu infrastruktur yang disediakan yang kurang memadai untuk digunakan, atau SDMnya yang kurang banyak atau terlalu banyak sehingga komunikasinya terhambat, atau karena kehabisan/tersendaknya biaya yang dikeluarkan oleh pihak client. Ada baiknya diperhatikan betul waktu yang dibutuhkan untuk mencapai setiap cakupan (scope) tersebut. Baiknya ya dari pengalaman. “eh, dulu kita ngedevelop fitur x berapa lama y?” | “oh waktu itu 2 minggu, pak” | “ok, bisa kita coba 17 hari, kita lebihkan 3 hari untuk mencegah hal-hal yang tidak diinginkan”.
        Namun, dilihat juga berapa panjang timeline yang diberikan client, berapa banyak fitur yang dikerjakan dan berapa SDM yang tersedia.
      • Cost atau biaya. Dalam menentukan biaya, ada banyak faktor yang perlu diperhatikan. Saya tidak akan menjelaskan secara detail, namun setiap menentukan biaya itu ada peran “pengalaman” atau “jam terbang” atau “portofolio” yang bermain di sini. Semakin tinggi, harga yang ditawarkan semakin tinggi pula. Tentunya, dengan tinggi pengalaman, teknologi dan metode yang dipakai tentu sudah baik, tepat dan berkualitas. Dan tentunya, pihak client juga sudah “jatuh hati” pada pandangan pertama setelah mengetahui portofolio yang telah dikerjakan. Selain itu, berapa banyak deliveriables dan personil yang menjadi aktor di dalamnya menentukan besaran biaya yang dibutuhkan untuk investasi tersebut. Setiap posisi dalam aktor yang mengerjakan memiliki harga yang berbeda. Dan itu sudah disepakati melalui kontrak kerja. Ada yang menentukannya melalui work unit. Misal : harga per work unit : Rp 100.000 untuk seorang programmer. Si Programmer bekerja selama 5 hari dengan 8 jam kerja. Berarti work unitnya : 5 * 8 = 40 work unit. Kemudian menentukan harga si programmer dengan : 40 work unit * Rp 100.000 = Rp 4.000.000,-
      • Quality atau Kualitas. Banyak yang beranggapan, kualitas ini tidak termasuk dalam bentuk kepuasan dari client tersebut. (ya tergantung, kalo proyek atas dasar kepentingan pihak tertentu, yang penting asal jadi aja…biasanya kualitas itu malah hilang :p) Semakin baiknya kualitas, tentu lifetime dari software tersebut bisa berlangsung sangat lama. Dan tentunya, pihak client menjadi “terpesona” dengan apa yang sudah dibuat, dan meningkatkan rate biaya juga😀 Tetapi, kualitas bukan hal yang sederhana, untuk membuat software yang berkualitas, dibutuhkan jam terbang yang tinggi, mengikuti trend teknologi dan cakap dalam hal merancang, membangun dan memelihara software itu sendiri.

RBT = Resource, Budget, Time => “on time, on budget, to the specifications”

Portofolio menunjukan jati diri kita, apa yang sudah dikerjakan. Dan ini lebih ke arah strategic business ke client.

Agar sukses mencapai tujuan tersebut, ada beberapa hal yang diperhatikan, yaitu :

  • Tools yang dimanfaatkan harus tepat, tools di sini meliputi tools untuk manajemen proyeknya tersebut. Kalau biasa dengan produk Microsoft, mungkin bisa mencoba Ms. Project, atau dengan produk opensource seperti Redmine. Adapula tools yang lain, seperti CASE (Computer Aided Software Engineering) tools : Enterpisce Architect, Rational Rose, Power Designer, dll.
  • Selain itu, perlu digunakan metode formal dalam manajemen proyek TI. Tiap perusahaan menggunakan metode atau pendekatan berbeda dalam melaksanakan aktivitas proyek TI. Itu tergantung pada kenyamanan mereka bekerja dan jam terbang masing-masing. Namun, ada baiknya disesuaikan dengan kondisi proyek tersebut, ntah itu kondisi personilnya, biayanya, timelinenya dan apa yang akan dibuat.
    Metode Software Development yang banyak digunakan adalah metode Agile. Ada yang menggunakan XP (eXtreme Programming), Scrum. Selain Agile juga ada yang masih memanfaatkan metode classic, matematis ataupun waterfall (eh, waterfall bukannya biasa dipake anak-anak kuliah?😛 )
  • Peran pimpinan proyek (project manager) dalam mengatur dan mengelola proyek itu sendiri sehingga prosesnya berjalan dengan baik (tiap proses menghasilkan sesuai target). Mampu berkomunikasi dengan baik dengan personil, menumbuhkan kesan dan pengalaman berarti untuk soft-skill tiap personil dan tentunya mampu menjalin hubungan bisnis yang baik dengan client maupun personil. 
  • Pengukuran kesehatan project sedini mungkin. Bentuk pengukuran ini dapat diperhatikan dengan tingkat kepuasan client untuk setiap progress proyek itu sendiri, apa yang sudah dikerjakan, bagaimana hasilnya, bagaimana waktunya, tepat waktu dan benarkah? Bagaimana dananya? apakah menipis? biasanya bila dana menipis, ya kesehatan project terganggu, dan mempengaruhi aspek lain juga (time dan resource).

“Project dikendalikan oleh strategi, dapat dilakukan bagaimana setiap project dapat fit dengan strategy business, menghilangkan yang tidak dibutuhkan sesegera mungkin. Dan sedapat mungkin menggandeng stakeholders. Mengabaikan stakeholders sama saja membuat project gagal.” -Robert Butrick

Sumber : dari berbagai sumber, pengalaman di lapangan dan dari perkuliahan🙂

 
Leave a comment

Posted by on September 14, 2012 in Workit

 

Tags: , , , , , , , , , , , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: