Proyek TI gagal lebih sering dibanding jenis lainnya—biasanya karena ruang lingkup yang tidak jelas, dependensi yang terlewat, atau komunikasi yang lemah. Dengan Trupeer, Anda bisa menghemat berjam-jam untuk perencanaan dengan memulai dari template rencana proyek TI gratis, menyesuaikannya dengan identitas merek Anda, lalu mengubah rencana tersebut menjadi pembaruan video yang menjaga pemangku kepentingan teknis dan bisnis tetap selaras.

Apa itu rencana proyek TI, dan mengapa template generik sering meleset

Rencana proyek adalah dokumen yang menjelaskan apa yang akan diserahkan, kapan, oleh siapa, dan apa yang harus benar agar itu bisa terjadi. Setiap template yang mendapat peringkat untuk pencarian ini akan memberi Anda itu—biasanya sebagai daftar tugas dengan tanggal mulai, tanggal akhir, penanggung jawab, dan bilah Gantt.

Daftar tugas bukan masalahnya. Masalahnya adalah urutan saat Anda mengisinya.

Template generik dimulai dari pekerjaan Anda. Cantumkan tugas, perkirakan durasinya, susun urutannya, tambahkan penanggung jawab, lalu tanggal akhir jatuh di bagian bawah. Dependensi ditambahkan kemudian, dalam sebuah kolom, sebagai catatan.

Proyek TI jarang meleset karena perkiraan tersebut salah. Proyek meleset karena ada sesuatu yang datang dan tidak pernah ada dalam rencana—dan tidak bisa diperdebatkan: perubahan freeze yang mencakup minggu go-live, tinjauan keamanan dengan antrean enam minggu, vendor yang konsultan implementasinya sudah dibooking hingga akhir kuartal, lisensi yang diperpanjang sebelum penggantinya siap, audit yang mengunci lingkungan selama sebulan.

Tidak ada yang disebut itu sebagai risiko. Risiko adalah sesuatu yang mungkin terjadi. Semua itu sudah benar pada hari Anda mulai merencanakan, dan masing-masingnya bisa diketahui pada minggu pertama jika seseorang bertanya.

Jadi template ini membalik urutannya. Anda menggambar tanggal yang tidak bisa digeser terlebih dahulu. Lalu Anda mengetahui seberapa lebar jendela yang tersisa sebenarnya. Setelah itu, Anda menjadwalkan pekerjaan ke dalamnya. Daftar tugas tetap ada, hanya saja tidak lagi menjadi hal pertama yang Anda tulis.

Cara menyesuaikan template ini di Trupeer

Langkah 1: Buka Bagian Templates

Buka bagian Templates dari navigasi utama.

Langkah 2: Pilih dan Buka sebuah Template

Klik pada template apa pun yang ingin Anda gunakan untuk membukanya.

Langkah 3: Perluas Tampilan Template

Jika diperlukan, perluas tampilan template untuk melihat tata letak dan detailnya dengan jelas.

Langkah 4: Edit Template

Klik Edit untuk mulai memodifikasi template yang dipilih.

Di dalam editor, Anda bisa:

• Menambahkan bagian baru

• Menentukan atau memperbarui aturan pemformatan

• Menambahkan logo dan menyesuaikan posisinya serta pengaturan terkait

Langkah 5: Simpan Template yang Sudah Disesuaikan

Setelah membuat semua perubahan yang diperlukan, klik Save untuk menyimpan template yang diperbarui sebagai milik Anda.

Langkah 6: Pratinjau dan Penyempurnaan Template

Saat Anda ingin melihat seperti apa tampilan template yang sudah disesuaikan, buka Preview.

Dari layar pratinjau, Anda bisa terus melakukan penyesuaian langsung jika diperlukan, sehingga template tampil persis seperti yang Anda inginkan.

Dengan template rencana proyek TI, Anda bisa:

• Menghemat waktu untuk perencanaan: Lewati halaman kosong dengan struktur yang dibangun untuk inisiatif TI.

• Mengelola kompleksitas teknis: Bagian bawaan untuk arsitektur, dependensi, dan risiko.

• Tetap sesuai merek: Terapkan logo, font, dan warna Anda menggunakan brand kit Trupeer.

• Selaraskan bisnis dan TI: Ubah rencana teknis menjadi pembaruan video yang bisa dipahami pemangku kepentingan bisnis.

• Standarisasi di seluruh proyek: Gunakan template yang sama untuk setiap inisiatif TI.

• Jangkau tim global: Terjemahkan rencana dan pembaruan ke 65+ bahasa hanya dengan satu klik.

Tanggal yang tidak bisa diganggu, dan di mana menemukannya

Tanggal yang tidak bisa diganggu adalah tanggal atau durasi apa pun yang ditetapkan oleh seseorang yang tidak melapor ke proyek. Anda tidak bisa menegosiasikannya di dalam proyek, dan jika mengetahuinya terlambat, itu mengubahnya dari kendala menjadi krisis.

Berikut daftar inventaris yang perlu dijalankan pada minggu pertama. Tanyakan kepada setiap penanggung jawab dua pertanyaan: tanggal Anda apa, dan berapa waktu tunggu Anda.

Dua dari hal-hal ini layak mendapat perhatian khusus karena paling sering terlewat. Masa pemberitahuan dalam kontrak adalah tanggal yang tidak bisa diganggu yang berada sebelum tanggal perpanjangan, yang berarti tenggat sebenarnya lebih awal daripada yang ada di kalender. Dan kualitas data pada sistem sumber adalah satu-satunya tanggal yang tidak bisa diganggu yang ukurannya tidak bisa Anda lihat. Anda harus pergi dan mengukurnya, itulah sebabnya memprofilkan data sumber masuk dalam minggu pertama, bukan fase migrasi.

Gambarkan ini pada satu kalender sebelum Anda memperkirakan apa pun. Yang Anda cari adalah bentuk celahnya. Sangat sering celahnya jauh lebih sempit daripada durasi proyek, dan percakapan yang jujur tentang ruang lingkup terjadi pada minggu kedua, bukan pada bulan ketujuh.

Apa yang masuk ke dalam rencana

Setelah tanggal yang tidak bisa diganggu digambar, rencana itu sendiri memiliki dua belas bagian. Salin judulnya, isi dalam urutan ini.

1. Ringkasan. Satu kalimat: apa yang berubah, untuk siapa, dan apa yang berhenti menjadi benar setelahnya.

2. Hasil dan kriteria keberhasilan. Terukur, dan diberi tanggal. Sertakan setidaknya satu kriteria tentang hal yang digantikan—misalnya bahwa sistem legacy tidak memiliki trafik dan tidak ada biaya lisensi pada tanggal yang ditetapkan. Rencana yang berakhir pada go-live adalah cara perusahaan berakhir dengan membayar dua sistem.

3. Kalender kendala. Tabel tanggal yang tidak bisa diganggu di atas, diisi, dengan jendela pengiriman yang dihasilkan dinyatakan sebagai rentang tanggal dalam kata-kata sederhana.

4. Ruang lingkup. Tiga daftar: in, out, dan deferred. Daftar deferred adalah yang paling berguna, karena di situlah ruang lingkup masuk saat dipotong, dan percakapan yang sama tidak terjadi empat kali.

5. Fase dan tonggak. Tonggak adalah peristiwa dengan jawaban yang bisa diamati, misalnya "tinjauan keamanan lulus" atau "toko pertama live", bukan "fase desain selesai".

6. Rincian pekerjaan. Tugas, penanggung jawab, estimasi, urutan. Ini bagian yang selalu dimulai oleh template lain.

7. Dependensi. Pisahkan internal dari eksternal. Setiap dependensi eksternal harus memiliki orang bernama di organisasi lain dan tanggal yang mereka setujui—bukan tanggal yang Anda asumsikan.

8. Lingkungan dan data. Lingkungan apa saja yang ada, data apa yang ada di masing-masing, bagaimana data produksi dilindungi saat pengujian, dan hasil pemrofilan data sumber.

9. Cutover dan rollback. Urutan per jam untuk perpindahan, titik keputusan saat Anda berhenti, siapa yang membuat keputusan itu, dan bagaimana Anda kembali. Tulis ini sebagai prosedur yang bisa dijalankan, tempat template method of procedure berada.

10. Risiko dengan pemicu. Bukan grid kemungkinan dan dampak. Setiap risiko memiliki pemicu yang bisa diamati dan tindakan yang berjalan saat pemicu terlihat. "Konsultan vendor belum dikonfirmasi pada 12 Mei" adalah pemicu. "Vendor mungkin terlambat" bukan.

11. Komunikasi, pelatihan, dan adopsi. Siapa diberi tahu apa dan kapan, serta apa yang diharapkan bisa dilakukan pengguna pada hari pertama.

12. Tata kelola dan penutupan. Siapa yang memutuskan, siapa yang melakukan eskalasi, seperti apa catatan keputusan, serta kondisi saat proyek dinyatakan selesai dan diserahkan untuk dijalankan.

Contoh yang dikerjakan, dan biayanya

Ashmore Retail, delapan puluh empat toko dan tiga pusat distribusi, yang dimulai pada Februari untuk mengganti sistem manajemen gudang di ketiga DC tersebut. Sembilan bulan pekerjaan, go-live direncanakan pada pertengahan November, dijelaskan di kickoff deck sebagai akan mendarat dengan nyaman sebelum puncak.

Dua tanggal yang tidak bisa diganggu sudah ada pada hari kickoff itu. Keduanya dipublikasikan. Tidak satu pun ada dalam rencana.

Yang pertama adalah change freeze. Operasi retail mempublikasikannya setiap Januari dan berlangsung dari 1 November hingga 15 Januari, mencakup puncak perdagangan. Tidak ada perubahan produksi dalam bentuk apa pun yang masuk selama sebelas minggu itu.

Yang kedua adalah kontrak legacy. Kontrak itu diperpanjang pada 31 Desember untuk tambahan dua belas bulan sebesar seratus delapan puluh enam ribu pound, dengan pemberitahuan 90 hari yang diperlukan, sehingga tenggat sebenarnya menjadi 2 Oktober.

Proyek berjalan sesuai rencana hingga musim semi. Tinjauan keamanan memakan waktu empat minggu dibanding SLA dua yang disebutkan. Konsultan implementasi vendor tidak tersedia sampai Oktober, karena mereka diminta pada Juli. Kedua keterlambatan itu diserap dengan menggeser go-live dari pertengahan November ke akhir November, yang tidak disorot siapa pun karena tidak ada yang melihat kalender freeze.

Freeze itu muncul dalam rapat change advisory board pada awal September. Go-live pada November tidak memungkinkan, dan jendela berikutnya yang bisa digunakan terbuka pada 16 Januari.

Itu menyisakan satu pilihan yang harus dibuat pada 2 Oktober. Memberi pemberitahuan pada kontrak legacy dan berjalan mulai 1 Januari tanpa dukungan pada sistem yang menjadi ketergantungan seluruh bisnis, atau membiarkannya diperpanjang dan membayar satu tahun untuk sistem yang mereka rencanakan untuk dimatikan pada November.

Mereka membiarkannya diperpanjang. Sistem baru live pada 4 Maret. Kontrak legacy digunakan selama sembilan minggu dari total masa 52 minggu, yang kira-kira bernilai tiga puluh dua ribu pound dibanding tagihan seratus delapan puluh enam ribu pound. Kurang lebih seratus lima puluh empat ribu pound membeli apa pun.

Bagian yang mengajarkan adalah bahwa proyek tidak terlambat dengan cara orang biasanya mengartikan "terlambat". Pekerjaan dilakukan dengan standar yang wajar pada kecepatan yang wajar. Yang salah adalah jendela itu enam minggu lebih sempit daripada yang digambar siapa pun, dan dua tanggal yang mendefinisikannya sudah berada di kalender yang dipublikasikan dan kontrak yang ditandatangani sejak sebelum proyek itu ada.

Jika kalender kendala digambar pada Februari, urutannya akan terlihat jelas. Go-live sebelum 1 November, bekerja mundur melalui tinjauan keamanan empat minggu yang sebenarnya enam, jalur pengadaan enam minggu, dan konsultan yang membutuhkan pemberitahuan satu kuartal—artinya kontrak vendor harus ditandatangani paling lambat pertengahan April. Kontrak itu ditandatangani pada Juli. Proyek tidak perlu bergerak lebih cepat. Proyek perlu memulai dependensi yang tidak bisa diganggu sebelas minggu lebih awal.

Lima bentuk proyek TI, dan bagian mana yang menanggung beban

Daftar dua puluh template proyek TI umum ditemukan dalam pencarian ini, mencakup semuanya mulai dari implementasi ITSM hingga peningkatan infrastruktur hingga pembentukan PMO. Dalam praktiknya, semuanya menyusut menjadi lima bentuk, dan bentuk tersebut memberi tahu bagian mana di atas yang layak mendapat detail.

Replacement. Menukar sistem yang berjalan dengan sistem lain. Termasuk WMS, ERP, tooling ITSM, platform help desk, sistem HR. Bagian 3, 9 dan 2 menanggung beban, karena bagian tersulit adalah jendela, cutover, dan membuktikan bahwa sistem lama benar-benar sudah mati.

Implementation. Sesuatu yang baru tanpa pendahulu. Termasuk manajemen SLA, program tata kelola TI dan kepatuhan, manajemen aset, manajemen pengetahuan. Bagian 11 dan 2 menanggung beban, karena tidak ada yang rusak sebelumnya, jadi adopsi adalah satu-satunya hal yang membuatnya menjadi nyata. panduan implementasi digital adoption kami membahas lebih dalam tentang ini.

Migration atau upgrade in place. Sistem yang sama, versi baru, host baru, atau region baru. Termasuk virtualisasi, konsolidasi, migrasi cloud, upgrade database. Bagian 8 dan 9 menanggung beban, karena rollback adalah inti dari semuanya.

Build. Pengembangan perangkat lunak dan otomasi proses. Bagian 4 menanggung beban, karena ruang lingkup adalah variabel yang bergerak, dan kriteria penerimaan adalah hal yang menghentikannya bergerak diam-diam.

Programme dan assurance. Pembentukan PMO, audit TI, manajemen portofolio, manajemen risiko, kepatuhan keamanan. Bagian 12 menanggung beban, karena deliverable adalah bukti dan sign-off, bukan sistem yang berjalan, dan tonggak adalah tanggal tinjauan yang ditetapkan oleh pihak lain.

Jika proyek Anda tidak cocok dengan salah satu bentuk ini secara rapi, biasanya itu adalah dua proyek yang diberi satu nama.

Menyusun rencana dalam satu hari

Pagi hari, gambarkan tanggal yang tidak bisa diganggu. Kirim dua pertanyaan ke setiap penanggung jawab di tabel, kejar jawaban dari vendor dan keamanan terlebih dahulu karena keduanya memiliki ekor terpanjang, lalu masukkan setiap tanggal yang Anda dapatkan ke satu kalender. Nyatakan jendela yang dihasilkan dalam satu kalimat.

Sore hari, tulis bagian 1, 2 dan 4, lalu tonggaknya. Biarkan rincian pekerjaan yang detail diisi oleh tim pengiriman selama minggu tersebut. Rencana berguna begitu jendela dan ruang lingkup disepakati, dan tidak menjadi lebih berguna hanya karena ada empat ratus baris di dalamnya.

Tinjau terhadap jendela pada setiap rapat tata kelola. Satu pertanyaan yang layak diajukan bukan "apakah kita masih on track" melainkan "apakah ada tanggal yang tidak bisa diganggu yang bergeser". Freeze diperpanjang, audit dijadwalkan ulang, dan vendor kehilangan konsultan. Perubahan-perubahan itu membentuk ulang rencana dengan cara yang tidak pernah dilakukan oleh tugas yang terlambat.

Apa yang harus dikeluarkan

Bagan Gantt untuk setiap tugas tidak termasuk dalam dokumen rencana. Itu milik alat apa pun yang Anda gunakan untuk menjadwalkan, dan menduplikasinya ke dalam dokumen membuat dua versi yang saling bertentangan dalam waktu dua minggu.

Daftar risiko lengkap dengan skor juga tidak cocok di sini. Simpan risiko yang memiliki pemicu dan tanggal, dan masukkan sisanya ke dalam register.

Prosedur detail tentang bagaimana pekerjaan dilakukan masuk ke dalam IT SOP, dan deskripsi tentang apa yang Anda bangun masuk ke IT documentation—bukan di rencana. Serah terima ke tim operasional layak direncanakan dengan benar, dan itulah tujuan dari knowledge transfer SOP.

Kapan harus berhenti memakai dokumen dan beralih ke software

Dokumen adalah wadah yang tepat saat rencana masih diperdebatkan, yang biasanya terjadi pada bulan pertama. Dokumen tidak lagi menjadi wadah yang tepat ketika tiga hal menjadi benar sekaligus: lebih dari sekitar tiga puluh tugas sudah live, lebih dari empat orang memperbarui status, dan dependensi antar tugas mulai berubah setiap minggu.

Pada titik itu, pindahkan rincian pekerjaan ke software penjadwalan dan simpan dokumen untuk bagian 1 sampai 5 dan 12—yaitu bagian yang dibaca oleh orang yang tidak akan pernah membuka alat tersebut. Dokumen menyimpan kesepakatan. Alat menyimpan jadwal.

Mengubah rencana menjadi sesuatu yang benar-benar diikuti tim pengiriman

Rencana dibaca saat kickoff dan saat rapat steering. Runbook cutover dibaca pada pukul dua dini hari oleh seseorang yang tidak ada di kedua rapat tersebut.

Trupeer AI mengubah perekaman layar menjadi proses yang terdokumentasi, sehingga langkah cutover di bagian 9 dan tugas hari pertama di bagian 11 menjadi panduan walkthrough untuk sistem nyata Anda, bukan paragraf yang menjelaskannya. Rekam urutannya sekali, dan Anda mendapatkan panduan langkah demi langkah, video, dan dokumen di knowledge base Anda, dengan branding Anda sendiri.

Rekam. Beri merek. Terjemahkan. Trupeer-kan.

Untuk pekerjaan adopsi di bagian 11, change management dan training videos mencakup sisi peluncurannya, dan documentation menjaga rencana, runbook, dan materi serah terima tetap tersambung. Instruksi penyiapan ada di document template setup guide.

Pertanyaan yang Sering Diajukan

Apakah ada template rencana proyek TI gratis di Excel?

Tidak sebagai file dari kami, dan ada baiknya kita menyampaikan dengan jelas soal trade-off-nya. Excel memang wadah yang lebih baik untuk rincian pekerjaan di bagian 6, karena tanggal, dependensi, dan rollup berada di dalam sel. Buat lembar itu sendiri dengan kolom untuk tugas, penanggung jawab, mulai, akhir, dependensi, status, dan penanda tanggal yang tidak bisa diganggu. Simpan bagian 1 sampai 5, 9 dan 12 sebagai dokumen, karena bagian tersebut diperdebatkan dalam bentuk narasi dan tidak ada yang menegosiasikan ruang lingkup di spreadsheet.

Apakah ada versi Word, atau unduhan gratis Word doc?

Struktur dua belas bagian di atas ditulis agar bisa disalin langsung ke Word atau Google Docs. Tempel judulnya, pertahankan penomorannya, lalu isi sesuai urutan yang diberikan. Tidak ada unduhan berpagar, yang juga berarti tidak ada formulir di antara Anda dan struktur tersebut.

Apakah ada versi PDF?

Tempelkan bagian-bagian ke editor Anda dan ekspor ke PDF saat rencana sudah disepakati. Rencana layak dibekukan sebagai PDF pada saat sudah disahkan, dan layak tetap bisa diedit sebelum itu, jadi mengekspor salinan Anda sendiri pada momen yang tepat lebih baik daripada memulai dari file yang sudah tetap.

Apakah ada versi PPT untuk kickoff deck?

Deck adalah dokumen yang berbeda dengan tugas yang berbeda. Biasanya enam slide sudah cukup: hasil, jendela pengiriman dari kalender kendala Anda, ruang lingkup in dan out, tonggak, dependensi eksternal yang disebutkan namanya, serta siapa yang memutuskan apa. Jangan masukkan rincian pekerjaan ke dalam deck. Tidak ada yang membaca bilah Gantt di proyektor.

Bisakah saya mengunduhnya secara gratis?

Struktur, tabel tanggal yang tidak bisa diganggu, dan contoh yang dikerjakan gratis dan tanpa batasan. Gunakan, edit, lalu masukkan ke perpustakaan template Anda sendiri dengan nama Anda sendiri.

Apakah rencana pengiriman proyek sama dengan rencana proyek?

Cukup mirip sehingga pembedaan jarang benar-benar diperlukan. Jika organisasi memisahkannya, rencana proyek mencakup seluruh umur proyek termasuk business case dan penutupan, sedangkan rencana pengiriman hanya mencakup bagian build dan rilis. Jika tata kelola Anda meminta keduanya, tulis rencana di atas dan perlakukan bagian 5 sampai 9 sebagai rencana pengiriman.

Apakah saya perlu template laporan manajemen proyek yang terpisah juga?

Ya, dan buat jauh lebih singkat dari yang Anda bayangkan. Laporan status yang mengulang rencana akan diabaikan dalam waktu satu bulan. Laporkan empat hal: apakah ada tanggal yang tidak bisa diganggu yang bergeser, apakah jendela masih cukup lebar, keputusan apa yang Anda butuhkan dari grup ini hari ini, dan pemicu apa dari daftar risiko sejak terakhir kali.

Seberapa detail rencana proyek TI seharusnya?

Cukup detail agar orang baru bisa tahu apa yang terjadi selanjutnya, dan tidak lebih. Dalam praktiknya, dokumen rencana untuk proyek sembilan bulan biasanya sekitar delapan hingga lima belas halaman, sebagian besar adalah bagian 8 dan 9. Jika dokumen lebih panjang daripada runbook cutover, keseimbangannya salah.

Seberapa sering rencana harus diperbarui?

Bagian 6 dan 7 berubah setiap minggu dan berada di tempat tim Anda sudah bekerja. Bagian 1 sampai 5 seharusnya jarang berubah, dan setiap perubahan di dalamnya adalah keputusan yang harus disetujui seseorang. Jika bagian ruang lingkup Anda sedang diedit diam-diam setiap minggu, Anda tidak punya rencana—Anda punya buku harian.