Yürütülmekte olan projelerde değişiklik yönetimi önemli bir konu. Hatta en önemli ve dikkatle yönetilmesi gereken bir konu diyebiliriz. Projelerin doğası gereği değişiklik istekleri mutlaka karşımıza çıkıyor. Bu istekler farklı katılımcılardan, proje paydaşlarından, gelebiliyor. Kurumsal, büyük bir firmayı ele alalım. Satış, Pazarlama, Müşteri Hizmetleri bölümlerinden ihtiyaçlarına yönelik olarak diyelimki teknoloji grubuna proje ihtiyaçları geliyor. Teknoloji grubu içinde talep yönetimi departmanı da olsun. Gelen talepleri inceleyip iş analizini yaparak projeyi başlatıyorlar. Bu bahsettiğim organizayon yapısı matris bir organizayon olsun. Talep Yönetimini üstlenen departman aynı zamanda proje yönetimini de üstlensin. Teknoloji dışındaki gruplardan gelen iş istekleri yapılan iş analizi sonucunda projeye dönüşüyor. Bir proje yöneticisi atanıyor. Projeler ya iç kaynak kullanılarak yapılıyor ya da dışarıdan konunun uzmanı başka bir firmaya yaptırılıyor. Her iki durumda da proje yönetimi gerekli.
Projenin dışarıdan bir firmanın desteği ile yapıldığını düşünelim. Proje başlıyor, proje planı hazır, ön kapsam hazır. Proje başlıyor, ilk önce analiz aşaması ve kapsam belirleniyor. Sonra tasarım aşamasında istenilen iş detaylandırılıyor. İstekler nasıl karşılanılacak, ayrıntılı bir çalışma sonucunda dokümante ediliyor. Sonra tasarıma göre geliştirme yapılacak ve sonrasında test’ler yapılıp proje hayata geçecek. Kapsam belirlendikten sonra projeyi hangi bölümün ihtiyacı için yaptıysanız o bölümden “şunu da ekleyelim”, “bu da olursa işimiz kolaylaşır” vs gibi istekler gelmeye başlıyor. Bu istekler projenin kapsamını değiştiriyor, süresini uzatabiliyor ve ilave maliyet olarak yansıyabiliyor. Bu değişiklik istekleri kurum tarafından oluşturulmuş “değişiklik denetleme kurulu” (CCB: change control board) tarafından inceleniyor ve gerçekten faydalı ise kurul tarafından kabul ediliyor veya reddediliyor. Kurulun kararına göre değişiklik istekleri işleme konuluyor. Proje Yöneticisi’nin bir noktada kapsamı dondurması önemli. İsteklerin ardı arkası kesilmeyebiliyor. Bu standard bir süreç ve her projenin içerisinde doğal olarak karşımıza çıkıyor. PMBOK’da “integrated change control” sürecinde de bu konu detaylı olarak ele alınır.
Fakat bu değişiklik istekleri sadece kurumunuz içerisindeki iş talebini yapan gruptan gelmeyebiliyor. Projede istenilen işi başka bir firmaya yaptırıyorsanız değişiklik isteği bu firmadan kaynaklanabiliyor. Nasıl? Kurum içerisindeki bir grubun ihtiyacını karşılamaya yönelik bir proje ortaya çıktı ve işi uzman başka bir firmaya yaptıracaksınız. Şimdi bu noktada “rol ve sorumluluklar” çok iyi belirlenmesi gerekiyor. Yapılacak projede kurumun hangi noktada ne sorumluluğu olacak, işi yaptırdığınız firmanın sorumlulukları ne olacak? Kapsam çok net olarak tanımlanmalı. İstediklerinizi, işi yapan firma bu kapsam içinde değil bu yeni bir istek diyebiliyor. Bunlar net olarak ortaya konulmadığı takdirde projenin bir noktasında işi yaptırdığınız firma karşınıza ben şunları yaptım fakat kurum olarak siz geciktiniz diyebiliyor. Gecikmenizden dolayı ben şu kadar kişiyi ekstra çalıştırdım bu bizim için değişiklik diyerek karşınıza ilave maliyet ile çıkabiliyor. Projenin her safhasının, her bir kilometre taşının, her aktivitenin tarihini baştan belirleyip iletişim zeminini hazırlamakta fayda var. Bu konu gerçekten uzun, sayfalarca yazı yazılabilir.
Burada bahsettiğim konu ile yüz yüze olan birçok kişi var. Bu durumu yönetmek için projenin başından kapsamı, işi yapan ve yaptıranın rol ve sorumlulukları net bir şekilde ortaya koyulmalı, iyi bir çalışma yapılmalı ve iletişim sözlü değil mutlaka yazılı olmalı.
Bu yazıyı kaleme almamın sebebi bugün yaşadığım abartılı bir durum. Vurguladığım gibi bu konu çok dikkatli bir şekilde yönetilmeli.
12 Ağustos 2010 tarihinde bu konuda bir yazı daha yazdım. Okumak için “Proje Değişiklik Yönetimi Süreci” linkini kullanabilirsiniz.
Merhaba;
Projelerde değişiklik yönetimlerinde kapsam en çok değişiklik talep edilen konuların başında geliyor. Tecrübelerim bunun nedeninin en başta belirtilen kontrattan kaynaklandığını gösteriyor. Genellikle sabit ücret ve detaylı hazırlanmamış bir kapsam ile yola çıkılan sözleşmelerde birde doğru tahminleme yapılmadığında maliyetlerin ve karlılığın karşılanması için hizmet veren kapsamı kendi istediği yöne, hizmet alanda kendi istediği yöne çekebiliyor.
Kapsam değişikliği talebinin bir çok farklı nedeni olabilir. Ancak en çok karşılaştığım bir iki nedeni sizlerle paylaşmak istiyorum.
• Kapsam hizmet veren tarafından, hizmet alanın düşündüğü gibi algılanmamıştır. Hizmet alan kapsamı hizmet verene sözlü olarak aktardıktan sonra sözleşmeye aktarılan kapsam hizmet veren ve hizmet alan tarafından farklı olarak algılanabilmektedir.
• Proje iş geliştirme projesidir, ve kapsam detaylandırılmadan bir fikir silsilesi olarak iş kuralları ve akıştan bağımsız olarak hizmet alan tarafından tanımlanmıştır. (hatta proje içerisinde bir analiz safhası konularak kapsamın detaylandırılacağı belirtilebilir, ve bir anda dünyanın en iyi çözümünü sabit bir ücret ile istenen bir projenin yöneticisi olabilirsiniz. )
• Hizmet alan iş geliştirme projesini yol üzerinde geri beslemelere veya gördüğü çıktılarara göre geliştirmek istemektedir.
Yukarıdaki durumların her birinde kaçınılmaz olarak kapsam değişikliği olmaktadır. Kapsam değişikliği kötü değildir. Kötü olan bu kapsam değişikliği olmasına rağmen projenin başta istenilen fiyat, süre ve kalite’de istenmesidir.
Peki çözüm nedir? Çevik yöntemlerde manifestoları içerisinde (http://agilemanifesto.org/) kontrat üzerinde tartışmaktansa, müşteri ile iş birliğine gidip; baştaki planı takip etmek yerine değişime ayak uydurmanın daha iyi olduğunu düşünüyor. Tabii tüm bunları yaparken projenin başında belirtilen sabit ücret ile bunu gerçekleştir şeklinde bir tutumları bulunmuyor. Hatta kişisel kanatimce tam tersini gerçekleştirip harcanan zaman ve malzeme maliyetlerine (time & material) bir sözleşme imzalarsanız hizmet veren olan daha rahat edebilirsiniz.
İşletmelerin amaçlarının kar etmek olduğunu unutmamız gerekiyor. “kazan kazan” anlayışı içerisinde de olacaksak değişim gerekecektir, ancak değişimin maliyetlerinin de karşılanması gerekmektedir.
Yüksek güven ve hizmet alan,hizmet veren arasında tam bir iletişim olduğu durumlarda çevik yöntemlerle proje yönetmenin faydalarını gördüğümüzü belirtmek isterim. Bir örnek vermek gerekirse projelerimizden bir tanesinde sözleşme içerisinde en başta bir kapsam koymamıza rağmen kapsamın proje içerisinde tamamen değişebileceğini en başta kabul ettik. Bu arada elimizdeki ilk kapsama göre bir maliyet tahminlemesi gerçekleştirdik. Hizmet alan tarafındaki proje yöneticimiz buna göre üstlerinden bir bütçe aldı. Bu bütçe’nin %80 gibi bir kısmına ulaştığımız veya proje bütçesini aşacağımızı düşündüğümüz durumda müşterimize haber verme, devam için onay alma şartı koyduk. Kapsamı önceliklendirdik ve her gün belli çıktılar üreterek müşterimizle iş birliği içerisinde projemizi yönettik. Çıktıları gören müşterimiz çeşitli durumlarda kapsamı değiştirdi. Zamanımız dolduğunda baştaki kapsama yakın bir şekilde bazı + ve – lerle projemizi üretime aldık. Müşterimiz ve biz mutlu olduk. Eminim örneği beğendiniz ve sizde uygulamak isterdiniz. Ama ana noktayı unutmayın, sözleşme ne diyor, projeyi nasıl yönetebilirsiniz. Unutmayın değişiklik her zaman olacak, ancak sözleşme elinizdeki yasal belge. Değişiklikleri sözleşmenin kalıbına uydurmayı unutmayın.
Son bir söz: Proje yöneticisi olarak kendinizi mutlaka kollamalısınız. Sadece CCB için değil gerekirse kendiniz için de değişiklik yönetim kararlarınızı yazılı olarak tutunuz. Söz uçar yazı kalır.
Merhaba,
Değişiklik yönetiminde bir programdan faydalanmak cidden çok büyük avantaj sağlıyor. Ben Borland StarTeam almış BTG (Bilgi ve Teknoloji Grubu) diye bir şirketten. Gayet memnun kaldım. Herkese tavsiye ederim. Mutlaka alternatif programlar da vardır fakat bana bu daha iyi gelmişti. İlgilenenler için de web sitesi http://www.btgrubu.com
Bu bilgilendirici yazınız için de teşekkürler 🙂