kapsam yönetimi

KAPSAM YÖNETİMİ (SCOPE MANAGEMENT)

CÜNEYT AKDUMAN 1310060042

İÇİNDEKİLER

PROJE KAPSAM YÖNETİMİ 2

1. PROJE KAPSAMININ TANIMLANMASI VE YÖNETİLMESİ

◦ 1.1. ÖZET◦ 1.2. GİRİŞ

2. PROJE KAPSAM YÖNETİMİ SÜREÇLERİ◦ 2.1. PROJE KAPSAMININ BAŞLATILMASI◦ 2.2. PROJE KAPSAMININ PLANLANMASI◦ 2.3. PROJE KAPSAMININ TANIMLANMASI◦ 2.4. PROJE KAPSAM DOĞRULAMASI◦ 2.5. KAPSAM DEĞİŞİM DENETİMİ

SONUÇKAYNAKLAR

1. PROJE KAPSAMININ TANIMLANMASI VE

YÖNETİLMESİ

3

PROJE KAPSAM YÖNETİMİ

1.1 ÖZET

4

• Bu bölümde projenin ve projeden elde edilen ürünlerin tanımlanması ve yönetimi konuları üstünde durulmuştur.

• Kapsam yönetimini destekleyen beş süreç (PMBOK: Proje Yönetimi Bilgi Gövdesi – Başlangıç, Planlama, Kapsam Tanımlama, Kapsam Doğrulama ve Kapsam Değişim Denetimi) açıklanmıştır.

• Ürün kapsamı ve proje kapsamı arasındaki farklar belirtilmiş ve proje kapsamının belirlenmesinde kullanılan araç ve yöntemlerden söz edilmiştir.


ÖRNEK : PROJE KAPSAMININ BELİRLENMESİ -GTS( GLOBAL TECHNOLOGY SOLUTİONS)

5

• Proje hedefi tanımlandıktan sonra yapılması gerekenler belirlenmelidir.

• Proje kapsamı tanımlanmalıdır. Ara ürünlerin ve etkinliklerin ölçülebilir kurumsal değerleri desteklemesi gerekir.

• Bitmeyecek gibi görünen bir proje:• Kullanıcıların sürekli olarak yeni isteklerde bulunması

• Proje bitiş tarihinin gecikmesi

• Beklenenden daha maliyetli olması demektir.


ÖRNEK : PROJE KAPSAMININ BELİRLENMESİ -GTS( GLOBAL TECHNOLOGY SOLUTİONS) (DEVAM)

6

Bu durumdan çıkarılacak sonuç:◦ Proje kapsamını iyi tanımlanmış olması gerekir.◦ Proje hedefi açık olmalıdır.◦ Kapsam değişim denetimleri olmalıdır.

Değişimlerin hepsine ‘evet’ denilmesi durumu: Proje takvimine ve bütçesine olumsuz etki eder. Değişimlerin hepsine ‘hayır’ denilmesi durumu: Kullanıcının isteklerinin karşılanmaması

demektir.

Ne zaman ‘evet’, ne zaman ‘hayır’ demek gerekir?Kapsam değişimi ölçülebilir kurumsal değerleri desteklemelidir. Aksi durumda değişiklik için zaman ve para harcamaya değmeyecektir. Kullanıcı da durumu değerlendirmeli ve bu değişikliğe gerçekten gereksinimi olduğunu belirlemelidir.Sonuç: Proje yönetiminde zaman ve bütçe denetim altında olmalıdır.


1.2. GİRİŞ

7

• Bu bölüm, proje ekibi tarafından oluşturulması gereken projeye ilişkin iş tanımı ve yönetimi konularına odaklanmaktadır.

• “Kapsam” terimi işin sınırlarını ve projeden elde edilen ürünleri tanımlamak için kullanılmakta ve yapılacakları belirlemektedir.

• Yani, sadece projeye ilişkin olan bölümleri tanımlamanın dışında, projeye ilişkin olmayan bölümleri tanımlamak da önemlidir.

• Projeye ilişkin olmayan bölümler, proje kapsamı dışında kabul edilir.


2. PROJE KAPSAM YÖNETİMİ SÜREÇLERİ

8PROJE KAPSAM YÖNETİMİ

9

• PMBOK (Proje Yönetimi Bilgi Gövdesi) proje kapsam yönetimine ilişkin bilgi alanlarını destekleyen beş süreci tanımlamaktadır.

• Bu süreç, proje destekleyicisinin proje yöneticisine gerekli yetki ve kaynakları verdiği “kapsamın hazırlanması” ile başlar.

• BT proje yöntembilimi içeriğinde proje çizelgesi ve planının oluşturulduğu ikinci aşamada zaman ve kaynak yetkilendirmesi yer almaktadır.

• Diğer süreçler ise kapsam planlamaya odaklanmaktadır. Planlama sürecinde kapsamın sınırları oluşturularak, projede yer alacak ve almayacak konular belirlenir.

PROJE KAPSAM YÖNETİMİ SÜREÇLERİPROJE KAPSAM YÖNETİMİ SÜREÇLERİ


TABLO 1: KAPSAM YÖNETİM SÜREÇLERİ

10

Kapsam Yönetim Süreçleri Tanımı

Proje kapsamının başlatılması Kapsam yönetim planını geliştirecek yetki ve kaynakların atanmasının sağlanması

Kapsam planlama Kapsamın sınırları oluşturularak, projede olması gerekenler ve olmaması gerekenleri belirlemek

Kapsam tanımlama Projenin ölçülebilir kurumsal değerlerini (MOV) destekleyen proje ara ürünlerinin belirlenmesi

Kapsam doğrulama Projenin kapsamının doğru, tam olduğunun ve ölçülebilir kurumsal değerleri (MOV) desteklediğinin doğrulanması

Kapsam değişim denetimi Proje kapsamı oluşturulduğunda, kapsam değişikliklerini yönetecek denetimlerin yerinde olmasını ve yordamların tüm paydaşlar tarafından değerlendirilmesini sağlamak


11

• Üçüncü süreç kapsam tanımlamaya dayalıdır.

• Kapsam planlama proje sınırını belirlerken, kapsam tanımlama projeden elde edilenleri ve ürünleri tanımlamaktadır.

• Sonuç olarak, kapsam planlama ve tanımlamaya ilişkin sınırlar ve ürünler proje çizelgesi ve planı için anahtar niteliğindedir.

• Üstelik bu sınır ve ürünler projenin zaman ve maliyet açısından kestirimde bulunmada kullanılan kritik girdiler niteliğindedir.

PROJE KAPSAM YÖNETİMİ SÜREÇLERİ (devam)PROJE KAPSAM YÖNETİMİ SÜREÇLERİ (devam)


12

• Kapsam tanımlanmasından sonra gelen kapsam doğrulama aşaması, kapsamın tam ve doğru olduğunu gösteren süreçtir.

• Proje ekibi ve destekleyici projeden elde edilen ürünler üstünde ortak karara varmalıdır.

• Bu durum, beklentilerin belirlenmesinin dışında; proje ekibinin, gereksinimlerin neler olduğu konusunda odaklanmasını da sağlamaktadır.



13

Eğer proje kapsamında ortak karara varılmazsa veya kapsam tam olarak tanımlanamazsa, zaman ve kaynak boşa harcanmış olur.

Yeni bilgiler elde edilirse ya da yönetimin gereksinimleri değişirse, kapsamda değişiklik olması da kaçınılmazdır. Bu yüzden “kapsam değişim denetimi” süreci bu değişimler için gereklidir. Böylece eğer bir kapsam değişikliği uygunsa, bu değişiklik proje zaman ve bütçesine bağlı olarak kabul edilebilir.

Ayrıca kapsam değişim denetim yordamları kapsam sınırlarının genişlemesini (artan özellik eklemeleri) de denetler. Kapsam, zaman ve maliyet ilişkileri, kapsam sınırındaki artışın, zaman ve maliyet artışına neden olacağını göstermektedir.



14

• Bunun yanında, proje kapsamına eklenen her fazladan iş, projenin son bitiş tarihinin süre olarak aşılmasına ve maliyetin beklenenden fazla olmasına neden olacaktır.

• Proje kapsamı oluşturulduğunda, onaylanmış değişiklikler temel plana mutlaka yansıtılmalıdır.



15

• Kapsam tanımlanmasında ve yönetilmesinde kullanılan süreç ve teknikler “kapsam yönetim planı”nı oluşturur.

• Projenin boyutuna ve yapısına bağlı olarak, bu plan ayrı ve/veya çizelgede özetlenmiş olabilir.

• Projenin kapsamının belirlenmesinde ve yönetilmesinde kullanılan yordamlar yanlış anlaşılmaların olmaması için konuşulup tartışılmalı ve tüm paydaşlar tarafından anlaşılmalıdır.

• Ayrıca proje kapsamı projenin ölçülebilir kurumsal değerlerini (MOV) de desteklemelidir.



2.1. PROJE KAPSAMININ BAŞLATILMASI

16

• Kapsamın başlatılması, proje yöneticisi ve ekibin kapsam yönetim planını geliştirmesi için yetki verilen bir süreçtir.

• Bu yetkilendirme proje kabul edildikten ve kaynaklar sağlandıktan sonra gerçekleştirilir.

• Olurluk incelemesi (business case) projenin kapsamı, kurumsal değerleri, riskler, varsayımlar ve projenin geçmişi ile ilgili önemli bilgiler içerir.


17

Şekil 1 : Kapsam Yönetim Planı


2.2. PROJE KAPSAMININ PLANLAMASI

18

• Kapsam planlama, projenin tanımlandığı ve belgelerin oluşturulduğu bir süreçtir.

• Proje kapsamı, bütün işlerin, etkinliklerin ve ara ürünlerin proje ekibince sağlanarak kurumsal değerlere ulaşmayı hedeflemesi demektir.

• Bir projenin ne kadar süreceği ve maliyeti hakkında kestirimlerin yapılması planlama aşamasında gerçekleşmektedir.


KAPSAM SINIRI:

19

Bir projeye ilişkin olan ve olmayan kısımların belirlenmesi kapsam sınırının oluşturulmasında ilk adımdır.

Kapsam sınırları içindeki her iş projenin ölçülebilir kurumsal değerlerini destekleyen etkinlikleri içermelidir.

Diğer taraftan, projenin kurumsal değerlere ulaşma hedefine katkı sağlamayacak etkinlikler de olabilmektedir. Sonuç olarak proje zaman ve kaynakları tüketmektedir.

Kapsam sınırı ile bu tür etkinliklere karşı önlem alınmalıdır.

Şekil 2 : Kapsam Sınırı


KAPSAM AÇIKLAMASI:

20

• Kapsam sınırını belirlemenin bir yolu proje destekleyicisinin gereksinimlerini ve beklentilerini belgelendiren bir kapsam açıklaması oluşturmaktır.

• Elektronik ticaret örneği için kapsam açıklaması şu şekilde olmalıdır:• Süreçleri, ürünleri ve internet yoluyla iletilecek servisleri

tanımlayan bir elektronik ticaret stratejisi geliştirmek

• Bu stratejide tanımlanmış tüm süreçleri, ürünleri ve servisleri destekleyen bir uygulama geliştirmek

• Bankanın var olan kurumsal kaynak planlama sistemi ile bu uygulamayı bütünleştirmek.


KAPSAM AÇIKLAMASI (DEVAM):

21

• Projenin kapsamı genelde görüşmeler, toplantılar ve beyin fırtınası oturumları ile tanımlanmaktadır.

• Proje Kapsamı dışında kalanlar:

• Var olan ortamın teknolojik ve kurumsal açıdan değerlendirilmesi

• Müşteri kaynak yönetimi ve veri madenciliği bileşenleri


KAPSAM AÇIKLAMASI (DEVAM):

22

• Kapsam sınırının oluşturulması sadece beklentilerin belirlenmesini değil, ayrıca projenin kısıtları ve var olan sistemle nasıl bütünleştirileceğinin de tanımlanmasını sağlar.

• Kapsam açıklaması proje kapsamının tanımlanması için bir başlangıç noktasıdır. Başlangıçta proje kapsamının anlaşılması kısıtlı olabilir. Müşteri ile ortak çalışma sonucu daha fazla bilgi elde edilerek kapsam detaylandırılabilir ve daha anlaşılır hale gelir.

• Böylece proje kapsamı daha genel ve yüksek düzey konumundan, daha ayrıntılı ve anlaşılabilir duruma gelmiş olacaktır.


ÖRNEK: OREGON MOTORLU ARAÇLAR DEPARTMANI (OREGON DEPARTMENT OF MOTOR VEHİCLES)

23

◦ 1993 yılında Oregon’un geliştirdiği otomasyon sisteminin, 5 yılda tamamlanması ve $50 milyon maliyet olması hedeflenmiştir.

◦ Daha sonra çalışan sayısının %20 azaltılması ve yılda $7.5 milyon tasarruf planlanmıştır.

◦ 1995’te projenin bitiş tarihi 2001’e uzamış ve maliyet $123 milyon olarak kestirimde bulunulmuştur.

◦ 1996’da ilk örnek oluşturulmuş, fakat başarısız olmuştur. Sistem hatalı kabul edilerek, proje iptal edilmiştir.

◦ Başarısızlığın nedeni proje kapsamının iyi tanımlanmamış olmasıdır. Zamanında ürün teslimleri yapılmış olsa da, pazarlama düşünülmediği için proje ile ilgili somut sonuçlar elde edilememiştir.


2.3. PROJE KAPSAMININ TANIMLANMASI

24

• Kapsam açıklaması, proje kapsamının tanımlanması ve sınırların belirlenmesi için ilk adımdır.

• Proje kapsamı ayrıca, ekibin sağladığı ara ürünlere göre de tanımlanmaktadır.

• Bu ürünler, projeye yönelik ve ürüne yönelik olmak üzere ikiye ayrılır.

• Bu ayrım ekibe işin daha açık ve anlaşılır tanımlanmasını ve kaynak atama, zaman-maliyet kestirimlerinde kolaylık sağlar.


PROJEYE YÖNELİK ARA ÜRÜNLER:

25

• Projeye yönelik ara ürünler ya da kapsam, proje yönetimi ve BT geliştirme süreçlerini ITPM (IT Project Methodology – Bilgi Teknolojileri Proje Yöntembilimi) yöntemlerine göre desteklemelidir.

• Proje kapsamı olurluk incelemesi, proje sözleşmesi ve proje planını içerir.

• Sistem geliştirme yaşam döngüsü (SDLC – system development life cycle) ile ara ürünler desteklenmektedir.

• Projeye yönelik ara ürünler zaman ve kaynağa gereksinim duydukları için proje zaman çizelgesi ve bütçenin bir bölümünü oluştururlar.


PROJEYE YÖNELİK KAPSAM TANIMLAMA ARAÇLARI:

26

• Bütün proje ürünleri açık ve anlaşılır bir şekilde tanımlanmalıdır. Bunun için de ara ürün tanım tablosu (DDT – deliverable definition table) kullanılır. Banka elektronik ticareti için oluşturulmuş DDT aşağıdaki gibidir:

Ara Ürün Yapı Standartlar Onayı Gereken KişiOlurluk incelemesi (business case)

Belge Proje Yöntembiliminde tanımlandığı şekilde

Proje destekleyicisi

Proje sözleşmesi ve planı



Teknoloji ve kurumsal değerlendirme


Proje yöneticisi ve proje destekleyicisi

Gereksinimlerin tanımlanması


Proje yöneticisi

Tablo 2: Ara Ürün Tanım Tablosu (DDT)


PROJEYE YÖNELİK KAPSAM TANIMLAMA ARAÇLARI (DEVAM)

27

Ara Ürün Yapı Standartlar Onayı Gereken KişiKullanıcı arayüzü Örnek Kullanıcı arayüzü

kılavuzunda tanımlandığı şekilde


Fiziksel ve Teknik tasarım



Uygulama Sistemi Dosya ve veritabanı Proje Yöntembiliminde tanımlandığı şekilde


Planın test edilmesi Belge Proje Yöntembiliminde tanımlandığı şekilde

Proje yöneticisi

Sonuçların test edilmesi

Belge Test planında tanımlandığı şekilde

Proje yöneticisi

Değişim yönetimi ve gerçekleştirim planı


Proje yöneticisi

Eğitim programı Kullanıcı belgeleri ve eğitim sınıfları

Gerçekleştirim planında tanımlandığı şekilde


Son rapor ve sunum Belge Proje Yöntembiliminde tanımlandığı şekilde


Proje değerlendirilmesi ve öğrenilenler





28

• DDT’nin amacı projeye yönelik ara ürünlerin tamamının proje ekibi tarafından tanımlanmasını sağlamaktır.

• Tanımlamalar açık ve yapısal olmalıdır. Örneğin bir ürün; belge (kağıt ya da elektronik), ilk örnek(prototip), sunum ya da uygulama olabilir ve proje ekibi tarafından neyin teslim edileceğini tanımlar.

• Standartlar ile ürünün doğru bir şekilde üretilmesi sağlanır. Her ürün proje destekleyicisi ve yönetici tarafından doğrulanmalı ve onaylanmalıdır.



29

• Ürün onaylandıktan sonra, proje ekibine bir sonraki ürünle ilgili çalışma yetkisi verilir.

• Son olarak da kaynakların tanımlanması gerekir. Kaynak tanımlaması ile projenin gereksinimleri belirlenir ve her ürün teslimi için gereken zaman ve maliyet kestirilebilir.



30

• DDT ile ara ürünler tamamlandıktan sonra, teslim edilebilir ürün yapı çizelgesi - DSC (deliverable structure chart) ayrıntılı bütçe ve zaman kestirimi için iş paketleri olarak geliştirilir.

• Daha sonra bu paketler iş bölümleme yapısı – WBS (work breakdown structure) için kullanılır.



31

• Aşağıdaki şekilde SDLC ve DDT doğrultusunda tanımlanmış DSC görünmektedir:

Şekil 3 : Ara Ürün Yapı Çizelgesi - DSCPROJE KAPSAM YÖNETİMİ

ÖRNEK: PROJE KAPSAMI – BASİT TUTUN

32

• 1994’ten beri ‘Standish Group’ 23.000’den fazla proje üzerinde çalışmış ve genel olarak zamanında, belirlenen maliyet ile teslim edilen projelerin kapsamının basit olduğunu görmüşlerdir.

• Kısa süreli, az çalışanlı ve düşük maliyetli projeleri yönetmek daha kolay olmuş ve müşterilerinin isteklerini daha kolay ve hızlı karşılamışlardır.

• Kullanıcı katılımı, yönetimin desteği, proje yönetimi konusunda deneyim, anlaşılır iş hedefleri ve iyi iletişimin proje başarısında çok önemli olduğunu görmüşlerdir.


ÜRÜNE YÖNELİK KAPSAM:

33

• Uygulama sisteminin işlevselliğini ve özelliklerini tanımlamak, ara ürünün üretilmesi için gereken zaman ve maliyetin kestirilmesi açısından büyük önem taşımaktadır.


ÜRÜNE YÖNELİK KAPSAM TANIMLAMA ARAÇLARI:

34

• Ürün kapsamı, gerçekleştirilecek sistemin özellik ve işlevselliğinin belirlenmesine odaklanır.

• Kullanılan araçlardan birisi veri akış çizgesidir – DFD (data flow diagram).

• Çizgede bir süreç tanımlıdır ve sistem ile dış birimler arasında veri ve bilgi akışları bulunur.

• Dış birimler dikdörtgen ile gösterilir.

• Oklar veri akış yönünü göstermektedir.


35

Şekil 4 : Veri Akış Çizgesi


ÜRÜNE YÖNELİK KAPSAM TANIMLAMA ARAÇLARI (DEVAM)

36

• Ürün kapsamının tanımlanması sağlayan bir diğer araç da kullanım durumları çizgeleridir (use case diagrams).

• Gösterim açısından basit olan kullanım durumu çizgeleri, sistemin temel işlevleri ve özelliklerini belirtme açısından oldukça güçlüdür.

• Aktörler (kullanıcılar, müşteriler, yöneticiler…) , dış sistemler (bankanın ERP- kurumsal kaynak planlama sistemi) ile etkileşim içindedirler.

• Dikdörtgen kutu projenin sınırlarını belirler. Sınır içinde kalmış kullanım durumları proje kapsamı ile ilgili demektir.


ÜRÜNE YÖNELİK KAPSAM TANIMLAMA ARAÇLARI (DEVAM)

37

• Aktörlerin listelenmesi, paydaşların tanımlanması ve kurumun gereksinimlerinin belirlenmesi açısından önemlidir.

• Kullanım durumu çizgelerinin geliştirilmesi tekrarlamalı bir süreçtir ve birlikte uygulama geliştirme – JAD (joint application development) sırasında gerçekleştirilir.

• JAD, kullanıcı ve sistem çözümleyicilerin birlikte sistem gereksinimlerini tanımladığı ya da tasarım yaptığı grup çalışmasına dayalı bir yöntemdir.


38

Şekil 5 : Kullanım Durumu Çizgeleri (Use Case)

2.4. PROJE KAPSAM DOĞRULAMASI

39

Proje kapsamı tanımlandıktan sonra doğrulanmalıdır. Projenin ürünlerinin belirlenen standartlar doğrultusunda elde edildiğinin kesin olarak belirlenmesini sağlayan aşama proje kapsam doğrulamadır. Ürünlerin doğru tamamlandığı denetim listeleri ile belirlenir. ◦ MOV: Projenin ölçülebilir kurumsal değerleri doğru tanımlandı

mı? Olabilecek hata, projenin zaman ve maliyetine eklenen fazladan iş olarak etkisini gösterecektir.

◦ Ara ürünler: Ürünler somut ve denetlenebilir mi? Projenin kurumsal değerlerini destekliyor mu?


PROJE KAPSAM DOĞRULAMASI (DEVAM)

40

◦ Kalite standartları: Projenin sadece tamamlanmış olmadığını, aynı zamanda belirli standartlara uygun olarak tamamlandığını garanti eden denetimler bulunmakta mı?

◦ Kilometre taşları: Teslim edilebilir her ürün için bir kilometre taşı tanımlanmış mı? Kilometre taşları ürünün kabul edilebilir olduğunu gösterir ve proje yöneticisi ve ekibe diğer ürünler üzerinde çalışmaya başlama yetkisi verir. Yani bir ürünün denetlenmiş ve kabul edilebilir olduğunu gösterir.

◦ Gözden geçirme ve kabul etme: Her iki tarafın da beklentileri açık mı? Projenin kapsamı projenin paydaşları tarafından gözden geçirilmeli ve kabul edilmelidir. Proje destekleyicisi sınırı, üretilecek ürünü ve projeyle ilgili ürünleri resmi olarak kabul etmelidir. Beklentiler gerçekçi olmalı ve ortak karara varılmalıdır.


KAPSAM YÖNETİMİNDEKİ YANLIŞ DÜŞÜNCELER:

41

1) Kullanıcı katılımı proje gereksinimlerinin gerçekçiliğini azaltır.◦ Gerçekte: Kullanıcının katılması ve gereksinimlerin açık bir şekilde

aktarılması projenin kapsamının daha iyi anlaşılmasını sağlar.

2)Kapsam açıklaması projeyi tam olarak tanımlar, nelerin yapılacağını belirtir.◦ Gerçekte: İyi bir kapsam açıklaması projede olmaması gerekenleri de

tanımlar. Bu tanımlama özellikle görev ve sorumluluk atamalarında gereklidir. Kapsamın oluşturulması ile sınırlar belirlenir.

3) Projenin kapsamı belirlendikten sonra, işi sıkı tutmak gerekir; çünkü plandaki olabilecek sapmalar, projenin denetim dışında olduğunun işaretidir.◦ Gerçekte: Kapsam değişimi kaçınılmazdır. Zaman ve maliyet tanımları proje

ayrıntıları bilinmeden belirlendiği için, değişiklikler olacaktır. İyi bir kapsam yönetimi için, kapsam değişim yönetim kurulu olmalıdır.


KAPSAM YÖNETİMİNDEKİ YANLIŞ DÜŞÜNCELER: (DEVAM)

42

4) Kapsam değişim kurulunun görevi, kullanıcı isteklerini belirleyerek, projeye eklenecek özellikleri bulmaktır.◦ Gerçekte: Kapsam değişim kurulu istekte bulunurken, zaman ve maliyet

açısından da durum değerlendirmesi yapmalıdır.

5) Üst yönetim ile yapılacak düzenli toplantılar güncelliği ve yönetim desteğini sağlayacaktır. ◦ Gerçekte: Üst yönetimin proje ile ilgilenmesi için, sistemin avantajlarına

odaklanmalarını ve katılımlarını sağlamak gerekir.

6) Zaman ve maliyette olabilecek küçük sapmalar her zaman düzeltilebilir. ◦ Gerçekte: Erken uyarılar her zaman dikkate alınmalıdır. Daha sonra bu

açıkları kapatmak zor olabilir.


2.5. KAPSAM DEĞİŞİM DENETİMİ

43

PMBOK’ye göre kapsam değişim denetimi değişimlerin yararlı olacağının kesin olarak belirlendiği aşamadır.

◦ Kapsam yoklaması (scope grope): Kapsamın tanımlanmasındaki yetersizlikleri tanımlar. Proje başlangıcında proje yeterince anlaşılmadığında ortaya çıkan bir durumdur. İyi tanımlanmış bir kurumsal değer ya da süreçlerin doğru uygulanması ile bu durum azaltılabilir.


KAPSAM DEĞİŞİM DENETİMİ (DEVAM)

44

◦ Kapsam yayılması (scope creep): Özellik artması yani sisteme zaman ve kaynak eklenerek özelliklerin geliştirilmesi demektir.

◦ Kapsam yayılması proje zamanını uzatacağı ve maliyeti aşmaya neden olacağı için doğru tanımlanmalı ve denetlenmelidir.


KAPSAM DEĞİŞİM DENETİMİ (DEVAM)

45

◦ Kapsam sıçraması (scope leap): Kapsam yayılması özellik artması sonucu olurken, kapsam sıçraması proje kapsamındaki temel ve belirgin değişim sonucu olmaktadır.

◦ Kapsam ciddi anlamda değişir ve ortam da bu durumdan etkilenir.

◦ Eğer değişim kritikse projeye baştan başlamak gerekebilir.


KAPSAM DEĞİŞİM DENETİMİ YORDAMLARI

46

• Proje kapsamında istenen bütün değişikliklerin tanımlanması ve uygulanmasına izin verilen yordamdır.

• Kapsam değişikliği için istekte bulunulur ve değişiklik kabul edilir veya reddedilir.

• Kapsam değişim yordamında kapsam değişim isteği formu da bulunabilir.


47Şekil 6 : Kapsam Değişim İsteği Formu

KAPSAM DEĞİŞİM DENETİMİ YORDAMLARI (DEVAM)

48

• Kapsam değişim istek formu ile istekler, hangi tarihe kadar yanıt istendiği ve onaylayan kişiler kayıt edilir.

• Bütün değişiklik isteklerinin projeye fazladan süre ve maliyet getireceği unutulmadan bu istekler değerlendirilmelidir.


KAPSAM DEĞİŞİM DENETİMİ YORDAMLARI (DEVAM)

49

• Değişimlerin kabul edilmesinde neye göre karar verilmesi gerektiğini projenin kurumsal değerleri belirler.

• Eğer kurumsal değerlerine ulaşma hedefine yaklaşan bir değişim ise kabul edilmelidir.

• Aksi durumda projeye fazladan iş, kaynak, zaman ve maliyet eklenmesinin projeye hiçbir katkısı olmayacaktır.


50

Şekil 7 : Kapsam Değişim İsteği Kayıt Tablosu


KAPSAM DENETİMİNİN FAYDALARI

51

• Kapsam değişim denetim yordamının en önemli yararı projenin yöneticinin denetiminde olmasıdır.

• Ayrıca proje yöneticisinin zaman ve maliyet denetimi yapmasını da sağlar.

• Proje ekibinin projeye odaklanmasını ve hedeflenen kilometre taşlarına ulaşmaya yardımcı olur.


SONUÇ

52PROJE KAPSAM YÖNETİMİ

KAYNAKLAR

53

• Information Technology Project Management – Providing Measurable Organizational Value, Marchewka Jack T., 2003, Chapter 5: Scope Management

DİNLEDİĞİNİZ İÇİN TEŞEKKÜRLER…

54

kapsam yönetimi

Education