Yönetme Fonksiyonunu Sorumluluk Devrederek, Kolaylaştırın

Delegasyon, proje hedeflerine ulaşmak için öncelikle aktivitelerin tanımlnması ve işlerin en iyi kişilere atanmasıyla başlar. Fakat sonuçların düzenli olarak takip edilmesi, Proje Yöneticisinin görevidir.

Etkili delegasyon için aşağıdaki adımları kullanılmalıdır.

1. Projenin hedefini, kapsamını, önemini ve bitiş tarihini herkesin katılımıyla tanımlayın.

2. Her işin tamamlanması için sorumluyu, gerekli kaynakları, destek elemanlarını, kontrolörleri belirleyin. Aksi takdirde, ekipklerin birbirlerinden istedikleri yardım talepleri yeterli desteği görmeyebilir.

3. Bir işin tamamlanmasıyla hangi sonuca ulaşılması gerektiğine dair standartları belirleyin. Sorumlular, ilgili faaliyeti bitirdiklerinde çıkacak sonucun hangi faaliyette ve kimin tarafından kullanılacağını bilsin.

4. Proje taraflarını, riskleri veya sorunları zamanında haber vermeleri için motive edin. Eğer kişiler riskleri ve problemleri paylaştıklarında, cezalandırılacaklarını düşünürlerse, zamanında bilgi vermezler ve küçük bir problem erken müdahele edilmediği için daha büyük sorunlara yol açar.

5. Proje Yöneticilerini delege etmesi konusunda motive edin. Özellikle ekip sayısının arttığı projelerde Proje Yöneticisi, koordinasyonu, iletişimi, plan, uygulama ve kontrol sürecini takip eden bir kişi olmalıdır. PY, proje için ayırdığı zamamnın %60-%90’ını iletişime zaman ayırarak, geçirmelidir.

Proje Portföy Yazılımı Seçerken… – 1

Bir Proje Portföy Yönetimi yazılımı seçerken seçim sürecini bir proje olarak ele almalısınız. Bu süreçte iyi bir proje yönetimi uygulaması, ihtiyacınız olan yazılımı belirlemede büyük fayda sağlayacaktır.

Çok geniş fonksiyonlu bir yazılım satın alırsanız ihtiyaçlarınızın çok ötesinde bir ürünle karşılaşabilirsiniz. Bu yüzden öncelikle temel ihtiyaçlarınızı (olmaz ise olmazlarınızı düşünmeli ve belgelemelisiniz) Unutmayınız ki uygulayamayacak düzeyde ortaya koyduğunuz istekler, ek masraf yaratacak ve satın aldığınız ürünü verimsiz kullanmanıza sebep olacaktır..Ayrıca kurum içinde karmaşık bir bürokrasi de yaratacaktır. Bu çerçevede özellikle proje taraflarının belirlenmesi ve onların proje yönetimi ihtiyaçlarını, sorgulayarak veya gözlemleyerek, çıkarmak gerekir.

Risk Kategorileri ve Tehdit Indeksi

Projeyi etkileyebilecek Riskleri aşağıdaki gibi kategorilendirmek mümkündür.

Teknik – Kalite Riskleri
Finansal Riskler
İş – Yatırım Riskleri
İnsan Kaynakları Riskleri
Tedarikçi Riskleri
Çevresel Riskler

Kategorilendirme sayesinde her risk bir sınıfa ait olacak ve yapılan analizler neticesinde karşılaştırılabilir daha anlamlı verilere ulaşılacaktır.

Peki, analizler nasıl yapılmalıdır? Sorusuna da kısaca cevap arayalım.

Bu çalışmayı ilk defa yapacaksanız, doğru yapıp, yapmadığınız konusunda önemli şüphelere kapılırsınız, hiç dert etmeyin… Uygulamalarınız artıkça doğru yolu bulmak mümkün olacaktır.

Öncelikle yapılması gereken riskleri tanımlamak. Risk Tanımlamada dikkat etmeniz gereken soru şudur;

“Bir aktivite veya ardışık (arka arkaya yapılacak) aktiviteler grubunda gecikmeye, maliyet artışına, kalite düşüşüne veya kapsam azalmasına/artmasına sebep olabilecek olaylar nelerdir?”

“Bir tedarikçimin malı planladığımdan daha geç göndermesi” durumu veya “belirli bir döenemde yapılması gereken bir kaç aktivite için X departmanının yeterince insan kaynağı ayıramaması durumu” örnek olarak verilebilir.

Benzer riskleri tanımlayıp, kategorize ettikten sonra her kategori içindeki risklerin Tehdit Indeksini hesaplamak, mümkündür.

· Etki Gücü: Yukarıda tanımladığınız risk durumu gerçekleşirse ilgili aktivitenizini özellikle süre veya parasal açıdan ne kadar etkiler? Bu sorunun cevabı sayısal olmalıdır. Örneğin: “3 gün, 2 hafta, 1ay, 300 TL, 200€ gibi”

· Olasılık: Geçmişteki deneyimlerinizi veya varsa yazılı kayıtları inceleyerek, tanımladığınız riskin çıkma olasılığını % cinsinden tahmin etmeniz gerekmektedir. Örneğin “A tedarikçi firması geçtiğimiz 10 mal gönderiminin 2 tanesini geciktirmişti; bu durumda bir sonraki mal talebimizde malın gecikme olasılığı %20’dir” diyebiliriz.

Bundan sonrası oldukça basittir. Kategorize ettiğiniz her risk için Etki Gücü ve Olasılık değerlerini çarparak, risklerin ayrı ayrı Tehdit Indekslerini bulabilirsiniz. En yüksek değeri alan projenizi en çok tehdit edecek olan risktir. Büyükten küçüğe göre sıralayarak, hangi riske öncelikle tedbir almanız gerektiği ortaya çıkacaktır.

Son söz; Risk Değerlendirme Toplantıları, proje devam ettiği sürece en fazla 15 günde bir yapılıp, eski riskler çıkarılmalı, yenileri eklenmeli ve Tehdit Indeksleri tekrar değerlendirilmelidir.

WBS Oluşturma – PMBOK

Bugünkü yazımda PMI’ın en fazla önem verdiği konuya odaklanmak istiyorum. Bütün PMBOK versiyonlarında WBS’in her zaman ayrı bir yeri vardı ve hatta PMP sınavına hazırlananlara “eğer şıklarda WBS’i görüyorsanız o şıkkı işaretleyin, ” denirdi.

Bu kadar önem verilen WBS (Work Breakdown Structure – İş Kırılım Yapısı) PMBOK’ta Kapsam Yönetimi Bilgi Alanında ve Planlama süreç grubu içinde yer almaktadır. Tanım olarak da; Projeyi daha kolay yönetmek amacıyla projeyi teslimat odaklı düşünerek, bölümlendirme (ayrıştırma) işlemi olarak bilinir.

• Projenin bütün kapsamı oluşturulur ve özetlenir.

• İş ayrışım yapısı oluşturma sürecinde projenin teslimatları (deliverables) oluşturulur.

• WBS’te olmayan iş, proje kapsamı dışında sayılır.

• Projenin kapsamının netleşmesini sağlar.

WBS;

• Tarihler içeren bir “Proje takvimi” veya “Proje planı” değildir.

• İşler arasındaki bağımlılıkları (dependency) asla göstermez.

Neye İhtiyacımız Var? (Girdiler)

Proje Tanımlama Dökümanı ve Gereksinim Dökümanı projenin ana aşamalarının belirlenmesi için elde tutulmalıdır. Böylece ayrıştırma işleminde hem projenin yönetimsel politikası hem de ortaya çıkacak ürünün yapısına bağlı olarak o projede ne detayda bir ayrışım gerçekleştirileceğine karar verilir.

Nasıl Yapılır? (Teknikler)

Tek yöntem ayrıştırma çalışmasıdır. Ayrıştırma çalışması ise yukarıdan aşağıya düşünülerek, proje öncelikle hangi aşamalardan geçeceğine karar verirlir. Daha sonra her bir aşama daha küçük iş paketlerine bölümlendirilir. PMI’a göre iş paketleri bir aktivite yerine geçmez, İş Paketleri, aktivite gruplarıdır. Aktivitelerin tanımlanması ise ileriki yazılarımda yer vereceğim bir konu olacaktır.

Önemli olan nokta; ayrıştırmada iş paketlerinin belirli, elle tututlur, gözle görülür ara çıktılara ulaşmasıdır. Böylece projenin ara hedeflerini konulmuş olur ve aşamaların başarıyla tamamlanıp, tamamlanmadığı kolayca ve objektif olarak değerlendirme imkanı doğar.

Ne Çıkar? (Çıktılar)

Proje aşamalandırılmış ve her aşamanın neticesinde hangi ara ürüne (rapor, ara mamül, onay, laboratuvar sonucu vs.) ulaşılacağı net olarak belirlenmiştir. Proje tarafları hangi aşamanın hangi sonuca ulaştığında başarılı olarak değerlendirileceğini biliyorlardır.

WBS oluşturma esnasında Proje Tanımlama Dokümanı (Kapsam Tanımlama) tekrar revize edilebilir. Bu revize işlemiyle birlikte Proje Kapsamı artık netleşmiş olur (Scope Baseline) ve bundan sonraki tüm detaylı planlama çalışmaları, proje taraflarının mutabık kaldıkları bu Proje Kapsamı referans alınarak, yapılacaktır.

Kapsam Tanımlama

Projenin veya ürünün detaylı tanımını geliştirme sürecine Kapsam Belirleme denmektedir. Bu süreç PMBOK’ın Kapsam Yönetimi Bilgi Alanında ve Planlama Süreç Grubunda yer almaktadır.

Proje başarısı için kısıt ve varsayımların belirlendiği projenin ana aşamalarının ve kilometre taşlarının yer aldığı bir döküman üzerinde proje tarafları mutabakat sağlamalıdır. Kapsam Belirleme proje planlama sürecinde kısıt veya varsayımların değişmesiyle tekrar gözden geçirilmek ve revize edilmek durumunuda kalabilir.

Neye İhtiyacımız Var? (Girdiler)

Proje Başlatma Belgesi ve Gereksinim Dökümanı, Kapsam Belirlemek için gerekli olan ön koşul dokümanlardır. Projenin hem kabul edilmiş olması hem de proje paydaşlarıyla müzakereler yapılarak, genel olarak ihtiyaçların toplanmış olması gerekmektedir.

Nasıl Yapılır? (Teknikler)

Ürün Analizi yapılarak proje taraflarını ihtiyaç duydukları ürünün fonksiyonlarını belirleme işlemi gerçekleştirilebilir ayrıca teknik bilgi birikimi fazla olan uzman kişilerin yardımıyla alternatif ürün seçenekleri oluşturulur.

Ne Çıkar? (Çıktılar)

Daha teknik gözle bakan kişilerin katılımıyla projenin amacı, proje teslimatları, kabul kriterleri, çerçevesi, kısıtları, varsayımları ortaya çıkarılmış olur. Bu ifadelerin yazılı olduğu belge Proje Tanımlama Dokümanı olarak bilinir. .

PMI’a Göre Matris Organizasyonlar – PMBOK

Bir şirkette fonksiyonel yapılanmanın yanısıra projelerin yönetilmesi için de ayrı bir takım oluşturma işlemi gerçekleştiriliyorsa, bu durumda şirkette Matris Organizasyonun varlığından söz edilebilir.

PMI’a göre Matris Organizasyonlar üçe ayrılır.

Zayıf Matris Organizasyonlarda proje koordinasyonu, departman yöneticilerinden alınmış ve takım üyelerine bırakılmıştır. Bu tarz bir organizasyonda Proje Yönetimi çok etkin değildir. Proje takımını oluşturan kişilerden hiçbirisi Proje Yöneticisi ünvanını taşımaz. Proje Asistanı veya Proje Koordinatörü vasıflarıyla projenin gidişatı konusunda üst yönetimi bilgilendiren bir kişi mevcuttur.

Dengeli Matris Organizasyonda ise Proje Takımına, Proje Yöneticisi liderlik eder. Böylece projenin başarısından sorumlu ve ekibi yönlendirme yetkisine sahip bir kişi tanımlanmıştır. Proje Yönetimi’nin önem kazandığı ve Proje Yönetimi kültürünün oluştuğu şirketlerde etkili bir yönetim tarzıdır.

Güçlü Matris Organizasyonda ise Proje Yöneticileri’nin temel görevi proje yönetmektir. Proje Yöneticileri, Proje Ofisi’ne bağlı olup, Proje Ofisi’nin de bir departman yöneticisi bulunmaktadır. Böylece proje yöneticilerinin diğer birimlerle çalışması esnasında yaşanan kaynak kısıtı sorunu bu şekilde azaltılır. Özellikle projelerin şirket için hayati önem taşıdığı şirketlerde etkin olarak kullanılır.

PMI’a Göre Fonksiyonel Organizasyon

Bir ürünün çok fazla değişikliğe uğramadan üretildiği ortamlarda etkin olarak kullanılan organizasyon yapısıdır. Şirketin operasyonel işlerini yerine getirecek departmanlar tanımlanmıştır. Departmanların yetki ve sorumlulukları belirlidir. Personel, o departmanın ihtiyaç duyduğu uzmanlığa sahip kişilerden oluşur.

Bu organizasyon tipinde kurum genelinde yapılan projelerin idaresi ve kontrolü proje yöneticilerindedir.

Fonksiyonel organizasyonlarda emir-komuta zinciri belirgindir, kişiler bir uzmanlık alanında gelişme gösterirler, sorumluluk ve yetki alanlarında çok fazla çatışma olmaz.

Buna karşılık departman yöneticileri hem idari işleri hem de projeleri yönetmeleri gerektiği için iş yükleri artar. Projeler, departman işlerinin ardına atıldığından sürekli ötelenir. Projeleri üstlenen birey veya birim açıkça tanımlanmadığından projeler sürüncemede kalır ve etkin ilerleme kaydedilemez.

Üniversiteli Gençlere Tavsiyeler

İçinde bulunduğumuz dönemde Proje Yönetimi çok önemli hale geldi. Gelecek çok daha proje bazlı çalışmayı zorunlu kılacak.

Yani okuldan mezun olduktan sonra hangi sektörde çalışacağınız artık önemli değil; Her durumda projelere dahil olmanız, sonra da projeleri yönetmeniz istenecektir. Bu yüzden, boşa zaman geçirmeden Proje Yönetimine öğrencilik yıllarınızda önem vermenizi tavsiye ederim.

* PMI’yı tanıyın. Kütüphanenizde PMNetwork Dergisi geliyorsa mutlaka takip edin.

* PMBOK adlı kitabı mezun olmadan önce mutlaka okumuş olun.

* Proje Yönetimi Bilgi Alanlarının neler olduğunu öğrenmiş olun. İçeriğini bilin.

* Proje Yönetimi üzerine geliştirilen metodların neler olduğunu öğrenin. (PRINCE2, Agile, Scrum, Kanban)

* Microsoft Project programını kullanmayı mutlaka öğrenin.

* Stajlarınızda projelere dahil olun.

* Bitirme ödevinizi mutlaka proje yönetimi üzerine alın..

İş aramaya başladığınızda tecrübesiz olduğunuz için iş bulmanız zor olacaktır fakat öğrencilik yıllarınızda proje yönetimi üzerine yapacağınız her türlü etkinlik size avantaj sağlayacaktır.

PMI’a Göre Proje Bazlı Organizasyon – PMBOK

Proje bazlı organizasyonlarda Proje Yöneticilerinin Yetki ve Sorumluluk alanları oldukça geniştir. Bir şirketin proje bazlı organizasyon tipinde faaliyet göstermesi projelerin kurum içindeki önemiyle yakından ilgilidir. Eğer şirket temel kazancını proje yaparak kazanıyorsa, bu durumda doğal olarak, proje bazlı çalışmak zorunda ve organizasyonu da proje bazlı kurgulamak zorundadır.

Bu organizasyon tipinde kontrol ve yönetim, proje yöneticilerinde olduğu gibi çalışanlar arasında hedef odaklı çalışma alışkanlığı doğmuştur. Buna karşılık, proje yöneticileri çok fazla idari süreçlere dahil olmak zorunda kalabilirler. Ayrıca çalışanlar da tek bir konuda uzman olmaktan uzaklaşırlar hatta her işi yapan kişiler haline dönüşebilirler.

Uzmanlığı olan kişiler için de özelikle şirketteki proje miktarı azalması durumunda, kaynakların verimsiz kullanılması sorunu ortaya çıkar.

Project Server – Proje Merkezi ve Kurumsal Projeler

Project Server programından Üst Yönetimin özellikle beklentisi, şirket içindeki projelerin bir arada görülebileceği bir ekran yapısına ulaşmaktır.

Proje Yöneticilerimiz, MS Project Prof.2007 üzerinden hazırladıkları proje planlarını yayınlamak için File menüsünden – Publish komutuna basmaları yeterlidir. Üst Yönetim, herhangi bir projeye müdahale etmeden, projelerin genel durumuyla ilgili bilgileri Project Server 2007 üzerinden görme imkanı bulacaklardır.

Üst Yöneticimiz, kendi kişisel Windows hesabıyla Project Server ekranını açtığında sol kenardaki menülerden Project Center ifadesine tıkladığında PY’ler tarafından yayınlanan bütün projeler gözükecektir. Bu projeler farklı kategorilere göre sınıflandırılabilir. Örneğin; Ar-Ge, Satınalma, IT, Tedarikçi Geliştirme, Bakım, İyileştirme vb. Bunun yanı sıra üst yönetim projelerin genel bilgilerini (süre, başlangıç, bitiş) görebileceği gibi maliyet, adam*gün, planlanan ve gerçekleşen arasındaki sapma miktarları gibi deayları da incelemesi mümkündür.

MS PRoject Server

Proje Yapmak mı, Proje Yönetmek mi?

Hepimizin bildiği gibi Proje Yöneticisi projenin çıktılarından sorumludur. Proje Yöneticiliği pozisyonu temelde bu amaç için oluşturulmuştur. Bu çerçevede özellikle projenin planlanması, uygulaması, kontrolü ve kapanışı süreçlerinden PY sorumludur. Fakat bu durum PY’nin proje içindeki işleri yapması anlamına gelmez.

Proje Yönetmek tam zamanlı bir iş olduğunda proje yöneticisinden teknik analiz yapmasını , tasarım, üretim, test gibi işleri beklemek ve istemek projenin yönetim fonskioynuun sekteye uğramasına sebep olur. Eğer PY, teknik detaylara fazlasıyla gömülürse yukarıda saydığımız planlama, uygulama, kontrol süreçlerine zaman bulamaz ve projeyi yönetmekten çok , projeyi yapmaya odaklaır. Proje Yöneticiliği özellikle farklı talepleri olan proje taraflarının ihtiyaçlarını, belirli bir zaman ve bütçe içinde, mutabık kalınan bir kapsam dahilinde ortaya çıkarmak amacıyla vardır. Bu çerçevede PY özellikle koordinasyona odaklanmalı ve planlardaki herhangi bir değişikliğin projenin bir başka tarafını nasıl etkilediğini entegre (bir bütün) olarak düşünüp, yansımalarını çok hızlı biçimde etkilenecek kişilere, üst yönetime, sponsora, vs. haber vermelidir. Bu yüzden PY, proje için ayırdığı zamanının ağırlıklı bir bölümünü İLETİŞİMe odaklanarak geçirmelidir.

Proje içinde yaşanan iletişim sorunları pek çok projenin başarısızlık sebebidir bu yüzden, iletişim yönetimine özel bir önem vermek gerekir; Yanlış anlama, yanlış anlatma, bilgi vermeme, eksik bilgi verme, yanlış yorumlama vb. gibi sebeplerden pek çok projede gecikme veya kalite düşmesi yaşanır.

Araştırmalar, projelerdeki başarısızlığın arkasındaki %60’lık payın, iletişimin etkin yönetilmemesinden kaynaklandığını göstermektedir.

Projeden Vazgeçmek için 7 Sebep

Bütün projeler başarıyla sonuçlanmaz.

Projeyi durdurmak, iptal etmek gibi seçenekleri düşünmek de proje yönetimi içinde ele alınır.

Aşağıdaki durumlar, projenin devam etmesinin anlamsız olduğu anlardır. Unutulmaması gereken şey; Proje başarısızlıkla kapatılsa bile projeden öğrenilen derslerin gelecekteki proje yöneticileri için kayıt altına alınması gerektiğidir. Özellikle projenin hangi şartlar altında başarısızlığa uğradığı açıkça belirlenmelidir ki gelecekte benzer bir projede şartların karşılaştırılma imkanı olsun.

İlgi Azalması Varsa : Başlangıçta projenize karşı çok büyük ilgi ve alaka duyulmuş olabilir fakat zamanla önceliklerin değişmesinden dolayı sizin projenize olan ilgi azalmıştır. Özellikle yönetim desteğinin azalması ile projeye olan ihtiyaç gözden geçirilmelidir. Rekabet, piyasa şartları, müşterinin değişen istekleri, projenin bir zaman sonra varlığını sorgulama sebebidir.

Projenin Bitiş Tarihi Sürekli Erteleniyorsa: Özellikle, yeni gelen projelerden dolayı, ilgili proje her defasında öteleniyor, yeteri kadar kaynak desteği alamıyor ve sürekli erteleniyor ise bu projenin varlığı da sorgulanmalıdır. 6 ay diye başlayıp, seneler süren projelerde bir şeylerin yanlış gittiği görülmelidir. Bitiş tarihi bir kısıt olmasa bile, proje bütçesi açıkça masaya yatırılıp, harcanan kaynağın farklı noktalara kaydırılması gerektiği üst yönetime aktarılmalı ve projenin esaslı bir şekilde hangi şartlar altında ele alınacağı sorgulanmalıdır.

Risklerin Fazlalığı: Bazı projelerde riskler oldukça yüksektir. Risklerin yönetimi bütün paydaşlara aittir. Bazı şirketlerde tüm risklerin sorumluluğu ve yönetimi proje yöneticisine bırakılır ve yaşanan tüm olumsuz gelişmelerden proje yöneticisi sorumluymuş gibi davranılır.

Proje Paydaşlarındaki Uzlaşmazlık: Bazen proje paydaşları ortak bir hedef üzerinde hem fikir olamaz. Güç çatışmaları projenin ilerlemesine engel olabilir. Paydaş sayısının artması çatışmaların artmasında en önemli etkendir. Eğer tarafların çıkarları ortak bir noktada birleşmiyorsa projenin varlığı sorgulanmalıdır. Böyle durumlarda proje kapsamına çok dikkat etmek gerekir. Proje paydaşlarının artması kapsamın genişlemesine, hedeflerin gerçekçilikten uzaklaşmasına sebep olabilir.

Müşteri Tatmin Edilemezse: Başlangıçta ne istediğini bilmeyen veya doğru anlatamayan müşteri, ara ürünler ortaya çıktıkça isteklerini şekillendirmeye başlar. İstekler şekillendikçe projenin kapsamı, baştaki duruma göre değiştirecektir. Eğer projede kapsam yönetimi yapılıyorsa sorun yoktur fakat yapılmıyorsa, her gelen istek projeye sorgusuz sualsiz dahil ediliyorsa bu durumda projenin bitmesi de beklenemez.

Proje Paydaşlarında Değişiklikler: Bir projede paydaşlarda herhangi bir değişiklik olması projenin şekil değiştirmesine sebep olabilir. Üst yönetim, müşteri veya proje ekibindeki değişikliklerden dolayı projeye olan destek, talepler, ekibin performansı değişikliğe uğrar. Proje paydaşlarındaki değişiklik hızlı ve çok olursa projenin yönetilmesi imkansız hale gelir. Böyle bir durumda proje yöneticisi daha durağan bir paydaş yapısına ulaşana kadar projenin ertelenmesini isteyebilir aksi takdirde harcanan zaman ve parasal kaynak boşa gidecektir.

Yatırılan Parasal Miktarın Büyüklüğü: Bazı projelerde belirli bir aşamaya kadar çok fazla para harcandığı için vazgeçilemez olarak nitelendirilir. Eğer proje sonuçlar ile ilgili kuşkular var ise batık maliyet kurtarılamaz fakat batık maliyetin büyümesi önlenebilir.