Kategori arşivi: Kapsam Yönetimi

Projelerde Geç Fark Edilen Hataları Önlemek

Projelerin son aşamalarında fark edilen hatalar en başa dönülmesine, ciddi zaman ve bütçe kayıplarına yol açabilir. Müşteri beklentilerinin, kapsam doğrulanma ve onaylanma ölçütlerinin, müşteri onay gereksinimlerinin proje başında belirlenmesi gerekir.

Dikkat edilmesi gerekenler;

Projelerde performans gereksinimleri ve onay kriterleri net olarak tanımlanmadığında ek taleplerin ortaya çıkması, hatalarla karşılaşılması kaçınılmazdır.
Projenin teslimatlarını ve sonuçlarını onaylayacak paydaşların belirlenmesi gerekir. Bu paydaşlar projede gerçekleştirilecek aktivitelerin tanımlanması, tahminlerin yapılması ve zaman çizelgesi, bütçe vb. oluşturulması aşamalarında projeye dahil edilmelidirler.
Projelerde test, kontrol vb. süreçler için gerekli ve kaliteli zamanın ayırılması sağlanmalıdır. Gereksinimler nasıl test veya kontrol edileceği prensipleri ile beraber kayda alınmalıdır. Test ve kontrol çalışmalarının performans ve onay kriterlerine göre tasarlanması gerekir.
Gereksinimler, kapsam, kontrol ve testlere ilişkin riskler belirlenmelidir. Belirsizlik ve değişiklik durumlarında kontrol, test ve onay süreçlerinin nasıl etkilenebileceği dikkate alınmalıdır.
Onaylamamanın yaratacağı olumsuz etkiler dikkate alınarak döngüsel veya çevik yaklaşımlarla müşterinin adım adım, parça parça onay vermesi düşünülebilir.
Onay sonrası projenin geri kalanına yönelik ayarlamaların yapılması sağlanmalıdır.

Projelerde Temel Performans Göstergeleri - KPIGökrem Tekir, Savaş ŞakarProjelerde KPI'ları Belirleme ve Ölçümleme

Periyodik gözden geçirmeler ile tamamlanan bölümlerin onayı alınmalıdır.
Prototipler, pilot uygulamalar ve ara teslimatların gereksinimleri karşılaması ve onaya sunulması sağlanmalıdır.
Onay sorumlulularının proje katılımı teşvik edilmeli, test ve değerlendirmelerde aktif rol almaları sağlanmalıdır.
Projede erken uyarı sistemleri kurulmalı (örneğin 2 günden fazla sapma vb.), proje ekibinin ve paydaşların uyarıları dikkate alınmalıdır.
Geçmiş proje deneyimleri ve paydaşlara yönelik bilgiler onay, test, kontrol vb. süreçlere ilişkin deneyimleri yansıtması açısından değerlendirilmelidir.
Geçmiş projelerin onay problemlerine ulaşılmaya çalışılmalıdır.
Paydaş özelinde onayı kolaylaştırıcı yöntem ve araçlar tercih edilmelidir.
Değişiklik süreci dikkatlice ele alınmalıdır. Kabul ve red prensipleri paydaşlarla paylaşılmalı, onaylanan değişikliklerde kontrol, test, onay gibi alanlarda nasıl etkisi olacağı değerlendirilmeli ve gerekli güncellemeler yapılmalıdır.

Proje Ölçütleri ve Ölçüt YönetimiGökrem Tekir, Savaş ŞakarÖlçemediğinizi yönetemez, doğru ölçemediğiniz konularda doğru kararları vermezsiniz.

Küçük Projelerde Resmiyet Gerekli Mi?

Bir Cevap Yazın

Proje Yöneticisinin ve ekibin geçmiş deneyimleri, projeye özgün koşullar dikkate alınarak resmiyetin “yeterince” olması gerekir. Resmiyet, dokümantasyon, bürokrasi vb. olarak düşünülebilir. Büyük projelerde resmiyet kayıpların olma ihtimaline karşı artarken küçük projelerde azalabilir. Hiç olmaması düşünülmemelidir.

Proje büyüklüğü sadece süre veya bütçe olarak düşünülmemelidir. Bazı projeler içerdiği teknoloji veya işlerin hassasiyeti sebebiyle çok karmaşık hale gelebilir, büyük Kabul edilebilir ve resmiyet önemli bir hal alabilir.

Proje Yöneticisi, küçük projelerde, yönetimin ve müşterinin gereksinimlerini, şirket politikalarını dikkate alarak ekibiyle birlikte resmi ve resmi olmayan yöntemler konusunda mutabık kalmalıdır.

Hayatımız Proje - Proje Yönetimi Başvuru KaynağıGökrem Tekir, Savaş ŞakarProje Yönetiminin Temelleri ve Pratik Süreç Başlıkları

Küçük projelerde süreçlerin rahatlatılması, dokümantasyonun azaltılması projenin başarıyla tamamlanması için yardımcı olabilir.

Küçük projelerde başlangıç basitleştirilebilir ama gereksinimler ve kapsam yazılı olmalıdır.

Planlama basitleştirilebilir ama hiç yapılmaması doğru değildir. Örneğin zaman planlamasında MS Project yerine post-it kullanılabilir vb.)

Proje raporlaması basitleştirilebilir, izleme sıklığı azaltılabilir. Sadece raporlama veya toplantı tercih edilebilir. Önemli olan kontrolün kaybedilmemesi olmalıdır.

Yaşanan problemler doğrultusunda resmiyetin artırılması ya da azaltılması düşünülmelidir.

Proje Yönetimi Dokümanları ve UygulamalarıGökrem Tekir, Savaş ŞakarProjelerde kullanılan dokümanlar ve içerikleri, örnek şablonlar, dokümantasyon yönetiminin temel ilkeleri

Projelerde Müşteri Beklentilerinin Başarıyla Yönetilmesi

Bir Cevap Yazın

Basitçe söylemek gerekirse, projenin iç veya dış müşterisini “tanıyorsanız” başarıyla yönetebilirsiniz. Müşteri beklentilerini başarıyla yönetmek için yapmanız gerekenler aşağıdaki gibidir;

Projenin başından itibaren sponsor ve kilit paydaşlarla görüşmeler yaparak müşterinin ne istediği, beklediği, ihtiyaçları konusunu netleştirmekle başlayın.
Varsayımları yazılı hale getirin, müşterinin onayını alın.
Müşteri ile görüşmeler yapın. Görüşmelerde önceden hazırladığınız kontrol listelerini kullanın. Müşterinin emin olup olmadığı konuları not alın.
Müşterinin proje başarı tanımını netleştirin, neyin başarmanız gerektiğini belirleyin.
Müşterinin proje sonucunda ortaya çıkacak servis, hizmet veya sonucu hangi ortamda, kimlerle, ne için kullanacağını öğrenmeye çalışın. Müşterilerin beklentilerini her zaman doğru ifade edemeyeceğini unutmayın. Sizin tecrübeli olduğunuz bir konu müşteri için yeni bir konu olabilir.
Projenizden beklenen sonucu değerlendirebilecek ve tanımlayabilecek doğru kişileri bulmaya çalışın. Müşteri için yeni olan üründe, şirket içinde ne istediğini belirleyebilecek kişileri belirlemek zor olursa geçmiş projelerin müşterileri size yol gösterebilir.
Müşteri deneyiminin yetersiz olduğu durumlarda danışmanlık yapın, yol gösterin. Gelecekteki durumu, pazarı ve gereklilikleri göstermeye çalışın.
Müşteri gereksinimlerini yazılı hale getirdikten sonra onaylatın. Neleri kapsamda olup olmadığı konusunu net olarak aktarın. Zorunlu gereksinimlerin nasıl teslim edileceğini açıklayın. Müşterinin kapsamdaki konuları hayal edemeyebileceğini veya yanlış anlayacağını düşündüğünüz konularda görsel (akış grafikleri, ekran görüntüleri, ürün resinleri vb.) kullanın.
Zorunlu olmayan isteklerin planınızda ne şekilde yer aldığını veya almadığını açıklayın.
Müşteri için gereksiz olduğunu düşündüğünüz gereksinimleri (istisnalar, ileride değişecek olanlar vb.) müşteri ile görüşerek listenizden çıkarın.
Müşteriye büyük resmi göstermeye çalışın. Herhangi bir gereksiniminin tüm proje veya diğer konularda olası etkilerini açıklayın. Bazen küçük bir istek büyük yatırımlara sebep olabilir. Sebepleri ile açıklayın.
Yapamayacağınız veya yapılması imkansız konularda müşteriye söz vermeyin. İşi yapacak olan gruplarla (IT, Üretim vb.) hem fikir olmadan müşteriye taahhütlerde bulunmayın.
Kapsamınızı ve sözleşmenizi yapacağınız ve yapmayacağınız konuları içerecek şekilde hazırlayın.
Riskli konuları müşteri ile mutlaka paylaşın. Projenin başarı ve başarısızlığı ile ilgili gereklilikler konusunda uzlaşın.
Sürprizlerin ve değişikliklerin olası etkilerini, yaklaşım sistematiğinizi müşteri ile paylaşın.
Müşteri onay kriterlerini ve yöntemini projenin başında netleştirin.
Müşteri gereksinimlerinin neden önemli olduğunu anladığınızdan emin olun. Müşteri için önemi doğrultusunda ekibinizi hizalayın. Aksini düşünüyorsanız müşteri ile görüşmeler yaparak durumu masaya yatırın.
Müşterilerle yapacağınız çalışmalara (görüşmeler, test sonrası geri beslemeler, demonstrasyonlar, pilot uygulamalar, ekran akışları vb.) bir yöntem geliştirin ve periyodik olarak proje süresince uygulayın. Doğru yolda gittinizin güvencesini alın, geri dönmek zorunda kalmayın.
Müşterinin beklentileri ve pazar gereklilikleri değişebilir. Uzun süreli projelerde gereksinimleri (ör. 6 ayda bir) gözden geçirin ve güncelleyin.
Müşterilerle ve paydaşlarla yakın iletişim ve etkileşim içinde olun. Böylece olası değişikliklerin beklenenden fazla etkilemesinin önüne geçebilirsiniz.

Projelerde Paydaş İlişkilerini YönetmekGökrem Tekir, Savaş Şakar, Süleyman TosunProjeleri başarıyla tamamlamak için proje paydaşlarını anlamak ve yönetmek zorundayız.

Proje Yönetiminde Fikir/Zihin Haritalama (ldea/Mind Mapping)

Bir Cevap Yazın

Proje Yönetiminde Fikir/Zihin Haritalama (ldea/Mind Mapping), bakış açılarındaki ortak ve farklı noktaları yansıtmak ve beyin fırtınası seanslarıyla yaratılan fikirleri birleştirmek için kullanılır.

Aşağıdaki süreçler kullanılması önerilen bir tekniktir.

Gereksinimlerin Toplanması sürecinde kapsamın netleştirilmesi için beyin fırtınası ile toplanan gereksinimlerin ortak ve farklı yanlarını belirlemek için kullanılır.
Kalite Yönetiminin Planlanması sürecinde bilgileri görsel olarak düzenlemek için kullanılır. Proje ile ilgili kalite konseptinde yapılacakların veya fikirlerin organize edilmesinde kolaylık sağlar. Ayrıca kalite gereksinimlerini, kısıtları, bağımlılıkları ve ilişkileri belirlemeye yarar.
Paydaş Katılımının Planlaması sürecinde paydaşlarla ilgili bilgileri, paydaşlar arası ilişkileri ve paydaşların şirket ile ilişkilerini grafiksel olarak organize etmeye yarar.

Fikir/Zihin Haritalama yukarıdaki süreçlere ek olarak aşağıdaki konularda kullanılabilir;

Toplantılarda, fikirleri ve toplantı notlarını derleme,
Kapsamı belirlerken ihtiyaçları, kısıtları, varsayımları derleme,
Proje aşama ve aktivitelerini belirleme,
Kimin hangi aktiviteyi gerçekleştireceğini belirleme,
Proje sunumları,
Proje Yönetimi Yaklaşımının ve Proje yönetimi Planlarının gösterimi,
Problem çözümleri,
Karar verme,
Proje portföyünü belirleme.

Fikir/Zihin Haritalamayı etkin kullanabilmek için;

Birden fazla projede oluşturulan haritalar birbirleri ile ilişkilendirilebilir.
Ortak terminoloji ve grafiklerin (renk, sembol vb.) kullanılması paydaşlar tarafından anlaşılmasını kolaylaştırır.

Hayatımız Proje - Proje Yönetimi Başvuru KaynağıGökrem Tekir, Savaş ŞakarProje Yönetiminin Temelleri ve Pratik Süreç Başlıkları

Proje Yönetiminde Kırılım Yapıları ve Hiyerarşi

Bir Cevap Yazın

Proje yönetiminde kırılım yapıları yukarıdan aşağıya grafik formatında gösterim için kullanılır.

Genel olarak 3 kırılım yapısı yaygın olarak kullanılır;

1- İş Kırılım Yapısı (İKY)- Proje teslimatlarının, çalışma paketlerine kırılmış halidir ve grafiksel olarak aşağıdaki gibi hazırlanır.

Aşağıdaki kriterlere göre hazırlanabilir;

Sürece (yapılacak işlere) göre (örn. tasarım-tedarik-üretim-montaj)
Ürüne göre (motor-şanzıman-gövde-iç kısım vb.).
Organizasyon yapısına göre (tasarım-satınalma-insan kaynakları vb.).
Maliyet yapısına göre(Efor-Dış Kaynak_Malzeme vb.)
Sözleşmeye göre (Sözleşme teslimatlara bağlı ödemeler içeriyorsa)
Lokasyona göre (Ankara-Isparta-Adana vb.) hazırlanabilir.

Tüm planların altyapısı olan İş Kırılım Yapısını hazırlama konusunda süre kısıtlamasına gidilmemesi gerekir.

2- Organizasyonel Kırılım Yapısı (OKY) – Organizasyonun mevcut departmanlarına ya da ekiplerine göre düzenlenen ve her birinin altında proje aktivitelerinin ve çalışma paketlerinin listelendiği yapıdır. Departmanlar organizasyonel kırılım yapısında projeye ilişkin tüm sorumluluklarını görebilirler.

3- Kaynak Kırılım Yapısı (KKY) – Kaynakların (personel, ekipman vb.) kategorik ve/veya türüne göre sıralandığı hiyerarşik bir listedir. Proje çalışmalarının planlanmasının ve kontrolünün kolaylaştırılması için kullanılır. Her aşağı yöndeki (alt) seviye, çalışmaların planlanması, izlenmesi ve kontrol edilmesine olanak tanımak için, İş Kırılım Yapısı (İKY) ile birlikte kullanılabilecek kadar küçük bir kaynak biriminin bir tanımını temsil eder. Tüm kaynakları (personel, ekipman vb.) içeren Kaynak Kırılım Yapıları proje maliyetlerinin izlenmesine (kontrol hesapları) yardımcı olur ve organizasyonun muhasebe sistemi ile uyumlu hale getirilebilir.

Nitel Risk Analizi sürecinde, proje risklerinin birden fazla kategori altında incelenmesi gerektiğinde Olasılık Etki Matrisi yetersiz kalır ve Kabarcık Grafiği (Bubble Chart) kullanılabilir. Kabarcık Grafikleri verileri 3 boyutlu görmenizi sağlar. Risk’i bir kabarcık olarak düşünürsek, X ekseni, Y ekseni ve kabarcığın büyüklüğü olarak üç parametre ile ele alabiliriz. Aşağıda bir örneğini görebilirsiniz.

Hayatımız Proje - Proje Yönetimi Başvuru KaynağıGökrem Tekir, Savaş ŞakarProje Yönetiminin Temelleri ve Pratik Süreç Başlıkları

Proje Yönetiminde Yakınlık Şemaları

Bir Cevap Yazın

Proje Yönetiminde Yakınlık Şemaları (Affinity Diagram) fikirlerin gruplar halinde sınıflandırılıp gözden geçirilmesi ve analizi için kullanılır.

Projelerde gereksinimlerin toplanması sürecinde İş Kırılım Yapısını geliştirmek/iyileştirmek, kalitenin yönetilmesi sürecinde sorunların sebepleri gruplar halinde ele alınarak en çok odaklanılması gerekenler belirlenir.

Yakınlık Şemalarında benzer veya ilgili konular gruplar halinde ele alınır. Özellikle Beyin Fırtınası toplantılarında yaygın olarak kullanılır. Çok veri olan durumlarda verileri gruplamak üzerinde çalışılmasını kolaylaştırmaktadır. Elde az veri var ise tercih edilmez.

Yakınlık Şemaları, farklı fikirlerin ortak başlıklar altında ele alınmasıyla daha iyi anlaşılmasını ve karar verilmesini sağlar.

Yakınlık Şeması oluşturmak için;

Beyin Fırtınası vb. yöntemle fikirleri, istekleri, sorunları bir havuzda toplanır.
Bütün fikir, istek ve sorunların herkes tarafından görülebilmesini sağlanır.
Belirli başlıklar altında fikir, istek ve sorunları gruplanır.

Proje Yönetiminde Varyans Analizi

Bir Cevap Yazın

Varyans (Variance), bilinen bir temel çizgi veya beklenen değerden sayısal sapma, ayrılma veya uzaklaşma, Varyans Analizi (Variance Analysis) ise temel çizgi ve mevcut performans arasındaki farklılık derecesi ve nedenini belirleme tekniği olarak tanımlanmaktadır.

Projelerde aşağıdaki süreçlerde kullanılabilir;

Proje İşlerinin İzlenmesi ve Kontrolü, Faz ya da Proje Kapanışı süreçlerinde planlanan ve gerçekleşen performansın gözden geçirilmesinde kullanılır. Bu açıdan bakıldığında süre ve maliyet tahminleri, kaynak dağılımı ve oranları, teknik performans gibi örnekler verilebilir. Proje işlerinin izlenmesi ve kontrolü sürecinde maliyet, zaman, kaynak ve teknik değişkenlerinin entegre bir şekilde tüm proje üzerinden varyansları izlenebilmektedir. Bu sayede önleyici ve düzeltici eylemler planlanıp, uygulanabilmektedir.
Kapsamın Kontrolü sürecinde planlanan kapsam ile gerçekleşen kapsam arasındaki farka bakılarak önleyici ya da düzeltici eyleme gerek olup olmadığı belirlenir.
Zaman Çizelgesinin Kontrolü sürecinde planlanan ve gerçekleşen başlangıç ve bitiş tarihlerini, süreleri ve bollukları Varyans Analizi ile değerlendirebiliriz. Temel çizgiye göre sapmaların nedeni ve büyüklüğü gelecekteki işlerin tamamalanabilmesi, önleyici-düzeltici eylemlerin ne olması gerektiği gibi konular açısından önemlidir. Örneğin kritik yolda olmayan bir aktivitenin sapması proje süresini etkilemeyebilir. Varyans analizi sonucunda değişiklik talepleri oluşabileceği unutulmamalıdır.
Maliyetlerin Kontrolü sürecinde uzman görüşü ve Kazanılmış Değer analizinde kullanılır. Aktivitelerin planlanan maliyeti ile gerçekleşen maliyeti karşılaştırılır. Sapmanın nedenleri ve büyüklüğü değerlendirilir.

Varyans analizinin yapıldığı projeler için;

Satınalma Fiyatı Varyansı – Ürüne yapılan ödeme ile ürün fiyatı arasındaki fark
Çalışan Oranı Varyansı – Planlanan efor maliyeti ile gerçekleşen efor maliyeti arasındaki fark
Genel Gider Varyansı – Planlanan ve gerçekleşen genel giderler arasındaki fark
Sabit Maliyet Varyansı – Planlanan ve gerçekleşen sabit maliyetler arasındaki fark
Malzeme Miktarı Varyansı – Planlana ve Gerçekleşen Malzeme miktarı arasındaki fark.
Personel Verimlilik Varyansı – Standart performans ölçütlerine göre gerçekleşenlerin karşılaştırılması örnek olarak verilebilir.

Varyans Analizinin etkin yapılabilmesi eğilimlerin incelenmesi ile mümkündür. Sapma bir eğilim gösteriyorsa (artma ya da azalma) gerekli önlemler alınması kolaylaşacaktır. Tekil ya da sürpriz sapmalar ayrıca ele alınmalıdır.

Varyans analizinde sapmayı doğru belirlemek için karşılaştırılan değişkenlerin aynı parametreyi (gün, saat vb.) ve zaman dilimini (Ocak, Şubat vb.) içermesine dikkat edilmelidir.

Proje Yönetimi Ekibi kapsam, zaman ve maliyet sapmalarına odaklanmalı, sapmanın sebepleri farklı ise ayrı ayrı, ortak ise bir bütün olarak üzerine gitmelidirler.

Hayatımız Proje - Proje Yönetimi Başvuru KaynağıGökrem Tekir, Savaş ŞakarProje Yönetiminin Temelleri ve Pratik Süreç Başlıkları

%1-%10 Kuralı

Bir Cevap Yazın

Projeleri hangi düzeyde detaylandıracağız diye merak edenler için bir öneri

https://www.slideshare.net/savassakar/110-kural-78787013

Proje Yönetimi Tarihçesi: 1985 – 2013

Bir Cevap Yazın

1985: Şirketler maliyet kadar kalite konusunda da rekabet etmeleri gerektiğini anladılar. Toplam Kalite Yönetimini yerleştirmek için proje yönetimi prensiplerini izlediler. Kalite ve Proje Yönetimi birlikteliği başladı.

1990: 1989–1993 durgunluk döneminde, şirketler zaman çizelgesi sıkıştırma ve pazarda ilk olmanın önemini fark etti. Mühendislik daha iyi çizelgeleme tekniklerini kullanmaya başladı.

1991–1992: Üst Yönetimler, karar verme ve yetkileri Sponsorlara devretmeye başladılar. Kendini yöneten ekipler çıktı.

1993: 1989–1993 durgunluk dönemi bitmiş, şirketler yeniden yapılanma sürecine girmişlerdi. Daha az adamla daha fazla iş yapılabilmesi isteniyordu. Yeniden yapılanmanın yolu proje yönetiminden geçiyordu.

1994: Proje maliyet kontrol sistemleri ile tahmin gücünün gelişeceği, gerçek maliyeti hesaplamanın önemi anlaşıldı. Proje Yaşam döngüsü maliyeti hesaplanmaya başladı.

1995: Şirketler projelerin başlangıç kapsamından çok farklı bir şekilde sonuçlandığını fark ettiler. Etkin değişiklik kontrol sistemleri geliştirilmeye başlandı.

1996: Risk yönetiminin tampon süre belirlemek olmadığı anlaşıldı. Risk Yönetimi Planları yapılmaya başlandı.

1997–1998: Proje Yöneticiliğinin profesyonel bir kariyer olduğu anlaşıldı.

1999: Eşanlı mühendislik ve hızlı ürün geliştirmenin sırf o işe ayrılmış kaynaklarla gerçekleştirilebileceğini anladılar. Bir arada çalışan ekipler ortaya çıktı.

2000: Uluslararası işbirlikleri ve ortaklıkların artması proje yönetimini zorunlu hale getirdi. Uluslararası ekipler kurulmaya başlandı.

2001: Şirketler proje yönetimi olgunluk seviyelerini metodolojilerle geliştirmeye başladılar.

2002: Proje Yönetimi şirketler için stratejik bir konuma yükseldi. Hem proje yönetimi için stratejk planlama hem de stratejik planlamalara projelerin desteği başladı.

2003: Intranet durum raporlaması vb. hızlı bilgi paylaşımları çıktı.

2004: Intranet raporlaması hangi kaynağı nerede ve ne kadar çalıştığının görülmesini sağladı. Kaynak optimizasyonları ve dağılımları yapılmaya başlandı.

2005: Akti Sigma vb. teknikler Proje Yönetimi ile uyumlu hale geldiler. Sürekli Gelişim proje yönetim metodolojilerine de yansıdı.

2006: Sanal proje ekipleri ve proje ofisleri kurulmaya başladı.

2007: Yalım üretimin kavramları proje yönetimine uyarlandı.

2008: Geçmiş deneyimlerin önemi far kedildi, Alınan Dersler toplanmaya ve saklanmaya başlandı.

2009: Proje yönetim metodolojileri daha fazla iş süreçleri içermeye başladı.

2010: Karmaşık projelerde daha fazla paydaşı yönetmek zorunda kalan Proje Yöneticileri için Proje Paydaş Yönetimi önemli hale geldi

2011: Ek paydaşların ortaya çıkması tek bir Sponsor yerine Proje Yürütme Kurullarının ortaya çıkmasına sebep oldu.

2012: Kapsam, zaman, maliyet ve kalite kadar projenin üreteceği değer bir kısıt olarak ele alınmaya başlandı.

2013: Etkin proje yönetiminin zaman ve maliyetten çok daha fazla bilgi olduğu anlaşıldı.

Yararlanılan Kaynak: Project Management: A Systems Approach to Planning, Scheduling, and Controlling – 11th Edition – Harold Kerzner

Kamu Projelerinde Dikkat Edilmesi Gerekenler

Bir Cevap Yazın

Kamu projeleri etkiledikleri alan ve kişi sayısı açısından çok önemlidirler. Çoğu zaman özel sektör projelerinden daha zordurlar;

Çoğunluk için yapılan projeler çatışmalara yol açarlar.
Çok fazla paydaş ve paydaşların alt paydaşları söz konusudur.
Diğer politik görüşlerin eleştirileri ve baskıları söz konusudur.
Hata toleransı azdır.
Çıktının faydalarını sayısallaştırmak zordur.
Kanun ve bürokrasi kısıtları altında gecikmeler yaşanabilir, kaynak bulmak zorlaşabilir.
Dış Kaynaklarla koordinasyon zordur.
Mevcut kaynaklarla proje gerçekleştirilmek zorundadır.
Destek vermesi gereken paydaşların öncelikleri değişebilir, proje başarısını farklı algılıyor olabilirler.
Politik reklamlar zorlayıcı koşullar doğurabilir.
Kamu projeleri kısa-orta-uzun vade de olabilir. Uzun vade projeleri gelecek kuşaklar için yapılan yatırımlardır. Bunun yaratacağı problem bugün projeyi tanımlayan tarafların gelecek nesli temsil etmeleridir. Gelecek neslin ihtiyaçlarını belirlemeye çalışırlar.
Kamu projeleri özel sektör projelerinin çoğundan daha karmaşıktır. Bazı projelerin çıktıları proje başında tanımlanırken bazı projelerde yürütme esnasında netleştiriliyor olabilir. Kamu projeleri değişen politik ortam ve çevreye göre hızlı adaptasyon konusunda yavaş kalabilirler.
Kamu projelerinde sadece ekibi yönetmeniz yetmez, kamu ve özel sektör şirketlerini, STK’lar vb. diğer kuruluşları da yönetmeniz gerekir.
Kamu projelerinde proje ekipleri izole çalışırlar ve belirli dönemler haricinde yapılanlar izlenemeyebilir. Özel sektör projelerinde projelere daha yakın durulur ve ilgili tüm paydaşların izlemesi sağlanır.
Kamu projelerinde Proje Yöneticileri resmi olarak görevlendirilir ve gereken yetki verilir.
Verilen yetki doğrultusunda ilgili paydaşlar bilgilendirilir ve desteklemeleri istenir.

Kamu projelerinin başarı ya da başarısızlığı özel sektör projelerini doğrudan etkiler. Kamu projelerinde aşağıdaki hataların yapılmaması gerekir;

Projeden etkilenecek (vatandaşlar, şirketler) ve etkileyecek (paydaşlar) tarafların ihtiyaçlarının iyi tanımlanamaması,
Gerçekçi olmayan bitim tarihleri ve buna ek olarak gecikmelere tolerans gösterilmemesi,
Proje gerçekleştirecek nitelikli kaynaklar olmadan harekete geçmek, kaynakları sağlamamak,
Planlamaya gerekli vakti ayırmamak,
Doğru teknoloji, ekipman vb. seçiminde profesyonel tekniklere başvurmamak,
Doğru ve nitelikli tedarikçilerle çalışmamak,
Proje risklerini tanımlamamak, analiz etmemek, gerekli yanıt planlarını üretmemek,
Gerçekçi olmayan varsayımlarla yola çıkmak,
Paydaşlararası çatılmaları görmezden gelmek, çözümlememek,
Beklenmedik durumlarda harekete geçmemek, yavaş kalmak, karar verme ve problem çözme süreçlerini proje özelinde ele almamak,
Proje Yönetimi Metodolojilerini kullanmamak,
Deneyimli proje yöneticileri yetiştirmemek, nitelikli proje yöneticileri ile çalışmamak,
Proje sürecine paydaşları gerektiği gibi dahil etmemek
Geçmiş proje deneyimlerinden alınan dersleri yeni projelere adapte etmemek, bu konuda bir yöntem geliştirmemek,
İyi tanımlanmamış kapsamla yola çıkmak sayılabilir.

Kamu’nun özel sektör projelerine olumsuz etkilerine aşağıdaki örnekleri verebiliriz;

Bürokratik süreçlerin çokluğu ve uzunluğu,
Onay, Kabul vb. konularda kamunun yeterli personeli olmaması,
Kanun, yönetmeliklerdeki kısıtlayıcı güncellenmemiş kurallar,
Ödemelerin gecikmesi,
Devlet kademelerindeki değişikliklerin yaratabileceği otorite boşlukları,
Proje özelinde yaklaşılmaması sayılabilir.

Yararlanılan Kaynak: Project Management: A Systems Approach to Planning, Scheduling, and Controlling – 11th Edition – Harold Kerzner