Yazar arşivleri: savassakar

Gerçekçi Zaman Çizelgesi Nasıl Hazırlanır?

Projelerin büyük bir kısmı planlanan kapsam, zaman ve bütçe dahilinde bitmiyor, bitmeyeceği düşüncesi yaygın.

Çünkü;

Kapsam, zaman ve bütçe erken belirlenirken gerçekçi olunmuyor veya kaliteli verilere ulaşılamıyor. Elde edilen verilerle ya da geçmişe dayalı öngörülerle yapılan tahminler proje süresince güncellenmiyor.

Değişiklikler yönetilmiyor, sözleşmelere değişikliklere yönelik maddeler eklen(e)miyor, proje ilerledikçe telaş ve panik artıyor.

Özellikle projelerin sonuna yaklaştıkça iş tempoları çok yükseliyor, hata yapma olasılıkları artıyor, zamanında bitirmek diğer tüm parametrelerin önüne geçiyor, “sonra hallederiz” ile işler öteleniyor.

Geçmişe dayalı tahminlerin insan hafızasından yapılması, geçmişe yönelik kayıtların tutulmaması (yazılı kültürün olmaması) problemleri artırıyor.

Müşteri ve sponsor “Söyledim, yapın”, Proje Yöneticileri “suçlama ve mazeret” peşine düşüyorlar. Pazarlama, satış birimleri hatası çok bir ürün, servisi pazarlamaya, operasyon birimleri hatası bol bir servis ve ürüne destek vermeye çalışıyorlar.

Temel olarak şunu söyleyebiliriz;

  • Gerçekçi bir zaman çizelgesi olmadan kapsam, bütçe, kalite vb. konularda başarılı olmak çok zordur.
  • Öncelikle paydaşların iyi analiz edilmesi, planlama sürecine katılımları sağlanmalı, gereksinimleri analiz edilmeli, yazılı hale getirilmeli ve önceliklendirilmelidir.
  • Gereksinimler bir bütün olarak ele alınmalı Kapsam netleştirilmelidir. Kapsam Belgesinde sadece yapılacaklar değil yapılmayacaklar da net olarak belirtilmelidir.
  • Kapsam Netleştirildikten sonra İş Kırılım Yapısına dönüştürülmelidir. İş Kırılım Yapısında yapılacak işler kadar alt proje hedefleri ve teslimatlar, onay ve kontrol noktaları yer almalı, projenin tamamı ifade edilmelidir.
  • Daha sonra yapılacak işler bir mantıksal sıraya sokulmalıdır.
  • Aktivitelerin yapacak kişiler tarafından ve sırayla yapılması önemlidir. Örneğin Ocak ayında başlayacak bir proje yaklaşık 1 yıl sürecek olabilir. Ocak ayında yapılacak işleri ilgili kaynaklar zaman, ellerindeki işler vb. dikkate alarak tahmin etmelidirler ve zaman çizelgesine yerleştirilmelidir. Bir işin yapılma zamanı süresini ve ayırılacak kaynakları etkileyecektir. Örneğin sahada yapılacak bir çalışmanın süresini hava sıcaklığı etkileyeceği için tahmin farklılaşacaktır.
  • Bir tahmin yapıldığında takip eden aktivitenin tahmini yapılmalıdır. Örneğin Aktivite 1, 15 Ocak’ta başlayıp 20 Ocak’ta bitecek şekilde plan yapılmışsa, Aktivite 2’yi planlayacak kişi buna göre tahminini yapmalıdır.
  • Aktiviteleri gerçekleştirenler kendi uzmanlıklarına göre tahmin üretirler. Takip eden aktiviteyi gerçekleştirecek olan önceki aktiviteyi gerçekleştirecek olana ilişkin öngörüsü varsa tahminin ona göre yapar. Örneğin Aktivite 1’i Ali gerçekleştiriyorsa ve konusunda çok uzmansa daha az hata yapacağı varsayılabilir, Aktivite 2’yi yapacak kaynak bu doğrultuda bir tahmin yapar.  
  • Her koşulda X sürede işin gerçekleştirileceğini varsaymak hatadır. Bazen işi almak isteyen dış kaynaklar gerçekçi olmayan süreleri kabul ederek projeyi riske atabilirler. Zorlayıcı hedefler iyidir ama bilerek lades olmak tüm proje paydaşlarına zarar verir.
  • Bir işi herkesin aynı sürede yapacağını varsaymak yanlıştır. Uzman ve acemi ayrımı hem süreyi hem kaliteyi etkiler. Kalitesizlik ek süre ve bütçe anlamına gelir.
  • Süre tahmini yapanların hangi varsayımlar altında süreyi tahmin ettikleri önemlidir ve kayıt altına alınmalıdır. Örneğin kar yağmayacağı varsayımıyla 10 gün süre tahmini yapmış olunabilir. Kar yağdığı durumda ne olacaktır? Varsayımları riskler olarak öngörmek ve yanıt planlarını hazır tutmak gerekir. Zaman çizelgelerinde varsayımlar, kısıtlar ve riskler için tampon süreler yer almalıdır.
  • Doğru kişinin doğru işe atanması süre tahminini etkileyecektir. Atanan personelin projenin gerektirdiği niteliklerde olup olmadığı, süre tahmini konusunda ilgili taahhüdü verme konusunda yetkisi sorgulanmalıdır.
  • Verilen süre taahhütlerini engelleyici ve bozucu eylemlerden kaçınılmalıdır. Örneğin, Yönetici bir personelini projeye atar, süre tahmini yapıldıktan sonra çalışanının takvimini dikkate almayıp aynı personele ek iş verirse işin süresi uzayacaktır.
  • Çalışanın, taahhüt ettiği sürede işini başarıyla gerçekleştirme konusunda çekinceleri varsa (yöneticim ek iş verir, başka konularda problemlerle uğraşırım vb.) vereceği süre tahminlerine koyacağı emniyet süreleri artmaya başlar. Çalışanlarını ve kendilerini tanıyan yöneticiler yapılan süre tahminlerinin şişkin olduğunu düşünüyorlarsa tepen inme kısıntılarla gerçekçi olmayan süre tahminlerinin yapılmasına yol açarlar.
  • Süre tahminlerinde sadece işin yapılması değil kontrolü, raporlanması, iletişimler vb. diğer unsurlar dikkate alınmalıdır.
  • Süre tahminleri “kesin” olarak nitelendirilmemeli, proje ilerledikçe geri kalan işlerin süreleri üzerinden geçilerek güncellemeler yapılmalıdır.
  • Süresel gecikmeleri erken fark edebilmek için kontrol mekanizmaları kurulmalı, hesap verilebilir bir çalışan ortamı yaratılmalı, önleyici ve düzeltici eylemler için kaynak yaratılmalıdır.
  • Gerçekçi süre tahmini yapmak için gerekenleri yapma, yaptırma cesaretini gösteren yöneticilere çok ihtiyacımız var. Yapılacak işin gerçekçi olarak planlaması ve plana uygun davranılması gerekir. Aksi takdirde körler sağırlar birbirini ağırlar.

Projenin Başarısını Tanımlamak

Proje başarısı neredeyse yıllarca zaman, maliyet ve kalitenin gerçekleştirilmesi olarak tanımlandı;

  • Belirli bir zaman aralığında veya tarihte,
  • Belirlenen bütçenin içinde,
  • Uygun performans ya da spesifikasyon seviyesinde,
  • Müşteri/kullanıcı onayladığında,
  • Kapsamında ve ortak anlaşılmış kapsam değişiklikleriyle,
  • Şirketin ana iş akışını bozmayacak şekilde,
  • Kurumsal kültürü değiştirmeyecek şekilde tamamlanan projeler başarıyla biter.

Son üç maddeyi biraz açıklamakta fayda var;

Çok az proje başlangıçta tanımlanan kapsamı içerisinde tamamlanıyor. Kapsam değişiklikleri kaçınılmaz olduğu gibi proje ekibini olumsuz etkileyebiliyor. Kapsam değişiklikleri kontrol altında tutulmalı, proje yöneticisi/ekibi ve müşteri/kullanıcı tarafından onaylanmış olmalıdır.

Proje Yöneticileri, şirketin ana iş akışının değişmemesi için çaba göstermelidirler. Proje Yöneticileri, projeyi bir evlilik gibi görüp bittiğinde boşanacaklarını, işlerinin bittiğini düşünebilirler. Projeler bittikten sonra ilgili departmana devredilir. Bu yüzden, proje süresince ve sonrasında mevcut politika, prosedür ve kurallara uyulması çok önemlidir.

Her şirketin kültürü farklıdır, her projeye farklı yaklaşılır. Proje Yöneticisi kendini kurum kültüründen ayırmamalı, farklı görmemelidir. Şirket kültürü, müşteriye karşı açıklık, dürüstlük ise proje yöneticisi ayak uydurmalıdır. Proje Yöneticisinin kendini şirketten farklı göstermek gibi bir çabası olmamalıdır.

Proje başarısı ile şirketin proje yönetimi konusundaki başarısı karıştırılmamalıdır. Projelerin başarısı Proje Yönetimindeki başarının devamlılığı ile sağlanabilir.

Projenin başarısını paydaşların gözünden değerlendirmek gerekir.

Aşağıdaki şekilde zaman, maliyet ve kapsam başarı kriteri olarak birinci önceliktedir. İmaj, itibar, kalite ve değer ikinci önceliklidir.

Ancak günümüze geldiğimizde birden fazla kısıtın projeleri doğrudan etkiledinizi görebiliyoruz. Müşteri ilişkileri, imaj ve itibar klasik başarı faktörlerinden (kapsam, zaman, maliyet) bizi uzaklaştırabiliyor. Proje esnasında çevredeki değişiklikler, üst yönetimin değilmesi ve yeni gündemlerin ortaya çıkması vb. çeşitli sebeplerle klasik başarı tanımları bir kenara bırakılabilir.

Disneyland’ın Tema Parklarını yapan proje yöneticileri için 6 kısıt mevcuttu;

  • Zaman
  • Maliyet
  • Kapsam
  • Güvenlik
  • Estetik
  • Kalite

Son üç madde kesin ve netti. Diğerleri esneyebilir ama bu üç madde esneyemezdi.

Unutulmaması gereken tüm kısıtların aynı öneme sahip olamayacağıdır. Örneğin başlangıç fazında kapsam önemlidir, zaman ve maliyet esnetilebilir. Yürütme fazında zaman ve/veya maliyet önemlidir, kapsam esnetilebilir gibi düşünebilirsiniz.

Yararlanılan Kaynak: Project Management: A Systems Approach to Planning, Scheduling, and Controlling11th Edition Harold Kerzner

Proje Yönetiminde Kontrol Hesapları

Kapsam, bütçe, gerçekleşen maliyet ve zaman çizelgesinin bütünleştirildiği  ve performansı ölçmek için kazanılmış değerle karşılaştırıldığı yönetim kontrol noktalarına Kontrol Hesapları denir.

Projelerde, proje ekibi proje hedeflerine ulaşmak ve gerekli teslimatları yaratmak için İş Kırılım Yapısını (İKY) oluşturur. Projede maliyet muhasebesi yapılabilmesi için çalışma paketlerine hesap kodlarından özgün bir belirtecin (Kontrol Hesabı) verilmesi gerekir.

Kontrol hesapları İKY’deki seçilmiş yönetim noktalarına yerleştirilir ve Zaman Çizelgesinde yer alması sağlanır. Her bir kontrol hesabı bir ya da daha fazla çalışma paketi içerebilir, ama çalışma paketlerinin her biri sadece bir kontrol hesabıyla bağlantılandırılmalıdır.

Maliyet tahminleri Kontrol Hesabı düzeyinde birleştirilebilir. Böylece Kontrol Hesapları toplamı Maliyet Temel Çizgisini oluşturacaktır.

Organizasyonel Kırılım Yapısı ile İş Kırılım Yapısının kesişim noktalarında Kontrol Hesapları belirlenebilir. Böylelikle her bir kontrol hesabının zaman, maliyet ve kapsam düzeyinde sorumlusu belirlenmiş olur.

Proje Yönetimi ve 360° Geri Bildirim

360° Geri Bildirim (360° Feedback), takım üyelerinin, proje sponsorlarının ve diğer paydaşların anonim olarak tarandığı ve proje yönetiminin performansı hakkında görüşlerinin alındığı geri bildirim türüdür. Yeterliliklerdeki boşlukları tespit etmek, gelişim veya eğitim planı oluşturmak için dayanak olarak kullanılır.

Basitçe söylemek gerekirse 360° Geri Bildirim bir çalışanın yöneticisini, yöneticisinin çalışanını değerlendirmesidir. Proje Yönetiminde birbirini değerlendirecek tarafları şöyle sıralayabiliriz;

  • Proje Müşterisi
  • Sponsor
  • Proje Yöneticisi
  • Proje Ekibi
  • Fonksiyonel Departmanlar
  • Dış Kaynaklar

Bu değerlendirmede aşağıda yer alan konular sorgulanabilir;

  • Proje Yöneticisi, projenin paydaşlara olan etkisini yeterince anlamış mıdır?
  • Proje ekip üyesi rol ve sorumluluklarını etkin bir şekilde yerine getirmekte midir?
  • Proje Yöneticisi, Proje Ekibine destek olmakta mıdır?
  • Proje Sponsoru gerekli kaynakları sağlamakta mıdır?
  • Dış Kaynak raporlamalarını düzenli yapmakta mıdır?
  • Ekip üyeleri kendi aralarında etkin iletişim kurmakta mıdır?
  • Fonksiyonel Yönetici doğru kaynağı, doğru zamanda atamakta mıdır?

Proje ekipleri yöneticileri için bu yöntemin bazı artı ve eksi tarafları vardır. Bazı ekip üyeleri başarılarının ve gayretlerinin tek bir kişi tarafından değerlendirilmesini istemezler. Tüm ekip üyelerinin gözlemlerinin ve düşüncelerinin dikkate alınmasını tercih ederler. Belirli kişilerle yaşadığı olumsuz durumların tüm performanslarına yansıtılmasını doğru bulmazlar. Böyle değerlendirmelerde “kişisel” görüşlerin “profesyonel” görüşlerin önüne geçmesine izin verilmemelidir.

Yapılacak değerlendirme herkese aynı formatta yapılmalı, haksızlıklara ya da yanlış anlaşılmalara imkan vermemelidir. Değerlendirmede yer almayan konular ilgili taraflarca yazılı halde ayrıca toplanmalıdır.

Değerlendirmenin amacı birini iyi ya da kötü göstermek değil gelişim, eğitim vb. konularda yol gösterici olması olmalıdır.

Yapılan değerlendirmeler bir kenara bırakılmamalı, değerlendirmenin sonucunda gerekli aksiyonlar alınmalı ve raporlanmalıdır.

Değerlendirme esnasında tarafların soruları dinlenmeli ve dürüstlükle yanıtlanmalıdır.

Değerlendirmeye tabi olan konular ilgili paydaşlarla değerlendirme öncesi paylaşılmalı, değerlendirme kriterleri ve başarı ölçütlerinin iyi anlaşıldığından emin olunmalıdır.

Değerlendirmenin negative olması durumunda paydaşın yanlış anlayabileceği, performansının düşebileceği olasılığı göz ardı edilmemelidir. Bu değerlendirmelerin cezalandırma değil değerlendirme amaçlı olduğu açıklanmalıdır.

Değerlendirme sonuçları bağımsız denetleyiciler tarafından gözden geçirilmeli (hepsi çok iyi ya da kötü işaretlenmiş olabilir vb.) herhangi bir uygunsuzluk durumunda değerlendirmenin tekrarlanması istenmelidir.

Örnek Rapor

Projelerde Bilginin Önemini Anlamak

Projeler, kişisel ve kurumsal öğrenme fırsatları içerirler. Paydaşların bilgi alma ya da verme konusundaki farkındalıklarının iyileştirilmesi gerekir.

Bilgi Yönetimi paydaşın profiline bağlıdır. En basitinden Sponsor veya Yürütme Kurulunun yayınladığı Proje Başlatma Belgesi içeriğinden anlayabilirsiniz. Bir projenin ne kadar bilgiye dayandığı, nasıl seçilip, hedeflerinin belirlendiği anlaşılabilir.

Veriler sayılardan oluşur, bilgi ise verilerden çıkarılan, doğru olduğuna inanılan sonuçtur. Bilgi çoğu zaman sayı ve kelimelerle durumun açıklanmasıdır. Bilginin düzenli ve planlı bir şekilde proje yaşam döngüsünde yönetilmesi proje performansını doğrudan etkiler. Eğer bilgi gerçek zamanlı üretilebilirse projenin geri kalanı ile ilgili daha gerçekçi kestirimler yapılabilir. Bilginin “doğru ve kaliteli” akışı sağlanırsa gerçekçi performans bilgileri edinilebilir. Proje ile ilgili tehdit be fırsatlar paylaşılırsa paydaşlar doğru zamanda doğru pozisyon alabilirler.

Bilgi, pozitif ve negatif durumların, alınan derslerin vb. kayıt altına alınmasıyla başlamalıdır. Böylelikle proje teslimatları ile başarılı sonuç arasındaki köprü görevini görecektir.

Bilgi yönetiminin kurum içindeki olgunluk seviyesi çok önemlidir. Geçmişteki hataların tekrarlanması, bilginin iyi yönetilemediği anlamına gelir.

Proje Yöneticisi, hangi paydaşın hangi bilgiye ihtiyacı olduğunu, pozitif ve negatif etkilerini çok iyi analiz etmelidir. Paydaşlar, hangi bilgiyi, ne zaman nasıl, hangi paydaşa aktarmaları gerektiğinin önemini anlamalıdırlar.

Şirket projeleri, bilgi açısından denge ve karmaşıklık olarak sınıflandırılmalıdır. Şirketler denge ile dinamik arasında yer alırlar. Belirsizliğin yüksek olduğu ortamlarda dinamiklikten söz edilir. Şirket karmaşıklığı, basit ile karmaşık arasındadır. Bazı projeler dengeli ve basit, bazıları dinamik ve karmaşık olabilir. Dinamik ve karmaşık projelerde bilgi yönetimi daha önemlidir. Tek bir yaklaşım her projeye uygulanamaz.

Dinamik ve karmaşık projeler ikiye ayrılır; Nitelikli ve Niteliksiz. Nitelikli projeler bilgi yönetimi ile yönetilirler, niteliksiz projeler bilgi yönetimi olmadan yönetilirler.

Nitelikli projelerde bilgi yönetimine yönelik Maliyet-Fayda Analizi yapılmalı ve yönetime sunulmalıdır. Bilgi Yönetimine ilişkin spesifik aktiviteler planda yer alır maliyetleri doğrudan hesaplanabilir.

Bilgi Yönetiminin faydaları tanımlanmalı ve tahmin edilmelidir; geleneksel yöntemlerle yönetilmenin ve bilgi yönetimi ile yönetilmesinin yarattığı performans farklılıkları, proje sonrası operasyonel maliyet farklılıkları, proje ile öğrenilen ve değer yaratan konular.

Değer yaratan bilgi, problem çözmede ve karar vermede destekleyici olandır.

Unutmayın;

  • Bilgilerin %80’i keşfedilmeyi, ele ve dikkate alınmayı bekler. Bilgi akışı bilgiyi saklamaktan daha önemlidir.
  • Bilgi doğru zamanda doğru kişiden doğru kişiye aktarılıyorsa şeklin önemi yoktur. Önemli olan sürekliliği saklamaktır. Bu sağlanırsa bilginin saklanmasının yöntemleri araştırılmalıdır.
  • Herkes işini yapma sorumluluğu kadar bilgi paylaşma sorumluluğu olduğunu bilmelidir.
  • Alınan dersler içselleştirilmezse bir anlamı kalmaz. Edinilen bilginin sürdürebilirliği sağlanmalıdır.

Daha İyi Bir Proje Yöneticisi Olmak

Eğitimlerimde, “Daha iyi bir proje yöneticisi olmak için ne yapıyorsunuz?” diye soruyorum. Hatta daha iyi anne-baba, eş, çalışan, yönetici, şirket olmak için ne yapıyorsunuz sorularını da çok severim.

Kendinizin ne kadar farkındasınız? Yeteneklerinizin, güçlü-zayıf taraflarınızın farkında olmalısınız.

Size destek olan, yol gösterenler var mı? Yoksa her şeyi kendi başınıza halletmeye mi çalışıyorsunuz? Size destek olacak uzmanları ve deneyimli kişileri bulmalı desteklerini almalısınız.

Deneyimlerinizi ve çevrenizi faydaya dönüştürebiliyor musunuz? Hiç bir şey kendiliğinden faydaya dönüşmez. Deneyimlerinizi ve çevrenizi size değer yaratacak şekilde değerlendirebilmelisiniz.

Gelecekte kendinizi nasıl bir dünyada görüyorsunuz? Daha zor, karmaşık işlerin sorumluluğunu alan biri olarak görüyorsanız ihtiyacınız olan yetenek ve becerilere şimdiden yatırım yapmaya başlamalısınız.

Kendi konunuzda farklı mısınız ya da fark yaratabilir misiniz? Benzerler arasında kaybolmak kolaydır. Sizi farklılaştıracak ve tercih edilmenizi sağlayacak bilgi, beceri ve deneyimlere odaklanmalısınız.

Kendinizi gözlemleyip, gerçekçi ve samimi değerlendiriyor musunuz? Başarı ve başarısızlıkları samimice sahiplenmek çok kıymetlidir. Kendinizi kandırmadan hata yaptığınız konularda tekrarlamaması için gerekeni yapmalı, kendinizi sürekli geliştirmelisiniz.

Yaşadığınız problemleri neden yaşadığınızı sorguluyor musunuz? Mazeretleri ve suçlamaları bir kenara bırakın, kalan konulara odaklanın.

İnsanları nasıl motive edebileceğinizi veya bir projeye samimi katılımlarını nasıl sağlayacağınızı biliyor musunuz? Bu konuda ne yapıyorsunuz? İletişim ve insanları anlamak proje başarısının sırrıdır. Daha iyi ve etkin iletişim kurmanın, insanların iletişim gereksinimleri doğrultusunda doğru yöntem ve araçları seçtiğinizden emin olmalısınız.

Başarısızlıktan korkuyor musunuz? Korkmayın, mücadele ruhunuzu koruyun. Başarmak için bir çok alternatif yol olduğunu aklınızdan çıkarmayın ve denemeye devam edin.

Proje Yöneticisi olmak lider olmak demektir. Başarı ve başarısızlıklardan ders çıkararak sürekli gelişim sağlayabilmek demektir. Her zaman esnek ve Pratik olmalı, basit ama geçerli çözümler üretebilmelisiniz.

Proje Yönetimi yolculuğunuzu planladınız mı? Daha iyi bir proje yöneticisi olmak için yanınıza almanız gerekenler, rotanız ve en önemlisi planınız olmalı.  

Projeleri tamamlamaya değil başarıyla bitirmeye odaklanın. Daha iyi bir proje yöneticisi nasıl olabilirim sorusunu sormayı hiç bırakmayın, cevaplarını biliyor olabilirsiniz, farkında olmadığınız yeni cevaplar bulabilirsiniz, azminiz ve iradeniz size bu yolda başarılı kılacaktır.

Proje Yönetiminde Sorun Kayıtları (Issue Log)

Proje süresince projeyi olumsuz etkileyecek çeşitli sorunlar ortaya çıkar. Proje Yöneticisinin sorunlarla baş edebilmesi ve gelecekte benzer sorunların çözümü için Sorun Kayıtları tutması gerekir.

Sorunlar nedir?

Proje süresince ortaya çıkan problemler, farklar, uygunsuzluklar ve çatışmalardır. Proje ekibi veya tedarikçilerle, teknik hatalarla vb. projeyi olumsuz etkileyecek şekilde ortaya çıkarlar. Sorunlar çözüme kavuşturulmazsa gereksiz çatışmalara, gecikmelere ve teslimatlarda hatalara yol açarlar. Sorunlar özellikle paydaş beklentileri üzerinde büyük etkiye sahiptirler.
 
Sorun ve Risk Arasındaki Fark

Proje Yöneticisinin sorunları ve riskleri yönetme süreci benzerdir. Risk gelecekte ortaya çıkabilecek olumsuz durumdur. Proje ekibi gerçekleşmesi olasılığına karşılık yanıt planı hazırlar. Risk yönetimi stratejik ve proaktiftir.

Sorun ise projeyi etkilemekte olan ve hemen çözülmesi gereken durumlardır. Reaktif ve anında taktiksel çözüme ihtiyaç duyulan durumlardır.

Proje gerekli nitelikte bir ekipmanı bulabilmek risktir, bulunan ekipmanın arıza yapması Sorun’dur.

Sorun Kayıtları nedir?

Tüm sorunların kaydedildiği ve izlendiği belgedir. Bir sorun kaydı yaratıldığında raporlanması ve iletişiminin sağlanması gerekir. Proje Yöneticisi kayıtları tutmaktan, sorunun izlenerek çözümlenmesinden sorumludur.

PMBOK®, proje ekibinin yönetilmesi sürecinde insan kaynakları odaklı sorunların proje yöneticisinin proje ekibini uygun yönetmesiyle çözebileceğini vurgular.  Kaynağın projeden ayrılması, düşük moral veya ekip içi çatışmalar bu sorunlara örnektir ve proje hedeflerini doğrudan etkilerler.

Sorun kaydı girildiğinde her soruna bir sorumlu atanır.

Proje Yöneticisi, paydaşların beklentilerini ve çekincelerini dikkatlice ele almalı ve olası sorunlara proaktif yaklaşmalıdır.

Sorun Kayıtlarında Hangi Bilgiler Yer Alır?

  • Proje Adı:
  • Sorun Tipi : Teknik, Kaynaklar, Tedarikçiler vb. sorunun doğru kişiye aktarılarak çözümlenmesi için.
  • Sorunu ileten : Kişi veya Departman
  • Sorun İletilme Tarihi : Sorunun kayıtlara giriliş tarihi
  • Detaylı Açıklama:
  • Öncelik : Yüksek, orta, düşük vb.
  • Sorun Giderme Sorumlusu:
  • Hedef Çözüm Tarihi:
  • Durum: Açık, Çalışılıyor, Çözüldü vb.
  • Çözüm: Sorunun nasıl giderildiği

Örnek Sorun Kaydı

Projelerden Öğrenmek

İster istemez, deneyimlerimizden çıkardığımız dersleri uygulamaya çalışırız.

Geçmiş projelerde yapılan hataların veya yakalanan fırsatların gelecekteki projelerde yapılmaması ya da yapılması yönünde bir çok metodoloji ve yöntem Alınan derslerin önemine vurgu yapar.

Ders çıkarmanın sürekli olması gerekir. Sadece proje sonlarında bir kaç cümle ile raporun tamamlanması için yapılmamalıdır. Projenin her adımında, alınan derslerin fark edilmesi, tanımlanması, analiz edilmesi, yazılı hale getirilmesi ve ilgili paydaşlarla paylaşılması gerekir. Nefes almak, yemek yemek, uyumak kadar doğal bir davranışa dönüşmesi gerekir.

Projelerdeki yüksek tempolu çalışma vb. bir çok sebep Proje Yöneticisinin ders çıkarmayı ikinci plana atmasına sebep olur. “Elimdeki işi yapmaya gücüm ve zamanım anca yetiyor ders çıkarmakla uğraşamam” diyebilir. Zaten bir proje bitmeden diğeri başlamıştır, geçmişte olduğu gibi durumlara “olduğunda” adapte olma kabiliyetimiz ve pratik zekamıza güveniriz. “Bu şirket böyle”, “Ne yapsam olmuyor” gibi bizi koruyucu bahanelerimiz zaten hazırdır. Kabul edelim ya da etmeyelim hepimiz “bilinçli tembeliz” kolayı seçip, zordan kaçarız, buna “akıl” adını verdiğimiz çok olur.

Bir projeyi “tamamlamaktan” çok “başarmanın” önemli olduğunu Proje Yöneticilerinin iyi kavraması gerekir. Proje Yöneticisinin rolü başarmaktır ve deneyimleri en büyük yardımcısıdır. Şirketin yapısı, projenin büyüklüğü, paydaşların çokluğu vb. bir çok konuda mazeretler bulmak ve diğerlerini suçlamak gibi “moda” yöntemleri tercih etmemesi gerekir.

Projelerden ders çıkarmak proje yöneticisinin asli görevi olmalıdır. İsteğe bağlı olmamalı, bilinçli olarak projesinde ele alması gereken bir konu olmalıdır. Proje öncesinden başlayarak proje bittikten sonra dahi devam edecek bir süreç olarak ele alınmalıdır.

Resmi bir süreç olarak ele almadan önce kişisel olarak başlanabilir. Küçük notlar tutmak şeklinde yaşanılanlar kayıt altına alınabilir. Unutulmaması gereken yaşanan bir olayın veya üretilen bir çözüm hangi şartlar altında ortaya çıktığı veya çözüldüğünün çok önemli olduğudur. Çıkarılan dersler “fotokopi” gibi gelecekte aynen uygulanamayabilirler. Alınan norlar “Unutmamam Gerekenler” “Dikkat etmem gerekenler” “Yapmam Gerekenler” “Yapmamam Gerekenler” vb. kişisel bazda olabilir.

Çıkardığımız dersler kişisel düzeyde olabilir. Kendi kişisel alanımız konusunda daha fazla kontrole sahibizdir. Bu yüzden kurumsal veya proje ekibindeki herkese uygun olup olmadığı dikkatlice ele alınmalıdır.  

“İnsan çalışmak için tasarlanmamıştır” sözünü çok severim. Her hangi bir durumda en az eforla işin üstesinden gelmeye çalışırız. Çoğu zaman az ve eksik bilgi ile kararlar almak durumda kalırız. İşimize gelene yönelmeye, gelmeyenden uzaklaşmaya çalışmamız normaldir.

Düşünebilmemiz ve aklımızın olması öğrenebildiğimiz anlamına gelmez. Mevcut deneyimlerimize rağmen gelecekte aynı hataları tekrarlayabiliriz. Yaşadığımız kötü şeyler sonucunda ileride aynısını tekrar yapmamaya kendimize söz verebiliriz. Yine de tekrarlayan hatalarla karşılaşmaktan kurtulamayız.

Proje Yöneticisi her hangi bir şeyi nasıl öğrenebildiğine odaklanmalıdır. En iyi öğrenmenin okuyarak, dinleyerek veya gözlemleyerek değil yaparak olduğu unutulmamalıdır.

Önce deneyimlerinizi fark ederek başlamalısınız. Deneyimlerimiz, öğrenmemizi garantilemez. Neyi deneyimlediğinizi, neyin iyi ya da kötü olarak tanımlanabileceğini düşünmelisiniz. Deneyimlerinizin doğru noktalarına odaklanmadan bir ders çıkartamayabilirsiniz.

Deneyimizin sonrasında gelecekteki farklı durumlarda neyi nasıl farklı yapacağınızı kararlaştırmaya çalışın.

Çoğu zaman sondan başlıyoruz. Bir projeden ders çıkarmayı değil fark etme, analiz etme, anlama, öğrenme kapasitenizi nasıl geliştireceğinize odaklanmalısınız. Böylelikle geçmişte öğrendikleriniz geleceğinize ışık tutabilir.

Yukarıda bahsettiğim konuların anlaşılması kolay uygulanması zor konular olduğunun farkındayım. Ne var ki iyi şeylerin maliyetine katlanılması gerekir. Öğrenme kapasitenizi geliştirmeye ve ders çıkarmaya harcayacağınız efor ve ayıracağınız süre size gelecekte çok daha iyi koşullar yaratacaktır.

“Proje Seyir Defteriniz” olsun, yaşanan bir durum sonrasında veya aklınıza bir şey geldiğinde küçük notlar tutun. Hedefiniz sürekli gelişim için yapılabilecekler ve yapılmaması gerekenleri belirlemek olsun.

Çıkardığınız dersleri az ve öz bir şekilde proje paydaşlarıyla paylaşın. Organizasyonel anlamda önemli olan çıkarımlarınızı ilgili departmanlarla paylaşarak ve yönetim onayıyla politika ve prosedürlere girmesi için çaba sarf edin.

Proje Paydaşları Nasıl Tanımlanır?

Proje Yönetimi yapmanın temel amacı paydaş gereksinimlerinin karşılanmasıdır. Bu sebeple paydaş tanımlama süreci büyük öneme sahiptir.

Paydaş, projeye aktif olarak dahil olan ya da projenin gerçekleştirilmesi ya da tamamlanması ile çıkarları olumlu ya da olumsuz yönde etkilenebilecek kişi veya organizasyonlardır. Örneğin, müşteri, sponsor, çalışan organizasyon, kamu kurumları vb.

Proje paydaşlarının, proje başlatma belgesi yayınlanır yayınlanmaz belirlenmesi ve tüm proje yaşam döngüsü boyunca yönetilmeleri gerekir. Proje Başlatma Belgesi, projenin başlatıcısı ya da sponsoru tarafından yayımlanan, projenin varlığını resmi olarak onaylayan ve proje yöneticisine organizasyonun kaynaklarını proje aktivitelerine tahsis etme yetkisi veren bir belgedir. Bu belgede üst düzey proje hedefleri, bütçe, zaman çizelgesi, varsayımlar ve kısıtlar, sponsorun, proje yöneticisinin adı ve ilgili paydaşların adları vb. bilgiler yer alır.

Paydaşları belirlemek için dikkat edilmesi gerekenler aşağıdaki gibidir;

  • Proje bir sözleşme ile başlamışsa, sözleşmede ilgili paydaşlar (tedarikçiler vb.) yer alıyor olabilir.
  • Organizasyonel yapıyı inceleyerek projeden etkilenecek ya da etkileyecek paydaşları görebilirsiniz.
  • Geçmiş projelere ilişkin kayıtlar, alınan derslere ilişkin belgelerden paydaşlar belirlenebilir.
  • Benzer proje deneyimine sahip uzman kişilere danışılabilir.
  • Projeyi ilgilendiren yasa, kural vb. incelenerek ilgili paydaşlar belirlenebilir.
  • Çeşitli uzman ve departmanlarla beyin fırtınası yapılarak paydaşlar belirlenebilir. Sorulması gereken sorular aşağıdaki gibidir;
    • Projeye doğrudan katılması gerekenler kimlerdir?
    • Projeden kim(ler) etkilenecek?
    • Projenin çıktılarından kim(ler) etkilenecek?
    • Projenin başarıyla tamamlanması durumunda kim kazanacak kim kaybedecek?
    • Projenin başarıyla tamamlanmasını isteyecekler, istemeyecek olanlar?
    • Tedarikçiler kimlerdir?
    • Rakiplerimiz kimlerdir?
    • Hissedarlarımız kimlerdir?
    • Projeyi veya çıktısını etkileyecek yasal bir otorite veya organizasyon var mıdır?
    • Proje başarısında yetkisi olanlar kimlerdir?
    • Kimler projeyi başarısızlığa uğratabilir?

Paydaş tanımlama proje süresince devam eden bir süreçtir. Proje boyunca proje paydaşları izlenmelidir. Bazen yeni proje paydaşları ortaya çıkabileceği gibi mevcut bir paydaşın projeyle ilgisi kalmayabilir. Paydaşların projeye ilgisi veya proje fazlarındaki güçleri zaman içerisinde değişiklik gösterecektir.

Tüm paydaşlar, Paydaş Listesinde yazılı halde tutulmalıdır. Paydaş Listesinde paydaşın ad ve soyadı, iletişim bilgileri, güç, etkilenme, beklenti, gereksinimleri yer almalıdır.

Proje Yönetiminde Çalışma Performansı Verileri, Bilgileri ve Raporları

Çalışma Performansı Verileri

Proje çalışmasını yerine getirmek için gerçekleştirilen aktiviteler sırasında belirlenen işleme alınmamış gözlemler ve  ölçümlerdir.

Örneğin;

  • Tamamlanmış işler
  • Anahtar Performans Göstergeleri,
  • Teknik performans ölçüleri (gözlem sayısı, kalite ölçütleri vb.)
  • Aktivitelerin başlangıç, bitiş tarihleri
  • Tamamlanan hikaye noktaları sayısı,
  • Değişiklik talep sayısı
  • Onaylanan Değişiklik Sayısı
  • Kusur sayısı
  • Gerçekleşen maliyetler
  • Onaylanmış maliyetler
  • Faturalanmış Makliyetler
  • Ödenmiş Maliyetler, faturalar
  • Gerçekleşen Süre
  • Kalan Süre
  • Gerçekleşme Yüzdeleri
  • Biten aktiviteler
  • Harcanan Efor
  • Gereksinimlere uyum
  • Uygunsuzlukların sıklığı
  • Belirli bir zaman içinde onaylama sıklığı
  • Tamamlanan teslimat sayısı
  • Kullanılan kaynak tipi ve miktarı
  • İletişim tipleri ve miktarları
  • Uygulanan risk yanıtları
  • Gerçekleşen risk sayısı
  • Aktif riskler
  • Kapatılmış riskler
  • Tedarikçi teknik performansı
  • Tedarikçinin başladığı, devam ettiği, bitirdiği işler
  • Destekleyici, köstekleyici paydaşlar

Çalışma Performansı Bilgileri

Çeşitli kontrol süreçlerinde toplanan, bağlama bağlı olarak analiz edilen ve alanlar arası ilişkilere göre birleştirilen performans verileridir. 

Örneğin;

  • Hangi teslimatlar onaylandı, hangileri onaylanmadı, neden?
  • Kapsam temel çizgisine etkiler
  • Gelen değişiklik kategorileri
  • Kapsam sapmaları ve sebepleri, zaman ve maliyet etkileri
  • Gelecek kapsam performansı öngörüsü
  • Zaman temel çizgisine etkiler
  • Başlama ve bitiş tarihleri, sürelerdeki sapmalar
  • Zaman çizelgesi sapması ve zaman çizelgesi performans endeksi
  • Maliyet temel çizgisine etkiler
  • Efor ve maliyet sapmaları
  • Maliyet varyansı, maliyet performans endeksi, bitimde beklenen, bitimde beklenen fark
  • Proje gereksinimleri karşıladı mı?
  • Redlerin sebepleri
  • Yeniden iş yapma gereklilikleri
  • Düzeltici eylem önerileri
  • Onaylanmış teslimatlar
  • Kalite ölçütleri durumu
  • Süreç ayarlama gereklilikleri
  • Kaynak gereksinimlerine göre kaynak dağılımları
  • Planlanan – Gerçekleşen İletişimler
  • Risklerin beklentilere uygunluğu
  • Tedarikçi gerçekleşmelerinin planlarla uygunluğu
  • Paydaş katılım durumu

Çalışma Performansı Raporları

Yeni fikirler yaratmak, eylem ya da farkındalık oluşturmak niyetiyle proje belgelerinde toplanan çalışma performans bilgilerinin fiziksel ya da elektronik temsilidir.

Örneğin;

  • Durum Raporları
  • İlerleyiş Raporları
  • Kaynak uygunluğu
  • Kazanılmış Değer