Bent Flyvbjerg, 70 yıl boyunca 20 ülkede gerçekleştirilen 258 projeyi inceledi. Bu projelerin 10'da 9'u bütçeyi aştı. Maliyetler ortalama olarak tahminlerin %28 üzerinde gerçekleşti.
Sorun, uygulamanın kötü olmasından değil, takımların plana nasıl yaklaştığından kaynaklanıyordu. Planı bir kez hazırladılar, onaylattılar ve sonra kullanmayı bıraktılar. Koşullar değiştiğinde, plan değişmedi.
Çoğu plan üçüncü haftaya gelindiğinde rafa kaldırılır. Bu planlar onaylanmak için hazırlanmış, uygulanmak için değil. Planlama (ne yapılacak ve neden yapılacak) ile zamanlama (ne zaman yapılacak) kavramlarını birbirine karıştırırlar. Ayrıca, kapsam değişikliğini aksamaya yol açmadan ele alabilecek net bir yöntemleri yoktur.
Bu kılavuz, herhangi bir araçta uygulanabilen yedi adımda bir proje planının nasıl yazılacağını gösterir. Ayrıca Waterfall, Agile, pazarlama ve inşaat alanlarından gerçek hayattan örnekler göreceksiniz. Üstelik planların gerçekte nerede tutulduğuna dair bir karşılaştırmalı inceleme de sunuluyor: elektronik tablolar, paylaşılan Dokümanlar ve özel proje yönetimi araçları.
Özet
Proje planı, kapsamı, zaman çizelgesini ve kaynakları takımınızın harekete geçebileceği bir temel haline getiren belgedir. En iyi planlar, planlamayı zaman çizelgesinden ayırır. Her değişikliği bu temel üzerinden yönlendirir. Ve her dönüm noktasında gözden geçirilir.
Bu kılavuz, kapsam değiştiğinde, bağımlılıklar bozulduğunda ve ekip üyeleri başka işlere yönlendirildiğinde bile sağlam kalacak bir proje planının nasıl oluşturulacağını gösterir.
Proje Planı Nedir?
Proje planı, bir projenin nasıl yürütüleceğini, izleneceğini ve kapatılacağını gösteren resmi bir belgedir. Kapsam, zaman çizelgesi, kaynaklar, riskler ve iletişim protokollerini içerir ve uygulama başladığında takımın çalışacağı temel çerçeveyi oluşturur.
Proje planı ne değildir?
Proje planı, proje şartnamesi değildir. Şartname, projeye yetki verir ve proje yöneticisine yetki tanır. Şartname, “Bunu yapılacak mı ve sorumlu kimdir?” sorularına yanıt verir. Plan ise şartnamenin bittiği yerden devam eder ve “Nasıl, ne zaman, kim tarafından ve ne maliyetle?” sorularına yanıt verir.
Proje planı, kapsam bildirimi ile aynı şey değildir. Kapsam bildirimi, projenin neyi sağlayacağını ve neyi sağlamayacağını tanımlar. Size “tamamlandı” durumun neye benzediğini gösterir. Proje planı ise kapsam bildiriminin yanına zaman çizelgesini, kaynakları, riskleri, iletişimi ve değişiklik kontrolünü de ekler. Takımın hedefe nasıl ulaşacağını, kimin ne yapacağını ve bir değişiklik olduğunda ne olacağını size anlatır.
Bir proje planının 5 aşaması
Bir proje planı, Proje Yönetimi Enstitüsü (PMI) tarafından proje yaşam döngüsü olarak tanımlanan beş aşamayı kapsar: başlatma, planlama, yürütme, izleme ve kontrol etme ile kapanış.
- Başlangıç: Projenin amacını tanımlayın, paydaşları belirleyin ve proje şartnamesini onaylatın. Plan henüz hazır değil, ancak planı hazırlamak için gerekli koşullar mevcut.
- Planlama: Kapsamı, zaman çizelgesini, kaynak planını, risk kaydını ve iletişim planını oluşturun. Bu kılavuzun geri kalan kısmı bu aşamayı ele almaktadır.
- Uygulama: İşi takım yapar. Plan, kimin neyi ne zaman yapacağına dair referans belgesi haline gelir.
- İzleme ve kontrol: İlerlemeyi referans durumuna göre takip edin. Her değişiklik talebini, planda tanımladığınız değişiklik kontrol sürecinden geçirin.
- Kapanış: Teslim edileceklerin kabul edildiğini teyit edin, çıkarılan dersleri belgelendirin ve takımı görevden alın. Plan silinmez, arşivlenir: bir sonraki benzer proje, boş bir sayfadan değil, bu plandan yola çıkarak başlar.
Planın kendisi Planlama aşamasında hazırlanır, ancak Uygulama ve İzleme aşamalarında da aktif olarak kullanılır. Planlama aşaması bittiğinde Kapalı olan bir plan, erken aşamada terk edilen plandır.
Proje Planı Neden Önemlidir?
Planı atlarsanız, aynı sorunlar tekrar tekrar ortaya çıkar. Kimse sınırları belirlemediği için kapsam genişlemesi, iki iş akışı aynı mühendisi talep ettiği için kaynak çatışmaları ve gizli bağımlılıklar geç ortaya çıktığı için teslim tarihlerinin kaçırılması gibi sorunlar yaşanır.
Bir proje planı, işin yürütülmesine başlamadan önce sürecin görünürlüğünü artırarak bu tür başarısızlıkları önler.
- Paydaşlar arasında uyum. Sponsorlar, takım liderleri ve katılımcılar, işe başlamadan önce başarının neye benzeyeceği konusunda mutabık kalırlar. Bir plan olmadan, herkes “tamamlandı” kavramını kendine göre biraz farklı bir şekilde yorumlayarak çalışır.
- Bağımlılıkların görünürlüğü. Plan, hangi görevlerin diğerlerini engellediğini ortaya çıkarır. Bu, projelerin yarıda kalmasına neden olan “Benden beklediğini bilmiyordum” sorununu önler.
- Gerçekçi kaynak tahsisi. Bu, takımı mevcut personel ve bütçeyi gerçek proje kapsamına uydurmaya zorlar. Artık, düzeltmesi çok pahalı hale geldiğinde proje ortasında eksikliklerin farkına varmak zorunda kalmayacaksınız.
- Daha iyi karar verme. Yeni talepler ortaya çıktığında, plan, ödünleşimleri değerlendirmek için bir referans noktası sağlar. Bu referans noktası olmadan, her talep aynı derecede acilmiş gibi algılanır.
- Mikro yönetim olmadan hesap verebilirlik. Belgelenmiş roller, sorumlular ve son tarihler sayesinde, güncellemeleri takip etmek zorunda kalmadan ilerlemeyi izleyebilirsiniz.
PMI’nin Proje Başarısını En Üst Düzeye Çıkarma raporu, başarı kriterlerini önceden belirleyen ve sağlam temellere dayalı bir performans ölçüm sistemi kuran projelerin başarı oranlarının neredeyse iki kat daha yüksek olduğunu ortaya koymuştur.
Plan bir temel oluşturur, kesin bir şablon değildir
Çoğu proje yöneticisi, planı bir teslim belgesi olarak görür. Planı, paydaşlara ne yapacağınızı göstermek için hazırlarsınız ve ancak mecbur kaldığınızda güncellersiniz. Bu da size bir karar aracı değil, sadece anlık bir durum özeti sunar.
Bir projenin asıl işlevi, gelecek beklenenden farklı şekilde geliştiğinde dayanabileceğiniz somut bir dayanak sağlamaktır. Kapsam değişikliği talepleri, bir hisse göre değil, temel plana göre değerlendirilir. Zaman çizelgesindeki gecikmeler, hafızaya göre değil, plana göre ölçülür. Başarılı olan plan, her dönüm noktasında güncellenen plandır.
Bundan iki kural çıkar ve bu kılavuzun geri kalanı bu kurallar üzerine inşa edilmiştir:
- Önce planlayın, sonra zamanlamayı yapın. Planlama, yapılacak şeyin ne olduğunu ve neden yapıldığını belirlemektir. Zamanlama ise ne zaman yapılacağına karar vermektir. İkisini karıştırırsanız, zaman çizelgeleri projenin kapsamını belirlemeye başlar.
- Her dönüm noktasında gözden geçirin. İlk haftada oluşturulup sekizinci haftaya kadar hiç değiştirilmeyen bir plan, yanlış bir güven duygusu yaratır. Takımın doğru bilgilere dayanarak iş yapabilmesi için planı bilinçli bir şekilde güncelleyin.
Bu yaklaşım, Flyvbjerg'in iyimserlik önyargısı olarak adlandırdığı olguyu ele alır: planlamacıların maliyetleri, zaman çizelgelerini ve riskleri hafife alırken faydaları abartma eğilimidir. Statik tahminler olarak oluşturulan planlar, ilk günden itibaren bu önyargıyı taşır ve hiçbir zaman düzeltilmez.
Proje Planının Anahtar Bileşenleri
Her proje planı, ister genel hatlarıyla ister son derece ayrıntılı olsun, aynı temel bileşenlerden oluşur. Aşağıdaki liste, bu bileşenlerin her birini ve ele alması gereken konuları kapsamaktadır.
- Proje kapsam beyanı. Projenin sınırları: nelerin dahil olduğu, nelerin açıkça hariç tutulduğu ve tamamlanma kriterleri
- Hedefler ve başarı ölçütleri. Projenin sağlaması gereken somut ve ölçülebilir sonuçlar (“müşteri deneyimini iyileştirmek” gibi belirsiz hedefler değil)
- İş Dağılım Yapısı (WBS). Tüm çıktılar, yönetilebilir görevler ve alt görevler halinde yapılandırılır
- Zaman çizelgesi ve dönüm noktaları. Anahtar tarihleri, aşama kontrol noktalarını ve projenin en erken tamamlanma tarihini belirleyen kritik yolu içeren zaman çizelgesi
- Kaynak planı. Kime hangi görevler verilmiş, hangi kapasitede çalışacaklar ve hangi araçlara veya bütçeye ihtiyaçları var?
- Risk kaydı. Tespit edilen riskler, bunların olasılığı ve etkisi ile her biri için risk azaltma veya acil durum stratejisi
- İletişim planı. Kimlere ne sıklıkla, hangi kanal üzerinden bilgi verilir ve hangi tetikleyicilerde üst yönetime bildirim yapılır?
- Değişiklik kontrol süreci. Kapsam değişikliklerinin, temel plan temelinde nasıl talep edildiği, değerlendirildiği ve onaylandığı (veya reddedildiği)
Ancak her proje, bu sekiz bölümün hepsine aynı ayrıntı düzeyinde ihtiyaç duymayabilir. İki haftalık bir iç proje, bu bölümlerin birçoğunu tek bir sayfada özetleyebilir. İlaç sektöründeki bir uyum girişimi gibi düzenlemelere tabi bir sektör projesinde ise her bölüm, resmi onay aşamaları içeren ayrı bir alt belgeye ayrılabilir.
7 Adımda Proje Planı Nasıl Yazılır?
Bu yedi adım, metodoloji ne olursa olsun (Waterfall, Agile veya hibrit) işe yarar. Sırası önemlidir çünkü her adım bir sonrakine zemin hazırlar. Adımları atlamak, ilk seferinde doğru bir şekilde planlama yapmaktan daha maliyetli olan yeniden çalışma gerektirir.
1. Adım: Hedeflerinizi belirleyin ve paydaşları tespit edin
Hedeflerinizden başlayın. Planlama konusunda en sık yapılan hata, “başarı neye benzer?” sorusuna cevap vermeden hemen “ne yapılacak?” sorusuna geçmektir. Her hedefi ölçülebilir bir sonuca ve bir son tarihe bağlayın.
Örneğin, “Web sitesini yeniden tasarlamak” bir görevdir. “3. çeyrekten önce fiyatlandırma sayfasındaki dönüşüm oranını %15 artırmak” ise, sonraki tüm kararları şekillendiren bir hedeftir.
Ardından, proje üzerinde yetkisi, etkisi veya projeye bağımlılığı olan herkesi listeye alın. Bunları rollere göre sınıflandırın. Sponsor, bütçe ve kapsam değişikliklerini onaylar; katkıda bulunanlar işi yapar; bilgilendirilen taraflar ise güncellemelere ihtiyaç duyar ancak karar vermez. Basit bir paydaş haritası, tüm bunları düzenli tutmanıza yardımcı olur.
| Ad | Rol | Yetki düzeyi | Güncelleme sıklığı |
| Ürün Başkan Yardımcısı | Sponsor | Kapsam değişikliklerini ve bütçeyi onaylar | İki haftada bir |
| Baş Mühendis | Katkıda Bulunan | Kapsam dahilindeki teknik kararlar | Haftalık |
| Hukuk Danışmanı | Danışmanlık | Uyum gerekliliklerini gözden geçirin | Dönüm noktalarında |
| Satış Direktörü | Bilgili | Karar verme yetkisi yok | Aylık özet |
2. Adım: Proje kapsamını ve çıktıları belirleyin
Kapsam, bir sınır çizgisidir. İçinde yer alan her şey için kaynak ayrılır ve zamanlama yapılır; dışında kalan her şey ise açıkça ertelenir veya reddedilir. İki sütunlu bir “kapsam içinde/kapsam dışında” liste, daha sonra kapsam genişlemesine neden olan belirsizliği önler.
Proje çıktıları ile görevleri birbirinden ayırın. Çıktı, paydaşların aldığı somut bir sonuçtur: “taşınan veritabanı”, “onaylanmış tasarım maketi”, “yayınlanmış API belgeleri”. Görevler ise bunu üretmek için gereken işlerdir. Bu ayrım önemlidir çünkü paydaşlar çıktılara önem verir; takımınız ise görevlere önem verir.
Kapsamla ilgili en yaygın hata nedir? Sınırları o kadar geniş tutmak ki, eklemelere “hayır” demek için kullanılamaz hale gelmesi.
“Kullanıcı deneyimini iyileştirin” ifadesi her anlama gelebilir. “Tablet düzenlerini ve ödeme sağlayıcı değişikliklerini hariç tutarak mobil tarayıcılar için ödeme akışını yeniden tasarlayın” ifadesi, proje ortasında birisi tablet desteği talep ettiğinde reddetmek için size belgelenmiş bir gerekçe sunar.
3. Adım: İş bölünme yapısını oluşturun
2. Adımdaki her bir çıktıyı alın ve bunları ayrı ayrı atanabilecek, tahmini süresi belirlenebilecek ve izleme yapılabilecek en küçük görevlere bölün. Proje -> çıktı -> iş paketi -> görev şeklindeki bu hiyerarşi, iş bölünme yapınız (WBS)dır.
Kullanışlı bir kural: Bir görev birkaç günden uzun sürüyorsa, olasılık yüksekliğiyle daha küçük parçalara bölünebilir.
WBS, zaman çizelgesi ve kaynak planının temelini oluşturur. Eğer eksikse, bundan sonraki tüm aşamalar güvenilir olmaz. Bazı işleri gözden kaçırdığınız için zaman çizelgeniz yanlış olur ve kaynak planınızda boşluklar oluşur.
Örnek olarak, ClickUp'ta bu şöyle görünür:
4. Adım: Proje takvimini ve dönüm noktalarını oluşturun
WBS görevlerinizi alın ve sıralayın: hangi görevlerin diğerlerinin önce tamamlanmasına bağlı olduğunu (bağımlılıklar) ve hangilerinin paralel olarak yürütülebileceğini belirleyin.
Proje dönüm noktaları, ana aşamaların veya çıktıların tamamlandığını gösterir. Bunlar, “tasarım aşaması tamamlandı” veya “kullanıcı kabul testi (UAT) onayı alındı” gibi kontrol noktalarıdır. Bunları, paydaşlarla doğal gözden geçirme noktaları oluşturmak için kullanın. Karmaşık projelerde, bağımlılıkları ve kritik yolu netleştirmek için programı bir Gantt grafiği olarak görselleştirin.
Gerçekçi olası beklenmedik durumlar için programa bir tampon süre ekleyin. Ardından, baskı arttığında kesintiye uğrayacak şekilde sonuna toplu olarak eklemek yerine, aşamaların içine, özellikle de test ve inceleme aşamalarına acil durum payı ekleyin.
5. Adım: Roller belirleyin ve kaynakları tahsis edin
WBS'deki her bir görevi belirli bir sorumlu kişiye atayın. Sahipliğin paylaşımı, sahipliğin olmaması anlamına gelir. Kaynak tahsisi, görevlendirilen kişilerin planlanan zaman diliminde yeterli kapasiteye sahip olduklarının teyit edilmesi anlamına gelir.
İşte burada planlar gerçeklikle yüzleşir. Baş geliştiriciniz aynı anda üç projeye atanmış olabilir. Plan, bu çakışmayı, teslim tarihinin kaçırılmasına yol açmadan önce gün yüzüne çıkarır.
RACI çerçevesi (Sorumlu, Hesap Verebilir, Danışılan, Bilgilendirilen), aşırı belgelemeye gerek kalmadan kimin ne yapacağını netleştirir. Proje için yeni bir yazılım veya bir yüklenici gerekiyorsa, bu da planla birlikte onaylanır.
6. Adım: Riskleri değerlendirin ve iletişim planı hazırlayın
Neler ters gidebileceğini belirleyin, her bir riskin olasılığını ve etkisini değerlendirin ve her biri için bir müdahale planı hazırlayın.
Yaygın proje risklerini bir risk kayıt defterine kaydedin, böylece bu riskler görünürlük kazansın ve sorumlulukları netleşsin. İşte bir örnek.
| Risk | Olasılık | Etki | Risk azaltma stratejisi | Proje Sahibi |
| Proje yarıda kalırken baş geliştirici ayrılıyor | Orta | Yüksek | Kritik modüller konusunda ikinci bir mühendisi çapraz eğitimden geçirin | Mühendislik Müdürü |
| Tedarikçi, API'yi iki hafta gecikmeli olarak teslim etti | Yüksek | Orta | Entegrasyon aşamasına iki haftalık bir tampon süresi ekleyin | Proje Yöneticisi |
| Tasarım aşamasından sonra talep edilen kapsam değişikliği | Yüksek | Yüksek | Değişiklik talebi sürecini önceden tanımlayın | Sponsor |
| 3. çeyrekte bütçe %15 oranında azaltıldı | Düşük | Yüksek | Ertelenebilir çıktıları önceden belirleyin | Proje Yöneticisi |
Profesyonel İpucu: Haftalık standup toplantısı veya iki haftada bir yazılı rapor gibi durum güncellemelerinin sıklığını ve kanalını belirleyin. Ayrıca, bu güncellemeleri kimlerin alacağını ve hangi tetikleyicilerin üst yönetime bildirim yapılmasını tetikleyeceğini de listeye ekleyin. Bir proje iletişim planı, “Birinin size söylediğini varsaydım” gibi sorunların ortaya çıkmasını önler.
7. Adım: Paydaşların onayını alın ve bir başlangıç noktası belirleyin
Plan, sponsor ve anahtar paydaşlar tarafından resmi olarak onaylanana kadar kesinleşmez. Bu onay, projenin temel referans çerçevesini oluşturur: üzerinde mutabık kalınan kapsam, zaman çizelgesi ve bütçe; gelecekteki tüm değişiklikler bu referans çerçevesine göre değerlendirilir.
Bir referans noktası olmadan, orijinal anlaşmadan meşru bir değişikliği ayırt etmenin bir yolu yoktur.
Plan bir kez ayarlandıktan sonra, kapsam, zaman çizelgesi veya bütçede yapılacak her türlü değişiklik, planda tanımladığınız değişiklik yönetimi sürecinden geçer. Onaylanan planı tüm paydaşlarla paylaşın. Planı, her zaman erişilebilir, sürüm kontrolü yapılan ve paylaşılan bir konumda saklayın. Üç ay önceki bir e-posta konusunun derinliklerinde kaybolmasın.
Başlangıç durumu, planın sabit olduğu anlamına gelmez. Bu, değişikliklerin bilinçli bir şekilde yapıldığı ve belgelendiği anlamına gelir. Birisi "bu özelliği ekleyebilir miyiz?" gibi bir değişiklik talebinde bulunduğunda, bunu başlangıç durumuyla karşılaştırırsınız ve ardından maliyet, zaman çizelgesine etkisi ve ödünleşimlere ilişkin tam bir görünürlük içinde birlikte karar verirsiniz.
Proje planınız elektronik tablolar, sohbetler ve e-postalar arasında dağınık haldeyse, bu bir sistem değil, bir engeldir. Bir proje yönetimi veritabanı, her şeyi tek bir yapılandırılmış ve aranabilir yerde bir araya getirir. İster tek bir projeyi ister birden fazla projeyi yönetiyor olun, bu adım adım kılavuz, işlerin uyumlu bir şekilde ilerlemesini ve ilerlemenin görünürlüğünü sağlayan bir veritabanının nasıl oluşturulacağını gösterir.
Proje Planı Örnekleri
Aşağıdaki örnekler, aynı temel bileşenlerin farklı bağlamlara nasıl uyarlanabileceğini göstermektedir. Her birinde yapı, onu diğerlerinden ayıran özellikler ve ne zaman kullanılması gerektiği açıklanmaktadır.
Şelale modeline göre hazırlanmış proje planı örneği
Şelale modeli planı şu sırayla ilerler: gereksinimler, tasarım, geliştirme, test, devreye alma. Her aşama resmi bir kontrol noktasıyla sona erer. Paydaşlar işi inceler ve bir sonraki aşamayı onaylar. Bir önceki aşama onaylanana kadar hiçbir şey ilerlemez.
Örnek akış:
- Gereksinimler belgesi (sponsor tarafından onaylanmış)
- Tasarım aşaması, ardından tasarım inceleme aşaması
- Önce geliştirme aşaması, ardından kod inceleme aşaması
- Test aşaması (birim, entegrasyonlar, UAT), ardından kalite güvencesi onay aşaması
- Uygulamaya geçin, ardından lansman sonrası değerlendirme yapın
Bu yöntemi farklı kılan nedir: Projenin tüm kapsamı, gereksinim belirleme aşamasında kesinleşir. Gantt grafiği, her aşamayı sırayla gösteren ana araçtır. Değişiklik talepleri resmi bir süreç gerektirir ve maliyetlidir. Şelale modeli, esnekliği öngörülebilirlikle takas eder.
En uygun olduğu durumlar: Sabit gereksinimleri, kuralları ve düzenlemeleri olan projeler veya kapsamı sabit tutması gereken dış takımlar. Kamu ihaleleri, uyum işleri ve imalat sektörü bu yöntem için oldukça uygundur.
Aşağıdaki durumlarda uygun değildir: Proje başlangıcında “Tamamlandı” kavramını yüksek bir güvenle tanımlayamıyorsanız. Anlamadığınız bir kapsamı sabitlemek, yineleme yapmaktan daha maliyetlidir.
Çevik proje planı örneği
Çevik bir plan, ürün vizyonunu, öncelik sırasına göre düzenlenmiş iş listesini, sprint süresini (genellikle iki hafta) ve takım rollerini belirler. Ayrıntılı plan, her sprintte daha da gelişir. Takım, her turdan ders çıkarır ve gerekli ayarlamaları yapar.
Örnek akış:
- Ürün vizyonu ve başarı ölçütleri (proje başlangıcında bir belge dosyasına kaydedilir)
- Sıralı iş yığını (her hafta güncellenir)
- Sprint 1 planı: hikayeler, sahipler, kapasite kontrolü
- Sprint 1'in geriye dönük değerlendirmesini yapın, ardından iş yığınına yeniden öncelik sıralaması verin
- Sprint 2 planı…
Bu yaklaşımı farklı kılan şey: Plan, kapsamı bir sonraki sprintin ötesine sabitlemez. Paydaşlar, sprint bazında teslim edilecekler listesi yerine, çeyrek bazında temalar içeren bir yol haritası görür. Retrospektif, geri bildirim döngüsüdür. Bu olmadan Agile, fazladan adımlar içeren bir kapsam genişlemesine dönüşür.
En uygun olduğu durumlar: İhtiyaçların değiştiği, müşteri geri bildirimlerinin işi yönlendirdiği veya takımın küçük partiler halinde teslimat yaptığı projeler. Agile, yazılım, ürün tasarımı ve şirket içi araçlarda yaygın olarak kullanılır.
Şu durumlarda atlayın: Paydaşların önceden belirlenmiş sabit bir kapsam ve tarihe ihtiyacı varsa. Sözleşme katı kurallara dayalıysa, Agile'ın esnekliği size zarar verir.
Pazarlama kampanyası proje planı örneği
Çok kanallı bir pazarlama kampanyası, içeriği, ücretli medyayı, e-posta ve etkinlikleri bir araya getirir. İnceleme döngüleri içeren yaratıcı çıktılar üretir, dış tedarikçileri (ajanslar, serbest çalışanlar) koordine eder ve tüm kanalları tek bir lansman tarihinde bir araya getirir.
Örnek akış:
- Kampanya özeti: hedef, hedef kitle, mesaj, KPI'lar (başlangıç aşamasında belirlenir)
- Çıktılar, sorumlular ve gözden geçirme tarihlerini içeren içerik takvimi
- Lansman tarihinden geriye doğru planlanan kanala özgü zaman çizelgeleri (içerik, ücretli reklamlar, e-posta, etkinlikler)
- Her bir varlık için yaratıcı inceleme ve onay aşamaları
- Lansman günü ve ardından kampanya sonrası performans değerlendirmesi
Neden farklı: Pazarlama planlarında, karar verme yetkisi olanlardan çok, fikir beyan eden paydaşlar daha fazladır. Net bir onay akışı olmadan, her bir varlık beş tur düzenleme sürecinden geçer ve lansman tarihi ertelenir. Burada RACI matrisi isteğe bağlı değildir; lansman tarihini koruyan şey budur.
Diğer bir belirgin risk: Kanallar tek bir tarihte birleşiyor, ancak her birinin hazırlık süresi farklı. Baskı için altı hafta gerekiyor. Ücretli sosyal medya için iki hafta. E-posta için bir hafta. Lansmandan geriye doğru değil de başlangıçtan ileriye doğru planlama yaparsanız, hazırlık süresi uzun olan kanallar ilk günden itibaren zaten gecikmiş olur.
En uygun olduğu durumlar: Ürün lansmanları, sezonluk kampanyalar, marka yenileme çalışmaları veya ortak bir tarihte iki kanaldan fazla kanalda yayınlanan her türlü iş.
Şu durumlarda atlayın: Tek kanallı, sürekli aktif bir program yürütüyorsanız (sadece bir blog, sadece ücretli bir hesap gibi). Bu durumda bir içerik takvimi ve haftalık durum değerlendirmesi yeterlidir. Kapsamlı bir kampanya planı, kullanmayacağınız gereksiz bir yük olacaktır.
İnşaat proje planı örneği
İnşaat projeleri, katı kurallar (ruhsatlar, denetimler) ve zorlu fiziksel bağımlılıklar altında yürütülür. Çerçeve tamamlanmadan elektrik tesisatı kurulamaz.
Örnek akış:
- Proje şartnamesi ve izinler zaman çizelgesi (herhangi bir iş başlamadan önce kesinleştirilir)
- Şantiye hazırlığı ve temel atma (hava koşullarına bağlı)
- Çerçeveleme ve ardından çerçeveleme denetim aşaması
- Belirli bir sırayla mekanik, elektrik ve sıhhi tesisat işleri
- Alçıpan, son rötuşlar, son kontrol, teslimat
Bu yaklaşımı farklı kılan nedir: Asıl risk kapsam değil, zaman çizelgesidir. Bir aşamadaki gecikme, onu takip eden her aşamayı etkiler. Çatı iskeleti işleri bir hafta gecikirse, elektrik, sıhhi tesisat ve ısıtma-havalandırma-iklimlendirme (HVAC) işleri de kayar. İnşaat planları, her aşamanın sonuna değil, aşamanın içine bir tampon süre ekler. Neden? Proje sonu tamponu, her zaman daha önceki adımlarda geciken işler tarafından tüketilir.
En uygun olduğu durumlar: Fiziksel bağımlılıklar, hava durumu riski veya koordine edilmesi gereken birden fazla iş kolu içeren her türlü iş.
Şu durumlarda atlayın: Bilgi tabanlı bir iş yürütüyorsanız. Bir pazarlama kampanyası için inşaat sektörünün ağır kapılarını ödünç almak, gerçek bir koruma sağlamadan ek masraf yaratır.
Bir sonraki projenize boş bir sayfadan başlamayın. ClickUp’ın Üst Düzey Proje Planı Şablonu, görev durumları, onayları ve takım atamalarını izlemek için özel alanlar ve Zaman Çizelgesi ile Teslim Edilecekler Listesi dahil olmak üzere beş yerleşik görünüm içeren, kullanıma hazır bir yapı sunar.
Proje Planları Nerede Saklanmalıdır?
Yöntem, işleri nasıl sıralayacağınızı belirler. Araç ise planın üçüncü haftadan sonra da geçerliliğini koruyup korumayacağını belirler. Üç seçeneğiniz var.
Hesap tabloları (Google E-Tablolar, Excel)
Bunlar, her zaman elektronik tabloları kullanmış olan takımlar için ön tanımlı araçlardır. Görevler için bir tablo, zaman çizelgesi için bir tablo, risk kaydı için bir tablo. Herkes düzenleme yapabilir. Birisi çevrimdışı olsa bile hiçbir şey aksamaz.
Neler işe yarar
- Esneklik. Herhangi bir yapıyı birkaç saat içinde modelleyebilirsiniz
- Filtreler ve pivot tablolar, bir kez ayarlandıktan sonra çok etkilidir
- Neredeyse hiç öğrenme eğrisi yok
Nerede aksıyor?
- Bağımlılıklar manuel olarak belirlenir. Bir görev geciktiğinde, sonraki tüm tarihleri elle güncellemeniz gerekir.
- Sürüm kontrolü, en son kaydeden kişiye aittir
- Ekipler arası bağımlılıkları olan 15 ila 20'den fazla görev olduğunda, planın sürdürülmesi maliyeti planın değerinden daha fazla olur.
En uygun olduğu durumlar: 20'den az görev içeren, tek bir takımın yürüttüğü, tek bir sorumlu sahibi olan ve iç içe geçmiş bağımlılıklar bulunmayan projeler.
Aşağıdaki durumlarda bu adımı atlayın: İki takımdan fazlasının koordinasyonuna ihtiyaç duyuluyorsa veya zaman çizelgesi haftada birden fazla kez değişiyorsa.
Paylaşılan Belgeler (Google Dokümanlar, Notion, Confluence, ClickUp Dokümanlar)
Belge tabanlı bir plan, planın büyük ölçüde düz metinlerden oluştuğu durumlarda işe yarar: kapsam beyanı, paydaş haritası, başarı kriterleri ve risk kaydı. Görevler, sahipleri ve tarihleri ile birlikte madde işaretli listelerde yer alır.
Neler işe yarar
- Plan, bir veritabanı değil, bir belge gibi okunur. Paydaşlar bu belgeyi gerçekten açarlar
- Yorumlar ve inceleme geçmişi, içeriğin hemen yanında yer alır
- Kapsam beyanı ve risk kaydı tek bir yerde bulunur
Nerede aksıyor?
- Canlı durum bilgisi yok. Belge, birisi elle güncelleme yapmadıkça sonsuza kadar “API entegrasyonu oluşturma: ilerleme var” yazısını gösteriyor.
- Bağımlılık izleme veya Gantt görünümü yok. Plan ile iş arasında hızla bir uçurum oluşuyor
En uygun olduğu durumlar: Kısa süreli projeler (bir aydan kısa), anlatım ağırlıklı planlar veya bir görev takip sisteminin ön aşaması olarak. Kapsam ve paydaşlar bu belgededir. Görevler ise başka bir yerde bulunur.
Şu durumlarda atlayın: Bugün kimin hangi konuda bloklanmış olduğunu görmeniz gerekiyorsa.
Özel proje yönetimi araçları (ClickUp, Asana, Jira, Monday)
Görevlerin, bağımlılıkların, sahiplerin ve zaman çizelgelerinin tek bir veri modelini paylaştığı, amaca yönelik olarak tasarlanmış sistemler. Plan ve iş, aynı nesnedir.
Neler işe yarar?
- Bağımlılıklar gerçek zamanlıdır. Bir görev geciktiğinde, sonraki görevler kendiliğinden kayar ve takım bunu gösterge panelinden görebilir.
- Gantt görünümleri, manuel düzeltme gerektirmeden kritik yolu gösterir
- Durum raporları, takımın üzerinde çalıştığı verilerden derlenir; zamanla geçerliliğini yitiren ayrı bir belgeden değil.
Nerede aksıyor?
- Kurulum zaman alır
- İki haftalık bir şirket içi proje için özel durumlar, alanlar ve Gantt görünümü gerekmez
- Canlı verilerin avantajlarından yararlanabilmek için plan ve işin de aynı araçta yer alması gerekir.
En uygun olduğu durumlar: Birden fazla takımı kapsayan, bağımlılıkları değişkenlik gösteren ve kapsam değişikliklerinden etkilenmeyen bir temel gerektiren projeler.
Şu durumlarda atlayın: Tek bir sorumlu, tek bir takım, sabit kapsam ve üç haftadan kısa bir süreye sahip basit bir projeyse. Bu durumda bir belge daha hızlı olur.
Proje Planının Başarısız Olmasının 6 Nedeni
Çoğu proje planı, öngörülebilir nedenlerle ivme kaybeder.
1. Kapsamı o kadar geniş tutmak ki, reddedilemeyecek hale getirmek
Kapsam, eklemeleri reddetmek için size belgelenmiş bir neden sunduğunda yararlıdır. Kapsam belgesine işaret edip “Bu, kapsamın dışında” diyemiyorsanız, kapsam projeyi korumak için yeterince net değildir.
Her kapsam sınırını test edilebilir bir ifade olarak yazın. “Tablet düzenleri ve ödeme sağlayıcı değişiklikleri hariç olmak üzere, mobil tarayıcılar için ödeme akışını yeniden tasarlayın” bir sınırdır. “Deneyimi iyileştirin” ise değildir.
2. Yöneticilerden tahminler alma
Yukarıdan aşağıya tahminler her zaman iyimser olur. Bu, daha önce bahsedilen iyimserlik önyargısının tahminlere uygulanmış halidir. İşi atayan kişi, işi yapan kişiye kıyasla neredeyse her zaman işi hafife alır.
İşi yapılacak geliştirici, sorunların gerçekte nerede olduğunu bilir. WBS'yi işbirliği içinde oluşturun, aksi takdirde yeniden çalışma yapmanız gerekecektir.
3. Tüm yedek zamanınızı sonuna biriktirmek
Dört aylık bir projenin sonuna iki haftalık bir “acil durum payı” ekleyen bir zaman çizelgesi, gerçek anlamda acil durum payı içermeyen bir zaman çizelgesidir. Baskı arttığında ilk olarak bu tampon süre kesilir.
Aşamalara, özellikle de genellikle zamanın tükendiği test ve inceleme aşamalarına, acil durum süresi ekleyin. İşin içinde yer alan tampon süre, işin tamamlanmasına kadar kalır. İşin sonunda yer alan tampon süre ise, proje buna ihtiyaç duymadan önce tükenir.
4. “Tamamlandı” kavramını tanımlamamak
Tamamlanma kriterleri belirtilmediğinde, “tamamlandı” ifadesi her paydaş için farklı bir anlama gelir:
- Geliştirici, kod yayınlandığında iş tamamlandı der
- Ürün yöneticisi, kalite güvencesi ekibi onay verdiğinde iş tamamlandı sayılır.
- Müşteri, memnun kaldığında iş tamamlandı der.
Her bir çıktı için "tamamlandı"nın ne anlama geldiğini yazın. Hangi kriterleri karşılaması gerektiğini, hangi biçimde olacağını ve kimin onaylayacağını not edin. Belirsiz kriterler, projenin ilerleyen aşamalarında yeniden çalışmaya neden olan başlıca faktördür.
5. Planı e-posta ek dosyası olarak saklamak
Kimsenin bulamadığı bir plan, işlevsel olarak hiç plan olmamakla aynı şeydir.
Takım, güncel sürümün nerede olduğunu sormak zorunda kalırsa, karar verirken bu sürüme başvurmaz, sürümün güncelliğini yitirdiğini fark edemez ve gerçekler değiştiğinde sürümü güncelleyemez.
Planı takımın çalıştığı yerde saklayın, sürüm kontrolü altında tutun ve planın kapsadığı görevlerle bağlantılı hale getirin. Plan, herhangi bir takım üyesinin Çalışma Alanından iki tıklama uzaklıkta olmalıdır.
6. Planı tek seferlik bir çıktı olarak ele almak
En hızlı ipucu: Planın son değiştirilme tarihi, eklediğiniz en son görevden daha eskiyse. İşler ilerlemiş ancak plan değişmemişse, plan bir süre önce projeyi yönetmeyi bırakmış demektir ve kimse bunu fark etmemiştir.
Her dönüm noktasında ve bir değişiklik talebi onaylandığında 15 dakikalık bir plan gözden geçirme süresi ayırın. Amaç, planı sıfırdan yeniden yazmak değildir. Amaç, temel planın hâlâ gerçek durumu yansıtıp yansıtmadığını doğrulamak ya da yansıtmadığı durumları belgelemektir.
ClickUp'ta Proje Planlarını Nasıl Oluşturur ve Yönetiriz?
Proje planlarımızı Google Dokümanlar'da yazıp her şeyin yolunda gitmesini ummuyoruz. Planlarımız, tanımladıkları işlerin hemen yanında, ClickUp içinde yer alır. Böylece plan asla güncelliğini yitirmez.
Kapsam belgeleri ve paydaş haritası (1. ve 2. Adımlar)
ClickUp Docs'ta kapsam beyanı, başarı ölçütleri ve paydaş tablosu bulunur. Belge, görevlerle aynı çalışma alanında yer aldığı için "bu kapsamda mı?" sorusuna cevap vermek kolaydır. Birisi bir değişiklik önerdiğinde, onu üç ay önceki bir Google Dokümanlar belgesine değil, sponsorun onayladığı aynı belgeye yönlendiririz.
WBS için Görevler ve Alt Görevler (3. Adım)
Bağımlılıklar ve kritik yol için Gantt Görünümü (4. Adım)
<14>ClickUp Gantt Görünümü'nde görevler arasına bir çizgi sürükleyerek bağımlılık oluşturun. Kritik yol görünür hale gelir ve bir görev geciktiğinde, sonraki görevler de buna göre kayar. Kimseyi elle yeniden planlama zahmetine sokmadan program gerçekçi kalır. Bu, elektronik tablolarda en çabuk başarısız olan kısımdır ve proje yönetimi araçlarının önemini ortaya koyan unsurdur.
Temel senaryo için gösterge panelleri (7. Adım)
Sponsor planı onayladığında, ClickUp gösterge panelleri tamamlanma oranları, gecikmiş görevler ve iş yüküyle ilgili gerçek zamanlı verileri alır. "Şu anda neredeyiz?" sorusunun cevabı, takımın üzerinde çalıştığı verilerden gelir; paralel bir durum belgesi yerine. Paydaşlar, durum toplantısı talep etmek yerine gösterge paneliyi kontrol eder.
ClickUp'ın uygun olmadığı durumlar
ClickUp, projelerde birden fazla kişi, değişken zaman çizelgeleri ve departmanlar arası iş devri söz konusu olduğunda gerçek değerini ortaya koyar. İşinizin ne kadar bağlantılı olması gerekiyorsa, o kadar fazla değer elde edersiniz.
Şu durumlarda atlayın: Birkaç teslimatı izleyen bir serbest çalışan ya da karmaşık finansal modellere ve pivot tablolara ihtiyaç duyan bir takımsanız. Bu durumda basit bir belge veya elektronik tablo daha uygun olacaktır.
RevPartners planlama süresini nasıl %83 oranında kısalttı?
Uzaktan müşteri hizmetlerini yöneten bir HubSpot çözüm ajansı olan RevPartners, büyümekte olan çoğu hizmet takımının karşılaştığı aynı sorunla karşı karşıya kaldı: Beş müşteriyle işe yarayan proje yönetimi, müşteri sayısı 15'e çıktığında çöktü. Takım, Notion, Trello ve Asana arasında gidip geliyordu; neyin kapsamda olduğu, kimin sorumlu olduğu veya "tamamlandı" ifadesinin ne anlama geldiği konusunda tek bir kaynak yoktu.
Hizmet sunum kılavuzlarını ClickUp şablonları olarak yeniden oluşturdular, böylece her yeni müşteri projesine boş bir belge yerine temel bir planla başlanıyor. Proje planlama süresi proje başına 30 dakikadan 5 dakikaya düştü ( %83 azalma) ve genel hizmet sunumu %64 oranında hızlandı.
RevPartners'ın kurucu ortağı Matt Bolian, bu değişim hakkında şunları söylüyor:
“Proje yönetimi araçlarını çok seviyorum. Bunlar, bir kuruluşun tüm yaşam döngüsü için hayati öneme sahiptir. Deneyimlediğim üç platformdan birini seçmem gerekirse, her seferinde ClickUp’ı seçerdim.”
“Proje yönetimi araçlarını çok seviyorum. Bunlar, bir kuruluşun tüm yaşam döngüsü için hayati öneme sahiptir. Deneyimlediğim üç platformdan birini seçmem gerekirse, her seferinde ClickUp’ı seçerdim.”
Takımınızın Kullanacağı Bir Proje Planı Oluşturun
Bir proje planı, ancak tüm resmi tam olarak yansıtıyorsa işe yarar: her bir çıktı, sorumlu kişi, bağımlılık ve risk tek bir yerde toplanmış olmalıdır. Ayrıca, iş süresince bu plana başvurulmalı ve ilk dönüm noktasına ulaşıldığında unutulmamalıdır.
Yüzlerce projeye bakıldığında, projeleri başarıyla tamamlayan takımlar planlarını sürekli güncellenen belgeler olarak ele alırlar. Her dönüm noktasında planlarını gözden geçirir, koşullar değiştiğinde varsayımlarını günceller ve her kapsam talebini belgelenmiş bir değişiklik sürecinden geçirirler. İşte projeleri yolunda tutan şey budur.
Takımınız artık paylaşılan belgeler ve basit elektronik tablolarla yetinmiyorsa, ClickUp gibi bir aracı denemeye değer. Kapsam, görevler, bağımlılıklar, sorumlular ve gösterge panellerini tek bir yerde tutabilir ve plan geliştikçe görünümler de senkronizasyonunu korur.
Hemen ClickUp'a kaydolun!
Proje Planları Hakkında Sık Sorulan Sorular
Proje planı ile proje yönetimi planı arasındaki fark nedir?
Bir proje planı, tek bir projenin belirli çıktıları, zaman çizelgesi ve kaynaklarına odaklanır. Proje yönetimi planı (PMI terimi) ise daha geniş bir kapsamda olup, projenin nasıl yönetileceğini belirleyen değişiklik yönetimi, risk, iletişim ve tedarik alt planlarını içerir. Resmi PMI ortamları dışındaki çoğu takım için “proje planı” her ikisini de kapsar.
Proje yönetimi yazılımı olmadan bir proje planı oluşturabilir misiniz?
Evet, tek bir sorumlu ve yaklaşık 20'den az görev içeren kısa süreli projeler için. Kapsam beyanı, paydaş liste ve sorumlular ile son teslim tarihlerini içeren basit bir tablo içeren paylaşımlı bir belge, bir proje yönetimi aracı kurmaktan daha hızlıdır. Dönüm noktası genellikle takımlar arası bağımlılıklardır: iki takımdan fazlasının koordinasyonuna ihtiyaç duyulduğunda, elektronik tablo doğruluğunu kaybetmeye başlar.
Proje planında kritik yol nedir?
Kritik yol, programınızdaki birbirine bağımlı görevlerden oluşan en uzun zincirdir ve projenin mümkün olan en erken tamamlanma tarihini belirler. Kritik yoldaki bir görevde meydana gelen herhangi bir gecikme, tüm projeyi geciktirir; kritik olmayan görevlerdeki gecikmeler ise esneklik süresine dahil edilebilir. Gantt grafikleri kritik yolu görselleştirir, böylece proje yöneticileri hangi gecikmelerin gerçekten önemli olduğunu, hangilerinin önemsiz olduğunu bilir.
Proje planını hazırlamaktan kim sorumludur?
Proje planının sorumluluğu proje yöneticisine aittir, ancak planı tek başına yazmamalıdır. Konu uzmanları görev tahminlerini sunar, sponsor kapsamı ve bütçeyi onaylar, katkıda bulunanlar ise bağımlılıkları doğrular. İşi yapan kişilerin görüşleri alınmadan hazırlanan yukarıdan aşağıya planlar, harcanacak çabayı sürekli olarak hafife alır; bu durum, Bent Flyvbjerg’in binlerce proje üzerinde yaptığı araştırmada belgelenmiştir.
Proje planı ile proje takvimi arasındaki fark nedir?
Bir proje planı, neyin, kim tarafından, ne kadara mal olacağı ve risklerin nasıl yönetileceğini tanımlar. Proje zaman çizelgesi ise, görevlerin ne zaman ve hangi sırayla gerçekleştirileceğini gösteren planın bir bileşenidir. Bu ikisini birbirine karıştırmak, zaman çizelgelerinin kapsamı belirlemesine yol açar; oysa olması gereken tam tersidir. Bu, en yaygın planlama hatalarından biridir.
Bir proje planını ne sıklıkla güncellemelisiniz?
Proje planını her önemli dönüm noktasında ve bir değişiklik talebi onaylandığında güncellemelisiniz. Üçüncü ayda birinci haftanın varsayımlarını yansıtan bir plan, yanlış bir güven duygusu yaratır. PMI, her dönüm noktasında resmi plan gözden geçirmeleri yapılmasını ve riskler ortaya çıktığında veya değişiklik kontrol süreci yoluyla kapsam değişiklikleri onaylandığında geçici güncellemeler yapılmasını önerir.