PROJE YÖNETİMİ

Savunma sektöründe çalışanların hepsini en çok ilgilendiren, dolayısıyla ortak bilgi alanı olması gereken alan nedir diye sorulsa, kanaatimce “proje yönetimidir” yanıtını vermek doğru olacaktır.

Çünkü içinde olduğunuz iş, her gün yaptıklarınız, çalışmalarınız, katıldığınız toplantılar, hazırladığınız dokümanlar, yazılan evraklar, büyük olasılıkla yönetilen bir projenin parçası olacaktır.

Bu sebeple, bir projenin ne olduğunu ve geneli itibarıyla nasıl yönetildiğini bilmek ortak bilgi açısından önemlidir.

Proje yönetimi, bir firmada tüm alanlarla arayüzü olan, dolayısıyla mühendislikten finansa, kaliteden satın almaya, saha faaliyetlerinden teklif hazırlamaya, sözleşme yönetiminden ürün yönetimine, üretimden malzeme planlamaya kadar büyük resmin içinde olabileceğiniz ve firma işleyişini, süreçleri ve iş akışını kavrayabileceğiniz "generalist" alanların başında gelir. Bu niteliğiyle, bu alanda çalışanlar için, faaliyetlerin çoğuna katılmak, görevi ölçüsünde liderlik etmek ve karar vermek, inisiyatif kullanabilmek ve yönetime değişik seviyelerde katkı sağlayabilmek için önemli fırsatlar sunar.

Bir teknokent kuluçka merkezinde bir girişimci olabilirsiniz, iki üç arkadaş yan yana gelip bir şirket kurup sektöre atılmayı amaçlayabilirsiniz veya bir şirkette kariyer basamaklarını çıkıp proje yönetimiyle direkt veya endirekt birlikte çalışacağınız bir yönetim kademesine gelmiş olabilirsiniz.

(Proje yönetimi alanında kariyer yapıyorsanız, muhtemelen PMI, PRINCE2 gibi sertifikasyonlara tabi olacaksanız; ilgili standart, bilgi kılavuzu ve dokümanlarda bu işin teori ve ayrınrılarını öğreneceksiniz. Aşağıda ele aldığım şekliyle proje yönetimi, basitleştirilmiş ve ortak bilgi seviyesinde giriş seviyesi ve genele uygun hale getirilmiştir.)

Bu sebeple, proje yönetimi nasıl bir şey; çok basitleştirilmiş olarak - kısaca bakalım:

Bir Projenin Ana Safhaları

Öncelikle, proje "pat diye" gelmediği için, teklif hazırlık döneminde alt yüklenici adaylarının belirlenmiş olduğunu, hangi malzemenin kimden satın alınacağının taslak olarak önceden çalışıldığını, imzalanmış sözleşmenin bir bedeli (fiyatı) olduğunu, teklif aşamasında projede ihtiyaç duyulacak insan kaynağı miktarının en azından işçilik saati olarak biliniyor olduğunu varsayabiliriz.

İlave olarak, proje yöneticisinin de ilgili birim tarafından atandığını (görevlendirildiğini / belirlendiğini) varsayalım.

Proje yöneticisinin önünde imzalanmış sözleşmeyi bulduğu gün artık iş fiilen başlamıştır.

Farazi olarak, önünüzde şöyle bir iş olacak:

Savunma101 A.Ş., SSB ile imzaladığı sözleşme kapsamında 4 adet mobil Drone Tespit, Teşhis, Tanımlama, Takip ve Etkisizleştirme Aracı (DT4E) geliştirecektir.

DT4E Sistemi, ticari bir kara aracı üzerinde çalışacak, kritik tesislerin, havaalanı veya limanların terör olayları kapsamında korunması maksadıyla kullanılacak; ihtiyaca göre arazide, deniz seviyesinden 2500 metre rakımda konuşlandırılabilecek, 1000 metre içindeki dronları tespit, teşhis edebilecek, tanımlayabilecek ve RF (soft kill) veya 12,7 mm kalibre, asgari 3 namlulu gatling tipi silahla (hard kill) hedefi etkisiz hale getirecektir.

Sistem, tespit ve teşhis için hem RF almaç ve tanımlama kütüphanesini hem de gündüz ve gece görüş sistemlerini kullanabilecektir.

4 araç da gerektiğinde birbirleriyle haberleşebilecek ve çoklu drone saldırılarına karşı yapay zekâ destekli hedef tahsis ve paylaşımı yapabilecektir.

Sistem üzerinde lazer mesafe ölçer sistemi ve yüksek güçlü aydınlatıcı projektör de yer alacaktır.

Sözleşmeyi incelediniz. Aşağıdaki bölümlerden oluşuyor:

Sözleşme Ana Metni (Contract Terms and Conditions)
İş Tanımı (Statement of Work)

Takvim (Zaman Çizelgesi) (Project Schedule)
İş Dağılım Ağacı (İDA) (Work Breakdown Structure)
Teslimat Kalemleri Listesi (List and Quantity of Deliverables)
Veri Listesi (CDRL – Contract Data Requirements List)

Teknik Spesifikasyonlar (Technical Specifications)
Fiyat Dağılım Ağacı (CBS – Cost Breakdown Structure)

Proje klasik bir sistem geliştirme modeli olan “waterfall” (şelale) yöntemiyle yürütülecek.

Aşağıdaki faaliyetler iş tanımı dokümanında belirtilmiş:

Proje başlangıç toplantısı
Gereksinim Analizi Toplantısı
Proje Durum Değerlendirme Toplantısı (Her 3 ayda bir tekrarlanacak)
Ön Tasarım Toplantısı
Kritik Tasarım Toplantısı
Teste Hazırlık Toplantısı
Testler

Donanım/Yazılım ve Entegrasyon Testleri
Kalifikasyon, Doğrulama ve Geçerleme Testleri
Platform Entegrasyon Testleri
Kabul Testi

Kullanıcı (Operatör) ve Bakım Eğitimleri
Teslimat

Kalifikasyon, Doğrulama ve Geçerleme Testleri 1 adet pilot DT4E sistemi üzerinde yapılacak, bilahare üretilecek 4 adet araç ile kapsamlı platform entegrasyon testleri ve kabul testleri yapılacaktır.

Ana yüklenici olarak uymanız gereken standartlar da ilgili dokümanlarda belirtilmiş durumda. Bir kısmı şunlar: ISO 9001:2015, ISO/IEC 12207, ISO/IEC 15288, ISO 31000, MIL-STD-461, MIL-STD-810, MIL-STD-973.

Proje süresi (garanti hariç) 24 ay.

Proje yöneticisinin önünde temelde 5 safha var:

Proje Başlangıç
Proje Yürütme
Proje Kapanış

Ayrıca planlama ve İzleme&Kontrol safhaları da var... Genele uygun basitleştirilmiş halde, başlatalım, yürütelim ve kapatalım şeklinde inceleyeceğiz, planlama ve izleme / kontrol'a da içinde değineceğiz.

Projenin Başlangıç Safhası

Proje yöneticisi, proje başlatma safhasında, aşağıdaki faaliyetleri gerçekleştirir:

Proje Kodu

Projeye kapsamındaki tüm maliyetlerin, gelirlerin giderlerin kaydının tek bir hesap kodu altında tutulabilmesi için bir mali kod yayınlanacaktır. Bu mali kod olmazsa, örneğin hangi masrafın hangi proje için yapıldığı bilinemeyecek, dolayısıyla bir projenin maliyetleri konsolide edilerek takip edilemeyecek ve projenin mali performansı takip edilemeyecek veya ölçülemeyecektir.

Proje Yöneticisinin Atanması

Proje yöneticisinin kim olduğunun duyurulması gereklidir. Çünkü genellikle bir şirkette yürütülen birçok proje vardır ve çoğu proje yöneticisi birden fazla projeyi yönetiyordur. Yukarıdaki örnekte DT4E olarak adlandırdığımız projeyi kimin yöneteceğini şirket içinde duyurmalıyız ki DT4E projesi ile ilgili olarak tüm şirket birimleri kiminle çalışacağını öğrensinler. Bu bilgilendirmeyi “ben proje yöneticisi oldum” diye PY yapmayacak tabii ki, şirkette proje yöneticisi görevlendirme yetkisi kimdeyse o kişi tarafından bu duyuru yapılmalıdır.

Proje Beratının Yayınlanması

Adına proje beratı denen bir belge yayınlanacaktır. Genel Müdür imzası ile yayınlanacak bu berat, aslında kurum içinde, "ben bu işi şu kişiye yönetmesi için verdim ama bu beratta belirlenmiş çerçeve içinde yönetebilir" diyen önemli bir belgedir.

Bir proje beratı temel olarak aşağıdaki bilgileri içermelidir:

Proje Adı, kodu, başlangıç ve bitiş tarihi,
Gizlilik derecesi
Kısa tanımı
Kapsamı
Safhaları ve temel faaliyetleri/takvimi
Teslimat tanım, adet ve tarihleri
İş Dağılım Ağacı
Kısıtları
Tahsis edilmiş olan bütçe, ekip (insan kaynağı) ve yatırım kalemleri/malzemeleri
Varsayımları
Riskler ve risk yönetim adımları
Projenin performans hedefleri ve TPG (Temel Performans Göstergeleri) (KPI - Key Performance Indicator) (brüt kâr tutarı, patent, yeni ürün, vb. dahil)

Proje beratı önemlidir; PY ve birkaç üst yönetici arasında gidip gelen ve son olarak da üst yönetime imzalanıp dosyalanan, bir daha da yüzüne bakılmayan bir doküman olmamalıdır. Adı üstünde “berat”. Yani proje yöneticisinin, genel müdürle projeye yönelik firma içindeki akdidir. Sonuçta masanın üzerine berat konur. Firma proje yöneticisini nasıl yetkilendirmiş, proje yöneticisi de ne yapmış berata göre bakılır. Örneğin, projenin başarıya ulaşıp ulaşmadığının bir ölçüsü de beratta genel müdürün aslında bir talimat şeklinde proje yöneticisine verdiği proje performans hedeflerinin tutturulup tutturulmadığıdır. Ayrıca berat sadece proje yöneticisini de ilgilendirmez. Proje madem bir ekip işidir ve herkesin aynı hedefe doğru çalışması beklenir, proje ekibinde yer alan ve beratta belirlenmiş ilgili konularla örtüşen alanlarda çalışan herkesin genel müdürün talimatını, verdiği yetkinin sınırlarını, koyduğu hedefleri bilmesi gerekir.

Proje Başlangıç Toplantısının Yapılması

Proje yöneticisinin bir sonraki hedefi, proje başlangıç toplantısı (Project kick-off meeting) hazırlıklarını yaparak projeyi başlatmaktır.

Proje başlangıç toplantısı, proje ekibindeki personelin ve projenin iletişim içinde olacağı ekip-dışı birimlerin de katılımıyla yapılan ayrıntılı bir bilgilendirme ve koordinasyon toplantısıdır.

Proje başlangıç toplantısının yapılma amacı tüm proje iç paydaşlarını proje hakkında bilgilendirmek olduğu için, temelde aşağıdaki içerik/gündemle icra edilmelidir:

1) Projenin künyesi (PY) tanıtılmalıdır

Projenin Adı Kodu
Gizlilik Derecesi
Sözleşme Makamı
Sözleşme Süresi
Sözleşme Bedeli
Garanti Süresi
İdame Desteği Süresi

(Varsa, alt sözleşmeye ait yukarıdaki bilgiler dahil)

2) Proje ekibi tanıtılmalıdır.

Projede direkt işçiliği planlanan tüm personelin listesi ve yeni istihdam ihtiyaçları dahil görevlendirmeler, görevlendirilen personelin/takımların sorumlulukları
Varsa, ana yükleniciler, alt yüklenici(ler), alt yüklenici organizasyonu ve alt yüklenici sorumluluk matrisi

3) Teklif, Sözleşme ve ekleri, varsa sözleşmeye ait/ilgili ek protokol, Bilgi Değişimi ve Gizlilik Sözleşmesi (NDA), Teknik Bilgi Paylaşımı Sözleşmesi (TAA) vb. dokümanlar kısaca tanıtılmalıdır.

Sözleşme Şart ve Hükümleri (Fatura ve Ödeme planı dahil)
İş Tanımı
Projenin Fazları/Safhaları
İş Paketleri
Detaylı Proje Takvimi
Teslimat Kalemleri (Tarih ve yer bilgisini içerecek şekilde)
Dokümantasyon (sorumluları belirlenmiş olarak)
Teknik Özellikler (Burada teknik çözüm de tanıtılmalıdır)
Şartname ve İş Tanımının teknik açıdan değerlendirilmesi
Şartnameden gelen Teknik İsterler, üst seviye sistem gereksinimleri, tanımlı ise donanım ve yazılım gereksinimleri
Çevresel gereksinimler, Çevresel testlerde kullanılması öngörülen birimlerin adet ve kullanım zamanları
Mühendislik testleri (entegrasyon, kalifikasyon, doğrulama, geçerleme, vb.)
Kabul, Test ve Muayene

4) Proje Bütçesi tanıtılmalıdır.

İşçilik saatleri ve ay bazında dağılımı
Malzeme, Yatırım ve ay bazında dağılımı
Seyahat ve ay bazında dağılımı
Garanti dönemi bütçesi
Fiyat tablosu, ödeme planı
Nakit akış

5) Malzemeler tanıtılmalıdır. (Satın alım, malzeme planlama, üretim vb)

Taslak fiyatlandırılmış malzeme listesi (Malzeme tanımı, Üretici firma, Parça no, Adet)
Üretim kaybı olarak öngörülen adetler
Prototip/pilot üretim için gerekli miktar
Birim ve toplam fiyatı
Tedarik süresi (lead time)
En az satın alma miktarı (MOQ)
Stoktan kullanılması planlanan malzemeler ve bedelleri
Fire miktarları

6) Riskler tanıtılmalıdır.

7) Proje gizlilik ve sanayii güvenliği ile ilgili hususlar tanıtılmalıdır

8) Proje performans hedef ve göstergeleri tanıtılmalıdır (proje başarı kriterleri)

9) Soru ve cevaplar

Proje Yönetim Planının Yayınlanması

Proje başlangıç toplantısında görüşülen, tartışılan, koordine edilen ve kararlaştırılan esaslar kapsamında Proje Yöneticisi (PY) tarafından Proje Yönetim Planı hazırlanır. Sözleşmede mevcut proje takviminin daha ayrıntılı ve firma içi kullanıma yönelik bir çalışma versiyonu, proje yönetim planının ekidir.

Projelerin başlangıç safhasında harcanan her birim emek, ileri safhalarda birkaç birim katma değer yaratacak şekilde geri döner. Bizler, kültür olarak planlamaya çok ağırlık veren bir iş kültüründe yaşamıyoruz. Bu sebeple yöneticiler, planlamaya harcanan vaktin, ciddi olumlu sonuçları olacağını bilerek, ekibi planlama safhasında planlama yapmaya ve işleri akışına bırakıp günlük reflekslerle yönetmemeye motive ve ikna etmelidir. Bu çerçevede, her bir birimin kendi planını oluşturarak yayınlaması idealde beklenir. Kalite Yönetim Planı, Konfigürasyon Yönetim Planı, Mühendislik Yönetim Planı, Üretim Planı, Risk Yönetim Planı ve benzeri planlar, “daha bu aşamada ne gerek var", "zaten planlayacak bir şey yok", "çok erken", "gereksiz" demeden taslak olarak da olsa, kısa da olsa hazırlanarak yayınlanmalı ve proje süresince güncellenerek ayrıntılandırılmalıdır. Planlar, gerek gözden geçirme ve koordine süreçleri ile, farklı bakış açılarının aynı hedef etrafında kenetlenmesi ve koordinasyonun arttırılarak senkronizasyonun sağlanması için çok iyi birer araçtırlar.

Şimdi aşağıdaki şemaya bakalım:

Şu ana kadar ne yaptık? Sözleşmeyi aldık, sözleşmedeki girdileri esas alarak bir projenin başlangıç süreçlerini gözden geçirdik. Sırada ikinci safha, yani proje yürütme safhası var.

Projenin Yürütme Safhası

Proje her şeyden önce, belirlenen süre içinde (zaman), proje çıktıları nitelik açısından uygun kalitede olacak şekilde (kalite) ve proje için tahsis edilmiş bütçe içinde (bütçe) yönetilecek. Bir miktar toleranslar olabilir. Bu toleranslar sözleşmede tanımlanmış veya sözleşmeden sizin geliştirdiğiniz toleranslardır. Bu arada, riski yöneteceksiniz, kapsamı yöneteceksiniz, faydayı yöneteceksiniz ve tabii ki plana göre yöneteceksiniz.

Planla, icra et, kontrol et, güncelle, icra etmeye devam et şeklinde sürüp giden bir döngü. Çünkü planlar kanun değildir, statik değildir, güncellenir, süreç içinde yaşar ve gelişir. Elinizde değişmez kabul edilen tek doküman sözleşmedir (ki bir sözleşme bile, bazen firma için menfi sonuçları olsa da, uygun usullerle değiştirilebilir.)

"Biz böyle planlamıştık, o yüzden böyle oldu" diyerek hiçbir plan, sözleşmeden sapmanın bir açıklaması olamaz. Asıl olan sözleşmeden sapmamak ve planı sözleşmedeki hedeflere ulaşacak nitelikte, zamanında güncelleyerek icra edebilmektir.

Plan önemli bir araçtır ancak amaç değildir.

Proje yönetimi de dahil, tüm ana disiplinler planlarına göre projeye katkı sunarlar: Mühendislik kendi planını yaptı, test bölümü kendi planını yaptı, kalite, konfigürasyon, malzeme planlama, üretim ve benzeri tüm planlar aynı hedefe ulaşmak üzere, aralarında etkileşimli ve eş zamanlı, ahenk içinde icra ediliyor...

Planlar, her konuyu düşünüp, neyin ne zaman nasıl nerede neden ve kimler tarafından yapılacağını diğer planlarla birlikte uyum içinde ele alarak, önünüzdeki dönemi öngörmenizi sağlayan harika bir araçtır. Eğer ilk gününden bir projeye bakarak adım adım nelerin olabileceğini hayal edebiliyorsanız, kritik aşamaları derinliğiyle önden tasarlayabiliyorsanız, muhtemelen birkaç büyük projede aktif görev almışsınızdır ve büyük bir ihtimalle ve iyimser bir tahminle 10 yılı devirmişsinizdir. İyi bir plan yapmaya başlayabilirsiniz. Riskleri de öngörme beceriniz artmıştır. Yaşadıklarınızdan öğrendiğiniz dersler makul bir risk algısı sağlayacak noktaya ulaşmıştır. Eğer bu noktadaysanız birkaç soru ve girdi ile sizlerden tecrübesiz olanların planlarına yön verebilirsiniz.

Burada bahsettiğim, müşteriye sunmakla yükümlü olduğunuz, dili, kapsamı ve formatı dahil önceden belli olan planlar değil. Plan derken, bilfiil işi nasıl yapacağız diye düşünerek geliştireceğiniz iç planlardan bahsediyorum. Formattan bağımsız, mümkün olduğunca daha uzağa bakabilen, düşünmeye ve kurgulamaya vakit ayırmanıza araç olan, 5N1K sorularını her konu için göz önünde bulundurduğunuz bir plandan bahsediyorum. Adına plan demeden, bunlar haftalık proje yönetimi toplantılarının gündemleri olarak bile ele alınabilir. Perspektif açısından akılda bulundurulması gereken, adına milestone denilen olaylar zincirinde, olaylardan ziyade, olayların birbiriyle ilişkisine ve etkileşimine odaklanmanızdır. Bu böyle olursa ne olur, bu öyle olmazsa nasıl olur gibi soruları devamlı sorarak ve sık sık daha ileriye bakabilme motivasyonuyla bitmek bilmeyen bir düşünme, kurgulama, tasarlama eylemi içinde kalabilmekten bahsediyorum. Buna bir sonraki, bir sonraki, bir sonraki oyunu kurmak da diyebilirsiniz.

Proje yöneticisi, farklı gelişmelere, olumsuzluklara yönelik mümkün olduğunca farklı senaryoyu düşünüp tedbirler almalıdır. Hani B planı denilen, C planı denilen planlarınız olmalıdır. Büyük projelerde, çoğu zaman bir projeyi bitirene kadar alfabedeki harflerin yetmeyeceği kadar fazla olumsuzluk üzerinde senaryo çalışmış olmanız lazım. Bir süre sonra bu senaryolar içsel olarak kendiliğinden gelişecek, geçmişte tecrübe ettikleriniz kümülatif olarak artarak önünüzü aydınlatacaktır. Ancak sıkılmadan bu böyle olursa nasıl, bu böyle olmazsa nasıl sorularıyla çok yönlü bakmayı alışkanlık edinmelisiniz.

Şimdi konumuza dönelim ve gelelim işin teorik kısmına…

Bir projede toplam eforların yani harcanacak saatlerin hangi aşamada ne kadar harcandığına yönelik şekil yukarıdadır. Proje yönetimi teorisinde, farklı proje yönetim ekolleri farklı isimler verebilir, farklı sınıflandırmalar yapabilir, ancak işin tamamı yukarıdaki şekilde olduğu gibidir. Biraz mühendisçe açıklayalım: Yukarıdaki eğrilerin integrallerini alıp alanlarını hesaplarsan, proje yönetimi teorisine göre, tipik bir projenin hangi safhasının ne kadar efora karşılık geldiğini buluruz. Yürütme safhasının alanı en büyük olan, bunda bir gariplik yok. Dikkat etmeniz gereken yer, benim de ısrarla üstüne bastığım nokta, planlama safhasının alanı. Bu alana özellikle dikkat çekiyorum çünkü planlama aşamasının biraz kestirmeden alındığını ve gerekli zamanın ayrılmadığını -kıssadan hisse- düşünüyorum.

Hazır bu aşamalardan bahsetmişken, temelde hangi aşamada hangi sorulara yanıt aranıyor, ona da bakalım:

Bu sorular, göz önünde bulundurulması gereken sorular ve sadece proje yöneticisinin değil, proje ekibinde yer alan herkesin sürekli yanıt arayacağı sorulardır. Sorular çok güçlüdür ve önemlidir. Yeri geldiğinde sorulan kısa bir soru, riskin ortaya çıkmasının engellenmesine, işlerin akışının olumlu yönde değiştirilmesine sebep olabilir. Amaç çok soru sormak değildir. Doğru soruyu doğru zamanda sormaktır ve çok önemli bir yönetim yetkinliğine işaret eder.

Tekrar konumuza dönelim:

Proje yürütme safhasında, artık sözleşmede taahhüt etmiş olduğunuz faaliyetler birer birer tamamlanacak. Bu arada, sistem mühendisliği ile proje yönetiminin karşılıklı etkileşim ve uyumlu birlikteliğini V diyagramı ile birlikte göstermek istiyorum. Sistem Mühendisliği, proje yönetimi ile uyum açısından çok kritiktir ve sistem mühendisliği tüm savunma sanayii çalışanları için olmasa da, tüm mühendislik birimleri ve proje yönetimi için kanaatimce ortak bilgi alanı olmalıdır.

Proje yürütme aşamasında projenin sözleşme ile belirlenmiş adımlarını icra edeceğiz. Gelin, klasik bir projenin adımlarına bakalım ve proje yürütme safhasında yürütülecek faaliyetleri görelim:

Savunma sanayii projelerinin çok büyük bir kısmı, geliştirme projeleridir. Yani rafta hazır bir ürünün satışından ziyade, müşterinin özgün ihtiyaçlarını karşılamak üzere sıfırdan geliştirilen veya rafta hazır olsa da ciddi modifikasyonlar içerdiği için bazen bir geliştirme projesine dönüşen projelerdir.

Geliştirme projeleri, AR-GE niteliğinden kaynaklanan sebeplerle, mühendislik yoğun, karmaşık ve zorluklar içeren proje tipleridir. Savunma sanayii sektöründe faaliyet gösteren firma ve çalışanlarının aşina olduğu bu tür projelerdeki temel faaliyetlere değinmeden geçemeyiz, nitekim “Proje Yürütme” safhası temelde bu faaliyetlerin icrası ile geçecektir.

Sonuçta ister proje yöneticisi olsun ister projenin farklı safhalarında proje ekibine destek veren bir disiplin, bir savunma sanayii firmasındaki bitmek bilmeyen olaylar döngüsünün şablonu genellikle aşağıdaki faaliyetleri içerir.

1. Sözleşme Yürürlüğü (Contract Effectivity) >> 2. Sistem Gereksinim Analizi (SRA- System Requirement Analysis) >> 3. Sistem Gereksinim Gözden Geçirme Toplantısı (SRR- System Requiment Review) >> 4. Ön Tasarım (Preliminary Design) >> 5. Ön Tasarım Gözden Geçirme Toplantısı (PDR- Preliminary Design Review) veya İlk Tasarım Gözden Geçirme Toplantısı (IDR - Initial Design Review) >> 6. Kritik Tasarım (Critical Design) veya Ayrıntılı Tasarım (Detailed Design) veya Nihai Tasarım Gözden Geçirme Toplantısı (FDR – Final Design Review) >> 7. Kritik Tasarım Gözden Geçirme Toplantısı (CDR- Critical Design Review) >> 8. Geliştirme (Development) >> 9. Test Hazırlık Gözden Geçirme Toplantısı (TRR- Test Readiness Review) >> 10. Kalifikasyon ve Doğrulama (Qualification and Verification) >> 11. Tasarım Doğrulama Testi (DVT- Design Verification Test) >> 12. Geçerleme (Validation) >> 13. Tasarım Geçerleme Testi (DVT- Design Validation Test) veya Fabrika Kabul Testi (FAT- Fabrika Kabul Testi) veya Kabul Testi (Acceptance Test) >> 14. Platform Entegrasyon (Platform Integration) >> 15. Platform Kabul Testi (PAT- Platform Acceptance Test) veya Araç Kabul Testi (VAT- Vehicle Acceptance Test) veya Liman Kabul Testi (HAT- Harbour Acceptance Test) veya Deniz Kabul Testi (SAT- Sea Acceptance Test) veya Uçuş Kabul Testi (Flight Acceptance Test).

Bu aktiviteler 15 adetle sınırlı değildir. Örneğin aşağıdaki faaliyetler ve daha fazlası da mevcuttur:

Üretime Hazırlık Toplantısı (PRR- Production Readiness Review),
İşlevsel Konfigürasyon Kontrolü (FCA – Functional Confüguration Audit)
Fiziksel Konfigürasyon Kontrolü (PCA – Physical Configuration Audit)
Simülatör Performans Testi (SPT – Simulator Performance Test)

Ve diğerleri…

Bu faaliyetler için, “sistem, donanım ve yazılım yaşam döngüsü hakkında bilgi almak amacıyla aşağıdaki referanslara göz atınız” demek isterdim ancak şöylesi daha doğru olur: “mutlaka göz atmalısınız”:

MIL-STD-1521
IEEE 15288
IEEE 12207

Proje Takvimi

Takvimde, aktiviteler, kilometre taşları (milestone), faaliyetler arasındaki ilişkiler, aktivite süreleri, aktiviteler için tahsis edilmiş kaynaklar vb. gösterilir. Elinizdeki sözleşmede mevcut takvim 50 satırlık bir takvim olabilir ancak siz, her bir faaliyete yönelik ayrıntılı planlamalarla, sözleşme ekinde yer alan takvimi genişlettiniz ve muhtemelen elinizde artık birkaç yüz satırlık bir takvim var. (Bir uçak projesindeki takvim onbinlerce satır olabilir.) Eğer işi 50-100 satırla yürütecekseniz excel yeterli olabilir ama daha karmaşık ve uzun projeler için sadece proje takvimlerinin geliştirilmesi için özel yazılım araçları geliştirilmiştir. Büyük bir olasılıkla, Microsoft Project, Oracle Primavera, SAP Multiresource Scheduling gibi araçlardan birini kullanıyor olacaksınız. Pek çok başka araç da mevcut.

Proje Bütçesi

Şimdi gelin pandoranın kutusunu bir kere daha açalım.

Proje bütçesi nedir?

Farklı şirketlerde veya farklı üst yönetimlerce, proje bütçesinin ele alınışına yönelik değişik bakış açıları ve uygulamalar mevcuttur. Şirketin proje maliyetlerini muhasebeleştirme usullerinden, kullandığı IT alt yapısına kadar pek çok sebeple, bazen de üst yönetimin görmeye odaklandığı finansal parametreler sebebiyle değişiklik arz eden bütçe kavramı, temelde her şirkette aynı amaca hizmet eder ancak bütçe alt kalemleri ve söz konusu alt kalemlerin konsolidasyonu açısından farklılıklar içerebilir.

Benim burada açıklayacağım, mevcut örneklerden sadece biri. Ne olduğuna dair farkındalık sahibi olmak giriş seviyesinde yeterlidir:

Proje bütçesi, sözleşmeyi aldıktan sonra ekiplerin oturup "biz bu işi kaça yaparız" diye ayrıntılı olarak hazırladıkları bir bütçe midir? Yoksa zaten çoktan elde hazır, mevcut olan bir bütçe midir? Proje bütçesi yıllık mıdır? Yoksa ilk gününde sonuna kadar tüm maliyetleri öngören bir doküman mıdır?

Kısa cevaplarla;

Teklif tutarı sözleşme tutarına eşittir varsayımıyla, Proje bütçesi teklif aşamasında oluşmuştur, ayrıca hazırlanmaz. Teklif tutarından kâr ve risk çıkartılıp proje bütçesi bulunur. Proje yöneticisi, söz konusu bütçe içinde işi bitirmekle yükümlüdür. Risk tutarı bazı durumlarda proje yönetimine tahsis edilebilir (risk bütçesi olarak) ancak genellikle üst yönetim bu tutarı kendi inisiyatifinde tutar. Ayrıca, bazı durumlarda genel dağıtım giderleri de teklif tutarından çıkartılıp proje bütçesi bulunabilir. Ancak genellikle dağıtım giderleri de bütçeye dahil edilir.

Özetle,

Sözleşme Bedeli – Kâr – Risk Tutarı = Proje Bütçesi'dir.

Bu neden böyle olmalıdır?

Çünkü, sözleşme imzalandıktan sonra ekibi toplayıp proje bütçesinin hazırlanmasını isterseniz, “o maliyet kalemini teklif zamanında öngörmemişiz", "bunu da eklesek iyi olacak" diye giderler şişirilir ve maliyet arttırılır. Bu da kârın azalması demektir.

Halbuki biz zaten teklif aşamasında maliyetleri doğru öngörmüş olmalıydık. O halde sözleşme imzalandığında, kâr tutarı artık donmuştur. Kimse değiştiremez olmalıdır. Nitekim şirketin varoluşunun amacının temellerinden birinin kâr etmek olduğu unutulmamalıdır. Çünkü bu kâr ile yeni yatırımlar yapılabilecek, öz kaynak AR-GE projeleri finanse edilebilecek, şirketin muhtelif faaliyetlerinden dolayı ortaya çıkabilecek zararlar kapatılabilecektir.

Unutmayalım ki teklifte, dolayısıyla sözleşmede ön görülmüş olan kâr tutarı, topyekûn firma yönetiminin hissedarlara olan borcudur. Her şey, müşteriye ve şirket hissedarlarına karşı etik içinde ve iyi ahlaklı çalışmaya devam etmek kaydıyla, şirketi kâra geçirmek üzerine kurgulanmalıdır.

Ayrıca, proje bütçesi yıllık hazırlanmaz. Proje bütçesi, projenin topyekûn, baştan sona bütçesidir. Proje ekibi her yıl bütçe yapılırken o yıl ne kadar harcayacağını hesaplar ve günceller ancak sonuçta kendisine tahsis edilmiş toplam bütçe içinde kalmalıdır. Her sapmanın izahati alınmalıdır. Çok önemlidir.

Şimdi bir projenin tüm aşamaları ile iç içe geçmiş olan ve proje yürütme safhasında da sürekli icra etmemiz gereken proje izleme ve kontrol aşamasından da bahsedelim…

Projeyi nasıl izleriz?

Düzenli toplantılarla (proje yönetimi haftalık toplantıları, Konfigürasyon Kontrol Kurulu Toplantıları, Malzeme Kontrol ve Gözden Geçirme Toplantıları, vb.), raporlarla, denetimlerle, ara performans ölçümleriyle, müşteri memnuniyet anketleriyle, alt yüklenici anketleriyle... Bunların hepsi bize projenin izlenmesi için olanak sağlayan resmi faaliyetlerdir. Projelerin izlenmesi için en etkili, pratik ve iyi referans oluşturan noktalardan biri de aylık, çeyreklik, yarı yıl/yıllık bütçe gerçekleşmeleri üzerinden proje mali performansının izlenmesidir. Bu sebeple şirket muhasebe sisteminin proje mali performansının izlenmesine uygun yapılandırılması gerekir.

Bu faaliyetler sırasında uzman görüşü sık sık başvurulan bir değerlendirme usulüdür. Analitik teknikler nadiren kullanılır. Analitik teknikler veriye dayanırlar. Veri doğru ise sonuç da doğrudur. Objektif ve sübjektif unsurların birbirine karıştığı projelerde, doğru veri toplamak ancak iyi bir IT alt yapısı, uygun yazılım araçları ve hepsinden de önemlisi ancak uzun yıllarda elde edilebilecek bir firma kültürü gerektirdiğinden, kurumsal nitelik kazanmış firmaların dışında analitik tekniklerle proje değerlendirmesi yapmak güçtür.

Projenin Kapanış Safhası

Proje kapanışında projeler herkesin derin bir “oh” çekmesiyle kapanmaz. Projelerin kapanışı da tanımlı ve önemli bir safhadır; geleceğinize ve kurum kültürünüzün oluşumuna katkı sağlar.

Proje neden kendi halinde bitmez; tanımlı bir süreç, bir aşama olarak nasıl kapatılır?

Savunma sanayiinde platform ve sistem projeleri uzun soluklu projelerdir. Atak Projesi, 2020 yılı itibarıyla halen teslimatları devam eden bir proje. Projenin savunma sanayii firmalarıyla ilk görüşüldüğü günlerin üzerinden 20 yıldan fazla süre geçti. Barış Kartalı Projesi, ilk ihale tarihinden yaklaşık 16-17 yıl sonra tamamlandı. Sistem projeleri (radar, sonar, eh sistemi vb) o kadar uzun sürmez; ama onlar da ihaleye çıkış ile projenin bitirilmesi arasında 4-6 yıllık bir zaman diliminde gerçekleşirler.

Platform projelerini hesaba katmazsak, oldukça iyimser ve iddialı bir hesapla, TÇD ile projenin garanti süresi hariç teslimatlarının tamamlanması arasındaki sürenin tüm projeler için ortalaması 4-5 yıl olarak düşünülebilir.

Ardında pek çok mühendisin çalıştığı bu projelerde entelektüel sermaye birikimi bir sonraki proje için büyük önem arz eder. Dolayısıyla, her bir projede elde edilen tecrübenin kayıt altına alınması ve geleceğe ışık tutacak şekilde kurumsal ortak belleğe alınması şirketler için hayati öneme sahiptir.

Örneğin, bir proje yöneticisinin müşteri veya alt yüklenicilerle yapılan bir toplantıda "tamam yaparız" demek zorunda kaldığı basit bir işlem maddesinin maddi karşılığı 5-10 Bin dolar, platform projelerinde 25-50 bin dolar olabilir. Böyle birkaç işlem maddesiyle, 8-10 yıllık süre zarfında sadece mühendislik, proje yönetimi veya diğer branşların şirket bilançolarına örtülü bir şekilde enjekte ettiği zararlar rahatlıkla milyon dolar mertebesine ulaşabilir. Buradan alınan derslerin tekrarlanmaması için entelektüel sermayenin sadece proje ekibinde kalmaması, diğer şirket için birimlerle de paylaşılabilmesi için projelerin kapanışına önem verilmelidir.

Normal şartlar altında herkesin hatası, ihmali, unuttuğu bir şeyler, yeni öğrendiği şeyler olması beklenir. Öğrenilen dersler üzerinden entelektüel sermayenin oluşturulmasına izin veren bir ortamın tesisinde en büyük katkı üst yönetime düşer. Üst yönetim, hatanın kaçınılmaz olduğunu, insan olmanın doğal bir sonucu olduğunu bilerek açık ve samimi bir kurum kültürü inşa ediyorsa, güven esasıyla bazı dersler kayıt altına alınabilir.

Peki, bir proje kapanış toplantısında ve sonrasında yayınlanarak konfigürasyon sisteminde kayıt altına alınması gereken kapanış raporunda neler olmalı?

Bunu bir şablonla gösterelim…

PROJE KAPANIŞ RAPORU

Doküman No: #

gg/aa/yyyy

KAPSAM: Proje kapanış raporunun hangi proje kapsamında hazırlanmış olduğu kısaca anlatılır. Müşteri ve son kullanıcı bilgisi, teslimat kalemleri, proje süresince yapılan çalışmalar ile (tasarım, üretim, geliştirme vb) eğer var ise ilave siparişler ve diğer sözleşme hususları (tamamlanamayan dokümanlar/hizmetler gibi ve diğer yakın dönem faaliyetleri gibi) detaylandırılmadan içeriğe dahil edilir.

SÖZLEŞME / SİPARİŞ BİLGİSİ: Sözleşmeye/Sipariş Emri’ne dair bilgiler girilir. Proje süresince sözleşme değişikliği/protokol imzalanması gerçekleşmiş ise bu hususlar da ayrıca eklenmelidir.

Sözleşme (Sipariş) Tarihi : ....

Sözleşme (Sipariş) No : ....

Sözleşme (Sipariş) Bedeli : ....

Yürürlük Tarihi : ....

Tamamlanma Tarihi : ....

Garanti Süresi : ....

PROJE KODU: Proje kodu yazılır.

MÜŞTERİ ADI VE YAZIŞMA ADRESİ: Müşterinin adı, adresi ve iletişim bilgileri buraya yazılır.

TESLİMAT KALEMLERİ: Gerçekleşen malzeme/birim teslimat durumu listelenir. Gecikme yaşanmış ise nedenleri belirtilmelidir. Yaşanan gecikmelerin sebepleri etkileri ile verilmelidir.

Tablo olarak - sütunlarda: Teslimat Kalemi / Teslimat Miktarı / Sözleşme Teslimat Tarihi / Gerçekleşen Teslimat Tarihi / Açıklamalar

DOKÜMAN/VERİ LİSTESİ: Gerçekleşen doküman teslimat durumu listelenir. Gecikme yaşanmış ise nedenleri belirtilmelidir. Yaşanan gecikmelerin sebepleri etkileri ile verilmelidir.

Tablo olarak - sütunlarda: Doküman Adı / Sözleşme Teslimat Tarihi / Gerçekleşen Teslimat Tarihi / Açıklamalar

ÖDEMELER: Proje kapsamında alınmış ödemeler listelenir. Gecikme yaşanmış ise nedenleri belirtilmelidir. Yaşanan gecikmelerin sebepleri etkileri ile verilmelidir.

Tablo olarak - sütunlarda: Ödeme Adı / Ödeme Tutarı / Sözleşme Ödeme / Tarihi / Gerçekleşen Ödeme Tarihi / Açıklamalar

BÜTÇE: Proje Planı ekinde yayınlanmış ilk bütçe ile proje kapanışında gerçekleşenler üzerinde tüm bütçe kalemleri karşılaştırılır. Karşılaştırma tüm kalemler için maliyet üzerinden yapılırken, işçilik gerçekleşmeleri, ilave olarak saat olarak da karşılaştırılır.

KAYITLAR: Savunma sanayii projelerinde kayıtların ne kadar süre ile saklanacağı genellikle sözleşmelerde belirtilir. Sözleşmede belirtilmediyse, 5 yıl standart süre olarak kabul edilebilir. Proje kapanışı aşamasında, her bir kaydın nerede ve nasıl, hangi birim sorumluluğunda tutulacağı hayıt altına alınmalıdır. Kayıtlar, projede üretilmiş basılı veya elektronik her şeydir. Kayıtlara örnek olarak aşağıdakiler listelenebilir. Bu liste genişletilebilir:

Tüm gelen ve giden evrak
Tüm proje dokümantasyonu
Tüm test ve kabul prosedür, sonuç raporu ve ilgili belgeler
Tüm toplantı tutanakları
Tüm sunumlar ve bilgi notları
Tüm sözleşme, alt sözleşme, Bilgi Değişimi ve Gizlilik anlaşmaları, muhtıralar
Tüm fatura, sevk irsaliyesi, satın alma kayıtları, sipariş emirleri ve giriş kalite kontrol kayıtları

PROBLEMLER VE ÖĞRENİLMİŞ DERSLER: Proje süresince karşılaşılan problemler; sebepleri, oluşturulan çözümleri ve etkileri ile burada anlatılır. Öğrenilen dersler bu raporun en önemli kısmıdır.

Herkesten görüş veya girdi alarak ve sonra bunları birleştirerek yayınlandığında, bazı çalışanların görüşleri arada kaybolabileceği için, ekipteki tüm kilit görevler için ayrı ayrı başlıklar altında problemler ve öğrenilmiş derslere yer verilmelidir. Aşağıdaki personel, öğrenilmiş dersleri birbirinden bağımsız; ayrı ayrı hazırlayarak rapora dahil etmelidir:

Proje Yöneticisi
Proje Sözleşme Yöneticisi/Sorumlusu
Proje Kalite Yöneticisi/Sorumlusu
Proje Konfigürasyon Yöneticisi/Sorumlusu
Proje Mühendislik/Teknik Yöneticisi/Sorumlusu
Proje Sistem Mühendisliği Yöneticisi/Sorumlusu
Proje Donanım Tasarım Yöneticisi/Sorumlusu
Proje Yazılım Tasarım Yöneticisi/Sorumlusu
Proje Gömülü Yazılım Tasarım Yöneticisi/Sorumlusu
Proje Mekanik Tasarım Yöneticisi/Sorumlusu
Proje Test Yöneticisi/Sorumlusu
Proje Donanım Tasarım Yöneticisi/Sorumlusu
Proje Entegre Lojistik Destek (Satış Sonrası Hizmetler) Yöneticisi/Sorumlusu
Proje Saha Entegrasyon Yöneticisi/Sorumlusu
Proje Satın alma Yöneticisi/Sorumlusu
Proje Üretim Yöneticisi/Sorumlusu
Proje Malzeme Planlama Yöneticisi/Sorumlusu
vb.

İnsanlara ne öğrendin diye sorulduğunda sadece ilk akla gelenler yazılacağı için, aşağıdaki sorular tek tek sorulmalı, yanıtları tek tek alınmalı ve böylece kişilerin değişik perspektiflerden projeyi düşünmeleri, hatırlamaları ve ele almalarına yön verilmelidir:

Doğru ne yaptık?
Yanlış ne yaptık veya doğru yaptığımızı düşündüğümüz ancak olumsuz sonuçları olan şeyler neydi? Nasıl olsa sonuçları olumsuz olmayabilirdi?
Benzer bir proje için başka bir arkadaşına ne önerilerde bulunurdun?
Geliştirilmesi gereken alanlar nelerdir?
Sence proje hedeflerine ulaşıldı mı? Ulaşılmadıysa neden ulaşılmadı? Nasıl olsa ulaşılırdı?
Hangi sorunlara çözüm buldun?
Karşılaştığın sorunlardan çözemediklerine şimdi aklına gelen bir çözüm var mı?
Projede görevleri zamanında ve doğru tanımla aldığını düşünüyor musun? Yanıtınız hayır ise açıklayınız.
Projede yatay ve dikey iletişim iyi miydi?
Projede bilgilendirilmen gerektiğini düşündüğün ancak bilgilendirilmediğin neler vardı? Gerekçeleriyle birlikte açıklayınız.
Öğrenilmiş dersler yanında edinilen deneyimler / kazanılan başarılar da bu bölümde anlatılabilir.

Şimdi en kritik noktadan bahsedeyim: İnsanlar unuturlar. 5 yıllık bir projenin sonunda insanlara ne öğrendiniz diye sorarsanız, alacağınız sonuç almanız gerekenin çok altındadır. Bu sebeple, öğrenilmiş dersler aslında ilk andan itibaren not alınarak zaman içinde son haline doğru şekil alması gereken bir dokümandır. Bu sebeple projelerde en geç her 12 aylık zaman dilimi sonunda, döneme ait öğrenilmiş dersler bu bölümde aktardığım usullerle hazırlanmalı ve ara raporlar olarak yayınlanmalıdır.

Proje Yönetimi Metodolojileri

Proje yönetimi için kullanılan pek çok metodoloji mevcuttur. Genellikle karma (hibrit/melez) yani birden çok metodolojiyi, işin gereklerine göre uyumlandıran ara metodolojiler kullanılır. Metodolojinin, işin gereklerine göre seçilmesi çok önemlidir. Çünkü bu metodolojiler, her yol Roma’ya çıkar şeklinde biri olmazsa diğeri ile başarının yakalandığı metodolojiler değildir ve bir metodoloji ile Konya’ya, diğer metodoloji yolu çok uzatıp önce Hanya’ya sonra Konya’ya gidiyor olabilirsiniz.

Proje yönetim metodolojilerinin seçimi tecrübe gerektirir. Örneğin, sistem projelerinde, donanım projelerinde, yazılım projelerinde, ürüne göre, projenin süresine, karmaşıklığına, ekibin büyüklüğüne, şirketteki proje yönetim kültürüne göre, şirkete tanımlı süreçlere ve bilişim teknolojisi / yazılım araçları alt yapısına göre, teknik isterlerin değişip değişemeyeceğine göre, proje ekiplerinin coğrafi olarak aynı lokasyonda olup olmamalarına, müşterinin projeye dahil olma miktarına göre bile izleyeceğiniz yol değişmelidir. Kulak aşinalığı için, sadece listeleyerek geçeceğim;

Agile / Adaptive Project Framework
Agile / Extreme Programming
Agile / Scrumban
Agile /Kanban
Agile /Scrum
CCPM- Critical Chain
CPM- Critical Path
ECM - Event Chain Methodology
Lean
NPI (New Product Introduction)
PER (Package Enabled Re-engineering)
PMBOK® Guide (bir metodolojiden ziyade kapsamlı bir kılavuzdur)
PRINCE2
RAD (Rapid Application Development)
Six Sigma
Waterfall

Savunma sanayiinde geliştirme projeleri için en sık uygulanan metodolojiler waterfall ve Agile (Scrum, Kanban) metodolojileridir.

Proje yönetiminde bir adım daha öteye geçmeyi planlarsanız, en azından waterfall ve agile metodolojilerini öğrenmeli ve özellikle karmaşık, isterleri sık değişebilen ürün geliştirme projeleri için agile metodolojisine odaklanmalısınız. Unutmayınız, her şey başarıya ulaşmak için sadece bir araçtır. Amaç x metodolojisini uygulamak değildir. Önemli olan işin felsefesidir. Ancak felsefeyi içselleştirerek ileride özgün ve farklı ihtiyaçlara cevap verebilen melez metodolojileri doğru zamanda ve doğru yerde uygulayabilecek entelektüel sermayeye sahip olabilirsiniz. Bazen uygulanacak metodoloji aşikardır ancak içinde olduğunuz kurum kültürü, nitelik ve tecrübe olarak insan kaynağı ve IT alt yapısı sebebiyle söz konusu aşikar metodolojiyi de uygulamak mümkün olamayabilir.

EĞİTİM VİDEOLARI

Proje Yönetimine giriş seviyesi bir temel vermek amacıyla hazırlamış olduğum ücretsiz video serisine aşağıdan ulaşabilirsiniz.