Proje Yönetimi · 12 Çizelge · Tek Proje Üzerinden
Proje yönetim çizelgeleri ayrı formlar değil, tek bir zincirdir
Bir projede on iki ayrı form doldurmazsınız; tek bir düşünce zincirinin on iki halkasını yazarsınız. Başlatma belgesindeki “operasyon maliyetleri %30 azalmalıdır” cümlesi gereksinim matrisinde A1 kodunu alır, kapsam bildiriminde sınırı çizilir, iş kırılım yapısında bir iş paketine düşer, aktivite listesinde süre kazanır, kritik yolda tarihe ve maliyet tabanında paraya dönüşür. Halkalardan biri koptuğunda zincirin tamamı yük taşımaz: İKY numarası olmayan gereksinim kimsenin işi değildir, kapsam dışı yazılmayan istek er geç kapsama girer.
Aşağıda zinciri tek bir gerçek proje üzerinden takip ediyoruz ve her bölümde bir kalemin bir öncekinden nasıl türediğini gösteriyoruz. Bu belgelerin değeri dokümanın kendisi değil, dokümanı üretirken yapmak zorunda kaldığınız düşünmedir.
- Proje
- Telekomünikasyon iş ve operasyon yönetim (İOY) programı kurulumu
- Müşteri
- AlfaBeta Telekom
- Tarih
- 17.06.2020
- Sponsor
- Can — Operasyon Başkan Yardımcısı
- Proje Yöneticisi
- Bünyamin
- Bütçe tavanı
- 100.000 $
Çizelgeler arasındaki besleme zinciri
Oklar “önce şunu yaz” demiyor; “bu belgenin içeriği şuradan türer” diyor. Bir belgeyi beslemeden yazdığınızda, o belgedeki her satır tahmin olur.
Zaman çizelgesi, CPM sonuçlarının takvime oturtulmuş hâli olduğu için 06. bölümde Gantt olarak veriliyor. Kesikli çizgiler “hepsi Proje Yönetim Planı’nda birleşir” ilişkisini gösterir.
Proje Başlatma Belgesi Nedir, Nasıl Yazılır — Ölçülebilir Hedef Örnekleri
Ne işe yarar
Projeyi resmen var eden ve proje yöneticisine yetki veren tek belgedir. Asıl işlevi yetkilendirme değil, başarının tanımını proje başlamadan önce sabitlemektir. Bu belge yoksa, proje bittiğinde “başarılı mı” sorusunun cevabı tarafların hafızasına kalır; her taraf farklı hatırlar.
Zincirdeki yeri
Hiçbir şeyden beslenmez, zincirin başıdır.
Gereksinim İzlenebilirlik Matrisi'ni ve Paydaş Analizi'ni besler; buradaki 100.000 $ tavanı 08. bölümdeki bütçe kontrolünün ölçütüdür.
Dolu örnek — AlfaBeta İOY programı hedefleri
| # | Hedef | Ölçü türü | Bunun sağlandığını nasıl kanıtlarım? |
|---|---|---|---|
| 1 | 1 Ocak 2021'den itibaren iş süreçlerinin tamamı kurulan sistem üzerinde çalışmalıdır | Tarih + kapsam | 1 Ocak 2021 sonrası süreç işlemlerinin sistem kayıtlarından okunması |
| 2 | 15 Aralık 2020'ye kadar kabul testleri tamamlanarak operasyon ekibine teslim edilmelidir | Tarih | İmzalı kabul testi tutanağı İKY 2.2 |
| 3 | Proje bütçesi 100.000 $ aşmamalıdır | Tutar | Onaylı proje bütçesi ile fiili harcamanın karşılaştırılması |
| 4 | Operasyonların çevrim hızı en az %50 hızlanmalıdır | Yüzde | Kurulum öncesi ve sonrası çevrim süresi ölçümü |
| 5 | Operasyon maliyetleri %30 azalmalıdır | Yüzde | Kurulum öncesi ve sonrası birim operasyon maliyeti A1 |
| 6 | Süperkullanıcı düzeyinde 3 çalışan yetiştirilmiş olmalıdır | Adet | Yetkinlik değerlendirmesi sonucu C6 İKY 4 |
Ölçülebilirlik testi: “Proje bitiminde bunun sağlandığını nasıl kanıtlarım?” sorusuna cevap veremiyorsanız madde hedef değil temennidir, yeniden yazılmalıdır.
En sık yapılan hata
Hedefi yüzdeyle yazıp başlangıç değerini hiç ölçmemek. AlfaBeta’da 4. ve 5. hedefler (%50 hız, %30 maliyet) ancak kurulum öncesi çevrim süresi ve birim maliyet ölçülmüşse kanıtlanabilir. Bu ölçüm proje başlamadan yapılmazsa, hedef ölçülebilir görünür ama denetlenemez.
İkinci sık hata: bütçe tavanını belgeye yazıp bir daha dönmemek. 08. bölümde bu tavana geri döneceğiz — ve 23 $ aştığını göreceğiz.
✗ Böyle yazma / ✓ Böyle yaz
| ✗ Böyle yazma | ✓ Böyle yaz |
|---|---|
| Operasyon verimliliği artırılacaktır. | Operasyon maliyetleri, proje başlangıcında ölçülen birim maliyete göre %30 azalmalıdır. |
| Sistem en kısa sürede devreye alınacaktır. | 15 Aralık 2020'ye kadar kabul testleri tamamlanır; 1 Ocak 2021'den itibaren tüm süreçler sistem üzerinde çalışır. |
| Yeterli sayıda kullanıcı eğitilecektir. | Süperkullanıcı düzeyinde 3 çalışan yetiştirilmiş olmalıdır. |
| Bütçeye dikkat edilecektir. | Proje bütçesi 100.000 $ aşmamalıdır; aşım hâlinde karar sponsora (Can) gider. |
Paydaş Analizi Nasıl Yapılır — Güç/Çıkar Matrisi Örneği
Ne işe yarar
Kime ne kadar zaman ayıracağınıza karar verdirir. Paydaş analizi olmadan proje yöneticisinin zamanı, en çok bağıran kişiye gider; oysa en çok bağıran kişi çoğu zaman kararı verecek kişi değildir. Bu çizelgenin çıktısı bir liste değil, dört farklı davranış biçimidir.
Zincirdeki yeri
Başlatma Belgesi'nden beslenir (sponsor, müşteri, proje yöneticisi oradan gelir).
İletişim Yönetimi Planı’nı besler; buradaki her Y/Y paydaş 11. bölümdeki tabloda görünmek zorundadır.
Dolu örnek — AlfaBeta paydaş listesi
| Kod | İsim | Unvan | Güç/Çıkar | Strateji |
|---|---|---|---|---|
| A | Can | Operasyon Başkan Yrd. (Sponsor) | Y/Y | Yakından yönet |
| G | Mehmet | AlfaBeta Proje Yöneticisi | Y/Y | Yakından yönet |
| B | Fırat | Finansal Koordinatör | Y/D | Memnun tut |
| E | Pulat | Network ve Teknik Danışman | D/Y | Bilgilendir |
| H | İsmail | AlfaBeta Teknik Mühendis | D/Y | Bilgilendir |
| C | Soner | Operasyon Müdürü | D/D | İzle |
| D | Mustafa | Kurulum Mühendisi | D/D | İzle |
| F | Burçin | Tedarik Sorumlusu | D/D | İzle |
Güç / çıkar matrisi
Yüksek güç · Düşük çıkar
Memnun tut
- BFırat — Finansal Koordinatör
Yüksek güç · Yüksek çıkar
Yakından yönet
- ACan — Sponsor
- GMehmet — AlfaBeta PY
Düşük güç · Düşük çıkar
İzle
- CSoner
- DMustafa
- FBurçin
Düşük güç · Yüksek çıkar
Bilgilendir
- EPulat
- Hİsmail
En sık yapılan hata
Herkesi “yüksek güç, yüksek çıkar” işaretlemek. Sekiz paydaşın sekizi de sağ üst kutuya düşüyorsa analiz yapılmamış, sadece liste kopyalanmıştır. Matrisin işi kimi eleyeceğinizi söylemektir; hiçbir kutu boşalmıyorsa çizelge size hiçbir karar verdirmiyor demektir.
İkinci hata: konumu bir kez işaretleyip dondurmak. Burçin D/D konumundadır ama 10. bölümde en yüksek skorlu riskin sahibidir — risk sahibi olan paydaş, konumundan bağımsız olarak iletişim planında yer alır.
✗ Böyle yazma / ✓ Böyle yaz
| ✗ Böyle yazma | ✓ Böyle yaz |
|---|---|
| Fırat — Finansal Koordinatör — önemli paydaş — sürekli bilgilendirilecek. | B Fırat — Y/D — Memnun tut: maliyet tabanı ve rezerv kullanımı dışındaki detaya dâhil edilmez. |
| Tüm paydaşlar: yüksek güç, yüksek çıkar. | Yakından yönet kutusunda yalnız A Can ve G Mehmet var; kalan altısı için farklı strateji yazılı. |
| Paydaş: Operasyon birimi. | C Soner — Operasyon Müdürü. Paydaş birim değil kişidir; kararı kişi verir. |
Gereksinim İzlenebilirlik Matrisi Nedir, Nasıl Doldurulur — Örnek
Ne işe yarar
Her isteği tek tek numaralandırıp nereden geldiğini ve nereye bağlandığını kayda geçirir. Bu matris olmasaydı, proje sonunda “biz bunu istemiştik” diyen kişiye verilecek tek cevap hafıza olurdu. Matrisin asıl kazancı izleme değil, ayıklamadır: istek yazıya döküldüğünde hangisinin gerçekten iş hedefine bağlı olduğu görünür hâle gelir.
Zincirdeki yeri
Başlatma Belgesi'ndeki altı hedeften beslenir.
Kapsam Bildirimi'ni besler; kapsam dışı kararı burada verilen A4 ve B2 kodları 04. bölümde gerekçeleriyle yazılır.
Dört gereksinim sınıfı
| Sınıf | Ne cevaplar | AlfaBeta örneği |
|---|---|---|
| A — İş | Neden yapıyoruz? Kurumun elde edeceği fayda. | A1 Operasyon maliyetlerinin %30 azalması |
| B — Paydaş | Belirli bir paydaş grubunun ne yapabilmesi gerekiyor? | B1 Bölge bayileri AlfaBeta sunucuları üzerinden işlem yapabilmeli |
| C — Çözüm/Kalite | Ne teslim edeceğiz? Ürünün somut özelliği. | C2 Belirtilen özelliklere sahip 2 adet sunucu |
| D — Geçiş | Yeni durumdan eskisine geçerken bir defalık ne gerekiyor? | D1 İOY programı kullanım eğitimleri |
A “neden yapıyoruz”, C “ne teslim edeceğiz”. “Maliyetlerin %30 azalması” teslim edilemez, ölçülür; “2 adet sunucu” ölçülmez, teslim edilir. Bu ikisi karıştığında proje ya ölçülemez bir iş paketi ya da hedefsiz bir teslimat üretir.
Dolu örnek — AlfaBeta gereksinim matrisi (seçme)
| Kod | Sınıf | Gereksinim | Öncelik | İKY | Durum |
|---|---|---|---|---|---|
| A1 | A | Operasyon maliyetlerinin %30 azalması | 5 | — | Kapsam içi (fayda) |
| A3 | A | 7 ana bölge bayiinin tamamı sisteme dâhil olmalı | 5 | İKY 2.3 | Kapsam içi |
| A4 | A | 1200 alt bayinin tamamı sisteme dâhil olmalı | 3 | — | Kapsam dışı |
| B1 | B | Bölge bayileri AlfaBeta sunucuları üzerinden işlem yapabilmeli | 5 | İKY 2.3 | Kapsam içi |
| B2 | B | Alt bayiler AlfaBeta sunucuları üzerinden işlem yapabilmeli | 3 | — | Kapsam dışı |
| B5 | B | Teknik detayları eksiksiz doldurulmuş satınalma dokümanı | 5 | İKY 1.2.1 | Kapsam içi |
| C2 | C | Belirtilen özelliklere sahip 2 adet sunucu | 5 | İKY 1.2.1.1 | Kapsam içi |
| C6 | C | 3 Süperkullanıcı | 5 | İKY 4 | Kapsam içi |
| D1 | D | İOY programı kullanım eğitimleri | 5 | İKY 4 | Kapsam içi |
A1 satırında İKY sütunu boş: A sınıfı fayda gereksinimleri tek bir iş paketine düşmez, projenin bütünü tarafından üretilir. Bu istisnanın bedeli, karşılığında bir ölçüm anı ve ölçüm yönteminin yazılmasıdır — bu projede kurulum öncesi ve sonrası birim maliyet ölçümü. B, C ve D sınıfı gereksinimlerde boş İKY hücresi istisna değil, eksiktir.
En sık yapılan hata
Bir isteği hem A hem C sınıfına yazmak, ya da C sınıfı bir teslimatı A sınıfı gibi ifade etmek: “Sunucular verimliliği artırmalı.” Bu cümle sunucunun hangi özellikte olacağını da, verimliliğin ne kadar artacağını da söylemez; tedarikçiye de sponsora da bir şey ifade etmez.
✗ Böyle yazma / ✓ Böyle yaz
| ✗ Böyle yazma | ✓ Böyle yaz |
|---|---|
| Sunucular verimliliği artırmalı. | C2 Belirtilen özelliklere sahip 2 adet sunucu — İKY 1.2.1.1 · öncelik 5 |
| Bayiler sisteme dâhil edilmeli. | A3 7 ana bölge bayiinin tamamı (kapsam içi) / A4 1200 alt bayi (kapsam dışı) — ikisi ayrı satır, ayrı karar |
| Kullanıcılara eğitim verilecek. | D1 İOY kullanım eğitimleri + C6 3 Süperkullanıcı — İKY 4 |
Proje Kapsam Bildirimi Nasıl Yazılır — Kapsam Dışı Maddeler ve Kapsam Kayması
Ne işe yarar
Neyin yapılacağını değil, neyin yapılmayacağını yazıya döker. Kapsam kaymasına karşı elinizdeki tek savunma budur: kapsam dışı bölümü boş bir kapsam bildirimi, sonradan gelen her isteğe “bu zaten kapsamdaydı” demenin kapısını açık bırakır. Bir projede tartışma çıktığında açılan sayfa kapsam içi listesi değil, kapsam dışı listesidir.
Zincirdeki yeri
Gereksinim Matrisi'nden beslenir.
İş Kırılım Yapısı'nı besler, ayrıca Risk Yönetimi ve Kalite Planı'nın sınırını çizer.
Dolu örnek — kapsam içi / kapsam dışı
| Kapsam | Madde | Kod | Kabul ölçütü / gerekçe |
|---|---|---|---|
| İçi | 7 bölge bayiinin sisteme dâhil edilmesi | A3 B1 | 7 bölge bayiinin tamamı AlfaBeta sunucuları üzerinden işlem yapabiliyor |
| İçi | İOY programının kurulumu ve kabul testleri | İKY 2 | Kabul testleri 15 Aralık 2020'ye kadar tamamlanmış ve teslim edilmiş |
| İçi | Süperkullanıcı yetiştirilmesi ve eğitimler | C6 D1 | 3 çalışan süperkullanıcı düzeyinde yetkin |
| Dışı | 1200 alt bayinin sisteme dâhil edilmesi | A4 | Öncelik 3; bu projede yapılmaz, ayrı bir projeye konu olur |
| Dışı | Alt bayilerin AlfaBeta sunucuları üzerinden işlem yapabilmesi | B2 | Öncelik 3; A4 kapsam dışı olduğu için teknik karşılığı da kapsam dışıdır |
| Dışı | Alt bayiler için temas birimi | B4 | Alt bayi kapsam dışı olduğundan destek yapısı da kurulmaz |
Kapsam dışı maddenin yanındaki kod, o maddenin uydurulmadığının kanıtıdır. Kodsuz bir kapsam dışı maddesi (“alt bayiler dâhil değildir”) tartışma çıktığında “biz onu kastetmemiştik” savunmasına açıktır. A4 yazdığınızda, konuşulan şeyin matriste öncelik 3 ile kayda geçmiş belirli bir istek olduğunu gösterirsiniz. Ayrıca 05. bölümde göreceğiniz gibi A4 ve B2’nin İKY’de hiçbir karşılığı yoktur — zincir burada da tutarlıdır.
En sık yapılan hata
Kapsam dışı bölümünü boş bırakmak ya da “bu belgede yazmayan her şey kapsam dışıdır” gibi tek cümlelik bir muafiyet yazmak. Bu cümle hiçbir tartışmayı kapatmaz; kapsam dışı, adı konularak ve kodu yazılarak reddedilen istektir. Reddedilmemiş istek geri gelir.
✗ Böyle yazma / ✓ Böyle yaz
| ✗ Böyle yazma | ✓ Böyle yaz |
|---|---|
| Kapsam dışı: Bu belgede belirtilmeyen tüm işler. | Kapsam dışı: 1200 alt bayinin sisteme dâhil edilmesi A4; alt bayilerin sunucular üzerinden işlem yapabilmesi B2; alt bayiler için temas birimi B4. |
| Bayi kurulumları tamamlanacaktır. | 7 bölge bayii kurulumu tamamlanır A3; alt bayiler bu projenin kapsamı dışındadır A4. |
| Kabul ölçütü: Sistemin sorunsuz çalışması. | Kabul ölçütü: Kabul testleri 15 Aralık 2020'ye kadar tamamlanır ve operasyon ekibine imzayla teslim edilir. |
İş Kırılım Yapısı (WBS) Nedir, Nasıl Hazırlanır — Örnekle
Ne işe yarar
Kapsamı, iş atanabilecek ve maliyeti tahmin edilebilecek parçalara böler. İKY yoksa süre ve maliyet tahmini projenin tamamı için tek kalemde yapılır; tek kalemde yapılan tahmin de daima yanlıştır. İKY aynı zamanda kapsamın sınırını görünür kılar: İKY’de karşılığı olmayan iş yapılmaz, İKY’de olmayan teslimat teslim edilmez.
Zincirdeki yeri
Kapsam Bildirimi'nden beslenir.
Aktivite Listesi’ni ve maliyet tahminini besler; her iş paketi 06. bölümde aktiviteye, 08. bölümde maliyet kalemine dönüşür.
Üç kural
| Kural | Ne demek | Nasıl denetlenir |
|---|---|---|
| %100 kuralı | Alt seviyedeki kalemlerin toplamı üst kalemin tamamını verir — ne eksik ne fazla. | 2.1'in altındaki 2.1.1–2.1.4 toplamı, sistem kurulumunun tamamı mı? Dışarıda kalan bir iş varsa kural bozuktur. |
| Teslimat odaklı yazım | İş paketi isim tamlamasıyla yazılır, fiille değil. İKY iş listesi değil, teslimat ağacıdır. | Kalemin başına “… teslim edildi” ekleyebiliyor musunuz? |
| 8–80 saat | Bir iş paketi 8 saatten küçük, 80 saatten büyük olmamalı. | 8 saatin altı mikro yönetimdir; 80 saatin üstü izlenemez, ilerlemesi tahmine kalır. |
Dolu örnek — AlfaBeta İKY
- 1Teknik alt yapının hazırlanması
- 1.1Teknik Projenin oluşturulması
- 1.1.1Sunucu / softswitch / kablo standartlarının belirlenmesi
- 1.1.2Rack yerlerinin belirlenmesi
- 1.1.3Teknik proje dokümanlarının hazırlanması
- 1.2Satınalma
- 1.2.1Şartnamelerin oluşturulması← gereksinim B5
- 1.2.1.12 adet sunucu← gereksinim C2
- 1.2.2Tekliflerin alınması
- 1.2.3Satınalma kararı
- 1.2.4Girdi kalite kontrol← kalite planı, 09
- 1.2.5Onay
- 1.1Teknik Projenin oluşturulması
- 2İOY Programının kurulumu
- 2.1Sistem Kurulumu
- 2.1.1Fiziksel kurulum
- 2.1.2Yazılım kurulumu
- 2.1.3Konfigürasyon
- 2.1.4Kontrol
- 2.2Kabul Testleri← başlatma belgesi hedef 2
- 2.37 Bölge bayi kurulumları← gereksinim A3, B1
- 2.1Sistem Kurulumu
- 3Süreçlerin İOY Programına taşınması
- 4Eğitimlerin planlanması ve verilmesi← gereksinim C6, D1
Zincirin en somut kanıtı burada: bu ağaçta A4 (1200 alt bayi) ve B2 için hiçbir dal yoktur. Kapsam dışı bırakılan bir gereksinimin İKY’de hâlâ duruyor olması, kapsam kaymasının en erken ve en sessiz belirtisidir.
En sık yapılan hata
İKY’yi iş listesi gibi yazmak. “Toplantı yapılması”, “koordinasyon sağlanması” gibi kalemler İKY’ye girdiğinde %100 kuralı denetlenemez hâle gelir: bu kalemlerin ne zaman bittiğini kimse söyleyemez. İkinci hata: kapsam dışı bırakılan gereksinimin dalını silmeyi unutmak.
✗ Böyle yazma / ✓ Böyle yaz
| ✗ Böyle yazma | ✓ Böyle yaz |
|---|---|
| 1.1.3 Teknik proje dokümanlarının hazırlanması (fiil — ne zaman bittiği belirsiz) | 1.1.3 Teknik proje dokümanları (teslimat — teslim edilir, tarihi olur) |
| 2. İOY kurulumu ile ilgili tüm işler | 2.1 Sistem Kurulumu · 2.2 Kabul Testleri · 2.3 7 Bölge bayi kurulumları (toplamı 2’nin tamamını verir) |
| 1.2 Satınalma süreci (yaklaşık 3 ay) | 1.2 Satınalma → 1.2.1 … 1.2.5 (her biri 8–80 saat aralığında, ayrı ayrı izlenebilir) |
| 5. Alt bayi entegrasyonu | A4 kapsam dışıdır; İKY’de dalı yoktur. |
Aktivite Listesi ve Kritik Yol (CPM) Nasıl Hesaplanır — İleri Geçiş, Geri Geçiş, Bolluk
Ne işe yarar
Projenin en erken ne zaman bitebileceğini ve hangi gecikmenin bitiş tarihini doğrudan ittiğini söyler. CPM olmadan hazırlanan takvimde her aktivite eşit önemde görünür; oysa aktivitelerin bir kısmı gecikse proje gecikmez, bir kısmı bir gün gecikse proje bir gün gecikir. Kritik yol, hangi işin gecikmesine üzüleceğinizi önceden söyler.
Zincirdeki yeri
İş Kırılım Yapısı'ndan beslenir; her aktivite bir iş paketinden türer.
Zaman çizelgesini, PERT hesabını (07) ve risk kaydını (10) besler; kritik yol üzerindeki D aktivitesi 10. bölümdeki en yüksek skorlu riskin konusudur.
Nasıl hesaplanır
İleri geçiş soldan sağa gidilir: bir aktivitenin en erken başlama zamanı (EB), öncüllerinin en erken bitişlerinin en büyüğüdür. Projenin en erken bitişi buradan çıkar: 49,5 gün. Geri geçiş sağdan sola gidilir: aktivitenin en geç bitişi (GBi), ardıllarının en geç başlamalarının en küçüğüdür. Toplam bolluk = GB − EB; projeyi geciktirmeden kaybedilebilecek gün sayısıdır. Serbest bolluk, ardılın en erken başlangıcını geciktirmeden kaybedilebilecek gün sayısıdır. Süreler PERT beklenen değerleridir (07. bölüm).
Dolu örnek — AlfaBeta aktivite listesi ve CPM tablosu
| Kod | Aktivite | Öncül | Süre | EB | EBi | GB | GBi | Toplam bolluk | Serbest bolluk |
|---|---|---|---|---|---|---|---|---|---|
| A | Teknik projenin oluşturulması | — | 8 | 0 | 8 | 0 | 8 | 0 | 0 |
| B | Satınalma şartnameleri | A | 6 | 8 | 14 | 8 | 14 | 0 | 0 |
| C | Tekliflerin alınması | B | 3 | 14 | 17 | 14 | 17 | 0 | 0 |
| D | Satınalma kararı ve sipariş | C | 5 | 17 | 22 | 17 | 22 | 0 | 0 |
| E | Girdi kalite kontrol | D | 3 | 22 | 25 | 22 | 25 | 0 | 0 |
| F | Fiziksel kurulum | E | 4 | 25 | 29 | 25 | 29 | 0 | 0 |
| G | Sunucu odası uygunluk kontrolü | A | 2 | 8 | 10 | 27 | 29 | 19 | 19 |
| H | Yazılım kurulumu ve konfigürasyonu | F, G | 7 | 29 | 36 | 29 | 36 | 0 | 0 |
| I | Kabul testleri | H | 4 | 36 | 40 | 36 | 40 | 0 | 0 |
| J | 7 bölge bayi kurulumu | I | 8,5 | 40 | 48,5 | 41 | 49,5 | 1 | 1 |
| K | Süreçlerin taşınması ve eğitimler | I | 9,5 | 40 | 49,5 | 40 | 49,5 | 0 | 0 |
Beklenen proje süresi 49,5 gün. Bolluğu olan tek iki aktivite G (19 gün) ve J (1 gün). Kritik yol = bolluğu sıfır olan kesintisiz zincirdir, “en uzun süreli aktiviteler” değil: J aktivitesi 8,5 günle E’den (3 gün) çok daha uzundur ama kritik yolda değildir.
Zaman çizelgesi — aynı verinin takvim hâli
Dolu çubuklar süreyi, kesikli çubuklar bolluğu gösterir. G’nin 19 günlük bolluğu gözle görülüyor; J’nin 1 günlük bolluğu ise neredeyse görünmüyor — kritiğe yakın yol bu demektir.
En sık yapılan hata
Yalnızca kritik yolu izleyip kritiğe yakın yolları (bolluk 1–3 gün) izlemeyi bırakmak. Bu projede J’nin bolluğu 1 gündür: J iki gün gecikirse kritik yol K’den J’ye kayar ve proje gecikir. O ana kadar haftalık raporda “kritik yol sorunsuz” yazıyor olur. Kritik yol sabit bir liste değil, her güncellemede yeniden hesaplanan bir sonuçtur.
✗ Böyle yazma / ✓ Böyle yaz
| ✗ Böyle yazma | ✓ Böyle yaz |
|---|---|
| Kritik yol: en uzun süren aktiviteler (J, K, A). | Kritik yol: A → B → C → D → E → F → H → I → K (bolluğu sıfır olan kesintisiz zincir). |
| Kurulum işleri yaklaşık 1,5 ay sürer. | Beklenen proje süresi 49,5 gün; H 29. günde başlar, 36. günde biter. |
| G aktivitesi gecikirse proje gecikir. | G’nin toplam bolluğu 19 gün; 19 güne kadar gecikme proje bitişini etkilemez. Kaynak önce kritik yola verilir. |
| Öncül: kurulum ekibi hazır olduğunda. | H’nin öncülleri F ve G; ikisi de bitmeden başlamaz. |
PERT Nedir, Nasıl Hesaplanır — Üç Nokta Tahmini ve Güven Düzeyi
Ne işe yarar
Tek bir süre tahmini yerine iyimser, olası ve kötümser üç tahmin alarak belirsizliği sayıya çevirir. PERT olmadan verilen tarih, tahmini yapan kişinin o günkü iyimserliğidir. PERT’in asıl kazancı beklenen süreyi hesaplamak değil, o sürenin ne kadar tutacağını söylemektir.
Zincirdeki yeri
Aktivite listesindeki a/m/b tahminlerinden beslenir.
Sponsora verilecek tarih taahhüdünü ve 12. bölümdeki zaman yönetimi kararını besler.
Formüller
| Formül | Ne verir | AlfaBeta’da |
|---|---|---|
| E(t) = (a + 4m + b) / 6 | Aktivitenin beklenen süresi | D: (2 + 16 + 12) / 6 = 5 gün |
| σ² = ((b − a) / 6)² | Aktivitenin varyansı — belirsizliğin ölçüsü | D: ((12 − 2) / 6)² = 2,78 |
| σ = √Σσ² | Projenin standart sapması — yalnız kritik yolun varyansları toplanır | √9,36 = 3,06 gün |
Dolu örnek — kritik yol PERT hesabı
| Kod | a | m | b | E(t) | σ² | Kritik yolda mı? |
|---|---|---|---|---|---|---|
| A | 6 | 8 | 10 | 8,0 | 0,44 | Evet |
| B | 3 | 6 | 9 | 6,0 | 1,00 | Evet |
| C | 1 | 3 | 5 | 3,0 | 0,44 | Evet |
| D | 2 | 4 | 12 | 5,0 | 2,78 | Evet — en belirsiz aktivite |
| E | 2 | 3 | 4 | 3,0 | 0,11 | Evet |
| F | 3 | 4 | 5 | 4,0 | 0,11 | Evet |
| H | 3 | 7 | 11 | 7,0 | 1,78 | Evet |
| I | 2 | 4 | 6 | 4,0 | 0,44 | Evet |
| K | 4 | 10 | 13 | 9,5 | 2,25 | Evet |
| G | 2 | 2 | 2 | 2,0 | 0,00 | Hayır — varyansı toplanmaz |
| J | 5 | 8 | 14 | 8,5 | 2,25 | Hayır — varyansı toplanmaz |
| Toplam | — | — | — | 49,5 | 9,36 | σ = √9,36 = 3,06 |
Güven düzeyi ve taahhüt
| Süre | Anlamı | Kime söylenir |
|---|---|---|
| 49,5 gün | Beklenen süre. Gerçekleşme olasılığı yaklaşık %50: yarı yarıya aşılır. | Proje ekibinin iç hedefi |
| 53,4 gün | %90 güven düzeyi (49,5 + 1,28 × 3,06). On projeden dokuzunda tutar. | Sponsora taahhüt edilecek tarih |
Aradaki 3,9 gün keyfi bir pay değil, kritik yolun ölçülmüş belirsizliğidir. Bu farkı sponsora “ihtiyatlı davranıyorum” diye değil, “%50 ile %90 arasındaki fark budur” diye anlatırsınız.
En sık yapılan hata
Beklenen süreyi taahhüt tarihi sanmak. 49,5 günü sponsora söz verdiğinizde, daha ilk gün %50 gecikme olasılığını kabul etmiş olursunuz.
İkinci hata: bütün aktivitelerin varyansını toplamak. Kritik yolda olmayan J ve G’nin varyansları toplama girmez — girerse σ şişer ve gereğinden geniş bir taahhüt verilir. Ama dikkat: J’nin varyansı 2,25 ile yüksek, bolluğu ise yalnız 1 gün. Bu birleşim, J’nin gerçekleşen sürede kritik yola girme ihtimalinin ciddi olduğunu söyler.
✗ Böyle yazma / ✓ Böyle yaz
| ✗ Böyle yazma | ✓ Böyle yaz |
|---|---|
| Proje 49,5 günde biter. | Beklenen süre 49,5 gün (%50); %90 güvenle taahhüt edilebilir süre 53,4 gündür. |
| Süre tahmini: D aktivitesi 4 gün. | D: a=2, m=4, b=12 → E(t)=5 gün, σ²=2,78. Kötümser tahmin olası tahminin üç katı; bu aktivite risk kaydına girer. |
| Emniyet payı olarak süreye %15 eklendi. | 49,5 → 53,4 gün farkı, kritik yolun standart sapmasından (3,06) ve seçilen %90 güven düzeyinden gelir. |
Proje Maliyet ve Bütçe Çizelgesi — Yedek ile Yönetim Rezervi Arasındaki Fark
Ne işe yarar
Tahminleri, üzerinde durulabilecek tek bir sayıya çıkarır ve o sayının hangi parçasını kimin harcayabileceğini belirler. Bu ayrım yapılmadığında proje yöneticisi rezervi kendi payı sanır, sponsor da her aşımı kötü yönetim sanar. Bütçenin işi para vermek değil, harcama yetkisini bölmektir.
Zincirdeki yeri
Aktivite tahminlerinden ve İş Kırılım Yapısı’ndan beslenir.
Proje Yönetim Planı'nı besler ve Başlatma Belgesi'ndeki 100.000 $ tavanına geri döner.
Dolu örnek — AlfaBeta bütçe merdiveni
| Basamak | Ne eklenir | Tutar | Kimin yetkisinde |
|---|---|---|---|
| Aktivite ve iş paketi tahminleri | Aşağıdan yukarı toplanan doğrudan maliyet | 86.600 $ | Tahmini yapan ekip |
| + Yedek (%10) | Bilinen belirsizlikler için: tanımlanmış risklerin karşılığı | 8.660 $ | Proje yöneticisi — Bünyamin |
| = Maliyet tabanı | Projenin performansının ölçüldüğü çizgi | 95.260 $ | Proje yöneticisi — Bünyamin |
| + Yönetim rezervi (%5) | Bilinmeyen belirsizlikler için: tanımlanmamış olayların karşılığı | 4.763 $ | Sponsor — Can |
| = Proje bütçesi | Kuruma taahhüt edilen üst sınır | 100.023 $ | Sponsor — Can |
| Başlatma Belgesi tavanı | Hedef 3: “Proje bütçesi 100.000 $ aşmamalıdır” | 100.000 $ | Aşım: 23 $ |
Bu 23 dolar neden önemli
Tutar önemsiz, an önemli. Çizelge, projenin ilk gününde konulan bir sınırın son satırda tutmadığını kendiliğinden gösterdi. Kontrol mekanizmasının işe yaraması tam olarak budur: aşımı proje yöneticisi keşfetmiyor, çizelge keşfediyor. Bu noktada üç seçenek vardır ve üçü de sponsorun önüne yazılı konur: (1) tavan 100.023 $’a güncellenir, (2) yönetim rezervi 4.740 $’a çekilir, (3) kapsamdan 23 $’lık bir kalem çıkarılır. Sessizce yuvarlamak, yani “yaklaşık 100.000 $” yazmak, dördüncü bir seçenek değil kontrolün kapatılmasıdır.
En sık yapılan hata
Yedek ile yönetim rezervini aynı torbaya koymak. Yedek maliyet tabanının içindedir ve proje yöneticisinin yetkisindedir; tanımlanmış bir risk gerçekleştiğinde onay beklemeden kullanılır. Yönetim rezervi tabanın dışındadır ve sponsorun yetkisindedir; kullanıldığında maliyet tabanı resmen değişir. İkisi karıştığında proje yöneticisi sponsorun parasını haber vermeden harcamış olur.
✗ Böyle yazma / ✓ Böyle yaz
| ✗ Böyle yazma | ✓ Böyle yaz |
|---|---|
| Proje bütçesi: yaklaşık 100.000 $ (rezervler dâhil). | Maliyet tabanı 95.260 $ + yönetim rezervi 4.763 $ = proje bütçesi 100.023 $. Başlatma belgesi tavanı 23 $ aşılmıştır; karar sponsorda. |
| Beklenmedik durumlar için %15 pay ayrılmıştır. | %10 yedek (8.660 $) tanımlı riskler için, proje yöneticisi yetkisinde; %5 yönetim rezervi (4.763 $) tanımsız olaylar için, sponsor yetkisinde. |
| Maliyet: satınalma kalemleri piyasa koşullarına göre güncellenecektir. | Tedarik gecikmesi riski (D) %10 yedek içinde karşılanır; yedek yetmezse yönetim rezervi talebi Can’a yazılı gider. |
Proje Kalite Planı Nasıl Hazırlanır — Kalite Ölçütü ve Kontrol/Onay Ayrımı
Ne işe yarar
Her teslimatın hangi ölçütle, hangi yöntemle ve kim tarafından kabul edileceğini önceden yazar. Kalite planı olmadığında kabul kararı teslim gününde ve o günkü ruh hâline göre verilir. Kalite planının işi kaliteyi yükseltmek değil, kabul ölçütünü teslimden önce sabitlemektir.
Zincirdeki yeri
Kapsam Bildirimi’ndeki kabul ölçütlerinden ve gereksinim matrisinin C sınıfından beslenir.
İKY’deki kontrol iş paketlerini (İKY 1.2.4, İKY 2.2) ve Proje Yönetim Planı’nı besler.
Dolu örnek — AlfaBeta kalite planı
| Teslimat / iş paketi | Kalite ölçütü | Kontrol yöntemi | Kontrol eden | Onaylayan |
|---|---|---|---|---|
İKY 1.2.4 Girdi kalite kontrol | Teslim edilen 2 sunucu C2 şartnamedeki özelliklerin tamamını karşılar | Girdi muayenesi; şartname ile birebir karşılaştırma | Mustafa D | Pulat E |
İKY 2.2 Kabul testleri | Kabul testleri 15 Aralık 2020'ye kadar tamamlanır ve operasyon ekibine teslim edilir | Kabul testi senaryolarının yürütülmesi ve tutanağa bağlanması | İsmail H | Mehmet G |
İKY 2.3 7 bölge bayi kurulumu | 7 bölge bayiinin tamamı AlfaBeta sunucuları üzerinden işlem yapabiliyor A3 B1 | Bayi bazında işlem testi; 7 bayi için ayrı ayrı kayıt | Soner C | Mehmet G |
İKY 4 Eğitimler | 3 çalışan süperkullanıcı düzeyinde yetkin C6 D1 | Süperkullanıcı yetkinlik değerlendirmesi | Pulat E | Can A |
İKY 3 Süreçlerin taşınması | 1 Ocak 2021'den itibaren iş süreçlerinin tamamı sistem üzerinde çalışıyor | Süreç işlem kayıtlarının sistemden okunması | Soner C | Can A |
Zincirin bir başka kanıtı: C2 gereksinimi (2 adet sunucu) 05. bölümde İKY 1.2.1.1 oldu, burada da girdi kalite kontrolünün ölçütü hâline geldi. Aynı kalem üç çizelgede aynı kodla görünüyor.
En sık yapılan hata
Kontrol eden ile onaylayanın aynı kişi olması. Kurulumu yapan Mustafa’nın kendi kurulumunu onaylaması, kontrolü bir imza formalitesine indirir; kimse kendi işinde hata aramaz. Bu iki sütun ayrı kişilerle doldurulamıyorsa sorun kalite planında değil, ekip yapısındadır.
İkinci hata: kalite ölçütünü sıfatla yazmak. “Sağlam kurulum”, “yeterli eğitim”, “kaliteli sunucu” ölçüt değildir; hiçbiri reddedilemez, dolayısıyla hiçbiri kabul edilemez.
✗ Böyle yazma / ✓ Böyle yaz
| ✗ Böyle yazma | ✓ Böyle yaz |
|---|---|
| Kalite ölçütü: Sunucular kaliteli ve uygun olmalı. Kontrol: Mustafa. Onay: Mustafa. | Ölçüt: 2 sunucu C2 şartnamedeki özelliklerin tamamını karşılar. Kontrol: Mustafa. Onay: Pulat. |
| Eğitimler tamamlandığında kalite sağlanmış sayılır. | 3 çalışan süperkullanıcı yetkinlik değerlendirmesini geçtiğinde İKY 4 kabul edilir; onay Can’da. |
| Testler sistem çalışır hâle geldiğinde yapılır. | Kabul testleri 15 Aralık 2020'ye kadar tamamlanır; tutanak imzalanmadan teslim yapılmaz. |
Proje Risk Yönetimi Çizelgesi — Risk, Neden ve Etki Ayrımı ile Olasılık × Etki Örneği
Ne işe yarar
Henüz olmamış ama olursa projeyi vuracak olayları, gerçekleşmeden önce sahibiyle ve yanıtıyla birlikte kayda geçirir. Risk kaydı olmayan projede ilk kötü haber geldiğinde ekip önce şaşırır, sonra doğaçlama yapar. Risk yönetiminin çıktısı liste değil, önceden verilmiş kararlardır.
Zincirdeki yeri
Kapsam Bildirimi’nden ve kritik yol analizinden beslenir.
Maliyetteki %10 yedeği ve Proje Yönetim Planı’ndaki gözden geçirme sıklığını besler.
Risk / neden / etki nasıl ayrılır
| Neden (var olan durum) | Risk (belirsiz olay) | Etki (gerçekleşirse sonuç) |
|---|---|---|
| Tek tedarikçiye bağımlılık ve ithalat süreci | Sunucu ve softswitch teslimatının gecikmesi | Kritik yoldaki D aktivitesi kayar, proje bitişi gecikir |
Neden bugün doğrudur, risk belirsizdir, etki gelecekte olur. Ayrım şuna yarar: nedene önlem alınır (ikinci tedarikçi), riske olasılık atanır, etkiye yedek ayrılır. Üçü tek cümlede birleşirse hangisine müdahale edeceğiniz belirsiz kalır.
Dolu örnek — AlfaBeta risk kaydı
| Alan | İçerik |
|---|---|
| İlgili aktivite | D Satınalma kararı ve sipariş — kritik yol üzerinde, toplam bolluk 0 |
| Risk | Sunucu ve softswitch teslimatının gecikmesi |
| Neden | Tek tedarikçiye bağımlılık ve ithalat süreci |
| Olasılık × Etki | 4 × 5 = 20 — yüksek |
| Strateji | Azaltma |
| Yanıt | İki tedarikçiden paralel teklif alınması · sözleşmeye gecikme cezası konulması · çizelgeye 2 hafta zaman yedeği eklenmesi |
| Sahibi | Burçin F — Tedarik Sorumlusu |
| Kalan risk | 2 × 3 = 6 — düşük |
Bu satırın D aktivitesine bağlanması tesadüf değil: 07. bölümde D’nin kötümser tahmini (12 gün), olası tahmininin (4 gün) üç katıydı ve varyansı 2,78 ile bütün aktivitelerin en yükseğiydi. PERT’teki geniş aralık, risk kaydına girecek aktiviteyi zaten işaret etmişti.
Önceliklendirme ve tehdit stratejileri
| Skor (olasılık × etki) | Seviye | Ne yapılır |
|---|---|---|
| 15 ve üzeri | Yüksek | Yanıt planı ve sahip zorunlu; düzenli gözden geçirilir |
| 8 – 14 | Orta | Yanıt planlanır, seyrek gözden geçirilir |
| 7 ve altı | Düşük | Kayda alınır, izlenir |
| Strateji | Ne demek | AlfaBeta’da karşılığı |
|---|---|---|
| Kaçınma | Riski doğuran işi tamamen ortadan kaldırmak | Kapsam dışı bırakılan 1200 alt bayi A4 ile birlikte o kurulumun bütün riskleri de projeden çıktı |
| Aktarma | Riskin finansal sonucunu başka tarafa geçirmek | Sözleşmeye gecikme cezası konulması |
| Azaltma | Olasılığı veya etkiyi düşürmek | İki tedarikçiden paralel teklif; 20 → 6 |
| Kabullenme | Bilerek hiçbir şey yapmamak, yedekle karşılamak | Kalan 2 × 3 riski kabullenilir; karşılığı %10 yedeğin içindedir |
Risk kaydına girmesi gereken iki uyarı
Bu projede çizelgeler iki şeyi kendiliğinden işaret etti; ikisi de risk kaydına açılmalıdır:
Jaktivitesinin bolluğu 1 gün ve varyansı 2,25. Kritiğe yakın yol; iki günlük bir kayma kritik yolu değiştirir. Riskin nedeni değil, ölçülmüş konumudur.- Proje bütçesi tavanı 23 $ aşıyor. Bu bir risk değildir — zaten olmuştur. Gerçekleşmiş belirsizlik risk değil sorundur; risk kaydına değil, sorun kaydına ve sponsorun karar listesine girer.
En sık yapılan hata
Zaten gerçekleşmiş bir durumu risk diye yazmak. “Bütçe tavanı aşıldı” bir risk değil sorundur: olasılığı yoktur, olmuştur. Risk kaydına sorun yazıldığında iki şey birden bozulur — sorun geciktirilir (çünkü “izleniyor” sayılır) ve risk kaydının ortalama skoru anlamsızlaşır.
İkinci hata: riski sahipsiz bırakmak. Sahibi yazılmamış risk, gerçekleştiği gün kimsenin sorumluluğunda olmayan bir sürprizdir.
✗ Böyle yazma / ✓ Böyle yaz
| ✗ Böyle yazma | ✓ Böyle yaz |
|---|---|
| Risk: Tedarikçi sorunları nedeniyle gecikme yaşanabilir ve proje aksayabilir. | Neden: tek tedarikçiye bağımlılık ve ithalat süreci. Risk: sunucu ve softswitch teslimatının gecikmesi. Etki: kritik yoldaki D kayar, bitiş gecikir. 4 × 5 = 20. |
| Yanıt: Tedarikçi yakından takip edilecektir. Sahibi: Proje ekibi. | Azaltma: iki tedarikçiden paralel teklif, sözleşmede gecikme cezası, çizelgede 2 hafta zaman yedeği. Sahibi: Burçin. Kalan risk 2 × 3. |
| Risk: Bütçe tavanı aşıldı (olasılık 5 × etki 4). | Sorun: proje bütçesi 100.023 $, tavan 100.000 $, aşım 23 $. Karar sponsorda; risk kaydında değil sorun kaydında izlenir. |
Proje İletişim Yönetimi Planı Nasıl Yapılır — Kime, Ne, Hangi Sıklıkta
Ne işe yarar
Paydaş analizindeki stratejiyi takvime bağlar: kime ne bilgi, hangi biçimde ve hangi sıklıkta gider. Bu plan yoksa iletişim talep üzerine yapılır; yani en çok soran en çok bilgilenir, susan paydaş ise proje bitiminde sürprizle karşılaşır. İletişim planının ölçütü bilgi vermek değil, hiçbir kararın bilgisiz alınmamasıdır.
Zincirdeki yeri
Paydaş Analizi’nden beslenir.
Proje Yönetim Planı’nı besler; raporların içeriği çizelge 06, 08 ve 10’dan gelir.
Kural
Paydaş analizindeki her “yakından yönet” paydaşı — yani her yüksek güç + yüksek çıkar paydaşı — bu tabloda mutlaka bir satıra sahip olmalıdır. AlfaBeta’da bu iki kişidir: Can A ve Mehmet G. Biri tabloda yoksa, projenin kararını verebilecek bir kişiyi bilgilendirmeyi plana yazmamışsınız demektir. Ayrıca risk sahibi olan paydaş, matristeki konumundan bağımsız olarak plana girer — bu projede Burçin F.
Dolu örnek — AlfaBeta iletişim planı
| Paydaş | Konum | Neye ihtiyacı var | Biçim | Sıklık | Sorumlu |
|---|---|---|---|---|---|
Can A | Y/Y | Bütçe tavanı, tarih taahhüdü, karar bekleyen konular | Durum raporu + karar notu | Haftalık | Bünyamin |
Mehmet G | Y/Y | Kabul testi ve 7 bayi kurulum durumu | Ortak durum toplantısı | Haftalık | Bünyamin |
Fırat B | Y/D | Maliyet tabanı ve rezerv kullanımı | Maliyet özeti | Aylık | Bünyamin |
Pulat E | D/Y | Teknik şartname ve konfigürasyon kararları | Teknik doküman paylaşımı | Aktivite bazlı: A, B, H | Mustafa |
İsmail H | D/Y | Kabul testi senaryoları ve sonuçları | Test planı ve tutanak | I aktivitesi öncesi ve sonrası | Mustafa |
Soner C | D/D | Süreç geçiş takvimi ve eğitim tarihleri | Bilgilendirme notu | Faz sonunda | Bünyamin |
Burçin F | D/D | Tedarik teslim durumu — yüksek riskin sahibi | Sipariş takip listesi | D–E aktiviteleri süresince haftalık | Bünyamin |
Mustafa D | D/D | Kurulum iş emirleri ve girdi kontrol sonuçları | İş listesi | Faz sonunda | Bünyamin |
En sık yapılan hata
Herkese aynı raporu göndermek. Fırat’a Y/D teknik konfigürasyon detayı gönderdiğinizde, gerçekten ihtiyaç duyduğu maliyet bilgisini de okumaz hâle gelir; Pulat’a D/Y bütçe özeti gönderdiğinizde hiçbir işine yaramaz. Tek bir dağıtım listesi, paydaş analizini yapmamış olmakla aynı sonucu verir.
İkinci hata: yüksek güç + yüksek çıkar bir paydaşı planda unutmak. Karar verecek kişiye bilgi gitmiyorsa, karar ya gecikir ya da eksik bilgiyle verilir.
✗ Böyle yazma / ✓ Böyle yaz
| ✗ Böyle yazma | ✓ Böyle yaz |
|---|---|
| Tüm paydaşlara aylık durum raporu gönderilecektir. | Can ve Mehmet: haftalık durum raporu ve karar notu. Fırat: aylık maliyet özeti. Pulat: aktivite bazlı teknik doküman. |
| Gerektiğinde bilgilendirme yapılacaktır. | Burçin’e D–E aktiviteleri süresince haftalık sipariş takip listesi; risk skoru 15’in üzerinde olduğu sürece bu sıklık düşürülmez. |
| Sponsor proje boyunca bilgilendirilecektir. | Can A — haftalık, durum raporu + karar notu; sorumlusu Bünyamin. Karar bekleyen konu varsa rapor başına yazılır. |
Proje Yönetim Planı Nedir, İçinde Ne Olmalı — Ana Kararlar Sütunu Örneği
Ne işe yarar
Önceki on bir çizelgeyi tek bir belgede birleştirir ve her yönetim alanının bu projede nasıl işletileceğini yazar. Bütünleştirici belge olduğu için en son yazılır: beslendiği çizelgeler bitmeden yazılan bir yönetim planı, süreç adlarının sıralandığı bir içindekiler listesinden ibaret kalır.
Zincirdeki yeri
Bütün çizelgelerden beslenir.
Hiçbir çizelgeyi beslemez; proje boyunca uygulanan karar setidir.
Dolu örnek — AlfaBeta proje yönetim planı
| Alan | Ana kararlar | Kaynak çizelge |
|---|---|---|
| Kapsam | A4, B2 ve B4 kapsam dışıdır. Kapsam değişikliği talebi yalnız Can’ın yazılı onayıyla açılır; açılan her talep önce gereksinim matrisine kod alarak girer. | 03 · 04 |
| Zaman | Sponsora taahhüt edilen süre 53,4 gündür (%90); 49,5 gün ekibin iç hedefidir. J’nin bolluğu 1 gün olduğu için kritik yol her haftalık güncellemede yeniden hesaplanır. | 06 · 07 |
| Maliyet | 95.260 $ maliyet tabanını Bünyamin yönetir; 4.763 $ yönetim rezervi yalnız Can’ın onayıyla açılır. Tavan 23 $ aşıldığı için ilk sponsor toplantısının gündem maddesi tavan/kapsam kararıdır. | 01 · 08 |
| Kalite | Hiçbir teslimatta kontrol eden ile onaylayan aynı kişi olamaz. Girdi kontrolünü Mustafa yapar, Pulat onaylar; kabul testi tutanağı imzalanmadan teslim yapılmaz. | 09 |
| Risk | Skoru 15 ve üzeri riskler haftalık, 8–14 arası aylık gözden geçirilir. Gerçekleşmiş belirsizlikler risk kaydından çıkarılıp sorun kaydına taşınır. | 10 |
| İletişim | Can ve Mehmet her durum raporunun dağıtım listesindedir. Karar bekleyen konu varsa raporun ilk satırına yazılır; rapor sonuna konmaz. | 02 · 11 |
| Tedarik | Sunucu ve softswitch için iki tedarikçiden paralel teklif alınır; sözleşmede gecikme cezası bulunur. Girdi kalite kontrolünden geçmeyen teslimat için ödeme yapılmaz. | 09 · 10 |
En sık yapılan hata
Ana Kararlar sütununa süreç adını tekrar yazmak: “Risk yönetimi — riskler yönetilecektir”, “Kapsam yönetimi — kapsam kontrol edilecektir”. Bu satırlar hiçbir soruyu cevaplamaz; projede bir tartışma çıktığında açılıp bakılamaz. Sütunun testi şudur: bu cümle bir tartışmayı bitirebiliyor mu? “Yönetim rezervi yalnız Can’ın onayıyla açılır” bitirir; “maliyet kontrol edilecektir” bitirmez.
İkinci hata: yönetim planını en başta yazmak. Beslendiği çizelgeler yokken yazıldığında, plan projeyi değil şablonu anlatır.
✗ Böyle yazma / ✓ Böyle yaz
| ✗ Böyle yazma | ✓ Böyle yaz |
|---|---|
| Kapsam yönetimi: Kapsam değişiklikleri kontrol altında tutulacaktır. | Kapsam değişikliği yalnız Can’ın yazılı onayıyla açılır; talep önce gereksinim matrisine kod alarak girer. |
| Zaman yönetimi: Takvim düzenli olarak güncellenecektir. | Taahhüt 53,4 gün (%90), iç hedef 49,5 gün. J’nin bolluğu 1 gün olduğundan kritik yol haftalık yeniden hesaplanır. |
| Kalite yönetimi: Kalite standartlarına uyulacaktır. | Kontrol eden ile onaylayan aynı kişi olamaz; kabul testi tutanağı imzalanmadan teslim yapılmaz. |
Planınızı beş dakikada denetleyin
Cevabı evet ya da hayır olan sorular. Bir tanesine bile “kısmen” diyorsanız cevap hayırdır.
- Her kapsam içi gereksinimin bir İKY numarası var mı?Tek istisna A sınıfı fayda gereksinimleridir; onların da bir ölçüm yöntemi ve ölçüm anı yazılı olmalıdır.
- Kapsam dışı bıraktığınız gereksinimler İKY'nizde hâlâ duruyor mu?Duruyorsa kapsam kayması başlamıştır ve henüz kimse fark etmemiştir.
- Kabul kriterlerinizin hepsi sayı, tarih ya da yüzde içeriyor mu?“Sorunsuz çalışması”, “yeterli eğitim” gibi ifadeler reddedilemez, dolayısıyla kabul de edilemez.
- Kritik yol üzerindeki her aktivite için en az bir risk tanımlı mı?Bolluğu sıfır olan aktivitede her gecikme doğrudan bitiş tarihine yazılır.
- Yüksek güç + yüksek çıkar paydaşlarınızın hepsi iletişim planında var mı?Karar verecek kişi dağıtım listesinde yoksa karar ya gecikir ya eksik bilgiyle verilir.
- Bütçeniz yedek ve yönetim rezerviyle birlikte tavanı aşıyor mu?Aşıyorsa bu bir hesap hatası değil, verilecek bir karardır: tavan, rezerv ya da kapsam değişir.
Kısa not
Bu çizelgeler ve aralarındaki besleme ilişkisi PMBOK 6. baskı süreç yapısına dayanır. Çevik yürütülen projelerde İş Kırılım Yapısı ve CPM yerine ürün iş listesi (product backlog) ve sprint planı kullanılır; ölçülebilir kabul ölçütü, kapsam dışı listesi ve risk sahibi kuralları ise her iki yaklaşımda da geçerliliğini korur.