KOBİ'ler için proje yönetimi temelleri

Salı sabahı kurucu, yeni depoya taşınma işini konuşmak için ekibi topladı. Kimse taşınma tarihini tam bilmiyordu, raf siparişinin verilip verilmediğini iki kişi birbirine sordu, muhasebe ise taşınma haftasında faturaların hangi adresten kesileceğini ilk kez duyuyordu. Aslında herkes çalışıyordu; eksik olan emek değil, işin nerede başlayıp nerede bittiğini gösteren tek bir resimdi.

KOBİ'lerde proje yönetimi çoğu zaman kurucunun kafasındaki listedir: kimin ne yapacağı sözlü konuşulur, tarihler tahmin edilir, aksamalar yine kurucunun hatırlamasıyla telafi edilir. Aşağıda ağır metodoloji dayatmadan, üç kişilik bir ekibin bile uygulayabileceği bir düzen kuruyoruz: kapsamı tanımlamak, işi parçalara ayırmak, her parçaya tek sahip vermek, zamanı gerçekçi planlamak, riski önceden yazmak ve projeyi kapatırken öğrendiğinizi kayda geçirmek.

1Kapsam2Plan3Sorumluluk4Yürütme5İzleme6Kapanış ve öğrenme

Proje nedir, rutin işten farkı ne?

Proje; başı ve sonu belli olan, daha önce birebir aynısını yapmadığınız ve bittiğinde ortada benzersiz bir çıktı bırakan iştir. Her ay kesilen faturalar rutindir, yeni ön muhasebe düzenine geçmek projedir. Gelen siparişleri toplamak rutindir, ikinci şubeyi açmak projedir. Bu ayrım teorik bir incelik değil: rutin işi süreçle, projeyi planla yönetirsiniz. Rutin işin doğru aracı yazılı bir akış ve kontrol listesidir; bunu süreç dokümantasyonu ve SOP yazımızda ayrıntılı anlatıyoruz. Projenin doğru aracı ise kapsam, takvim ve sahiplik üçlüsüdür.

İkisini karıştırdığınızda iki tipik hata çıkar. Projeyi rutin gibi yürütüp "nasılsa her hafta biraz ilerler" demek projeyi sonsuza kadar uzatır; rutini proje gibi ele alıp her tekrar eden iş için sıfırdan plan yapmak da ekibi yorar. Doğru refleks basit: iş tekrar ediyorsa şablonlaştırın, bir kez olacaksa planlayın.

KOBİ'de en sık görülen projeler

Küçük işletmelerin proje listesi şaşırtıcı derecede benzerdir: yeni ürünün pazara çıkışı, bir sistem geçişi (tablodan CRM'e, eski muhasebeden yenisine), fuar katılımı, şube ya da depo açılışı, web sitesi yenileme, ISO benzeri bir belgelendirme süreci, bazen de büyük bir müşteriye özel teslim işi. Hepsi aynı iskeletle yürütülebilir. Fuar katılımı, tarihi dışarıdan sabitlenmiş en klasik örnektir; hazırlık takvimini fuar hazırlığı ve stand planlaması yazısında adım adım bulabilirsiniz. Ürün çıkışının satış ayağı için de yeni ürün lansmanı satış planı iyi bir başlangıç noktası.

Kapsamı tek sayfada tanımlayın

Proje planının ilk satırı takvim değil, kapsamdır. İyi bir kapsam üç soruya net cevap verir: Bu iş bittiğinde elimizde tam olarak ne olacak? Neyi bilerek yapmayacağız? Başarıyı nasıl anlayacağız? Üçüncü soru en çok atlanandır. "Web sitesi yenilendi" bir başarı ölçüsü değildir; "yeni sitedeki formu dolduran ziyaretçi CRM'e otomatik düşüyor ve ilk yanıt aynı gün veriliyor" ölçülebilir bir tanımdır.

Kapsamı yazarken projeyi işletmenin daha büyük hedefine bağlamak da işe yarar. Çeyreklik hedeflerle çalışıyorsanız OKR ve hedeflerle yönetim mantığı projeyi soyut bir "iyileştirme" olmaktan çıkarır. Daha büyük bir kurgunun içindeyseniz, örneğin yeni bir iş kolu açıyorsanız, iş planı hazırlama adımları kapsamın çerçevesini kendiliğinden verir.

Kapsam kayması ile başa çıkmak

Kapsam kayması (scope creep) kötü niyetle olmaz; iyi fikirlerle olur. Web sitesi projesinin ortasında "hazır girmişken blog tasarımını da değiştirelim" denir, iş üç hafta uzar. Panzehir yasak koymak değil, fikri kaydetmektir. Tek kural: sonradan eklenen her iş için üç şeyi yazın — kimin isteği, hangi tarihi ötelediği, hangi işin yerine geçtiği. Bu üçlüyü yazmak zorunda kalan kişi isteklerin yarısını kendi eler; kalanı da bilinçli bir karar olur, kaza değil.

Bir projede en pahalı şey gecikme değil, kimin karar vereceğinin belli olmamasıdır; gecikme yalnızca bunun faturasıdır.

İşi parçalara ayırın: iş kırılımı ve gerçekçi görev büyüklüğü

Kapsam netleştiyse sıradaki iş, büyük hedefi yönetilebilir parçalara bölmektir. Buna iş kırılımı denir ve mantığı çok basittir: çıktıyı ana bloklara ayırırsınız, her bloğu da tek kişinin makul sürede bitirebileceği görevlere indirirsiniz. Depo taşıma projesinde ana bloklar "yer ve sözleşme", "raf ve donanım", "stok sayımı ve aktarım", "adres ve belge güncellemeleri", "ekip bilgilendirme" olabilir. Her bloğun altında beş on görev vardır.

Görev büyüklüğü için pratik bir sınır kullanın: bir görev iki günden uzun sürüyorsa muhtemelen görev değil, bir bloktur ve bölünmesi gerekir. Uzun görevler ilerleme göstermez; "üzerinde çalışıyorum" diye üç hafta durur, gecikme ancak son gün fark edilir. Tekrar eden proje türleriniz varsa görev listelerini şablona dönüştürmek en büyük zaman kazancıdır; görev şablonları ve otomatik görev oluşturma yaklaşımıyla ikinci fuarın hazırlığı birincinin yarısı kadar sürer.

Sorumluluk netliği: her işin tek sahibi olsun

Küçük ekiplerde en sık duyulan cümle şudur: "Ben senin yaptığını sanıyordum." Bunun tek çaresi, her görevin karşısında tek bir isim olmasıdır. İki isim, sıfır isim demektir. Sahip, işi mutlaka kendi elleriyle yapan kişi olmak zorunda değildir; işin bittiğinden emin olmakla yükümlü kişidir.

Büyük şirketlerde bu iş için harf tabanlı sorumluluk tabloları kullanılır; aynı fikri jargon olmadan da kurabilirsiniz. Her önemli iş için dört soruyu cevaplayın: Kim yapacak? Kim onaylayacak? Kime danışmak gerekiyor? Kimin sadece haberi olsun? Özellikle "kim onaylayacak" sütunu kritiktir: onay makamı belirsiz olduğunda ekip haftalarca bekler ve buna "iş yoğunluğu" der.

Zaman planı: kilometre taşları, bağımlılıklar ve tampon

Zaman planı yapmak, her göreve bir tarih yazmak değildir. Üç şeyi belirlemektir. Birincisi kilometre taşları: projenin geri dönülemez eşikleri. "Sözleşme imzalandı", "raflar montajlandı", "stok yeni adrese aktarıldı" gibi. Dört altı kilometre taşı, bir KOBİ projesi için yeterlidir ve ilerlemeyi tek bakışta anlatır.

İkincisi bağımlılıklar: hangi iş bitmeden hangisi başlayamaz? Raflar gelmeden yerleşim uygulanamaz, adres değişmeden yeni faturalar kesilemez. Bağımlılıkları yazmayan plan kâğıtta hızlı görünür, sahada tıkanır. Üçüncüsü tampon süre. Her göreve ayrı pay dağıtmak yerine projenin sonuna toplu bir tampon koyun: görev bazında dağıtılan pay her zaman harcanır, sonda duran tampon gerçekten ihtiyaç olunca kullanılır.

Gantt gerçekten gerekli mi?

Renkli çubuklardan oluşan zaman çizelgesi, işler arasında çok sayıda bağımlılık varsa ve gecikme zinciri uzunsa değerlidir: inşaat, taşınma, belgelendirme gibi. On beş görevlik bir web sitesi yenilemesi için kilometre taşı listesi ve bir pano fazlasıyla yeter. Araç karmaşıklığın peşinden gelmeli; karmaşıklığı araç üretmemeli.

Şelale mi çevik mi? KOBİ'de melez yol

Klasik (şelale) yaklaşım işi baştan sona planlar ve sırayla yürütür; çevik yaklaşım kısa döngülerle ilerler, her döngüde çalışan bir parça çıkarır ve yönü düzeltir. KOBİ'de saf haliyle ikisi de nadiren işler; melez kullanım gerçekçidir.

Durum	Uygun yaklaşım	Neden
Tarih dışarıdan sabit (fuar, denetim, sezon)	Şelale	Geri sayım var; sıralama ve bağımlılık kritik
Çıktı belirsiz (yeni hizmet, yeni pazar denemesi)	Çevik	Erken geri bildirim yön düzeltmeyi ucuzlatır
Sistem geçişi (CRM, muhasebe)	Melez	Omurga planlı, kurulum ve eğitim iterasyonlu
Müşteriye özel teslim	Melez	Kilometre taşları sözleşmeli, ara teslimler döngülü

Pratik melez tarif şu: kilometre taşlarını ve bağımlılıkları baştan planlayın, ama işi iki haftalık dilimlerde yürütün ve her dilimin sonunda gerçekten biten şeyi gösterin. Sistem geçişlerinde bunun işleyen bir örneğini CRM uygulama yol haritası ve 30/60/90 gün planı yazımızda bulabilirsiniz.

Kaynak ve kapasite: kişi-gün mantığı

KOBİ projelerinin en sessiz katili kapasite hesabı yapmamaktır. Ekip zaten günlük işini yürütüyor, proje bunun üstüne biniyor. Planı saatle değil kişi-günle düşünün: bu projeye kim, haftada kaç gün ayırabilir? Satış sorumlusu haftada bir gün ayırabiliyorsa, ona verdiğiniz "üç günlük" iş takvimde üç hafta demektir. Bu tek çeviri, tahmin hatalarının büyük bölümünü siler.

Kapasite yetmiyorsa üç seçeneğiniz vardır: kapsamı küçültmek, tarihi ötelemek ya da dışarıdan kaynak almak. Dördüncüsü yoktur; "ekip biraz sıkışır" demek üçünden birini gizlice seçmektir. Dış kaynak kararında tek soru yeter: bu iş bizim ayırt edici yeteneğimiz mi, yoksa bir kez yapılacak teknik bir iş mi? İkincisiyse dışarıdan almak neredeyse her zaman doğrudur. Bütçe tarafında tutar tartışmasından önce kapsamı sabitleyin; kapsamı belirsiz işe alınan teklifler kıyaslanabilir değildir.

Risk listesi ve basit önlem planı

Risk yönetimi kulağa kurumsal geliyor ama KOBİ versiyonu on beş dakikada biter: ekipten "bu proje neden aksar?" diye sorun, gelen cevapları yazın, her birine bir önlem ve bir sahip verin. Beş satırlık bir liste, hiç liste olmamasından kat kat iyidir.

• Tedarik gecikmesi: Kritik malzeme veya donanım zamanında gelmezse tüm zincir kayar; siparişi kilometre taşından önce verin ve alternatif tedarikçiyi şimdiden belirleyin.
• Tek kişiye bağımlılık: Projenin kilit adımını yalnızca bir kişi biliyorsa izin ya da hastalık projeyi durdurur; o adımı yazılı hale getirip ikinci bir kişiye gösterin.
• Onay darboğazı: Kararlar tek kişide birikiyorsa haftalık sabit bir karar penceresi açın ve onay bekleyen maddeleri o pencereye taşıyın.
• Veri kaybı ve geçiş hatası: Sistem geçişlerinde eski verinin yedeği alınmadan aktarım başlatılmasın; küçük bir örnek kümeyle deneme aktarımı yapın.
• Günlük işin projeyi yutması: Sezon yoğunluğu projeyi durduruyorsa haftalık sabit bir proje bloğu ayırın ve o bloğu toplantıya açmayın.

İletişim ritmi: kısa durum, tek pano, karar kaydı

Proje iletişiminde amaç çok konuşmak değil, aynı resme bakmaktır. Üç bileşen yeter. Birincisi haftada bir kez, on beş dakikayı geçmeyen sabit durum buluşması: geçen hafta ne bitti, bu hafta ne bitecek, önümüzde ne engel var. İkincisi tek gerçek kaynak: görevlerin, tarihlerin ve dosyaların bulunduğu tek yer — aynı bilgi iki yerde duruyorsa biri mutlaka yanlıştır. Üçüncüsü karar kaydı: kararın ne olduğu, kim verdiği ve gerekçesi tek satırla yazılır. Üç ay sonra "bunu neden böyle yapmıştık?" sorusunu bu satır cevaplar.

Toplantı sonrası konuşulanların aksiyona dönmesi ayrı bir disiplindir; toplantı notları ve aksiyon takibi yazımızda notu göreve çevirmenin yolunu anlatıyoruz.

Araç seçimi: elektronik tablo yeter mi?

Tek bir aktif projeniz, beşten az kişilik bir ekibiniz ve elli civarı göreviniz varsa iyi düzenlenmiş bir elektronik tablo gerçekten yeterlidir. Görev, sahip, tarih, durum ve not sütunları işi görür. Şu üç işaretten biri belirdiğinde pano tabanlı bir araca geçin: aynı anda birden fazla proje yürütüyorsanız, görevlerin durumunu güncelleyen kişi sayısı arttıysa, ya da kimsenin tablodaki tarihlere bakmadığını fark ettiyseniz. Görsel akış, listeye göre çok daha kolay benimsenir; Kanban panosu mantığı satış fırsatlarında olduğu gibi proje görevlerinde de tıkanan yeri anında gösterir.

Müşteri projelerini satışa bağlayın ve ilerlemeyi dürüst ölçün

Projeleriniz müşteriye teslim edilen işlerse, proje panosunun satıştan kopuk durması pahalıya patlar. Doğru zincir şudur: fırsat kazanılır, kazanılan fırsattan proje açılır, proje kilometre taşlarına göre teslim edilir, teslim bitince fatura kesilir ve tahsilat takibi başlar. Rocketly gibi bir CRM'de fırsat kazanıldığında görevlerin otomatik açılması ve ekibin aynı müşteri kartından hem yazışmayı hem işi görmesi bu zinciri tek yerde tutar.

İlerleme ölçümünde yaygın hata oransal tahmindir. "Neredeyse bitti" cümlesi kimseye bir şey söylemez; bitmiş kilometre taşı sayısı söyler. Durum raporlamasında üç renkli basit bir dil kullanın: yeşil, plana göre gidiyor; sarı, risk var ama içeride çözülüyor; kırmızı, dışarıdan karar veya kaynak gerekiyor. Kritik olan, kırmızının cezalandırılmamasıdır: bedeli varsa herkes son ana kadar sarı der ve proje bir anda çöker.

Kapanış, öğrenilenler ve en sık altı hata

Projeler çoğu KOBİ'de bitmez, sadece susar. Oysa kapanış beş kalemlik bir işlemdir: çıktı teslim edildi mi, açık maddeler kime devredildi, dosyalar ortak yere taşındı mı, fatura ve tahsilat tamam mı, ekip teşekkürü yapıldı mı. Ardından yarım saatlik bir öğrenilenler buluşması gelir: ne iyi gitti, ne kötü gitti, bir dahakine neyi farklı yaparız? Çıkan maddelerin en az birini hemen şablona işleyin; işlenmeyen ders, ders değildir.

• Kapsamın yazılı olmaması: Herkesin kafasındaki proje farklıdır; tek sayfalık kapsam metni bu farkı ilk gün ortaya çıkarır.
• Tarihi baştan taahhüt etmek: İş kırılımı yapılmadan verilen tarih tahmin değil temennidir; önce parçaları çıkarın, tarihi sonra söyleyin.
• Sahipsiz görevler: "Ekip halleder" diye yazılan her satır, kimse halletmediği için gecikir.
• Kapasiteyi yok saymak: Günlük işi hesaba katmayan plan ilk yoğun haftada çöker.
• Sessiz gecikme: Kötü haberin geç gelmesi, kötü haberin kendisinden daha pahalıdır.
• Kapanışsız bitiş: Öğrenilenler yazılmazsa aynı hata bir sonraki projede aynı bedelle tekrarlanır.

Tek sayfalık proje şablonu

İlk projenizde şunu bir sayfaya sığdırın: proje adı ve amacı, elde edilecek çıktı, kapsam dışı maddeler, dört altı kilometre taşı ve tarihleri, ana bloklar altında görevler ve tek isimli sahipler, beş satırlık risk listesi, haftalık durum buluşmasının günü, kararların yazılacağı yer. Bu sayfa en pahalı proje yazılımından daha çok işe yarar, çünkü ekibin tamamı okur.

Düzen kurmaya hazırsanız, projeleri müşteri ve satış tarafıyla aynı yerde tutmak en hızlı kazancı verir: görevler, hatırlatmalar, teklif ve fatura tek akışta olduğunda proje panosu kendiliğinden güncel kalır. Rocketly hesabınızı ücretsiz oluşturarak ilk projenizi bugün kapsam, sahip ve kilometre taşlarıyla birlikte kurabilirsiniz.