Aylık arşivler: Eylül 2020

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ı

Paylaşın:
“5onlineegitim”

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.

Paylaşın:
“5onlineegitim”

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.

Paylaşın:
“5onlineegitim”

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
Paylaşın:
“5onlineegitim”

Proje Yönetiminde Kusurların Giderilmesi, Düzeltici ve Önleyici Eylemler

Kusurların Giderilmesi

PMBOK®’a göre uygunsuz ürünün ya da ürün bileşeninin değiştirilmesi için yapılan bir aktivitedir. Proje esnasında bir kusur oluştuğunda giderilmesi gerekir. Oluşan kusur üründe ve düzeltilemiyor ise değiştirilmesi gerekir.

Ürün ve servis kalite gereksinimlerini karşılamadığında yapılır.

Düzeltici Eylem

Proje çalışmaları performansını proje yönetim planıyla uyumlu hale getirmek amacıyla yapılan bir aktivitedir. Hatanın sebebinin veya kendisinin tekrar etmemesi için yapılan eylemdir. Örneğin tetkiklerde bir hata buldunuz ve düzelttiniz. Hatanın sebeplerine bakıp tekrar etmemesi için kalıcı çözüm bulmanız gerekir. Düzeltici eylemler problemin köküne inip tekrar etmemesini sağlamaktır.

Reaktif bir süreçtir, problem oluştuğunda hareket geçilir ve sapmalar kontrol altında tutulmaya çalışılır.

Önleyici Eylem

Proje çalışmalarının geleceğe yönelik performansının proje yönetim planıyla uyumlu hale getirilmesini sağlayan bir aktivitedir. Gelecekteki hataları önlemeye yönelik eylemlerdir. Örneğin bir hatanın oluşacağını düşündüğünüz bir süreçte ek kontrol noktaları ya da önlemler geliştirebilirsiniz.

Proaktif bir süreçtir, problem yaşanmadan harekete geçilir.

Düzeltici eylem problem oluştuğunda tekrar etmemesi için, önleyici eylem problem gerçekleşmeden önlemek için yapılır.

Önleyici ve düzeltici eylemler, projenin temel çizgilerinden sapmamasını güvence altına almak için gerçekleştirilirler.

Paylaşın:
“5onlineegitim”

Proje Yönetiminde Zaman Çizelgesi Sıkıştırma – Paralel Çalışma ve Kaynak Yükleme

Yaşanan problemler, değişiklikler, ek talepler projenin bitiş tarihini öteleyebilir. Bu tip durumlarda projenin hedeflenen tarihte bitmesi için zaman çizelgesinin sıkıştırılması gerekir.

Projelerde gecikmeler aşağıdaki sebeplerle oluşabilir;

  • Gerçekçi olmayan zaman çizelgeleri
  • Kaynakların yetersizliği veya kaynak önceliklerinin değişmesi
  • Beklenmedik problemler, ek talepler, değişiklikler

Bazen projede her şey yolunda giderken süre kısılmak istenebilir;

  • Müşterinin daha erken bir tarihte tamamlanma istemesi
  • Projenin erken tamamlanmasının yaratacağı fırsatlar
  • Rakiplerin önüne geçmek, avantaj yaratmak

Paralel Çalışma

Kritik yolda yer alan aktivitelerin paralel gerçekleştirilip gerçekleştirilemeyeceğine bakılır. Kritik yolda yer almayan aktivitelerin bollukları olacağından, paralele çekmek sadece bolluklarını artıracaktır.

Paralel çalışma ile birden fazla kritik yol ortaya çıkabilir ve risk artar.

Paralel Çalışma ek maliyet yaratmaz. Aynı anda birden fazla iş yapılmasının yönetimi zordur ve risklidir.

Eğer gerçekçi olmayan paralel çalışma yapılırsa, işlerin yeniden yapılma olasılığı vardır.

Kaynak Yükleme

Projeye ek kaynak atayarak zaman çizelgesinin sıkıştırılmasıdır.

Kritik yola bakılarak, kaynak etkin aktivitelere ek kaynak atanır. Bazı aktiviteler zaman etkindir(duvarın boyasının kuruması vb.), bu aktivitelere ek kaynak yüklenmesi süreyi değiştirmez. Kaynak yüklemede en az maliyet yaratacak alternatifler değerlendirilmelidir.

Kaynak yükleme ile birden fazla kritik yol oluşabilir ve riski artırır.

  • Kaynak yükleme;
  • Fazla mesai verme
  • Ek kaynak atama

Ödüllerle ekibin motivasyonunu artırma gibi yöntemlerle uygulanabilir.

Paralel Çalışma ve Kaynak Yükleme Arasındaki Farklar

  • Paralel çalışmada aktiviteler yeniden planlanır, paralel veya kısmen paralel gerçekleştirilir. Kaynak yüklemede planlama müdahale edilmez aktiviteye ek kaynak kaynak atanır.
  • Paralel çalışma ek maliyet getirmez, Kaynak Yükleme getirir.
  • Paralel Çalışma riski yükseltir, Kaynak Yüklemenin risk açısından büyük etkisi yoktur.

Ne Zaman Paralel Çalışma veya Kaynak Yükleme Tercih Edilmeli?

Duruma ve gereksinimlere bağlı olarak değişir. Müşteri projenin erken bitmesini istiyor ve maliyetine katlanacağını ifade ediyorsa Kaynak Yükleme yapılabilir.

İstenmeyen sebeplerle proje gecikecekse ek maliyet yaratmaması açısından Paralel Çalışma tercih edilebilir.

Sözleşmede gecikme sebebiyle oluşabilecek bir ceza varsa Kaynak Yükleme maliyeti ile karşılaştırılır, cezadan daha az maliyetliyse Kaynak Yükleme yapılabilir.

Firmanın itibarı söz konusu ise Kaynak Yüklemenin maliyetine katlanılabilir.

Maliyet yaratmaması açısından Paralel Çalışma tercih edilebilir.

Paylaşın:
“5onlineegitim”

Proje Yönetiminde Kapsam Kayması ve Altın Kaplama

Eğitimlerimde, “Projeye bazen elma diye başlarsınız karnıbahar şeklinde biter” diye söylüyorum. Proje bittiğinde, başlangıçtaki gereksinimler ve hedefler çok değişebilir.

Projenin müşterisi her isteğinin gerçekleştirilmesini isterken projeyi planlayanlar, yürütenler, kontrol edenler ve hatta yatırım yapanlar için aynı şeyi söyleyemeyiz.

Özel hayatımızda gömlek almak için çıktığımız alışverişten gerekli gereksiz başka şeyleri de alıp dönebiliyoruz ve bu durumu çoğu zaman önemsemeyiz.

Projelerde Kapsam Bildirimi oluşturulduktan gelen ek talepler, değişiklikler gelmeye başlar. Projenin sonucunda ortaya çıkacak ürün, servis ve hizmet değişir.

Kapsam Kayması

Ürün veya proje kapsamının kontrolsüz bir biçimde değişmesidir.

Neden olur?

  • Müşteri müdahaleleri
  • Kapsam Bildiriminin eksik olması
  • Değişiklik kontrol sisteminin olmaması
  • Ekip üyeleri arasındaki iletişimsizlik
  • Proje dışı etkenler. Pazar değişimleri, yasal düzenlemeler vb.

Kapsam kayması proje için sağlıksız bir durumdur ve kaçınılması gerekir. Düzgün bir gözden geçirme olmaksızın yapılan değişiklikler projenin ileri safhalarında daha büyük problemlere yol açarlar. Değişikliğin yarattığı problemler, yeni değişikliklerle giderilmeye çalışılır.

Kapsam kayması zaman çizelgesinin gecikmesine ve bütçe aşımlarına sebep olur. Çok fazla kapsam kayması projenin iptaline sebep olabilir.

Örnek

Bir web sitesi projesine başlayan ekip, müşteriden gelen ek talepleri karşılamak için önceden yaptığı tüm çalışmaları değiştirmek zorunda kalabilir. Taahhüt edilen zamanı tutturmak için hızlı gidilmeye çalışılır, istenmeyen hatalar çıkar, engellenmek istenen zaman kaybı daha fazla gerçekleşir.

Kapsam Kaymasından Nasıl Kaçınılır?

Kapsam Kaymasından tam anlamıyla kaçınamazsınız ancak;

  • Proje Müşterisinin doğrudan ekip üyeleriyle değil Proje Yöneticisi ile iletişim kurmasını sağlamalısınız.
  • Kapsam Bildirimini tam olarak hazırlamalısınız.
  • Değişiklik Kontrol Sistemi kurmalısınız. Değişiklik taleplerini düzgün bir gözden geçirme ve onay sürecine sokmalısınız.
  • Ekip üyeleri arasında iyi bir iletişim kurulmasını sağlamalı, cesaretlendirmelisiniz.
  • Projeyi düzgün bir şekilde takip etmeli, gelişmeleri izlemelisiniz.

Altın Kaplama

Kapsam Bildiriminde yer almayan ek özelliklerin, fonksiyonların müşteri onayı alınmaksızın proje ekibince yapılmasıdır.

Proje Yöneticisi veya proje ekibi müşteriden ek ücret talep etmeden ve müşteri isteği olmadan bazı ek işler yaparlar. Müşterinin istememesine rağmen hoşuna gideceği düşünülen bu ek özellikler gelecekte problem yaratabilir. Bazı durumlarda müşteri istemediği bu özellikleri reddedilebilir.

Genellikle yazılım projelerinde ekibini kendi becerilerini göstermeye çalışması ya da müşteriyi mutlu etmek için yapılan çalışmalar olarak ortaya çıkar.

Neden Olur?

  • Ekip üyesi kendi becerilerini müşteriye veya proje yöneticisine göstermek isteyebilir.
  • Proje yöneticisi müşteriden veya üst yönetimden artı puan toplamak istiyor olabilir.
  • Müşterinin ilgisini başka yere çekmek için.

İyi gibi durmasına rağmen Altın Kaplama uzun vadede ek maliyetler yaratması açısından istenmez. Bir proje böyle yapılması gelecekteki projelerde müşterilerin aynı beklentileri koymasına sebep olabilir.

Örnek

Web sitesi projesinde müşterinin istememesine rağmen taksit özelliğinin eklenmesi iyi de karşılanabilir, müşteri öyle bir özelliği istemiyor da olabilir.

Altın Kaplamadan Nasıl Kaçınılır?

Kapsam Kaymasından kaçınmaktan daha kolaydır;

  • Proje Ekibinin onaylanmamış hiç bir özelliği geliştirmemesini istersiniz.
  • Proje Yöneticisi olarak Kapsam Bildiriminde yer almayan hiç bir ek çalışmayı, gözden geçirme ve onay süreci olmadan yapmazsınız,
  • Proje ekibi ile düzgün iletişim kanalları kurarsınız.
Paylaşın:
“5onlineegitim”

Proje Yönetiminde Varsayımlar ve Kısıtlar

Bir projeyi hayata geçirmek ile ilgili varsayımlarda bulunurken kısıtlarla sınırlıyızdır. Normal Koşullar Altında (NKA) diye yola çıktığımızda bazı olumsuzlukların olabileceğini düşünür, olmayacağını varsayarak hareket ederiz.

Planlama aşamasında bir çok parametre varsayım ve kısıtlardan etkilenir. Ör. Proje Risk Yönetimi Planı varsayımlara dayalı olarak hazırlanır. Varsayımlar sürekli gözden geçirilmediğinde proje çıktıları olumsuz etkilenir.

Varsayımlar

Gelecekte doğru olacağına inandığımız konulardır. Bilgi, deneyim ve eldeki bilgiler doğrultusunda yapılır. Bazı durumların gelecekte olacağını veya olmayacağını varsayarız. Örneğin proje ekibinden birinin ayrılabileceği varsayımıyla planlarımızı ve stratejilerimizi belirlememiz gerekebilir.

İhtiyacımız olan kaynakların sağlanacağını, tedariklerin gecikmeyeceğini, müşteriden ek isteklerin gelmeyeceğini, toplantıya herkesin katılacağı vb. varsayımlarda bulunabiliriz. Tüm bunlar risklerin belirleyicisi olacaktır.

Kısıtlar

Maliyet, zaman, kaynak, kanun ve kurallar gibi projeyi sınırlandıran faktörlerdir. Projenin bu kısıtlar altında gerçekleştirilmesi gerekir. Kısıtların olabildiğince erken netleştirilmesi çok önemlidir.

PMBOK®, 6 adet proje kısıtından söz eder: kapsam, zaman çizelgesi, maliyet, kalite, kaynak ve risk. Kapsam, zaman çizelgesi ve maliyet “Üçlü Kısıtlar” olarak ta bilinirler.

Kısıtlar iki tipte olabilir;

  • İş Kısıtları
  • Teknik Kısıtlar

İş Kısıtları

Zaman, bütçe, kaynak vb. şirket kaynaklı kısıtlardır.

Teknik Kısıtlar

Tasarımı etkileyen teknik özellikler, kanun ve kurallar ile ilgili uygulama yönetmelikleri örnek verilebilir.

Kısıtlar kontrolünüz dışındadır. Müşteri, şirket veya devlet tarafından getirilmiş olabilir. Örneğin, 1.12.2020’de projenin tamamlanması gerekmektedir, 3 adet mühendis vardır, ISO XXXXX standartlarına uyulacaktır vb.

Projeyi etkileyebilecek varsayımların analiz edilmesi ve kısıtların netleştirilmesi çok önemlidir. 

Paylaşın:
“5onlineegitim”

Proje Yönetiminde Program Değerlendirme ve Gözden Geçirme Tekniği (PERT)

Program Değerlendirme ve Gözden Geçirme Tekniği (Program Evaluation and Review Technique – PERT) aktivitenin bilinen kesin bir süresi olmadığında kullanılır. 1957 yılında Amerikan Deniz Kuvvetleri tarafından geliştirilmiştir.

Geçmişe dayalı veriler olmadığında özellikle büyük ve karmaşık projelerde zaman çizelgesinin belirlenebilmesi ve süre tahminlerinin yapılması için kullanılan istatistiksel yöntemdir.

Kritik Yol Yöntemi ile farklılıklar içerir;

  • Kritik Yol Yöntemi (Critical Path Method-CPM) aktivite odaklıdır, PERT olay odaklıdır
  • CPM’de süreler bellidir, PERT’te kesin değildir.
  • CPM’de aktiviteler düğüm üzerinde, PERT’te ok üzerindedir. PERT’te kilometre taşları düğüm şeklindedir.
  • PERT sadece bitiş-başlangıç ilişkilerini içerir, CPM her tür ilişkiyi (Başlangıç-Başlangıç, Bitiş-Bitiş vb.) içerir.
  • Düğümler CPM’de dikdörtgen, PERT’te daire şeklindedir.

PERT metodolojisi büyük ve karmaşık projelerde zaman faktörü maliyet faktöründen daha önemli olduğunda tercih edilir. Araştırma tipindeki projelerde özellikle ne zaman sonuçlanacağı belli olmayan aktivitelerin olduğu projelerde kilometre taşları temelinde işlerin planlanmasında tercih edilir.

Aktiviteler için üç tahmin yapılır;

  • En olası süre
  • İyimser Süre
  • Kötümser Süre

En Olası Süre (Tm)

En yüksek olasılıkla aktivitenin gerçekleştirileceğinin düşünüldüğü süredir.

İyimser Süre (To)

En iyi koşullar altında aktivitenin gerçekleştirileceğinin düşünüldüğü süredir.

Kötümser süre (Tp)

En kötü şartlar altında aktivitenin gerçekleştirileceğinin düşünüldüğü süredir.

PERT Formulü

PERT Tahmini = (To + 4Tm + Tp)/6

Standart Sapma = (Tp – To)/6

PERT’in Faydaları

  • Geçmişe dair zaman çizelgesi verilerinin çok az ya da hiç olmadığı durumlarda çok kullanışlıdır
  • Planlamayı kolaylaştırır.
  • Kritik Yolu gösterir.
  • Projedeki belirsizliği ve riski azaltır.
  • Daha kesin proje tamamlanma tarihi bulunmasını sağlar.
  • Yönetimin kaynak optimizasyonu yapmasına destek olur.

PERT’le İlgili Dikkat Edilmesi Gerekenler

  • PERT tahminin kesinliği, tahminlerin güvenirliğine bağlıdır.
  • Kritik yol değişiklikleri tam olarak görülemeyebilr.
  • CPM gibi tüm kaynakların proje için uygun olduğu varsayılır.
  • Güncelleme ve düzenleme zaman ve efor ister.

Örnek

Bir aktivite en iyi ihtimalle 2 günde, en kötü ihtimalle 10 günde tamamlanabilecektir. En olası beklene tamamlanma süresi 3 gündür.

PERT Tahmini = [En iyi + 4X(Olası) + En kötü]/6

= [2 + 4X3 + 10]/6
= [2 + 12 + 10]/6
= 24/6
= 4 gün

Standart Sapma = (Kötümser-İyimser)/6
= (10 – 2)/6
= 8/6
= 1.3 gün

Paylaşın:
“5onlineegitim”

Proje Yönetiminde Maliyet Geri Ödemeli ve Süre-Malzeme Sözleşmeleri

Maliyet geri ödemeli sözleşmeler

Satıcıya tamamlanan çalışmalar için gerçekleşen maliyetlerin ödendiği ve ayrıca satıcının karına karşılık belli bir ücret ödemesi yapılan sözleşmelerdir.

Kapsamın belirsiz, riskin yüksek olduğu durumlarda tercih edilir. Alıcı tüm maliyeti öder ve riski üstlenir. Gereksinimlerin net olmaması kapsam kayması riskini ve olası maliyetleri artırabilir. Sözleşme ile sınırlandırılması ve alıcının sürekli kontrol edilmesi gerekir.

Maliyet geri ödemeli sözleşmeler dörde ayrılır;

  1. Maliyet Artı Sabit Fiyat Sözleşmeleri (MASFS)
  2. Maliyet Artı Teşvik Ücreti Sözleşmeleri (MATÜS)
  3. Maliyet Artı Ödül Sözleşmeleri (MAÖS)
  4. Maliyet Artı Maliyetin Yüzdesi Sözleşmeleri (MAMYS)

Maliyet Artı Sabit Fiyat Sözleşmeleri (MASFS)

Satıcının maliyetleri performansına bakılmaksızın geri ödenir ve ayrıca satıcı başlangıçta belirlenen sabit bir ücret alır. Alıcı tüm riski üstlenir.

Yüksek riskli ve kimsenin teklif vermeye yanaşmadığı projelerde tercih edilebilir. Satıcıyı risklerden korur.

Örnek: Toplam Maliyet + 15,000 TL

Maliyet Artı Teşvik Ücreti Sözleşmeleri (MATÜS)

Satıcının maliyetlerine ek olarak sözleşmede belirtilen belli performans hedeflerine ulaşması durumunda belirlenmiş bir teşvik ücreti (ödül) alır. Teşvik ücreti (ödül) belirli bir formüle bağlanır.

Risk alıcıdadır ama maliyet artı sabit fiyat sözleşmesinden daha düşüktür. Teşvik ücreti (ödül) satıcının motivatörüdür, daha az maliyetle ya da erken bitirmesi durumunda ödülünü artırır.

Teşvik ücreti çoğu zaman kazanımların, tasarrufların belirli bir yüzdesi olarak belirlenerek alıcı ve satıcı arasında paylaşılır.

Örnek: Proje bütçenin altında biterse kalan bütçenin %10’u satıcıya verilecektir.

Maliyet Artı Ödül Sözleşmeleri (MAÖS)

Satıcıya tüm maliyetleri geri ödenir, tanımlanmış ve sözleşmeye dahil edilmiş geniş ve öznel performans kriterlerine bağlı olarak ek ücret ödenir. 

Teşvik ücreti ile ek ücret arasında bir fark yoktur. Teşvik ücreti bir formüle dayanırken, ek ücret satıcının başarısına göre ödenir.

Örnek: Eğer satıcı tüm kalite kriterlerini karşılarsa 10.000 TL ödenecektir.

Maliyet Artı Maliyetin Yüzdesi Sözleşmeleri (MAMYS)

Alıcı tüm maliyetlere ek olarak tüm maliyetin belirli bir yüzdesi öder. Satıcının daha çok gelir elde etmek için maliyetleri yükseltmesi riski vardır.

Örnek: Toplam maliyet + %10’u

Süre ve Malzeme Sözleşmesi

Satıcının karını da içeren birim iş gücü ya da malzeme ücretleri alıcı ve satıcı tarafından önceden belirlenir, kullanım oranında satıcıya ödeme yapılır. Sabit fiyatlı ve maliyet geri ödemeli sözleşmelerin bir karışımı gibi düşünülebilir.

Genellikle teslimatlar kiş-saat üzerinden hesaplanıyorsa tercih edilir. Uzman, danışman vb. dış kaynak kullanımında tercih edilir.

Sözleşmede aşılmaması gereken limitler belirlenmelidir.

Örnek: Saati 20 TL’den kaynakçı

Sonuç

Sözleşme tipinin seçimi proje yöneticisi için en önemli konulardan biridir. Alıcı için sabit fiyatlı, satıcı için maliyet geri ödemeli sözleşmeler tercih edilir.

Paylaşın:
“5onlineegitim”