Müşteri görüşmesinde küçük görünen bir ek istek duyulur: rapora yeni bir sütun eklenecek, teslim ekranına ikinci bir onay konacak, eğitime başka bir grup da katılacaktır. Yönetici çoğu zaman bu isteği ekibe iletir ve iş başlamış sayılır. Birkaç gün sonra aynı işin tarihi uzar, maliyeti artar ya da başka teslim geri kalır. Ekip değişikliği yaptığını söyler; müşteri ilk sözü hatırlar. Aradaki kararın sahibi yoktur.
Buradaki sorun talebin gelmesi değildir. İş değişebilir. Sorun, değişen işin hangi sonuca dokunduğu anlaşılmadan uygulamaya geçilmesidir. Yönetici ekibe "buna da bakalım" dediğinde, ekip yalnız yeni işi hesaplamaz; önceki sözün hâlâ geçerli olup olmadığını da tahmin etmeye çalışır.
Association for Project Management'ın değişiklik denetimi rehberi, onaylanmış planı etkileyen taleplerin kayda alınmasını, etkisinin değerlendirilmesini ve kabul, ret ya da erteleme kararını öngörüyor. Rehber; kapsam, süre, kalite, kaynak, maliyet, risk ve ilgili taraflar üzerindeki etkinin ayrı ayrı düşünülmesini istiyor. Birleşik Krallık'ın güncel proje teslim standardı da değişiklik talebinin tanımlanmasını, iş gerekçesi, hedefler, sonuç, çözüm ve plan üzerindeki etkisinin değerlendirilmesini; kararın ilgili kişilere bildirilmesini tarif ediyor. Bunlar kamu projeleri için yazılmış standartlar. Küçük bir ekibin her talep için kurul toplaması gerekmez. Ancak yöneticinin değişikliği sözlü onayla başlatıp etkisini sonradan aramasının maliyeti her işyerinde aynıdır: aynı iş iki kez planlanır.
Ben müşteriden ya da başka bir ekipten gelen önemli bir değişiklikte yöneticinin dört kısa satır yazmasını gerekli görüyorum:
- Değişen sonuç: Müşteriye veya iç kullanıcıya verilecek yeni çıktı nedir?
- Etkiyi hesaplayacak kişi: Süre, maliyet, kapasite ve başka teslimler üzerindeki etkiyi kim, hangi güne kadar çıkaracak?
- Karar eşiği: Hangi değişikliği ekip doğrudan uygular; hangi değişiklik yeniden yönetici ya da söz sahibi müşteri kararı ister?
- Güncellenen söz: Karar çıkınca hangi plan, tarih veya müşteriye verilen mesaj değişecek; bunu kim gönderecek?
Bu dört satırın amacı değişikliği durdurmak değildir. Düşük etkili, geri dönmesi kolay bir talebi ekip aynı gün uygulayabilir. Örneğin rapora daha önce toplanan bir sütun eklenecekse, sorumlu kişi bunun iki saatlik iş olduğunu yazıp mevcut teslimin değişmeyeceğini bildirebilir. Yönetici burada yeniden onay bekletmez.
Fakat aynı talep bir veri kaynağını, tasarımı, sözleşmedeki teslimi ya da başka ekibin kapasitesini değiştiriyorsa, "ekleyelim" kararı henüz tamamlanmamıştır. Önce hangi eski işin yer değiştireceği, kimin seçim yapacağı ve müşteriye ne zaman dönüleceği görünmelidir. Aksi halde ekip talebi reddetmek istemediği için işi araya sıkıştırır; gecikme ortaya çıktığında da hiç kimse hangi sözü değiştirdiğini açıkça söyleyemez.
Yönetici bu kaydı herkes için uzun bir forma çevirmemeli. Değişiklik isteğini alan çalışan, etkisini çıkaracak uzman ve son kararı verecek kişi zaten belliyse dört satır tek bir iş notunda kalabilir. Kayıt, yöneticinin kendi masasındaki iki kararı ayırır: önce talebin uygulanabilirliğini görmek, sonra yeni sözü vermek. Bu ayrım yapılmadığında ekip, uygulama kararı ile müşteri taahhüdünü aynı anda üstlenir.
İzlenecek ölçü de basittir. Son bir ayda uygulamaya alınan değişikliklerin kaçında teslim tarihi, kapsam ya da sorumlu sonradan yeniden yazıldı? Bu sayı tek başına başarısızlık göstermez; değişen koşulun doğal sonucu olabilir. Fakat aynı değişiklikler sürekli iş başladıktan sonra fark ediliyorsa, yönetici talebin etkisini değil yalnız talebin kendisini kaydediyordur.
Bu hafta gelen bir değişiklik isteğinde ilk mesajı yazmadan önce dört satırı kurun: yeni sonuç ne, etkiyi kim ne zamana kadar çıkaracak, hangi eşikte karar yeniden masaya gelecek, güncellenen sözü kim paylaşacak? Bu not, uygulamaya geçmeden önce etki hesabının sahibini ve müşteriye gidecek yeni mesajı açıklar.
