30 saniyede özet

Kapsam temeli, projenin hangi sonuçları teslim edeceğine ilişkin onaylanmış referanstır. Değişiklik kontrolü ise bu referansı değiştiren taleplerin değerini ve etkilerini değerlendirerek karar vermeyi sağlar. Amaç yeni fikirlere kapıyı kapatmak değildir. Amaç, eklenen işin hangi ihtiyacı karşıladığını, neyi ertelediğini ve kimin sorumluluğunda kabul edildiğini görünür kılmaktır. Sağlıklı bir süreç, “Bunu da yapabilir miyiz?” sorusunu “Bu değişiklik için hangi kaynak ve öncelik kararını vermeliyiz?” sorusuna dönüştürür. Proje yönetim ofisinin, yani PMO’nun katkısı, her talebi kendisinin onaylamasından çok bu karar düzenini tutarlı hale getirmesidir.

Neden önemli?

Bir projenin kapsamı çoğu zaman tek bir büyük kararla bozulmaz. Küçük görünen talepler birikir: yeni rapor, farklı müşteri grubu, ek entegrasyon, değiştirilmiş kabul koşulu. Her talep kendi başına makul olabilir. Fakat toplamları, aynı ekibin aynı tarihte tamamlayabileceği iş miktarını aşabilir. Kapsam sürünmesi, bu eklemelerin etkileri değerlendirilmeden ve gerekli onaylar alınmadan projeye girmesidir.

Yönetici açısından mesele yalnızca teslim tarihinin kayması değildir. Başlangıçta onaylanan yatırımın ekonomik gerekçesi de değişebilir. Müşteriye sağlanacak fayda büyürken bakım yükü daha hızlı büyüyebilir. Bir bölümün istediği özellik, başka bir bölümün kritik ihtiyacını geciktirebilir. Böyle durumlarda proje ekibinin gayreti, öncelik kararı eksikliğini telafi edemez.

İş analisti açısından kapsam temeli, gereksinim görüşmelerine ortak bir referans sağlar. Ürün sahibi açısından hangi isteğin mevcut hedef içinde kaldığını, hangisinin hedefi değiştirdiğini tartışmayı kolaylaştırır. Yönetim açısından ise onaylanan iş ile fiilen yapılan iş arasındaki farkı açıklanabilir hale getirir. Bu açıklanabilirlik, proje başarısını yalnızca “tamamlandı” ifadesiyle ölçmenin önüne geçer.

Terim nedir?

Kapsam temeli genellikle onaylanmış kapsam bildirimi, iş kırılım yapısı ve iş kırılım yapısı sözlüğünden oluşur. İş kırılım yapısı, teslim edilecek sonuçları yönetilebilir parçalara ayırır. Sözlük ise bu parçaların içeriğini, sınırlarını ve gerekli ayrıntılarını açıklar. Kapsam bildirimi, teslimatları ve kapsam dışında kalan işleri tanımlar. Kabul ölçütleri, teslimatın hangi koşullarda uygun sayılacağını somutlaştırır.

Proje başlatma belgesi daha üst düzey bir yetkilendirme sunar; ayrıntılı kapsam temelinin yerine otomatik olarak geçmez. Benzer şekilde kapsam temeli, takvim ve maliyet temel çizgileriyle bağlantılıdır ama bunlarla aynı şey değildir. Teslimat değişmeden maliyet tahmini değişebilir. Yeni bir teslimat ise hem kapsamı hem takvimi hem maliyeti etkileyebilir.

Değişiklik kontrolü; talebi kaydetme, etkisini inceleme, yetkili kişi veya kurulun kararını alma ve kararı ilgili planlara yansıtma sürecidir. Büyük ve bölümler arası etkiler taşıyan talepler için bir değişiklik kontrol kurulu kullanılabilir. Daha sınırlı kararlar, önceden belirlenmiş yetki sınırları içinde proje yöneticisine veya ürün sahibine bırakılabilir.

Her ayrıntılandırma kapsam değişikliği değildir. Onaylanmış bir teslimatı üretmek için gerekli işi sonradan daha ayrıntılı tanımlamak, yeni teslimat eklemekten farklıdır. Ancak eksik planlanan işin ortaya çıkması takvimi veya bütçeyi etkiliyorsa bu etki yine yönetilmelidir. Çevik çalışmada da ürün iş listesi, yani backlog, sürekli değişebilir. Kontrol ihtiyacı, her madde için kurul toplantısı yapmak değil, kararın hedef ve kaynak sınırları içinde kalıp kalmadığını bilmektir.

Gerçek vaka: Churchill Downs’ta kapsam kararlarının iş gerekçesine bağlanması

Chuck Millhollan’ın PMI tarafından yayımlanan 2008 tarihli konferans bildirisinde, Churchill Downs Incorporated bünyesindeki uygulama anlatılır. Şirketin PMO yaklaşımında kapsam kontrolü, yatırım gerekçesi ve onaylanmış proje başlatma belgesiyle ilişkilendirilmiştir. Değişiklikler için iş hedefini, fayda ölçütlerini, takvim ve maliyet etkisini, finansman kaynağını ve onayları içeren bir form kullanılmıştır.

Bildiride, geçmişten gelen projelerin kapsamı geriye dönük belgelendiğinde bazı projelerin durdurulduğu belirtilir. Gerekçe, kontrolsüz değişiklikler nedeniyle başlangıçtaki iş gerekçesinde öngörülen faydaları artık üretememeleridir. Ayrıca değişiklik taleplerinin yatırım getirisi ve etkileri üzerinden değerlendirilmesinin, uygun olmayan talepleri reddetmeye ve ekiplerin gayriresmî istekler karşısında sınır koymasına yardımcı olduğu aktarılır.

Bu vaka, kapsam kontrolünün yalnızca talep sayısını azaltmaya değil, yatırım gerekçesini korumaya hizmet edebildiğini gösterir. Bildiri nicel bir tasarruf sonucu sunmadığı için uygulamanın başarısını belirli bir tutara veya orana bağlamak doğru olmaz.

Kaynak: Chuck Millhollan, “Scope change control: control your projects or your projects will control you!”, PMI, 19 Ekim 2008.

Varsayımsal örnek: Entegrasyon projesine geçmiş veri temizliğinin eklenmesi

Müşteri, çalışmalar sürerken eski kayıtların da temizlenmesini ister. İş analisti önce talebin arkasındaki ihtiyacı araştırır. Sorun bütün kayıtların kalitesi mi, yoksa yeni sisteme aktarılacak kayıtların kullanılabilirliği midir? Bu ayrım, gereksiz işi azaltabilecek bir çözüm alanı açar.

Ekip alternatifleri değerlendirir: mevcut teslimatı koruyup temizliği ayrı çalışmada yapmak, aktarılacak kayıtlarla sınırlı temizlik eklemek veya kapsamı bütünüyle genişletmek. Her seçenek için geliştirme, test, müşteri katkısı, işletim sorumluluğu ve takvim etkisi incelenir. Belirsizlik yüksekse önce örnek veri üzerinde inceleme önerilir; tahmin kesin bilgi gibi sunulmaz.

Yetkili karar verici sınırlı temizliği kabul ederse yalnızca talep formuna imza atılmaz. Kapsam, kabul ölçütleri, iş planı ve gerekiyorsa sözleşmesel taahhütler ilgili taraflarca güncellenir. Yeni kararın tarihi ve gerekçesi korunur. Böylece ekip, eski beklenti ile yeni yükümlülük arasında sıkışmaz.

Yaygın üç hata

  1. Onay alınmasını etki analizinin yerine koymak. Üst düzey bir yöneticinin talebi desteklemesi, kaynakların hazır olduğunu göstermez. Karar dosyası, hangi işlerin etkileneceğini ve hangi varsayımlarla değerlendirme yapıldığını açıklamalıdır. Karar verici, talebin faydasını olduğu kadar fırsat maliyetini, yani vazgeçilen alternatifin değerini de görmelidir.
  2. Süreci her talebe aynı ağırlıkta uygulamak. Küçük bir açıklama düzeltmesi ile farklı bir müşteri grubuna hizmet verecek yeni teslimat aynı incelemeyi gerektirmez. Etki ve yetki eşikleri tanımlanmadığında süreç ya bürokrasiye dönüşür ya da insanlar sürecin etrafından dolaşır. Eşikler, kurumun riskine ve proje koşullarına göre belirlenmelidir.
  3. Kararı verip referansları güncellememek. Onaylı değişiklik toplantı notunda kalırsa ekipler farklı sürümlere göre çalışabilir. Talep, gereksinim, teslimat ve test arasındaki bağlantı korunmalıdır. Önceki temel silinmemeli; güncel sürümle birlikte karar geçmişi izlenebilmelidir. Reddedilen talebin gerekçesi de saklanmalıdır.

Mini uygulama: Tek sayfalık değişiklik değerlendirmesi

Bir sonraki kapsam talebinde aşağıdaki alanları doldurun. Yanıtı bilinmeyen alanı boş bırakmak yerine “belirsiz” yazın ve nasıl netleştirileceğini belirtin.

Talep kimliği ve sahibi
—
Değiştirilmek istenen onaylı teslimat
—
İş ihtiyacı ve beklenen fayda
—
Talep yapılmazsa oluşacak sonuç
—
Mevcut kapsam içinde çözüm seçeneği
—
Takvim, maliyet, kaynak ve kalite etkileri
—
Bağımlılıklar ve riskler
—
Ertelenecek veya çıkarılacak işler
—
Tahminlerin dayandığı varsayımlar
—
Karar yetkilisi ve gerekli karar tarihi
—
Karar
onay, ret, erteleme veya ek inceleme:
Güncellenecek belgeler ve sorumluları
—
Uygulama sonrası doğrulama yöntemi
—

Karar toplantısında önce ihtiyacı, sonra alternatifleri, ardından etkileri konuşun. Kararın gerekçesini tek cümleyle kaydedin. Uygulama tamamlandığında yalnızca işin yapıldığını değil, kabul edilen değişikliğin hedeflenen ihtiyacı karşılayıp karşılamadığını da kontrol edin. PMO, benzer taleplerde tekrar eden nedenleri inceleyerek başlangıç kapsamının kalitesini geliştirebilir.

İlgili terimler

Scope Statement, Work Breakdown Structure, WBS Dictionary, Scope Creep, Change Request, Change Control Board, Requirements Traceability, Acceptance Criteria, Business Case, Configuration Management, Integrated Change Control