Kapsam Kayması: Değişiklik Taleplerini Proje Batmadan Yönetmek

"Bunu da ekleyebilir miyiz? Küçük bir şey zaten." Bu cümle tek başına masum. Ama projede yirmi kez tekrarlandığında takvim üç ay kayar, ekip tükenir ve kimse sorunun ne zaman başladığını hatırlamaz. Buna kapsam kayması (scope creep) denir: Kontrolsüz, belgelenmemiş ve etkisi değerlendirilmemiş değişikliklerin birikmesi.

Önemli bir ayrım: Değişiklik kötü değildir. Projeler öğrenerek ilerler ve bazı değişiklikler projeyi çok daha değerli kılar. Sorun değişikliğin kendisi değil, görünmez olmasıdır.

Kapsam kayması nereden gelir?

• Belirsiz başlangıç: Kapsam ve kapsam dışı maddeler baştan net yazılmamışsa her yeni talep "zaten kapsamdaydı" iddiasıyla gelir.
• "Hayır" diyememe: Özellikle iç müşterilerle çalışırken ilişkiyi bozmamak için her talep kabul edilir.
• Doğrudan ekiple konuşan paydaşlar: Proje yöneticisini atlayıp geliştiriciye "şunu da hallediver" denmesi.
• Altın kaplama (gold plating): Ekibin kendisinin, kimse istemeden "daha iyi olsun" diye eklediği özellikler.

Değişiklik kontrolünün dört adımı

Basit ama işleyen bir süreç kurmak, değişikliği yasaklamaktan çok daha etkilidir.

1. Kaydet

Her talep, ne kadar küçük olursa olsun, tek bir yere yazılsın: kim istedi, ne istedi, neden istedi. Bir tablo ya da proje aracındaki bir liste yeterli. Kayıt, sözlü taleplerin kaybolmasını ve tekrar tekrar konuşulmasını önler.

2. Etkisini analiz et

Talebi kabul etmeden önce dört soruyu cevapla:

• Takvime etkisi ne?
• Maliyete etkisi ne?
• Kaliteye ve mevcut işlere etkisi ne?
• Yeni bir risk yaratıyor mu?

Burada dürüst ol. "İki gün sürer" denilen işlerin test, dokümantasyon ve eğitim payıyla bir haftaya çıkması çok sık görülür.

3. Karar ver

Kararı etkileri gören doğru kişi versin. Küçük değişiklikler için proje yöneticisine bir eşik (örneğin iki güne kadar veya belirli bir tutar) yetkisi verilebilir. Daha büyükleri sponsor ya da değişiklik kurulu onaylasın. Kararın üç olası sonucu var:

• Kabul: Takvim, bütçe veya kapsam buna göre güncellenir.
• Takas: Yeni madde alınır, eşdeğer büyüklükte başka bir madde çıkarılır.
• Erteleme ya da ret: Talep sonraki faza ya da ürün iş listesine alınır.

4. İlet ve güncelle

Kararı talep sahibine ve ekibe bildir, planı ve belgeleri güncelle. Onaylanmış değişiklik artık yeni kapsamın parçasıdır.

Çevik projelerde durum farklı mı?

Çevik yaklaşımda değişiklik sürecin doğal bir parçasıdır ve ürün iş listesi (backlog) bunun için vardır. Ama bu, kapsamın sınırsız olduğu anlamına gelmez. Çevikte denge şöyle kurulur:

• Sprint içine giren işler sprint boyunca korunur; yeni talepler iş listesine gider.
• Ürün sahibi önceliklendirmeyi yapar: Yeni bir iş eklendiğinde başka bir iş aşağı iner.
• Sabit tarihli sürümlerde değişkenin kapsam olduğu baştan kabul edilir.

Yani çevikte de değişiklik görünür ve bilinçlidir; sadece mekanizma daha hafiftir.

"Hayır" demenin yapıcı yolları

Doğrudan reddetmek yerine seçenek sunmak ilişkiyi korur:

• "Bunu eklersek teslim tarihi iki hafta kayıyor. Tarihi mi koruyalım, bu özelliği mi alalım?"
• "Bu harika bir fikir. İlk sürümden sonraki faza alalım mı?"
• "Bunu alabiliriz ama raporlama modülünü çıkarmamız gerekir. Hangisi daha değerli?"

Bu cümlelerin ortak noktası, kararın bedelini görünür kılması.

Kayan kapsamı fark etmenin işaretleri

• Proje bitiş tarihi sık sık "biraz" kayıyor
• Ekip yapılan işle plandaki işin örtüşmediğinden şikâyet ediyor
• Kimsenin hatırlamadığı özellikler test aşamasında ortaya çıkıyor
• Kazanılmış değer hesabında maliyet performansı her dönem düşüyor

Son söz

Kapsam kaymasına karşı en güçlü araç süreç belgesi değil, dürüst ve erken konuşmadır. Her değişikliğin bir bedeli vardır; iyi proje yöneticisi bu bedeli görünür kılar ve kararı doğru kişiye bırakır.