Proje planı, projenin neyi başarmayı amaçladığını, işin nasıl düzenleneceğini ve ekibin kararlarla değişiklikleri nasıl ele alacağını açıklar. Yararlı bir şablon; sonuç, kapsam, kabul, sahiplik, bağımlılıklar, kaynaklar, riskler, kilometre taşları ve gözden geçirme kurallarını kapsar. Takvim planın yalnızca bir parçasıdır.
Proje yoldan çıktığında bu ayrım önemlidir. Zaman çizelgesi kaçırılan tarihi gösterir ama ekibin teslimatı yanlış anlayıp anlamadığını, yetkisinin eksik olup olmadığını veya kapasite değişmeden yeni işi kabul edip etmediğini açıklamaz. Plan bu sorulara yanıt verebilmelidir.
PMI’nin proje planı bileşenleri hakkındaki makalesi kapsam, kaynak, kilometre taşı, onay ve değişiklik yönetimini içerir. Buradaki şablon işbirlikçi ekip için özgün, hafif bir sürümdür; resmî PMI formu değildir.
Projenin hizmet ettiği kararla başlayın
Sonucu teslimat ekibinin dışındaki birinin anlayacağı şekilde yazın. “Gösterge panosunu başlat” çıktı adıdır. “Destek liderlerinin haftalık incelemeden önce sahipsiz eskalasyonları bulmasına yardım et” ise çıktının neden önemli olduğunu anlatır.
Sponsor veya hesap verebilir karar vericiyi ve sonucu kullanacak kişileri belirtin. Küçük kurumlarda roller örtüşebilir ama kararları farklıdır. Birinin projenin hâlâ anlamlı olup olmadığına, bir başkasının teslimatın kararlaştırılan ihtiyacı karşılayıp karşılamadığına karar vermesi gerekir.
Kısıtları tercihlerden ayrı kaydedin. Sözleşmedeki gerçek son tarih, tercih edilen demo tarihinden farklı ele alınmalıdır. Tarih esnekse bunu söyleyin. Finansman üst sınırı varsa miktarı ve değiştirme yetkisini belirtin. Hassas finans kayıtlarını ortak panoya kopyalamak yerine ilgili kaynağa bağlantı verin.
Bu proje planı şablonunu kopyalayın
| Bölüm | Soru |
|---|---|
| Sonuç | Proje hangi yararlı değişikliği yapmalı? |
| Kapsam | Hangi teslimatlar ve işler dahil? |
| Hariç tutulanlar | Hangi makul talepler bilerek bu projenin dışında? |
| Kabul | Tamamlanmayı hangi kanıt ve kimin kararı belirleyecek? |
| Roller | Teslimat, kabul, teknik karar ve eskalasyonu kim üstleniyor? |
| İş yaklaşımı | Hangi aşamalar veya yinelemeler kullanılacak? |
| Bağımlılıklar | Ne, kimden ve ne zamana kadar gerekli? |
| Kapasite | Hangi roller müsait ve başka hangi taahhütler sürüyor? |
| Kilometre taşları | İlerlemeyi hangi anlamlı koşullar gösteriyor? |
| Riskler ve varsayımlar | Planı ne geçersiz kılabilir, hazır yanıt nedir? |
| Değişiklik kararları | Kapsamı, maliyeti veya zamanı kim değiştirebilir? |
| Gözden geçirme | Plan ne zaman ve nasıl kontrol edilip güncellenecek? |
Belge tamamlanmış görünsün diye her alanı paragrafla doldurmayın. Eksik bir kararı “çözülmedi, sahibi, karar tarihi” diye işaretlemek genel ifadelerin arkasına saklamaktan daha yararlıdır. Ayrıntılı takvime ve iş takip aracına bağlantı verin, rakip kopyalar tutmayın.
Örnek: destek eskalasyon raporu
Haftalık eskalasyon raporu planlayan varsayımsal bir ekip düşünün. Kararlaştırılan sonuç, destek liderlerinin sorumlusu olmayan kayıtları bulabilmesidir. Teslimat, “sahipsiz” tanımı belgelenmiş ve mevcut bilet verilerinden oluşturulan rapordur. Tahmin ve faturalama analizi açıkça kapsam dışıdır.
Kabul için bir destek lideri belirlenmiş örneklemi kaynak biletlerle karşılaştırmalı, farkları açıklamalı ve raporun haftalık incelemeyi desteklediğini doğrulamalıdır. Mühendislik uygulamadan, destek ise operasyonel tanımdan sorumludur. Adı belli sponsor, veri kaynaklarını veya rapor amacını genişleten istekleri karara bağlar.
Ekip iki bağımlılık bulur: bilet dışa aktarımına erişim ve bilet bölümler arasında geçtiğinde sahipliğin nasıl belirleneceği konusunda anlaşma. İkincisi teknik görev değildir. Karar verilmeden kod başlayabilir ama güvenilir kabul tarihi belirsizliğin kendiliğinden çözüleceğini varsayamaz.
Kilometre taşı sırası şöyle olur: tanımlar üzerinde anlaşma; örneklem mutabakatı; ilk operasyonel inceleme; bakımın sorumlu ekibe devri. Bunlar “analiz yüzde 50 tamamlandı” ifadesinden daha bilgilendiricidir çünkü gözlemlenebilir koşulları anlatır.
Örneğin tüm ayrıntıları açıklama amaçlıdır. Nextretro müşteri vakası veya bir plan biçiminin teslimatı garanti ettiği iddiası değildir.
Takvimi iş ve bağımlılıklardan oluşturun
Kapsam ve kabul koşulları anlaşılır olduğunda işi yapacak kişilerden faaliyet ve bağımlılıkları belirlemelerini isteyin. Katkıyı geçen süreden ayırın. Bir günlük analiz işi inceleyeni beklerken birkaç gün durabilir.
Tahminleri tahmin olarak işaretleyin. Belirsizlik önemliyse aralık verip varsayımı adlandırın. “Veri erişimi onaylandıktan sonra uygulama ve mutabakat yaklaşık bir-iki hafta” demek, onayın yarın geleceğini sessizce varsayan kesin bir tarihten daha dürüsttür.
Yol haritası sonuçların genel sırasını ve büyük bağımlılıkları iletir. Takvim faaliyetleri ve tarihleri eşgüdümler. Proje planı ikisini projenin amacı, yetkisi ve kısıtlarına bağlar. Aynı zaman çizelgesini üç kez yeniden adlandırmak yerine kitlenin sorusunu yanıtlayan belgeyi seçin.
Kısa bir incelemeyle planı canlı tutun
Düzenli teslimat kontrolünde varsayım, kapsam, bağımlılık ve kapasite değişikliklerine bakın. Karar taahhüdü değiştirdiğinde planı güncelleyin. Geçerli sürümün başlangıçtan neden farklı olduğunu açıklayacak kadar geçmişi koruyun.
Planlama atölyelerinde risk ve soruları ortaya çıkarmak için paylaşılan pano kullanın. Tarihleri, kaynak tahsislerini ve resmî onayları yetkili proje sistemlerinde tutun. Retrospektif panosu ortak düşünmeye yardım eder, tüm planlama işlevlerinin yerini almaz.
Anlamlı bir kilometre taşından sonra agile retrospektifi yürütün. Hangi planlama varsayımları işe yaradı, hangileri başarısız oldu ve sonraki aşamadan önce ne değişmeli diye sorun. İncelenecek belirsizliğe uygun retrospektif fikirlerinden bir format seçin.
Paylaşmadan önce yaygın hataları düzeltin
Sonuç göstermeyen, yalnızca iç çabayı anlatan kilometre taşlarını silin. “Paydaşlara danışıldı” yerine danışmanın üreteceği kararı yazın. Son sözü kimin söylediği belirsizse yinelenen sahipleri kaldırın.
Hariç tutulanları olası taleplerle karşılaştırın. Herkes eğitim, veri aktarımı veya bakım bekliyorsa bu konulara yer vermemek onları yok etmez. Kapsama girip girmediklerine ve nasıl kaynak ayrılacağına karar verin.
Son olarak planı yeni ekip üyesi gibi okuyun. Projenin neden var olduğunu, tamamlanmanın ne demek olduğunu ve zor bir kararı kime götüreceğini açıklayabiliyor mu? Değilse daha çok ayrıntı eklemeden dili sadeleştirin.
Sık sorulan sorular
Proje planı ile proje takvimi aynı mı?
Hayır. Takvim faaliyet zamanlamasını ve bağımlılıkları anlatır. Plan ayrıca amaç, kapsam, kabul, sahiplik, kaynak, risk ve değişiklik kararlarını içerir. Ayrıntılı takvimi çoğaltmak yerine ona bağlantı verebilir.
Proje planı ne kadar uzun olmalı?
Önemli taahhüt ve kararları açıklayacak kadar uzun olmalı. Küçük bir iç proje bağlantıları olan kısa belgeyle yürüyebilir. Karmaşık veya düzenlemeye tabi iş daha ayrıntılı plan ve resmî kontrol gerektirebilir.
Agile ekip proje planı yazmalı mı?
Ekipler arası bağımlılık, finansman kararı veya dış taahhüt olduğunda yararlı olabilir. Yakın dönem ayrıntılarını somut, gelecekteki işi uyarlanabilir tutun. Plan öğrenmeyi desteklemeli; her ileri tarihli görevin bilindiğini ima etmemelidir.