bĐlgĐ teknolojĐlerĐ proje yÖnetĐmĐ ve baŞari...

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




VE BAŞARI KOŞULLARI

Yüksek Lisans Tezi

Nuray ESATOĞLU

Tez Danışmanı Yrd.Doç.Dr.M. Arcan TUZCU

Ankara-2010




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.


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.


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


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

bĐlgĐ teknolojĐlerĐ proje yÖnetĐmĐ ve baŞari...

Documents