Proje Değişiklik Yönetimi Süreci

Değişiklik istekleri (change request) bir projede farklı kanallardan gelebiliyor. Bir proje nasıl ortaya çıkıyor? Çalıştığınız şirketin yapısına bağlı değişiklikler gösterebilir. Örneğin benim çalıştığım şirkette projeler şu şekilde ortaya çıkıyor. Ben bir GSM operatöründe program yöneticisi olarak çalışıyorum. Yukarıdan baktığınız zaman şirketimiz, kabaca, Teknoloji, Satış, Pazarlama ve Müşteri Hizmetleri bölümlerinden oluşuyor. Teknoloji dışındaki bölümler ihtiyaçlarını karşılamak için Teknoloji bölümüne ihtiyaçlarını bildiriyor. Teknoloji bölümü bu süreçte müşteriden iş gerekçesini istiyor. Tamam bu projeyi yapalım ama bunun sonucunda şirket ne kazanacak? Müşteri sayısı artacak mı, gelirimiz artacak mı? Bu akış tanımlanmış bir süreç çerçevesinde ilerliyor. İş’i isteyen, proje sonunda ortaya çıkan hizmeti, ürünü veya uygulamayı kullanacak olan bölümler Teknoloji bölümüne göre “müşteri”. İş’in sahibi bu bölümler. Daha fazla detaya girmeyeyim. Projenin yapılabilirliği iş analistleri tarafından çalışılıyor, analiz ediliyor. Eğer yapılabilir ise ne kadar sürede yapılacağı ve kabaca bütçesi müşteri ile paylaşılıyor. Projenin başlamasına karar veriliyor ve proje yöneticisi atanıyor. Artık elimizde bazı biligiler var, tahmini süre, bütçe ve eğer başka bir firma (tedarikçi) ile çalışılacaksa onların bilgileri vs… Proje kickoff toplantısı ile başlatılıyor. Planlama aşamasında proje paydaşları olarak hem müşteri hem de teknik proje ekibi ile yoğun mesai yapılıyor. Bütün bunların koordinasyonunu proje yöneticisi yapıyor. Bu çalışmaların içerisindeki en önemli doküman “kapsam dokümanı”. Kapsam çıkartılıyor ve müşterinin onayına sunuluyor.  Kapsam dokümanı projede ne yapılacak, müşteri tarafından ne isteniyor gibi bilgilerin detaylı olarak yer aldığı doküman. Bu doküman müşteri tarafından onaylanınca artık taraflar arasında mutabakat sağlanmış oluyor. Sonrasında tasarım aşamasına geliniyor, tasarım çalışmaları yapılıyor. Bu çalışmalar sırasında da müşteri ile iletişim devam ediyor. Tasarım dokümanı da onaylanıyor. Eğer proje bir yazılım geliştirme sürecini içeriyorsa tasarım onayından sonra geliştirmeler başlıyor. Vurguladığım gibi bu geliştirmeleri şirket içi kaynaklarla ve/veya tedarikçi bir firma ile yapabilirsiniz. Geliştirmeler bittikten sonra geliştirilen uygulamanın mevcut alt yapınıza entegrasyonu için testler yapılıyor. Bu teknik testler başarı ile tamamlanınca artık geliştirilen uygulama, yani müşterinin istediği uygulama son kullanıcı testi (UAT: user acceptance test) için hazır hale geliyor. Müşteri son kullanıcı testlerini de başarı ile bitirirse artık proje hayata geçiyor ve tamamlanıyor. Bu aşamadan sonra operasyon başlıyor ve projeyi şirketin operasyon bölümü devir alıyor.

Proje başladıktan sonra analiz yapılırken, tasarım çalışmaları sürerken müşteriden değişiklik istekleri gelebiliyor. Şuna da ihtiyacımız var, yeni bir düzenleme geldi şunları da eklememiz gerekiyor, tasarımı böyle yaptık ama kullanıcı ekranında şu buton şurada olsun, ben bu butona basığımda bir bilgilendirme mesajı önümüze çıksın, almak istediğim raporlar için şu tip raporları da ekleyelim gibi birçok değişiklik isteği geliyor. Değişiklik istekleri bir projenin doğasında vardır ve normaldir. Fakat proje sağlığı açısından değişiklik isteklerinin proje akışında bir noktaya kadar gelmesine izin vermek gerekiyor. Örneğin artık test aşamasına gelmişsiniz, tasarım onaylanmış, geliştirmeler tamamlanmış, artık projenin sonuna yaklaşmışsınız. Müşteri önünüze değişiklik isteği ile geliyor. Bu durum projeyi maliyet ve zaman açısından etkiliyor. Baştan planladığınız sürede bitiremeyeceksiniz ve üzerine fazla para harcamanız gerekiyor. Ben program yönetici olarak proje yöneticisi arkadaşlarıma tasarım sürecinin sonuna kadar müşteriden değişiklik isteklerini alabileceklerini ve değerlendirebileceklerini söylüyor ve onların da müşteriye bu bilgiyi aktarmasını istiyorum. Tamam müşterinin ihtiyacı varsa bu yapılacak, ihtiyacını karşılamak lazım. Ama bu ilave ihtiyaçların projenin 2.fazı olarak ele alınacağını müşteri ile paylaşmalarını, proje yöneticilerinden istiyorum.

Bu arada değişiklik istekleri sadece iç müşterinizden gelmiyor. Proje için birlikte çalıştığınız tedarikçi firma da karşınıza, farklı bir şekilde, değişiklik talebi ile çıkabiliyor. Örneğin tasarım aşamasında birlikte çalışmış, sonrasında çıkan dokümanı da şirket olarak onaylamışsınız. Geliştirmeler yapılıyor, teste geliyorsunuz ve geliştirilen uygulamayı fonksiyonel olarak ele alıyorsunuz, bakıyorsunuz ki eksikler var. Bunu tedarikçi firmaya iletiyorsunuz, bakın tasarım dokümanında yazdık bunu bekliyorduk ama şu anda yok bunu da eklemelisiniz diyorsunuz. Tedarikçi firma orada yazanı biz şu şekilde algılıyoruz, bu istek bir değişiklik isteğidir, daha önce konuşulan, yazılan şeylerin dışındadır diyebiliyor. Sonra ne oluyor, başlıyorsunuz kavga etmeye bu değişiklik isteğidir, değildir yapmalısınız vs.

Geçen yıl Değişiklik Yönetimi konusunda bir yazı yazmıştım. O yazıda kaleme aldığıım durum farklı bir değişiklik isteğiydi. O zaman üstünde çalıştığımız büyük bir projede çalıştığımız tedarikçi firma ile aramızdaki onların hatasından kaynaklanan bir durum için karşımıza değişiklik isteği ile gelmişler ve biz de bunu kabul etmemiştik. Biz onların hatası olduğunu ortaya koyuyorduk onlar da hayır siz bizi beklettiniz biz şu kadar adamı burada tuttuk, bize şu kadar para vermelisiniz diyorlardı. Oldukça sıkıntılı bir durumdu ve yönetmekte zorlanmıştık. O yazımda da bu tür değişiklik isteklerinin önüne geçmek için neler yapılması gerektiğini vurgulamıştım.

Bir projede değişiklik isteklerinin (change request) hangi süreçte ele alınacağının ve işleyişin, sürecin nasıl olması gerektiğinin başlangıçta belirlenmesi önemli. Değişiklik isteği proje ekibine nasıl ve hangi yolla iletilecek? Değişiklik istekleri nasıl analiz edilecek? İletilen değişiklik istekleri nasıl takip edilecek? Değişiklik isteğinin onaylanması ya da reddedilmesi için neler yapılacak? Büyük projelerde, örnek olarak 1 yıldan fazla süren, değişiklik yönetimi sürecinin proje başlangıcında çok net belirlenmesinde fayda var.

Değişiklik isteklerini ilk karşılayan kişi Proje Yöneticisidir. Gelen istekleri proje ekibi ile değerlendirip analiz eder. Projeye olan etkisi (zaman, maliyet…) çıkartılır. Analiz tamamlanıp dokümante edilince değişiklik kontrol kuruluna (change control board – CCB) proje yöneticisi tarafından aktarılır. CCB değişiklik isteği üstünde bir değerlendirme yapar ve sözkonusu isteğin yerine getirilip getirilmeyeceği konusunda bir karar verir.

Geçen seneki yazım Vikipedi Özgür Ansiklopedi’de ele alınan Değişiklik Yönetimi makalesinde kaynak olarak gösterilmiş. Sonradan fark ettim, ben bunun için bir şey yapmadım. Ama tanımadığım birisi yazımı kaynak olarak göstermiş, çok memnun oldum. Blog’umda yazdığım bu yazılar okuyanlara bir şeyler verebiliyorsa ne mutlu bana.