bĐlgĐ teknolojĐlerĐ proje yÖnetĐmĐ ve baŞari...
TRANSCRIPT
-
T.C. ANKARA ÜNĐVERSĐTESĐ
SOSYAL BĐLĐMLER ENSTĐTÜSÜ ĐŞLETME ANABĐLĐM DALI
BĐLGĐ TEKNOLOJĐLERĐ PROJE YÖNETĐMĐ
ve BAŞARI KOŞULLARI
Yüksek Lisans Tezi
Nuray ESATOĞLU
Ankara-2010
-
T.C. ANKARA ÜNĐVERSĐTESĐ
SOSYAL BĐLĐMLER ENSTĐTÜSÜ ĐŞLETME ANABĐLĐM DALI
BĐLGĐ TEKNOLOJĐLERĐ PROJE YÖNETĐMĐ
VE BAŞARI KOŞULLARI
Yüksek Lisans Tezi
Nuray ESATOĞLU
Tez Danışmanı Yrd.Doç.Dr.M. Arcan TUZCU
Ankara-2010
-
T.C. ANKARA ÜNĐVERSĐTESĐ
SOSYAL BĐLĐMLER ENSTĐTÜSÜ ĐŞLETME ANABĐLĐM DALI
BĐLGĐ TEKNOLOJĐLERĐ PROJE YÖNETĐMĐ
VE BAŞARI KOŞULLARI
Yüksek Lisans Tezi
Tez Danışmanı : Yrd.Doç.Dr.M.Arcan TUZCU
Tez Jürisi Üyeleri
Adı ve Soyadı Đmzası
.................................................................... ........................................
.................................................................... ........................................
.................................................................... ........................................
.................................................................... .........................................
.................................................................... .........................................
.................................................................... ......................................
Tez Sınavı Tarihi ..................................
-
i
ĐÇĐNDEKĐLER
BÖLÜM I. PROJE, PROJE YÖNETĐMĐ ve PROJE YÖNETĐMĐ BĐLGĐ ALANLARI ................................................................................................................. 3 1.1. Proje Kavramı ............................................................................................ 3 1.2. Proje Yönetimi ........................................................................................... 6 1.2.1. Proje Yönetimi Kavramı ............................................................................ 6 1.2.2. Proje Yönetiminin Avantaj ve Dezavantajları ......................................... 11 1.2.3. Proje Safhaları ve Proje Hayat Döngüsü.................................................. 14 1.2.3.1. Waterfall Metodu ..................................................................................... 17 1.2.3.2. Tekrarlı Metodlar ..................................................................................... 20 BÖLÜM II. PROJE YÖNETĐMĐ BĐLGĐ ALANLARI............................................. 22 2.1. Proje Bütünleştirme (Entegrasyon) Yönetimi.......................................... 24 2.1.1. Proje Plan Geliştirme ............................................................................... 25 2.1.2. Proje Plan Uygulama ............................................................................... 30 2.1.3. Bütünleşik Değişim Kontrolü .................................................................. 31 2.2. Proje Kapsam Yönetimi ........................................................................... 33 2.2.1. Başlangıç .................................................................................................. 34 2.2.1.1. Potansiyel Projelerin Belirlenmesi........................................................... 35 2.2.1.2. Proje Seçiminde Kullanılan Metodlar...................................................... 38 2.2.2. Kapsam Planlama..................................................................................... 40 2.2.3. Kapsam Tanımlama ................................................................................. 40 2.2.3.1. Đş Dağılım Yapısı ..................................................................................... 41 2.2.4. Kapsam Doğrulama.................................................................................. 44 2.2.5. Kapsam Değişim Kontrolü....................................................................... 44 2.3. Proje Zaman Yönetimi ............................................................................. 45 2.3.1. Faaliyet Tanımlama.................................................................................. 46 2.3.2. Faaliyetleri Sıralama ................................................................................ 46 2.3.2.1. Şebeke Diyagramları................................................................................ 47 2.3.2.2. Öncelik Diyagram Metodu....................................................................... 49 2.3.3. Faaliyet Süre Tahmini .............................................................................. 50 2.3.4. Takvim Geliştirme ................................................................................... 51 2.3.4.1. Gantt Modeli ............................................................................................ 53 2.3.4.2. Kritik Yol Modeli (CPM) ........................................................................ 56 2.3.4.3. Program Değerlendirme ve Gözden Geçirme Tekniği (PERT) ............... 60 2.3.4.4. Takvim Geliştirme Metodlarının Karşılaştırılması .................................. 63 2.3.5. Proje Takviminin Değişikliklerinin Kontrol Altına Alınması ................. 64 2.4. Proje Maliyet Yönetimi............................................................................ 64 2.4.1. Kaynak Planlama ..................................................................................... 66 2.4.2. Maliyet Tahmini....................................................................................... 66 2.4.2.1. Maliyet Tahmininde Kullanılan Teknikler............................................... 67 2.4.2.2. BT Projelerinin Temel Maliyet Tahminleme Sorunları ........................... 68 2.4.3. Maliyet Bütçeleme ................................................................................... 69 2.4.4. Maliyet Kontrol........................................................................................ 70 2.4.5. Kazanılmış Değer Analizi ........................................................................ 70
-
ii
2.5. Proje Kalite Yönetimi .............................................................................. 73 2.5.1. Modern Kalite Yönetimi .......................................................................... 74 2.5.2. Kalite Planlama ........................................................................................ 75 2.5.3. Kalite Güvencesi ...................................................................................... 76 2.5.4. Kalite Kontrol .......................................................................................... 77 2.5.4.1. Kalite Kontrol Teknikleri......................................................................... 77 2.5.4.1.1. Pareto Analizi........................................................................................... 78 2.5.4.1.2. Đstatistiksel Kalite Kontrol ....................................................................... 78 2.5.4.1.3. Kontrol Diyagramları ............................................................................... 80 2.5.4.1.4. Test........................................................................................................... 82 2.5.5. Proje Kalitesinin Geliştirilmesi ................................................................ 82 2.5.5.1. Liderlik..................................................................................................... 83 2.5.5.2. Kalitenin Maliyeti .................................................................................... 84 2.5.5.3. Kaliteye Organizasyonun ve Çalışma Alanları Faktörlerinin Etkisi........ 85 2.5.5.4. Olgunluk Modelleri.................................................................................. 86 2.5.5.4.1. Yazılım Kalite Fonksiyon Yayılımı (SQFD) ........................................... 86 2.5.5.4.2. Yetenek Olgunluk Modeli (CMM) .......................................................... 87 2.5.5.4.3. Proje Yönetimi Olgunluk Modeli ............................................................ 87 2.6. Proje Đnsan Kaynakları Yönetimi............................................................. 88 2.6.1. Organizasyon ve Planlama....................................................................... 89 2.6.2. Personel Temini ....................................................................................... 90 2.6.3. Takım Geliştirme ..................................................................................... 94 2.7. Proje Đletişim Yönetimi ............................................................................ 94 2.7.1. Đletişim Planlama...................................................................................... 95 2.7.2. Bilgi Dağıtımı .......................................................................................... 97 2.7.2.1. Bilgi Dağıtımını Geliştirmek Đçin Teknolojinin Kullanımı ..................... 97 2.7.2.2. Bilgi Dağıtımı Đçin Resmi Olan ve Resmi Olmayan Yöntemler.............. 98 2.7.2.3. Đletişimin Karmaşıklığının Belirlenmesi .................................................. 99 2.7.3. Performans Raporlama........................................................................... 101 2.7.4. Yönetsel Kapanış ................................................................................... 101 2.7.5. Đletişimde Çatışmaların Yönetilmesi...................................................... 102 2.8. Proje Risk Yönetimi............................................................................... 105 2.8.1. Risk Yönetimi Planlama ........................................................................ 108 2.8.2. Risklerin Tanımlanması ......................................................................... 108 2.8.3. Risk Analizi............................................................................................ 111 2.8.4. Risk Tepki Planlama .............................................................................. 113 2.8.5. Risk Đzleme ve Kontrol .......................................................................... 114 2.9. Proje Tedarik Yönetimi.......................................................................... 116 2.9.1. Tedariğin Planlanması............................................................................ 118 2.9.2. Teklifin Planlanması .............................................................................. 120 2.9.3. Teklif Süreci........................................................................................... 120 2.9.4. Kaynak Seçimi ....................................................................................... 121 2.9.5. Kontrat Yönetimi ................................................................................... 121 2.9.6. Sözleşme Kapanışı ................................................................................. 122 BÖLÜM III. BĐLGĐ TEKNOLOJĐLERĐ PROJELERĐNĐN BAŞARI KOŞULLARI 123 3.1 Başarılı Bilgi Teknolojileri Projesi Tanımı............................................ 123 3.2 Başarılı Bilgi Teknolojileri Projeleri...................................................... 125
-
iii
3.3 Bilgi Teknolojileri Projelerinde Başarı Faktörleri ................................. 128 3.3.1. Kullanıcı Katılımının Sağlanması .......................................................... 128 3.3.2. Gerçekçi Đhtiyaç Analizi ........................................................................ 129 3.3.3. Kesin ve Gerçekçi Takvim ile Kestirimler............................................. 130 3.3.4. Yönetim Desteği .................................................................................... 131 3.3.5. Gerçekçi ve Yetenekli Proje Yöneticisi ................................................. 133 BÖLÜM IV. BĐLGĐ TEKNOLOJĐLERĐ PROJELERĐNĐN BAŞARI KOŞULLARI ÜZERĐNE ARAŞTIRMA........................................................................................ 135 4.1 Araştırmanın Tasarımı ........................................................................... 135 4.2 Araştırma Yönteminin Belirlenmesi ...................................................... 136 4.2.1. Soru Formunun Đçeriği ........................................................................... 137 4.3 Popülasyon ve Örneklem ....................................................................... 138 4.4 Verilerin Değerlendirilmesi ................................................................... 139 4.5 Anket Sonuçlarının Analizi.................................................................... 139 4.5.1. Proje Geçmişi ......................................................................................... 139 4.5.2. BT Projelerinde Başarı Koşulları ........................................................... 140 4.6 Anket Sonuçlarının Değerlendirilmesi................................................... 158 KAYNAKLAR ............................................................................................................ 1 ÖZET 1 ABSTRACT................................................................................................................. 1
-
iv
TABLO LĐSTESĐ
Tablo 1 – Kazanılmış Değer Analizi Formülleri........................................................ 72 Tablo 2 – Bilgi Alanlarına Göre Muhtemel Risk Olayları....................................... 110 Tablo 3 – Risk Düzeyi Hesaplama Tablosu............................................................. 112
-
v
ŞEKĐL LĐSTESĐ
Şekil 1 - Proje Yönetiminin Üçlü Kısıtı....................................................................... 8 Şekil 2 - Proje Hayat Döngüsü Safhaları .................................................................. 15 Şekil 3 - Proje Hayat Döngüsü................................................................................... 16 Şekil 4 - Waterfall Metodu Akış Şeması................................................................. 19 Şekil 5 - Tekrarlı Teknikler Akış Şeması.................................................................. 21 Şekil 6 - Proje Yönetimi Đskeleti............................................................................... 23 Şekil 7 - Bilgi Teknolojileri (BT) Planlama Süreci .................................................. 36 Şekil 8 – Aktivite Ok Üzerinde.................................................................................. 48 Şekil 9 – Aktivite Düğüm Üzerinde........................................................................... 49 Şekil 10 – Kritik Yol Yöntemi Belirleme .................................................................. 56 Şekil 11 – PERT Diagramı......................................................................................... 61 Şekil 12 - Kontrol Diyagramı.................................................................................... 81 Şekil 13 - Bilgi Teknolojileri Projelerinde Kaynak Histogramı ............................... 91 Şekil 14 - Kaynak Seviyeleme .................................................................................. 93 Şekil 15 - Kişi Sayısının Đletişim Kanalı Üzerindeki Etkisi.................................... 100 Şekil 16 - Blake ve Mouton’un Çatışma Yönetimi Biçimleri Ölçeği ..................... 103 Şekil 17 Uygulamanın Gerçekleştirilmesi Süreci .................................................... 135
-
vi
GRAFĐK LĐSTESĐ
Grafik 1 Yıllara Göre Proje Performansları ............................................................. 127 Grafik 2 Proje Yönetimi Deneyimi .......................................................................... 141 Grafik 3 Proje Yöneticisinde Değişiklik .................................................................. 142 Grafik 4 Proje Ekibinin Uzun Saatler Boyunca Çalışmasının Desteklenmesi Yüzdesi.................................................................................................................................. 143 Grafik 5 Proje Ekibinin Fazla Çalışmaları için Ödüllendirilme Oranı .................... 144 Grafik 6 Đhtiyaçların Belirlenmesi Sırasında Metot Kullanımı................................ 145 Grafik 7 Proje Başladığında Đhtiyaçların Tamamlanmış ve Belirlenmiş Olma Oranı.................................................................................................................................. 146 Grafik 8 Đhtiyaçların Netleştirilmesi için Yeterli Zamanın Olma Yüzdesi .............. 147 Grafik 9 Proje Kapsamının Đyi Tanımlanma Oranı.................................................. 148 Grafik 10 Başarılı Proje Takvimi Oranı................................................................... 150 Grafik 11 Proje Grubuna Yeni Çalışanlar Eklenme Oranı....................................... 151 Grafik 12 Projelerdeki Sponsor Desteği Oranı ........................................................ 152 Grafik 13 Müşterinin Proje Sürecine Katılım Oranı ................................................ 153 Grafik 14 Proje Öncesi Risklerin Belirlenme Oranı ................................................ 154 Grafik 15 Proje Başarısındaki Önemli Faktörlerin Dağılımı ................................... 156 Grafik 16 Başarılı Projelerin Özelliklerinin Dağılımı.............................................. 157
-
GĐRĐŞ
Günümüzde birçok işletme veya birey proje yönetimi konusuyla yakından
ilgilenmektedirler. 1980’lere kadar proje yönetimi başlıca üst kademe yöneticilere
kullanılan kaynaklar konusunda bilgi sağlamak üzerine yoğunlaşmıştır. Ancak
özellikle doksanlı yılların sonralarında işletme çevresinin çok daha karmaşık bir hale
gelmesiyle bugünün koşullarında proje yönetimi çok daha fazlasını gerektirmektedir.
Böyle bir çevrede bilgi teknolojileri (BT) işletmeler için önemli bir faktör haline
gelmiştir. Toplumların geleceğini belirlemede en etkili güç konumunda olan ve
içinde yer aldığı toplumsal, ekonomik ve sosyal sistemleri etkileyen bilgi
teknolojileri, iş çevrelerinde radikal değişikliklere yol açmıştır. Doğal olarak bu
değişiklikler işletmelerde daha kapsamlı, etkili bir proje yönetiminin ateşleyici
unsuru olmuştur. Gerçekten de bugünün şirketleri başarılı olmanın modern proje
yönetimi teknikleri ile aşina olmayla sağlanacağının farkına varmalarıyla proje
yöneticiliği bir meslek haline gelmiştir.
Dünyadaki gelişmelere paralel olarak ülkemizde de proje yönetimi ilgi
çekmeye başlamış ve özellikle BT alanında kullanımı yaygınlaşmıştır. Proje yönetim
faaliyetlerinin yaygınlaşması ve buna rağmen projelerin başarısızlık yüzdelerinin
yüksek olması, projelerin başarı koşullarının ve BT proje yönetiminin nasıl olması
gerektiği konusundaki ihtiyacın gün geçtikçe artmasına sebep olmaktadır. Başarı
koşulları dikkate alınarak proje yönetim aşamalarına titizlikle uyulan BT projeleri
-
2
planlandığı biçimde, hedeflenen kaynak kullanımına yakın rakamlarla başarılı
biçimde sonlandırılmaktadır.
“Bilgi Teknolojileri Proje Yönetimi ve Başarı Koşulları” isimli çalışmamız,
açıklanmasında temel oluşturan BT proje yönetimi, bilgi alanları, metodolojiler ve
projelerin başarılı olma koşullarını içerecek şekilde planlanmıştır. Tezimiz üç
bölümden oluşmaktadır. Birinci bölümde proje ve proje yönetimi kavramlarına
değinilmekte, ikinci bölümde proje yönetimi bilgi alanları ayrıntılı olarak ele
alınmakta, izleyen bölümde de bilgi teknolojileri projeleri başarı koşulları
incelenmektedir. Çalışmanın uygulamasını oluşturan son bölümde, Ankara’da
faaliyet gösteren yazılım firmalarındaki proje yöneticilerinden oluşan örneklem
üzerinde ilgili proje yöneticilerinin proje yönetimi yaklaşımları ve görev aldıkları son
projelerin bilgi alanları açısından değerlendirmesi yapılacaktır.
-
3
BÖLÜM I. PROJE, PROJE YÖNETĐMĐ ve PROJE YÖNETĐMĐ BĐLGĐ
ALANLARI
1.1. Proje Kavramı
Proje; başlangıç ve bitiş zamanları belirli, maliyet ile zaman kısıtları altında
yeterli kapsama ulaşmaya çalışılan, belirli hedefler doğrultusunda yazılı hale
getirilmiş, geçici bir süreçtir. Belirsizlik ve risk içeren proje süreci, kaynaklara
(insan, para, teknik ekipman vb.) ve bu kaynakların sağlanacağı finansörlere ihtiyaç
duyar.
Literatürde proje kavramının çok sayıda tanımıyla karşılaşmak mümkündür.
Bu tanımlardan birisinde proje, ortak bir amaca ulaşmak için gösterilen geçici bir
çaba olarak tanımlanmıştır. 1 Başka bir tanımda proje; probleme özel, bir defaya
mahsus oluşturulan, belirli bir zaman içerisinde bir grup amacı başarmayı hedefleyen
işlemler olarak ifade edilmiştir. 2 Daha geniş anlamda proje, tek ve ortak bir amaca
ulaşmak için üzerinde uzlaşılmış, zaman, maliyet ve kalite kısıtlarından etkilenen;
risk, insan kaynakları, iletişim ve dağıtım bileşenlerini içeren bir süreç olarak
tanımlanmıştır. 3
Projenin hedefleri, süresi, başlangıç ve bitiş tarihleri bellidir. Her proje
kendine özgüdür ve diğer projelere benzemez. Hiçbir proje, aynı biçim ve koşullarda
1 Project Management Institute Standarts Committee, A Guide to the Project Management Body of Knowledge (PMBOK) , 3. Edition, Project Management Institute, USA, 2004, s.5 2 William J. Stevenson, Production/Operations Management, Richard D. Inc., 1993, s.776 3 Paul Steinford, Project Management, http://www. psaproject. com. au/home/default. asp?/pm/whatisaproject. shtm~Main)
-
4
kendini tekrarlamaz. Projelerde amaç odak noktasıdır ve bu projenin varoluş
nedenidir. Amacın olmadığı çalışmaların proje olarak adlandırılması mümkün
değildir. Her iş, belirli kısıtlar altında ve belirli kaynaklar kullanılarak
gerçekleştirilir.
Projeler, kültürel ve çevresel faktörlere duyarlıdır. Çoğu proje farklı kişilerin
ve/veya grupların işbirliğini gerektirmekte, katkı ve katılımın yanı sıra yaratıcılık ve
yenilik gerektiren çalışmaları içermektedir.
Başlama ve bitişi açıkça belirlenmiş faaliyetlerle bütçe ve zaman kısıtı altında
amaçlara ulaşma eylemi olan projeler aşağıda belirtilen minimum özellikleri taşımak
durumundadırlar: 4
• Belirli özelliklere sahip tanımlanmış bir hedef,
• Tanımlı başlangıç ve bitiş tarihleri,
• Bütçe
• Kaynakların nasıl tüketileceğini belirten minimum özellikler
Bunların yanı sıra tüm projelerde görülen bazı ortak özellikler de vardır.
Bunlar : 5
• Amaç: Her proje iyi tanımlanmış, ortak bir amaca sahiptir. Bilişim sektörü
açısında olaya baktığımızda, birçok proje getiri ve maliyetleri önceden analiz
4 Liu Lung-Chun. and Horowitz Ellis, A Formal Model For Software Project Management, IEEE Transactions For Software Project Management.1989,Vol.15,No.10, IEEE 5 Nigel Slack ve diğerleri, Operations Management, Prentice Hall, 1998 s:590
-
5
edilmiş bir ürün veya hizmeti ortaya koymak amacı ile gerçekleştirilir.
Burada önemli olan nokta, ürün veya hizmetten beklenenlerin net olarak
ortaya konmasıdır.
• Karmaşıklık: Proje amaçlarına ulaşabilmek için birçok farklı faaliyetin
tamamlanması gerekir. Bu faaliyetler arasındaki ilişkiler, özellikle de
projedeki faaliyet sayısı fazla olduğunda karmaşık olabilir. Rutin işlerin
planlanması bir kaç gün veya hafta öncesinden yapılabilirken projelerin
planlanması aylar sürebilir.
• Teklik: Bir proje genellikle bir kereye mahsus, tekrar etmeyen bir yapıdır.
Yinelenen projeler bile, aynı özellikte başka bir kimyasal fabrikanın
kurulması gibi, kaynaklar ve projenin gerçekleşeceği çevre açısından ayırt
edici farklılıklara sahiptir. Projeler tekrarlanan olaylar olmadığından
karşılaşılan problemler ve bunların çözümleri de rutin değildir.
• Belirsizlik: Her proje kendine özgü amaçlar içerdiğinden hepsi için ortak bir
çözüm elde etmek olası değildir. Bu nedenle zaman, maliyet ve kalite
beklentilerinin her birinin tam olarak karşılanması çoğu zaman sağlanamaz.
Bu belirsizlik proje yönetimini bir meydan okuma haline getirmektedir.
• Geçici Yapı: Projeler tanımlanmış bir başlangıç ve sonuca sahiptirler.
Dolayısıyla projenin gerçekleştirilebilmesi için ihtiyaç duyulan kaynaklar
geçici bir süre için kullanılır. Proje amaçları gerçekleştirildikten sonra,
kaynaklar genellikle başka bir iş için yönlendirilir.
• Yasam Eğrisi: Bir proje için kaynak ihtiyacı, projenin yasam eğrisi boyunca
değişir. Bir proje için tipik kaynak ihtiyacı tahmin edilebilir bir yol izler. Bu
-
6
yüzden planlama ve kontrol açısından bakıldığında projenin yasam eğrisini
proje aşamalarına bölmek gerekir.
Tüm bu açıklamalardan sonra, projeyi bir ihtiyacı gidermek üzere başlanan,
bir amacı olan, yalnızca bir defalık yapılan, başlama ve bitiş tarihleri belli olan, bir
organizasyon yapısı içinde gerçeklesen ve içerisinde kaynak tüketilen bir süreç
olarak tanımlamak mümkündür.
1.2. Proje Yönetimi
1.2.1. Proje Yönetimi Kavramı
Basit tanımıyla proje yönetimi, bir projenin gerçekleştirilmesi için harcanan
çabaların tümüdür. Başka bir ifadeyle proje yönetimi, belirli amaç ve hedeflere
ulaşabilmek için isletme kaynaklarının verimli ve etkin bir şekilde planlanması,
organize edilmesi, yönetilmesi ve kontrolüdür.
Projenin olduğu gibi proje yönetiminin de çok sayıda tanımı yapılmıştır.
Yapılan tanımlardan birinde proje yönetimi, uygulama geliştirme ekibinin
kullanımında ve yapım maliyetinde verimlilik sağlayan bir programı hayata
geçirirken sarfedilen planlama, organize etme, yönetme ve denetleme çabaları olarak
tanımlanmıştır. 6
6 Harold Kerzner, Project Management A Systems Approach to Planning, Scheduling and Controlling, New York , Van Nostrand Renhold Company, 1984, s. 4-5
-
7
Başka bir tanımda proje yönetimi, finansör ve müşterilerin beklentilerinin
karşılanması amacıyla, bilgi, yetenek, araç ve tekniklerin proje faaliyetlerine
uygulanması olarak ifade edilmiştir.7
Belli bir hedefi gerçekleştirmek için insanların, kaynakların ve zamanın
birbirleriyle uyumlu ve verimli kullanılması ile ilgili bir bilim olan proje yönetimi şu
konuları kapsamaktadır:
• Planlama: Proje yönetiminden beklenen sonuçların tanımlanması, bu
sonuçların elde edilmesi için iş gereksinimlerinin, iş miktarının, gereken
zamanın, bütçenin ve kaynakların belirlenmesi işlemidir.
• Organize Etme: Projenin organizasyon yapısı içerisinde yönetilebilir
işlemlere ayrılması ve bu işlemleri yürütecek çalışanların tanımlanması,
seçilmesi ve yerleştirilmesi işlemidir.
• Yöneltme: Đşlemlerin başarılı bir biçimde yapılması için gerekli bilginin
sağlanması, yerleştirilmesi, teşvik edilmesi ve iletişimin sürekli sağlanması
eylemidir.
• Kontrol Etme: Kontrol ölçütlerinin belirlenmesi, yapılanların izlenmesi,
sapmaların belirlenmesi ve gerekli önlemlerin alınması işlemidir.
Butler’e göre ise proje yönetimi karmaşık girişimlerle güçlendirilmiş,
yoğunlaştırılmış ve bütünleştirilmiş yönetimler kazandırmak için tasarlanmıştır ve
aşağıda belirtilenleri içerir; 8
7 Project Management Institute Standarts Committee, a.g.e., s.6
-
8
• Belirli bir konuda toplam örgütsel kaynakların önemli kısmına odaklanması
• Büyük ölçüde birbirine bağlı uzmanlaşmış faaliyetler
• Maliyet hakkında nispeten güç kısıtlamalar ve urun sonu performansı.
Bazı projeler bir takım farklı gereklilikleri ön plana çıkarsa da genellikle her
proje, faaliyet alanı, zaman ve maliyet kısıtları ile sınırlandırılır. 9 Bu kısıtlar başarılı
proje yönetimi için gerekli üçlü kısıt olarak adlandırılır. Proje yönetimi, merkezinde
kalitenin olduğu üç köşeli bir yapı olarak düşünülebilir (Şekil 1).
Şekil 1 - Proje Yönetiminin Üçlü Kısıtı
Kaynak: Yılmaz Alpdoğan, Proje Yönetiminde Temel Bilgiler, http://www.alpdogan.net/?p=18
Proje zamanında teslim edilmeli, belirlenen maliyet ve kapsamda kalmalı,
müşterinin kalite ihtiyaçlarını ve beklentilerini karşılamalıdır.
Kapsam kısıtında “Hangi hedefe ulaşılması amaçlanıyor” sorusuna cevap
aranır. Sponsor veya müşterinin proje sonucunda hangi ürün veya hizmeti elde etmek
istediği belirlenir.
8 Arthur G. Butler Jr, Project Management: A Study in Organizational Conflict, The Academy of Management Journal,1973, Vol. 16, No. 1. Jstor 9 Burhan Albayrak, Proje Yönetimi, Ankara, Nobel Basımevi, 2005, s. 5
-
9
Zaman kısıtında, projeyi tamamlamanın ne kadar zaman alacağı sorusuna
cevap aranır. Diğer bir deyişle ürün veya hizmetin gerçekleştiriliş takvimi ortaya
konur. Başlangıçta kararlaştırılan takvime uyulmadığı takdirde müşteri veya
sponsora tazminat ödenmek zorunda kalınabilir. Bu da maliyetlerin artmasına neden
olacaktır. Proje yöneticisinin görevi her aşamada takvim ile gerçekleşen işin
uyumunu takip etmektir.
Son olarak maliyet kısıtında, projeyi tamamlamanın maliyetinin ne olacağı
sorusuna cevap aranır. Bu şekilde eldeki kaynakların çalışır bir sisteme
dönüştürülmesinin maliyeti belirlenir.10 Burada maliyet kelimesi, analist veya
programcıların ücretleri, özel ekipmanların satın alınması, kira giderleri, yazılım
donanım ve bilgisayar ağları için yapılan harcamalar, yönetim ve kırtasiye giderleri
gibi projenin yürütülmesi ile doğrudan ilgili konu başlıklarını kapsamaktadır.
Projenin maliyet yönetimi denince sadece oluşan giderlerin görüntülenmesi ve kayıt
edilmesi anlaşılmamalıdır. Proje maliyet yönetimi, iyi düşünülmüş, iyi tasarlanmış,
zaman-maliyet ilişkisini göz önünde bulundurarak projenin kararlaştırılan tarihte
bitmesini hedefleyen işlerin bütünüdür.
Başarılı bir proje yönetimi her üç kısıt için belirlenen hedeflere ulaşılması ve
proje finansörünün veya müşterinin memnuniyeti ile ölçülür. Projelerde, özellikle de
bilişim teknolojileri projelerinde genellikle üçlü kısıtın sağlanamadığı görülmektedir.
10 Linda L.S. Lai, “A Synergistic Approach to I.S. Project Management” , http://www.is.cityu.edu.hk/Research/Publication/working_paper94.htm
-
10
Bu durum; “Daha kapsamlı, daha ucuz ve daha çabuk elde edemezsin, ikisini
seç!”11şeklinde özetlenebilir.
Ancak aşağıda kapsam, zaman ve maliyet kısıtlardan fedakârlıkta bulunmanın
meydana getirebileceği bazı sonuçlar dikkate alındığında bu seçim sürecinin zorluğu
anlaşılacaktır.
• Zamanı azaltmak, özellikle fazla mesai gerekiyorsa, maliyetlerde artışa
sebep olacaktır.
• Maliyetleri düşürmeye çalışmak proje takvimini olumsuz yönde etkiler.
Hatta kapsamdan ödün vermek gerekebilir.
• Kapsamı arttırmak maliyet ve zamanın artmasına neden olur.
• Kapsamı düşürmek her ne kadar maliyet ve zaman kısıtında azalış sağlasa da
daha sonra bahsedeceğimiz kalite kavramını olumsuz yönde
etkileyeceğinden finansör veya müşterinin tatminsizliğine yol açar. Bu ise
yeniden düzenleme, zamanda gecikme, verimlilikte düşüş ve maliyetlerin
artması demektir.
• Devam eden bir projeye beşeri veya fiziki bir kaynak eklemek proje
bütünlüğüne zarar verebileceğinden verimsizliğe yol açabilir.
• Bitirme zamanlarını geciktirmek, bilişim projeleri insan (analist, programcı)
odaklı projeler olduğundan maliyetleri düşürmeyecektir. Çünkü “Zaman,
para demektir.”12
11 Linda L.S. Lai , a.g.e.
12 Linda L.S. Lai , a.g.e.
-
11
Yukarıda belirtilen sonuçlardan da anlaşılacağı üzere, proje yönetiminin üç
kısıtı olan kapsam, maliyet ve zaman birbirleri ile ilişkilidir ve kıstasların birinde
yapılan değişiklik diğerlerini de etkilemektedir.
Üç kısıt proje yönetiminin temel faktörlerini temsil etmekle birlikte, kalite de
önemli bir faktördür. Her üç kısıtın da sağlandığı bir proje, kalite açısından yetersiz
ise finansör veya kullanıcılar tarafından ödeme yapılmayacaktır. Bu nedenle müşteri
memnuniyeti açısından kalite önemli bir faktördür.
Kısaca, proje yönetimi üç boyutlu bir bütündür ve yönetim kararları bu
boyutlardan sadece biri değil, tüm boyutlar düşünülerek alınmalıdır Başarılı bir proje
yönetimi, kapsam, zaman ve maliyet kısıtlarının her üçünü kalite çemberi içerisinde
yönetebilmektir.
1.2.2. Proje Yönetiminin Avantaj ve Dezavantajları
Şirketlerin proje yönetimine ihtiyaç duyma nedenleri incelendiğinde
aşağıdaki sonuçlarla karşılaşılmaktadır: 13
• Kısa zamanda gerçekleştirilmesi istenen işler ve dinamik iş ortamları
• Artan koordinasyon gerektiren, çoğalan işgücü ve karmaşıklaşan
organizasyon yapıları
• Sınırlı işletme kaynakları
13 Rory Burke, Project Management: Planning and Control Techniques, Fourth Edition, 2003. s. 10-11
-
12
• Yeniliklere adapte olma zorunluluğu
• Đletişimin karmaşıklaşması
• Đşlenecek bilgi kaynaklarının ve miktarının artması
Bu yüzden, proje yönetimi değişen zaman, maliyet, performans ve insan
kaynağı koşullarıyla karmaşıklaşan durumlar için geliştirilen bir yapı olarak da
algılanabilir.
Ücret ve hammadde fiyatlarındaki artışlar, üretilen mal ve hizmetlere
ihtiyacın artması, şirket ortaklarından gelen baskılar, yüksek enflasyon ve akabinde
alım gücü ve borçlanabilme olanaklarının azalması gibi ekonomik dengelerin
değişmesi günümüzde işletmelerin, giderek karmaşıklaşan sorunlar ve iş hayatı ile
karşı karşıya kalmalarına sebep olmaktadır.
Artık yöneticiler, tüm bu isletme sorunlarının çözümünün daha iyi kontrol ve
isletme kaynaklarının daha verimli kullanılması olduğunda mutabık kalırken,
sorunun dışarıdan değil daha çok iç yapıdan kaynaklandığı fikrini
benimsemektedirler.14 işletme içerisinde aranan bu çözüm, onları faaliyetlerin
yönetilme ve organizasyon şekillerinde bir arayışa itmektedir. Bu noktada proje
yönetimi, günümüzün modern yönetim anlayışlarından biri olarak karsımıza
çıkmaktadır.
14 Rory Burke, Project Management: Planning and Control Techniques, Fourth Edition, 2003.
-
13
Proje yönetimi, bu karışık düzene uygun, bürokrasiyi engelleyen, modern ve
gelişmiş bir organizasyonel form ve yönetim anlayışı olarak birçok isletmede kabul
görmektedir.15
Proje yönetimi ilk bakışta daha iyi kontrol ve değerlendirme sağlar, müşteri
ilişkilerinde mükemmelliği öngörür. Daha kısa üretim süreci, azalan maliyetler,
yüksek kalite ve güvenilirlik, yüksek kar marjları başarılı proje yönetimlerinin
çıktılarıdır. Bununla birlikte organizasyon bölümleri arasında iletişimi sağlayarak
koordinasyon çabalarına değer katar. Çalışanların birlikte hareket etmesini
sağlayarak moral değerleri korur. Bununla birlikte birtakım dezavantajları da yok
değildir. En önemli yan etkisi organizasyonel karışıklıklara sebebiyet vermesidir.
Genel anlamda proje yönetiminin isletmelere sağladığı yararlar su baslıklar
altında toplanabilir: 16
• Daha ekonomik geliştirme süreçleri sağlar
• Kaynakların daha verimli kullanılmasını ve daha etkin kontrolü sağlar
• Düşük maliyet ve yüksek kar yaratır
• Yüksek kalite ve güvenlik sağlar
• Etkin koordinasyon ve motivasyon sağlar
• Müşteri ilişkilerinde iyileştirme sağlar
• Amaç ve hedeflere ne zaman ve nasıl ulaşılacağını önceden belirler
• Sürekli raporlama gereksinimini minimum düzeye indirger
• Proje için gerekli zamanı bastan belirlemeye yardımcı olur.
15 Harold Kernzer, a.g.e., . s. 1-2 16 Burhan Albayrak, . a. g. e, s. 8
-
14
• Projenin maliyetinin önceden belirlenmesini sağlar
• Gerekli kaynakların neler olduğunu ortaya koyar
• Kullanılacak teknolojiyi açıklar
• Kontrol sisteminin kurulmasını sağlar
• Tüm görevlerin organizasyon şemalarında gösterilmesini sağlar
• Proje ekip üyelerinin proje geliştirme, uygulama ve tahmin yeteneklerinin
geliştirilmesini sağlar.
Proje yönetiminin değinilen faydalarının yanı sıra dezavantajları da
bünyesinde barındırmaktadır. Bunlar: 17
• Karmaşık organizasyon yapılarına neden oluşu
• Kuruluş politikalarının bozulması eğilimi
• Yönetim güçlüğü ve
• Personel kullanımı zorluğudur.
1.2.3. Proje Safhaları ve Proje Hayat Döngüsü
Proje hayat döngüsü proje safhalarının bir koleksiyonudur.18 Her ne kadar
farklı sektörlerde uygulanan projeler değişik hedeflere ulaşmak amacıyla
planlandıklarından birbirlerinden farklılıklar gösterseler de özünde hazırlık,
planlama, uygulama ve proje sonu gibi dört ana safhadan oluşurlar. Đlk iki safhada
17 Arthur G. Butler, a.g.e. 18 Kathy Schwalbe, a.g.e. , s.25
-
15
planlama veya fizibiliteye yoğunlaşılırken, son iki safhada hayata geçirmeye
odaklanılmaktadır. Bu durum Şekil 2’de izlenebilir.
Şekil 2 - Proje Hayat Döngüsü Safhaları
Kaynak: Kathy Schwalbe, a.g.e. , s.25
Hazırlık safhasında, proje belirlenir, amaçlar doğrultusunda değerlendirilir ve
başlangıç onayını verilir.
Planlama safhasında, detaylı proje planlaması yapılır. Proje takımı
oluşturulur. Proje sponsorları ya da müşteri tarafından onaylanan planlama sonrası
uygulama sürecine geçilir.
Uygulama safhasında, projede görev alan herkes aktif rol oynar. Projenin
planlanan tüm aşamaları bu süreçte gerçekleştirilir.
Proje sonu safhasına, üretilen ürün ya da hizmet gerçek ortamda uygulama
için teste hazır olduğunda geçilir. Proje sponsorları ve müşteri onayı ile proje teslim
edilir.
-
16
Şekil 3 - Proje Hayat Döngüsü
Kaynak: Elif Baktır , ”Proje Yönetimi”, Ekim 2002
Yukarıdaki Şekil 3’de görüldüğü gibi hazırlık ve planlama aşaması, harcanan
işgücü açısından sınırlı iken, uygulama aşaması proje kaynaklarının en yoğun
kullanıldığı aşamadır.
Bu çalışmanın kapsamı bilgi teknolojileri proje yönetimi olduğundan proje
hayat döngüsü, yazılım geliştirme süreci açısından ele alınacaktır. Uygulama
geliştirme açısından incelendiğinde yazılım geliştirme süreci, iş gereklerinin yazılım
ürünlerine dönüşmesi için gerekli olan faaliyetlerinin tanımlanması ve sonrasında iş
gereklerindeki bu değişikliklerin yazılım ürününe çevrilmesidir.19
19 Pierre Boutquin, Diane Poremsky, Ken Slovak, Beginning Visual Basic 6 Application Development, Wrox Press, 2000, UK, s.25
-
17
Yazılım geliştirme süreci sadece kod yazma olarak düşünülmemelidir. Bu
başlık altında yazılım proje yönetimi için test etme, bakım, dokümantasyon, kullanıcı
eğitimi ve benzeri yapılandırılmış safhalar tanımlanmıştır. Đşte bahsedilen bütün bu
faaliyetler yazılım geliştirme hayat döngüsü (Software Development Life Cycle-
SDLC) olarak adlandırılır. Birçok yazılım geliştirme metodu olmasına rağmen bu
çalışmada en önemli oldukları düşünülen iki metoda değinilecektir.
1.2.3.1. Waterfall Metodu
Waterfall Metodu bilinen en eski yazılım ürünü geliştirme tekniğidir.
1970’lerin ortalarında Amerika Birleşik Devletleri Savunma Departmanı tarafından
maliyetleri düşürme ve yazılım sistemlerinin güvenilirliğini arttırma amacıyla
geliştirilmiştir. Bu çalışmalar daha sonra Mil Spec (Military Spesification) olarak
formalleştirilmiştir.
Waterfall metodu yazılım ürünü geliştirilmesinde doğrusal bir yaklaşım izler.
Bu yaklaşımla, yapılacak işler listeler haline getirilerek safhalara ayrılır. Uygulama
adım adım her safhanın tamamlanması ile yürütülür. Herhangi bir safhada yapılacak
işlemler tamamlanmadan bir sonraki safhaya geçilmez. Uygulamanın herhangi bir
adımında kesinlikle kontrol veya test amaçlı geriye dönüş yapılmaz. Adından da
anlaşılacağı gibi kayalardan aşağı akan suyun tekrar yukarı çıkamaması gibi adım-
adım yaklaşım izlenir.
-
18
Geçmişte gerçekleştirilen uygulamalar incelendiğinde Waterfall Metodu ile
küçük çaplı uygulamalarda başarılı olunduğu görülmüştür. Ancak esnek olmayan
yapısı, dokümantasyon yükünün fazlalığı, değişikliklere izin vermemesi, maliyet ve
güvenilirlik ile ilgili problemlerde çözüm kapasitesinin kısıtlı olması nedeniyle
kapsamlı uygulamaların geliştirilmesine elverişli değildir. Yine de bugüne kadar bir
çok yazılım ürünün geliştirilmesinde Waterfall Metodu kullanılmıştır.
Waterfall Metodu aşama temelli bir yöntemdir. Uygulamada bir aşamada
bitmeden diğer aşamaya geçişi yasaklayan mesafe taşları (Milestones) vardır. Bu
aşamalar kendi içinde tanımlama, analiz, dizayn, yapılandırma, test, geçiş ve üretim
gibi bölümlere ayrılır. Aşağıda Waterfall sürecini gösteren diyagram yer almaktadır
(Şekil 4):
-
19
Şekil 4 - Waterfall Metodu Akış Şeması
Kaynak: Boutquin, Poremsky, Slovak, a.g.e., s.27
Waterfall Metodu akış şemasında belirtilen adımları açıklarsak;
• Tanımlama, projenin hedeflerinin kararlaştırıldığı adımdır. Bu aşamada
projenin vizyonu ve misyonu ortaya konur.
• Analiz, projenin hedeflerinin gerekleri ile uyumunun incelendiği safhadır.
Analiz safhasında yönetim hedeflerinin yöneticiler tarafından
kararlaştırılmasına özen gösterilmelidir. Bu gerekleri analiz etmek, iş
kurallarının oluşturulması, süreçlerin tasarlanması ve sonuç olarak projenin
başarısı için çok önemlidir.
• Tasarım safhasında bir önceki safhada kararlaştırılan kurallar ve gerekler
mantıksal tasarıma dönüştürülür. Đstenirse kararlaştırılan mantıksal tasarım,
akış diyagramlarına da dönüştürülebilir. Kullanıcı arabirimleri bu safhada
kararlaştırılır ve tasarlanır. Esas olarak tasarım safhasında bir sonraki
-
20
yapılandırma safhasının girdileri oluşturulur. Bütün proje için kullanılacak
dokümantasyon bu safhada oluşturulur.
• Yapılandırma, tasarım safhasının aktif koda dönüştürülmesidir. Veritabanı
tasarımı, kullanıcı arayüzü tasarımı, algoritma tasarımı farklı uzmanlar
tarafından gerçekleştirilmelidir.
• Test safhası da analiz gibi önemli safhalardan biridir. Uygulamayı geliştiren
ve kullanıcılardan seçilerek oluşturulan grup tarafından test işlemi
gerçekleştirilir. Hatalar şiddetlerine göre sınıflandırılır. Veri kaybına yol
açacak veya uygulamanın çalışmasını engelleyecek hatalar hemen onarılır.
Projenin akışını çok etkilemeyecek veya düzeltilmesi başka hataların
doğmasına yol açabilecek hatalar daha sonra düzeltilmek üzere ertelenebilir.
• Geçiş, geliştirilen ürünün kullanıcılara tanıştırıldığı safhadır. Mevcut
sisteme alışmış olan bir çok kullanıcı yeni sisteme uyum sağlamakta zorluk
çekecek, bu nedenle de yeni sisteme karşı direnç gösterecektir. Kullanıcılar
yeni sistemi rahatlıkla kullanmaya başlayana kadar eğitim görürler.
• Gerçekleştirim, yeni yazılımın tamamlandığı, kullanıcıların makinelerine
yüklendiği ve kullanıcılar tarafından rahatlıkla kullanıldığı safhadır.
1.2.3.2. Tekrarlı Metodlar
Daha önceki baştan savma yöntemlere kıyasla Waterfall Metodu yazılım
ürünlerinin geliştirilmesinde büyük bir atılımdı. Ancak, yazılım geliştirme
masraflarını arttırması, projenin önceden belirlenen takvimden geç bitimine yol
-
21
açması, ayrıca ürünün yapılandırılması sırasında esnek davranılamaması ve bu
sebeple güvenilirliğinin düşük olması gibi nedenlerden dolayı bu metod terk
edilmiştir. Bu dezavantajları, 1988 yılında Barry W. Boehm isimli teorisyenin
geliştirdiği Spiral Model ortadan kaldırılmış ve yazılım ürünlerinin geliştirilmesinde
formal tekrarlı tekniklerin kullanımının başlangıcı olmuştur. Waterfall metodunun
aksine, tekrarlı tekniklerin spiral yapıları sayesinde ihtiyaç olduğunda önceki
safhalar tekrar ziyaret edilebilir. Aşağıda spiral geliştirme prosesini gösteren akış
şeması yer almaktadır (Şekil 5):
Şekil 5 - Tekrarlı Teknikler Akış Şeması
Kaynak: Boutquin, Poremsky, Slovak, a.g.e. ,s.29
-
22
Bu bölümde adı geçen uygulama geliştirme süreçleri organizasyonların proje
yönetimi konusunda birikim sahibi olmaları ile birlikte ortaya çıkacak sistem
geliştirme metodolojileri için bir altyapı oluşturmaktadır. Bahsedilen Waterfall
metodu, geleneksel sistem geliştirme hayat döngüsüne örnek olmakla birlikte ilk
geliştirilen ve uzunca bir süre birçok proje yönetiminde kullanılan bir teknik
olmuştur. Ancak gelişen iş çevrelerinin ve çevre koşullarının çok hızlı bir değişim
içerisinde olması yeni teknikler geliştirilmesini zorunlu kılmış, böylelikle iteratif
teknikler sistem geliştirme projelerinde uygulanmaya başlanmıştır. Başlıca tekrarlı
teknikler Hızlı Uygulama Geliştirme(RAD), Nesne Yönelik Analiz ve Tasarım ve
Prototip Geliştirmedir.
BÖLÜM II. PROJE YÖNETĐMĐ BĐLGĐ ALANLARI
Proje hayat döngüsü hazırlık, planlama, uygulama ve kapanış gibi birbirine
bağımlı ve birbirini takip eden aşamalardan oluşurken, proje yönetim süreci hiyerarşi
ya da öncelik sırası olmaksızın birbirini tamamlayan fonksiyonlar olan kapsam,
zaman, maliyet, kalite, insan kaynakları, iletişim, risk ve satınalma yönetiminden
oluşmaktadır (Şekil 6).
Proje yöneticileri için amaç sadece kapsam, maliyet, zaman ve kalite
hedeflerini sağlamak olmamalı, bunun yanında bütün sürecin işleyişini kolaylaştıran
bir yaklaşımla projede görevli veya beklentileri olan kişilerin gereksinim ve
beklentilerini karşılama yönünde bir tutum sergilenmelidir.
-
23
Đhtiyaçlar ve beklentiler, projenin yürütülmesinde rol alan proje ekibi,
projeden beklentisi olan finansör veya müşteriler, tedarikçiler, destek ekibi ve
kullanıcıların ihtiyaç ve beklentilerini temsil etmektedir. Projenin ortaya çıkışında
itici güç bu kişilerin ihtiyaç ve beklentileridir ki bu durum projenin başlangıç
safhasında büyük önem taşımaktadır. Proje yöneticileri bu kişiler ile iyi iletişim
halinde olmaya özen göstermelidir. Đhtiyaçlar ve beklentiler uyumlaştırılmalıdır.
Şekil 6 - Proje Yönetimi Đskeleti
Kaynak: Kathy Schwalbe, a.g.e., s.8
Bilgi alanları, proje yöneticilerinin geliştirmek zorunda oldukları yetenekleri
temsil eder. Öz fonksiyonlar projelerin başarıya ulaşması için gereken spesifik bilgiyi
temin ederken, kolaylaştırıcı fonksiyonlar hedeflere ulaşılıp ulaşılmadığının analiz
edilmesine yardımcı olur. Bu bilgi alanlar aşağıda listelenmekte ve Şekil 6’da
görülmektedir:
• Proje Entegrasyonu Yönetimi, fonksiyonlar arasındaki ilişkiyi sağlar,
-
24
• Proje Kapsam Yönetimi, başarılı bir biçimde projenin tamamlanması için
gerekli bütün iş süreçlerinin tanımlanmasıdır.
• Proje Zaman Yönetimi, projenin tamamlanması için geçecek sürenin
belirlenmesi, uygulanabilir bir takvimin oluşturulmasını içerir.
• Proje Maliyet Yönetimi, proje bütçesinin oluşturulması ve
yönetilmesinden oluşur.
• Proje Kalite Yönetimi, garanti edilen ihtiyaç ve beklentilerin
karşılanmasını sağlar.
• Proje Đnsan Kaynakları Yönetimi, proje ile ilişkili kişilerin seçimi,
yönetimi ve koordinasyonu ile ilgilenir.
• Proje Đletişim Yönetimi, proje için gerekli bilginin oluşturulması,
biriktirilmesi, paylaştırılması ve saklanmasını içerir.
• Proje Risk Yönetimi, projenin başarıya ulaştırılması ile ilgili risklerin
tanımlanması, analiz edilmesi ve yanıtlanması ile ilgilenir.
• Proje Temin Yönetimi, projenin ihtiyaç duyduğu organizasyon dışı
kaynakların teminin yönetimidir.
• Araçlar ve Teknikler proje yöneticilerini kapsam, zaman, maliyet ve kalite
hedeflerine ulaşmada desteklerler.
Đzleyen bölümde sözü edilen bu bilgi alanları ele alınacaktır.
2.1. Proje Bütünleştirme (Entegrasyon) Yönetimi
-
25
Proje bütünleştirme\entegrasyon yönetimi, proje hayat döngüsü boyunca
diğer proje yönetimi bilgi alanları olan kapsam, kalite, zaman, maliyet, insan
kaynakları, iletişim, risk ve tedarik süreçleri arasındaki koordinasyonu sağlar. 20
Diğer bir deyişle proje bütünleştirme yönetimi, projenin başarılı bir biçimde
tamamlanabilmesi için projenin bütün unsurlarının doğru zamanda bir araya
gelebilmesini garanti etmektedir. Her ne kadar proje bütünleştirme yönetimi, proje
yönetiminde son fonksiyon olarak düşünülse de, proje yönetiminin omurgasını
oluşturması sebebiyle proje yönetimi içerisinde yer alan dokuz bilgi alanının ilki
olarak incelenmektedir.
Proje Bütünleştirme Yönetimi aşağıdaki üç süreçten oluşmaktadır:
• Proje plan geliştirme
• Proje plan uygulama
• Bütünleşik değişim kontrolü
2.1.1. Proje Plan Geliştirme
Proje plan geliştirme, diğer planlama süreçlerinin çıktılarının alınması ve bu
çıktıların proje planı olarak adlandırılan uygun, tutarlı bir belge haline getirilmesi
işlemidir. 21 Proje plan geliştirme sonucunda elde edilen dokümanlar diğer proje plan
belgelerinin koordinasyonuna yardımcı olurken, projenin yürütülebilmesi ve
20 Kathy Schwalbe, a.g.e., s.50 21 a.g.e.,s.51
-
26
kontrolü için bir rehber vazifesi görür. Proje planları aynı zamanda proje planlama
varsayımlarını ve seçeneklere bağlı olarak verilecek kararları belgeler, proje ekibinin
iletişimini kolaylaştırır, kapsamı belirler, projenin ilerleme durumu konusunda temel
oluşturur. Planlar mutlaka çevrede gerçekleşecek değişikliklere uyum sağlayacak
şekilde dinamik yapıda olmalı, ana hatları ile yapılacak işlere rehberlik etmeli,
sadece gerektiğinde detaylandırılmalıdır.
Her proje diğerlerinden farklı olduğu gibi proje planları da farklıdır. Buna
rağmen, tüm proje planlarında yer alması gereken ortak unsurlar vardır. Bunlar: 22
• Giriş
• Tanımlama
• Đdari ve teknik süreçler
• Çıktılar
• Zaman ve
• Maliyettir.
Söz konusu bu unsurların içinde yer alması gereken öğeler de şu şekilde ifade
edilebilir. Giriş kısmında:
• Proje Adı, her proje spesifik bir isme sahiptir. Spesifik olması aynı
organizasyon içerisindeki diğer projelerden ayırt edilmesini sağlar.
• Tanım, projenin yapılış amacını belirtir. Tanımlama esnasında, teknik
terimlerden kaçınılmalı, herkesin anlayabileceği biçimde yalın ifadeler
kullanılmalı ve kabaca zaman ve maliyet tahminleri de yapılmalıdır.
22 Kathy Schwalbe, a.g.e., s.53
-
27
• Müşteri/Sponsor Adı, müşterinin/sponsorun isim, ünvan ve irtibat bilgilerini
içerir.
• Proje yöneticisinin ve kilit takım üyelerinin isimleri, proje ile ilgili bilgiye
ihtiyaç duyulduğunda irtibata geçilecek en önemli kişi proje yöneticisi
olduğundan gerekli öz bilgi mutlaka yer almalıdır. Hatta büyük projelerde
önemli takım elemanlarının da bilgileri buraya eklenebilir.
• Çıktılar, projenin sonucunda üretilecek ürünleri listelemektedir
• Danışma Bilgileri, her proje bir geçmişe sahiptir. Önemli belgeler ve yapılan
toplantı kayıtları proje geçmişi hakkında bilgi verecektir.
• Terminoloji, proje planları farklı endüstriler için oluşturulabileceğinden ilgili
terminolojik bilgiler gerektiğinde eklenmelidir.
Tanımlama kısmında:
• Organizasyon Şeması, yetki, sorumluluk ve iletişimin sınırlarını tanımlar.
Firmanın organizasyon şemasının yanında müşterinin/sponsorun
organizasyon şeması da mutlaka eklenmelidir.
• Sorumluluklar, ana proje fonksiyonlarını, faaliyetleri ve bu faaliyetlerden
kimlerin sorumlu olduğunu tanımlar.
• Diğer Bilgiler, organizasyon içerisindeki kişiler veya müşteri/sponsor için
projenin işleyişi hakkında bilgi sunar.
-
28
Đdari ve Teknik Süreçler kısmında:
• Đdari Hedefler, üst düzey yöneticilerin proje hakkındaki görüş ve beklentileri
tanımlanır. Öncelikler ve kısıtlar belirlenir.
• Kontroller, projenin nasıl izleneceği ve meydana gelebilecek değişikliklerin
nasıl ele alınacağı belirlenir.
• Risk Yönetimi, risklerin nasıl tanımlanacağı, yönetileceği ve kontrol
edileceği açıklanır.
• Personel Temini, projede görev alacak kişilerin sayı ve nitelikleri tanımlanır.
• Teknik Süreçler, projede kullanılacak spesifik metodolojiler tanımlanır,
bilginin nasıl saklanacağı ve belgeleneceği konusunda açıklamalarda
bulunulur.
Çıktılar kısmında:
• Ana Đş Paketleri, projede yapılacak işler Đş Dağılım Yapısı (Work
Breakdown Structure-WBS) ve Đş Tanımı (Statement of work-SOW)
kullanılarak iş paketleri haline getirilir. Kapsam yönetimi açısından
önemlidir.
• Ana Çıktılar, müşteri ve sponsora teslim edilecek ana ürün tanımlanır. Kalite
beklentilerinin anlaşılması açısından önemlidir.
• Diğer Bilgiler, izlenmesi gereken önemli faaliyetler veya kullanılması
gereken spesifik araçlar tanımlanır.
Zaman kısmında:
• Özet Takvim, Gannt Şeması ile proje sadece ana hatları ile listelenir.
-
29
• Detaylı Takvim, özet takvimde ana hatları ile tasvir edilen proje en ince
ayrıntısına kadar detaylandırılır. Proje zaman yönetimi açısından önemlidir.
Proje akış diyagramı ve PERT şeması detaylı takvime eklenebilir.
• Diğer Bilgiler, proje takvimleri oluşturulurken yapılan varsayımlar açıklanır.
Maliyet kısmında:
• Özet Bütçe, bütün projenin maliyeti yaklaşık olarak tahmin edilir. Bu
tahminleme aylar veya yıllar için dönemsel olarak oluşturulabilir.
• Detaylı Bütçe, projenin yürütülmesi ile ilgili bütün maliyetler ayrıntıları ile
açıklanarak detaylı bir bütçe oluşturulur. Maliyet yönetimi açısından burada
ortaya çıkacak planın sonuçları büyük önem taşımaktadır. Projenin
gerçekleştirilmesinin finansal yararları eklenebilir.
• Diğer Bilgiler, bütçe oluşturulurken yapılan ana varsayımlar açıklanır.
Proje yönetiminin temel hedefinin müşteri/sponsor memnuniyeti olması
sebebiyle müşteri/sponsor analizi de proje planına eklenebilir. Müşteri/sponsor
analizi, bu kişi veya kurumun isim, organizasyon gibi öz bilgilerini içerir. Aynı
zamanda müşteri veya sponsorun proje ile ilişkilerini, eğer birden fazla iseler bu
ilişkilerin derecesini, proje üzerindeki etkilerini ve bu kişi veya kurumlarla iyi
ilişkiler yürütmek için dikkate alınması gereken hususları sıralar. Bu bilgiler özel
bilgiler olduğundan sadece proje yöneticisi ve birkaç önemli proje takım elemanı
tarafından görülebilmelidir.
-
30
2.1.2. Proje Plan Uygulama
Proje bütünleştirme yönetimi’nin ikinci süreci olan proje plan uygulama,
proje planında tanımlanan işlerin yerine getirilmesi işlemidir. 23 Proje hayat
döngüsünün en uzun safhasıdır ve maliyetlerin büyük bir kısmı bu safhadan
kaynaklanır. Proje ekibi proje planı çerçevesinde bilgi ve tecrübelerini kullanarak
hedeflenen ürünün üretilmesini ve test edilmesini gerçekleştirir. Proje entegrasyon
yönetimine göre proje plan geliştirme ve proje plan uygulama safhaları birbirinden
ayrılmaz faaliyetlerdir. Ürünü ortaya koyacak ekibin planı tasarlamasının, proje plan
ve uygulama safhaları arasındaki koordinasyonu sağladığına inanılır. 24
Bu gibi yeteneklerin yanında proje planını uygulama, bazıları proje
yönetimine has olan araç ve teknikler de gerektirmektedir. Bu araç ve teknikler:
• Đş Yetkilendirme Sistemi, proje ekibi elemanlarının görevlerini tam ve
zamanında yerine getirebilmelerini garanti eder.
• Durum Gözden Geçirme Toplantıları, proje ekibindeki elemanların düzenli
olarak bir araya gelerek fikir alışverişinde bulundukları toplantılardır.
• Proje Yönetimi Yazılımı, proje planlarının yapılması ve uygulanmasında
kullanılan yazılım araçlarıdır.
23 Kathy Schwalbe, a.g.e. , s.59 24 Kathy Schwalbe, a.g.e. , s.62
-
31
2.1.3. Bütünleşik Değişim Kontrolü
Bütünleşik değişim kontrolü, proje hayat döngüsü boyunca değişikliklerin
tanımlanması, değerlendirilmesi ve yönetilmesini içermektedir. 25 Değişime neden
olan faktörler anlaşılmaya çalışılır, değişimin fayda getirdiğinden emin olunmakta;
değişim fark edildiğinde, değişimin yönetilmesi için faaliyetlere hazırlanılmaktadır.
Bütünleşik değişim kontrolü, proje planlarını, performans raporlarını,
değişiklik isteklerini girdi olarak almakta ve güncellenmiş proje planlarını, düzeltici
aksiyonları ve öğrenilmiş derslerin dokümantasyonunu çıktı olarak üretmektedir.
Proje planları, proje değişikliklerinin belirlenmesi ve kontrol edilmesi için
altyapıyı oluşturmaktadır. Proje takımı, işin planlanan şekilde yapılmasına
odaklanmalıdır. Projenin uygulanması esnasında değişiklik olması durumunda, proje
planlarının da güncellenmesi gerektiği unutulmamalıdır.
Proje performans raporları, projenin gidişatı hakkında bilgi vermektedir. Bu
raporların esas hedefi gelecekte gerçekleşebilecek muhtemel problemlere karşı proje
yöneticisini ve ana proje ekibi elemanlarını uyarmaktır. Proje yöneticisi ve proje
takımı, ne zaman, hangi düzeltici faaliyetin yapılması gerektiğine birlikte karar
vermelidirler.
Proje planında yapılan değişikliklerin kapsamda değişiklere yol açması
neticesinde doğal olarak diğer bir çok bilgi alanı da etkilenecektir (takvimin
25 Project Management Institute Standarts Committee, a.g.e., s.44
-
32
değişmesi, maliyetlerin artması vs.). Proje hayat döngüsü boyunca ortaya çıkabilecek
değişiklikler değişim kontrol sistemi vasıtasıyla yönetilir. Değişim kontrol sistemi,
proje dokümanlarının ne zaman ve nasıl değişebileceğinin formal bir biçimde
belgelendirmesi sürecidir. Aynı zamanda bu sistemde değişiklik yapmaya yetkili
elemanlar, projede meydana gelebilecek değişimleri izleyebilmek için takip edilecek
manuel veya otomatik metotlar ve gerekli dokümantasyon tanımlanır. Genellikle
projelerde yapılacak değişikliklere değişim kontrol heyeti karar verir. Değişim
kontrol heyeti, değişiklikleri onaylama veya reddetme hakkına ve sorumluluğuna
sahip olan, proje ekibi elemanlarından kurulu formal bir gruptur.
Yukarıda bahsedilen bilgiler ışığında iyi bir bütünleşik değişim kontrolü için
aşağıda verilen maddeler sıralanabilir: 26
• Proje yönetimi iletişim ve uzlaşma süreci olarak görülmelidir,
• Değişimler için plan yapılmalıdır,
• Đçerisinde değişim kontrol heyetinin de bulunduğu formal bir değişim kontrol
sistemi kurulmalıdır,
• Đyi bir düzen/yapılanış yönetimi kullanılmalıdır,
• Küçük değişiklikler konusunda zamanında karar alınabilmesi için prosedürler
tanımlanmalı ve yazılı ve sözlü performans raporları kullanılmalıdır. Bu
değişimin tanımlanmasını ve yönetilmesini kolaylaştıracaktır,
• Proje yönetimi yazılımları kullanılmalıdır.
26 Kathy Schwalbe, a.g.e., s. 76
-
33
Her ne kadar değinilen konular proje yönetiminde önemli olsa da başarılı
proje yönetimi için kritik nokta liderliktir. Liderlik vasfı, proje yöneticisinde mutlaka
bulunması gereken bir özelliktir. Bu özelliği sayesinde proje yöneticisi projenin
başarısı için takım elemanlarını motive edebilmektedir.
2.2. Proje Kapsam Yönetimi
Proje yönetiminin en önemli ve en zor konularından bir tanesi projenin
kapsamının belirlenmesidir. Kapsam, bir ürünün üretilebilmesi için yapılması
gereken tüm işler ve bu işlerin yapılış süreçlerini ifade eder. Proje yönetiminde
kapsam sözcüğü iki farklı kavramı temsil eder, ürün kapsamı ve proje kapsamı.27
Ürün kapsamı ürünün özelliklerini ve hangi fonksiyonları içermesi gerektiğini
tanımlarken; proje kapsam yönetimi, projeye nelerin dâhil olup olmayacağının
belirlenmesi ve kontrol edilmesidir.28 Aralarındaki bir başka önemli fark ise ürün
kapsamı, ihtiyaçlar neticesinde belirlenirken proje kapsamı, proje planı neticesinde
belirlenir.
Proje ekibi ile müşterinin/sponsorun proje sonucunda ortaya konacak ürün ve
bazı durumlarda ürününün nasıl üretileceği hakkında aynı görüşte uzlaşmaları
neticesinde proje kapsamı tanımlanmış olur.
27 Project Management Institute Standarts Committee, a.g.e., s.44 28 Kathy Schwalbe, a.g.e., s.84
-
34
Proje kapsam yönetimi, proje kapsamı içinde olan ve olmayan noktaların
tanımlanması ve kontrol edilmesi süreçlerini içerir. Kapsamın belirlenmesinde
projenin içereceği kavramların netleştirilmesi ve hem proje ekibi hem de müşteri
tarafından aynı şekilde anlaşılması kadar projenin kapsamına dahil edilmeyen
noktaların da belirlenmesi projenin başarısı açısından önemlidir. Projenin başarısız
olma sebepleri arasında en önemli sebep olarak projenin tanımının net olarak
yapılmaması ve kapsamının doğru olarak tanımlanmaması gösterilmektedir. 29
Uygulama alanına göre kullanılan teknikler farklılık gösterse de proje kapsam
yönetimi :
• Başlangıç,
• Kapsam planlama,
• Kapsam tanımlama,
• Kapsam doğrulama ve
• Kapsam değişim kontrolünden oluşmaktadır.
2.2.1. Başlangıç
Kurumun stratejik planını incelemek veya büyük resmi görmeye çalışmak
hangi türdeki projelerin en faydalı olacağının kararının verilmesinde ve iş
ihtiyaçlarıyla projelerin hizalandırılmasında çok önemlidir. Bu sebeple projelerin
başlangıç aşaması, potansiyel projelerin belirlenmesi, projelerin seçiminde gerçekçi
29 Chalfin, Natalie, Four Reasons Why Project Fail, PM Network, PMI (June 1998) 7
-
35
yöntemlerin kullanılması ve başlangıç safhasının resmiyete dökülmesi aşamalarını
içerir.
2.2.1.1. Potansiyel Projelerin Belirlenmesi
Kapsam yönetimindeki ilk iş projelerin hangi sırada yapılacağı kararının
verilmesidir. Şekil 7’de dört aşamalı Bilgi Teknolojileri (BT) projelerinin seçimi
süreci yer almaktadır. Yukarıdan aşağıya olmak üzere, BT planlama sürecindeki ilk
adım kurumun stratejik planını temel alan BT stratejik planını oluşturmaktır.
Stratejik planlama, bir organizasyonun güçlü ve zayıf taraflarını analiz ederek uzun
dönemli hedeflerini tespit etmektir. Stratejik planlama için en çok kullanılan
araçlardan biri SWOT analizidir.
BT stratejilerinin belirlenmesi sürecine, BT departmanları dışından
yöneticilerin de katılması, BT çalışanlarının kurumun stratejilerini algılaması ve
süreçte etkileşim içerisinde olacakları iş alanlarının belirlenmesi açısından önemlidir.
Odaklanılacak iş alanlarının belirlenmesi sonrasındaki ikinci adım iş etki analizinin
yapılmasıdır. Đş etki analizi sonrasında BT planlama süreci, potansiyel projelerin,
proje kapsamlarının, faydalarının ve kısıtlarının belirlenmesi ile devam etmektedir.
Son adım olarak da uygulamaya alınacak projelerin belirlenmesi ve bu projelere
kaynakların atanması yer almaktadır.
-
36
Şekil 7 - Bilgi Teknolojileri (BT) Planlama Süreci
Kaynak: Kathy Schwalbe, a.g.e., s.86
BT projeleri planlama sürecinin kurumun stratejisinin analiziyle başlaması
çok önemlidir. Kurum içerisinde, bilgi teknolojilerinin kurumun iş hedeflerine
ulaşmasında nasıl etki yapacağının belirlenmesi gereklidir. BT stratejileri, kurumun
iş stratejilerinden hareketle belirlenmeli ve hizalanmalıdır. BT projelerinin
belirlenmesi ve seçilmesi kurumun iş stratejileri doğrultusunda yapılmalıdır.
Yeni bir projenin ortaya çıkışı bazen işletme gereksinimlerinden, bazen
müşteri taleplerinden, bazen teknolojik gelişmelerden bazen de pazar fırsatlarından
kaynaklanabilir. Her bir firma için, her bir endüstri kolu için hatta her bir proje için
bu alternatiflerin öncelik sırası farklı olsa da bir projeye yatırım yapma nedenleri
1992 yılında James Bacon tarafından seksen organizasyon üzerinde yapılan bir
araştırma sonucu aşağıda verilen on beş madde üzerinde yoğunlaşmıştır.30 Firmaların
30 James Bacon, The Use of Decision Criteria in Selecting Information Systems/ Technology Investments, http://www.terry.uga.edu/misq/MISQ/V16/V16n3art4.html
-
37
proje seçiminde karar verme aşamasında göz önünde bulundurdukları kriterler
öncelik sıralarına göre verilmektedir.
1. Organizasyonun açık hedeflerini desteklemesi
2. Đyi bir iç verim oranına (ĐVO) sahip olması
3. Organizasyonun gizli hedeflerini desteklemesi
4. Đyi bir net bugünkü değere (NBD) sahip olması
5. Kabul edilebilir geri ödeme periyodunun olması
6. Rekabetçi sistemlere cevap vermede kullanılması
7. Karar destek sistemlerini desteklemesi
8. Bütçe kısıtlarını karşılaması
9. Organizasyonun bu projeden fayda sağlama olasılığının yüksek olması
10. Muhasebe açısından iyi bir getiriye sahip olması
11. Projenin tamamlanma olasılığının yüksek olması
12. Teknik/Sistem gereklerin karşılanması
13. Yasal gereklerin desteklemesi
14. Đyi bir kar endeksine sahip olması
15. Organizasyona yeni teknolojiyi tanıştırması
Uzun dönemde firmaların ayakta kalışı yaptıkları kusursuz proje seçimleri ile
mümkün olduğundan proje yönetimi konusunda titizlikle davranılmalı,
organizasyonun hedeflerine en uygun maddeler baz alınarak bu tercih
gerçekleştirilmelidir. Bu noktada ise etkin proje seçme tekniklerine ihtiyaç
duyulmaktadır.
-
38
2.2.1.2. Proje Seçiminde Kullanılan Metodlar
Proje seçim teknikleri kendi yeteneklerine göre karı maksimize etme, maliyetleri
minimize etme, kaynak kullanımını maksimize etme veya organizasyonun rekabet
gücünü arttırma gibi özelliklere sahip olabilirler. Ancak bir firma proje seçim
tekniğini belirlerken aşağıda verilen kriterler önem taşımaktadır.31
1. Gerçekçilik: Seçilecek model mutlaka proje yöneticisinin kararlarını
yansıtmalı, aynı zamanda firma ve firma yöneticilerinin hedeflerini
onaylamalıdır.
2. Kabiliyet: Model kararı optimize edecek biçimde gelişmiş olmalıdır.
Đsteklere cevap verebilmelidir.
3. Esneklik: Model değişen vergi kanunları, yeni teknolojiler veya yeni
hedefler gibi değişen çevre koşullara karşı kolaylıkla uyum sağlayabilmelidir.
4. Kullanım Kolaylığı: Model uygulama kolaylığına sahip olmalı, hayata
geçirmesi uzun zaman almamalıdır.Aynı zamanda modelin parametreleri
gerçek hayatın parametreleri ile uygunluk göstermelidir.
5. Maliyet: Veriyi bir araya getirme ve modelleme maliyetleri düşük olmalıdır.
6. Bilgisayar Kullanımı: Değişen teknolojik çevre, proje yönetiminde
bilgisayar kullanımını bir zorunluluk haline getirdiğinden, eldeki veriyi
veritabanlarında saklamak ve proje amaçları doğrultusunda yönlendirmek
kolay olmalıdır.
31 Jack R. Meredith, Samuel J. Mantel, Project Management/ A Managerial Approach , John Wiley&Sons, 1995, s.42
-
39
Genel anlamda proje seçim teknikleri nümerik ve nümerik olmayan teknikler
olarak iki ana kategoriye ayrılabilir. Birçok organizasyon her ikisini aynı anda
kullanmaktadır.
Nümerik olmayan teknikler nümerik tekniklerin aksine daha eskidirler ve
kullanımları daha kolaydır. Nümerik teknikler ile aralarındaki belirgin fark girdi
değerlerinin sayısal olmaması ve sübjektif değerlemeler içermeleridir.
Nümerik olmayan teknikler; Sacred Cow Yöntemi, Đşletme Đhtiyacı Modeli,
Rekabet Đhtiyacı Modeli, Ürün Hattı Genişletme Modeli, Mukayeseli Fayda
Modeli’dir.
Nümerik tekniklerin, nümerik olmayan tekniklerin aksine girdi değerleri
sayısaldır ve karşılaştırma bu sayısal değerler arasında daha kolay yapılabildiğinden
objektiftirler. Nümerik tekniklerin büyük bir çoğunluğu organizasyona sağlanan
finansal getiriyi ölçerken bir kısmı da matematik modelleri ve optimizasyon
tekniklerini kullanmaktadırlar.
Nümerik teknikler; Geri Ödeme Süresi, Ortalama Verim Oranı, Net Bugünkü
Değer, Đç Verim Oranı, Ağırlıklandırılmış Faktör Derecelendirme Modeli’dir.
-
40
2.2.2. Kapsam Planlama
Kapsam planlama, gelecekte projenin safhalarının başarı ile tamamlandığına
karar verilebilmesine yardımcı olmak için yazılı bir kapsam bildirisi (scope
statement) geliştirme sürecidir.32
Hangi projenin yapılacağına karar verildikten sonra uygulanacak projelerin
organizasyona duyurulması ve tanıtılması organizasyonun desteğini alabilmek
açısından önemli bir adımdır. Proje bildirisi, projenin hedeflerine ve yönetimine yön
veren, projenin varlığının formal olarak onaylanmasını sağlayan belgedir.33
Proje bildirisinin kısa ve öz olmasına dikkat edilmeli mümkünse bir sayfayı
geçmemelidir. Proje bildirileri genellikle hazırlanması zor olmayan belgelerdir. Bu
safhanın zor olan yanı organizasyon içerisinde projenin formal olarak kabulünü
sağlayabilmektir.
2.2.3. Kapsam Tanımlama
Kapsam tanımlama kapsam planlamada belirtilen maddelerin daha ayrıntılı
bir biçimde ele alınarak yönetilebilir parçalara ayrılmasıdır.
Genel anlamda kapsam tanımlama safhasında ana proje çıktıları daha küçük
ve daha yönetilebilir bileşenlere ayrılır. Girdi olarak kapsam bildirisi, kısıtlar,
32 Project Management Institute Standarts Committee, a.g.e., s.51 33 Kathy Schwalbe, a.g.e., s.96
-
41
tahminler ve diğer planlama girdileri kullanılırken, çıktı olarak iş dağılım yapısı elde
edilir.
2.2.3.1. Đş Dağılım Yapısı
Đş dağılım yapısı projenin tüm kapsamını, yapılacak işleri tanımlayan sonuç
bazlı bir analizdir.34 Yapı olarak organizasyon şemalarına benzemekle birlikte,
projenin yapısını görselleştirdiğinden ilgili kişilerin projeyi anlamalarını
kolaylaştırmaktadır. Ürün ve safha bazında düzenlenebilen iki çeşidi mevcuttur. Đş
dağılım yapısı, proje ekibinin zaman ve maliyet yönetimini gerçekleştirebilmesi için
projeyi iş paketlerine ayrıştırır.35 Hiyerarşinin en alt seviyesinde genelde iş paketi
yer alır. Đş paketi, projenin alt ürünlerini gösteren ve bu ürünün ortaya çıkması için
yapılacak işlerin tümünü içeren işler grubudur.36
Dikkat edilmesi gereken bir nokta iş dağılım yapısının proje takvimi ile
karıştırılmamasıdır. Çünkü iş dağılım yapısı proje zaman yönetimi
gerçekleştirilmeden önce tasarlanır. Đş dağılım yapısı yapılacak işler arasındaki
hiyerarşiyi gösterirken, iş paketleri arasındaki akış veya bağımlılığı ortaya
koymamaktadır.
Đş dağılım yapısının oluşturulması ve gözden geçirilmesi süreçlerinde proje
takımının ve müşterinin yer alması önemlidir. Böylece projenin tamamlanabilmesi
34 Kathy Schwalbe, a.g.e., s.100 35 Greg Githens, Using The WBS to Define and Manage Work Scope , http://www.pdma.org/visions/print.php?doc=jul98/githens.html, 36 Bilişim Projeleri Yönetimi Çalışma Grubu, Bilişim Projelerinin Yönetimi, Ankara, Türkiye Bilişim Derneği Yayınları, 1999, s.42
-
42
için yapılması gerekenlerin herkes tarafından anlaşılması ve nasıl yapılacağı
kararının verilmesi sürecinde tarafların yer alması sağlanır.
Đş Dağılım Yapısı oluşturmanın çeşitli yöntemleri vardır. 37 Bunlar:
• Kılavuzlardan yararlanmak
• Benzerlik yaklaşımı
• Yukarıdan aşağıya doğru yaklaşımı
• Aşağıdan yukarıya doğru yaklaşımıdır.
Đş dağılım yapısı oluşturmanın kılavuzunun olduğu durumlarda, bu
kılavuzlardan yararlanmak kolaylık sağlamaktadır. Örneğin Amerika Birleşik
Devletleri Savunma Bakanlığı, kendi bünyesindeki bazı projeler için iş dağılım
yapısının şeklini ve içeriğini ortaya koyan bir çalışma yapmıştır. Bu kılavuzda, proje
önerilerinin iş dağılım yapısında yer alan tüm işlerin maliyet tahminlerini içermesi ve
proje maliyetinin iş dağılım yapısındaki tüm işlerin maliyet tahminlerinin
toplanmasıyla elde edilmesinin gerekliliği vurgulanmaktadır.
Đş dağılım yapısı oluşturmanın diğer bir şekli de benzerlik yaklaşımıdır.
Benzerlik yaklaşımında kurum önceki deneyimlerinden yararlanmakta ve yeri
projenin iş dağılım yapısını oluşturmada önceki benzer projelerin iş dağılım
yapılarından faydalanmaktadır.
37 Kathy Schwalbe, a.g.e., s.104
-
43
Yukarıdan aşağıya doğru yaklaşımında projenin ana bileşeni her seviyede
detaylandırılarak daha küçük parçalara ayrılmakta ve bu çalışma iş birimlerinin daha
küçük parçalara ayrılamayacağı seviyeye kadar sürdürülmektedir. Bu yöntem büyük
resmi görebilen proje yöneticileri için çok uygundur.
Aşağıdan yukarıya doğru yaklaşımında ise, projenin en küçük iş
bileşenlerinden başlanarak genele doğru gidilmekte ve her üst seviyede
sınıflandırılmaktadırlar. Bu yöntem, proje takımın iş dağılım yapısını oluşturmaya
katkı sağlayarak sinerji elde edilmek istenilen durumlar için uygundur.
Đyi bir iş dağılım yapısı oluşturmak kolay bir çalışma değildir ve yapının
üzerinden defalarca geçilmesi gerekebilir. Genelde projenin iş dağılım yapısını
oluştururken birkaç metodun kombinasyonundan faydalanılabilir. Đyi bir iş dağılım
yapısını oluşturmak için kullanılabilecek temel prensipler aşağıdaki gibidir: 38
• Đş birimi yapı içerisinde sadece bir yerde yer almalıdır.
• Đş dağılım yapısındaki bir iş biriminin içeriği, alt kırılımındaki iş birimlerinin
toplamıdır.
• Bir iş biriminde birden fazla kişi görev alabiliyor olmasına rağmen iş
biriminin sorumluluğu sadece bir kişide olmalıdır.
• Đş dağılım yapısındaki iş birimleri işin yapılışıyla tutarlı olarak
yapılandırılmalıdır.
• Tutarlılık açısından iş dağılım yapısının oluşturulması çalışmalarına proje
takımının üyeleri de katılmalıdır.
38 Kathy Schwalbe, a.g.e., s.106
-
44
• Đş dağılım yapısındaki her birim kapsam olarak içerdiği ve içermediği işlerin
herkes tarafından anlaşıldığının garanti edilmesi için dokümante edilmelidir.
• Kapsamdaki değişikliklerden kaynaklanan veya kaçınılmaz olan
değişikliklerin iş dağılım yapısına yansıtılabilmesi açısından yapının esnek
olarak kurgulanması gereklidir. 39
2.2.4. Kapsam Doğrulama
Kapsam doğrulama, geliştirilen sisteme müşteri/sponsor tarafından formal
kabulün verilmesidir. Đşler sonucunda elde edilen çıktılar proje dokümantasyonunda
varolan taahhütler ile karşılaştırılır. Olması gereken sistemden sapmalar ölçülmeye
çalışılır. Kapsam doğrulamanın düzgün bir biçimde yürütülmesi için proje ürününün
ve prosedürlerin dokümantasyonu net bir biçimde geliştirilmelidir.
2.2.5. Kapsam Değişim Kontrolü
Kapsam değişim kontrolü, kapsamda ortaya çıkan değişikliklerin tespit
edilmesi, yönetimi ve bu değişikliklerin faydalı olup olmadığının analizi ile
ilgilenir. Đş dağılım yapısının oluşturmaktan daha da zor olan, BT projelerinin
kapsamlarının doğrulanması ve kapsam değişikliklerinin en aza indirilmesidir. Çoğu
projenin kapsam belirleme ve değişikliklerin kontrol altına alınamaması sebebiyle
başarısız olduğu değerlendirildiğinde, projenin kapsamının doğrulanması ve kapsam
değişikliklerinin kontrol altına alınabilmesi için süreç geliştirilmesi gerekmektedir.
39 Cleland, David I, Project Management: Strategic Desing and Implementation, 3. Edition, New York, Irwın McGraw-Hill, 1999
-
45
2.3. Proje Zaman Yönetimi
Proje zaman yönetimi, basitçe tanımlanmış, projenin zamanında
tamamlanmasını sağlayan faaliyetler bütünüdür.40 Öncelik proje takviminin
oluşturulmasıdır. Proje takvimi, proje faaliyet planının tarifeye dönüştürülmüş
halidir. Projeyi izlemek ve proje faaliyetlerini kontrol etmek için temel oluşturur.
Projeler sürekli operasyonlar olduklarından proje takvimi büyük önem
taşımaktadır. Zaman, proje yönetimi değişkenlerinden en az esnekliğe sahip olanıdır.
1995 CHAOS raporuna göre projelerdeki ortalama zaman sapması %222’dir. Bu
durum müşterilerin/sponsorların neden takvim sapmaları üzerinde önemle
durduklarını açıklamaktadır.
Bütün proje faaliyetleri aynı detay seviyesinde tasarlanmamakla birlikte bir
proje için çok farklı takvimler oluşturulabilir. Ana takvim, geliştirme takvimi, test
takvimi gibi. Ancak üzerinde durulması gereken nokta, bu takvimlerin bir önceki
adımda oluşturulan sınıflandırılmış iş listesi ile uyumunu sağlamaktır.
Proje zaman yönetimi,
• Faaliyet tanımlama,
• Faaliyetleri sıralama,
• Süre tahmini,
40 Project Management Institute Standarts Committee, a.g.e. , s.59
-
46
• Takvim geliştirme,
• Takvim kontrol
safhalarından oluşur.
Proje yönetiminin üçlü kısıtları ile proje zaman yönetimi arasında çok yakın
bir ilişki vardır. Çünkü faaliyet tanımlama bir anlamda kapsamın belirlenmesini,
takvim geliştirme zamanı ve faaliyetlerin süre tahmini dolaylı olarak maliyeti
etkilemektedir.
2.3.1. Faaliyet Tanımlama
Faaliyet tanımlama, iş paketleri sonucunda elde edilecek alt çıktılar ve
bunların birleşiminden meydana gelecek ana çıktıyı elde edebilmek amacıyla, iş
dağılım yapısında yer alan spesifik faaliyet tanımlanması ve dokümantasyonunun
yapılmasıdır.41
2.3.2. Faaliyetleri Sıralama
Faaliyetlerin sıralanması, sınıflandırılmış iş listesindeki faaliyetlerin detaylı bir
biçimde incelenerek faaliyetler arasındaki mantıksal ilişkinin ve öncelik sıralarının
41 Project Management Institute Standarts Committee, a.g.e. , s.59
-
47
tanımlanmasıdır. Gerçekçi ve erişilebilir bir takvim elde edebilmek için öncelik
sıralarının kusursuz biçimde belirlenmesi ve mantıksal tasarımın iyi yapılması çok
önemlidir. Aynı zamanda öncelik sıralarının belirlenmesi safhasında, faaliyetler
arasındaki ilişkiler, faaliyetlerin karşılıklı bağımlılıkları ve bu bağımlılığın türü
belirlenmiş olur. Aktiviteler arasında bağımlılık kurmak için üç ana neden vardır: 42
• Zorunlu bağımlılıklar: Đşin türüne göre faaliyetler arasında kesin bir ilişki
olması durumudur
• Tanımlanan bağımlılıklar: Proje yönetimi takımı tarafından, daha önceki
başarılı uygulamalara dayanarak belirlenen ilişkilerdir.
• Dışsal bağımlılıklar: Dış faktörlerin projeye etkileri göz önünde
bulundurulmalıdır (Hava durumunun beton dökülmesine engel olması
gibi)
2.3.2.1. Şebeke Diyagramları
Faaliyetlerin sıralamasını göstermek için en çok tercih edilen yöntemlerden
biri şebeke diyagramlarıdır. Şebeke diyagramları iki farklı biçimde tasarlanabilir.
Faaliyetlerin oklarla ve olayların düğümlerle tasvir edildiği notasyon ok üzerindeki
faaliyet (activity on arrow-AOA) olarak adlandırılır (Şekil 8). Tam tersine
faaliyetlerin düğümlerle ve olayların öncelik ilişkilerinin oklarla gösterildiği format
düğüm üzerindeki faaliyet (activity on node-AON) olarak adlandırılmaktadır (Şekil
9). Đkisi arasında yapılacak tercih bir notasyonun diğerine üstünlüğünden çok kişisel
42 Kathy Schwalbe, a.g.e., s.123
-
48
bir tercihtir. Ancak ileride açıklanacak PERT tekniği kullanıcıları ok üzerindeki
faaliyet notasyonunu tercih ederken, CPM kullanıcıları daha çok düğüm üzerindeki
faaliyet notasyonunu tercih etmektedirler.
Şekil 8 – Aktivite Ok Üzerinde
Kaynak: Đpek Deveci Kocakoç, http://ipek.deveci.org
-
49
Şekil 9 – Aktivite Düğüm Üzerind