30 saniyede özet

Proje, belirli bir sonuç üretmek için yürütülen geçici bir çalışmadır. Başlangıcı, tamamlanma koşulu ve sınırları vardır. Bir ödeme sistemini değiştirmek proje olabilir; sistem üzerinden her gün ödeme almak operasyondur. Projeyi tanımlarken yalnızca yapılacak işleri değil, hangi ihtiyacın karşılanacağını da açıklamak gerekir. İşlerin tamamlanması teslimatı gösterir; beklenen faydanın oluşması ayrıca izlenir. Yönetimin temel sorusu şudur: Bu çalışma bittiğinde hangi kabiliyet kazanılmış olacak ve bunu hangi kanıtla kabul edeceğiz?

Neden önemli?

Bir şirkette her çalışma “proje” diye adlandırıldığında kaynak kararları bulanıklaşır. Sürekli müşteri desteği, yeni ürün geliştirme ve altyapı geçişi aynı planlama mantığına sıkıştırılır. Sonuçta bitmesi gereken işler kapanmaz, devam etmesi gereken hizmetler ise geçici ekiplerin sorumluluğunda kalır. Yöneticiler de hangi yatırımın ne zaman sonuç vereceğini görmekte zorlanır.

Proje kavramını doğru kullanmak, bir işi takvime yerleştirmekten daha fazlasını sağlar. Kaynağın neden ayrıldığını, hangi değişimin finanse edildiğini ve kimin hangi karardan sorumlu olduğunu görünür kılar. Aynı uzmanı isteyen çalışmalar arasında öncelik belirlemek ancak bu açıklıkla mümkündür. Her talep önemli olabilir; fakat hepsinin aynı anda yürütülebileceği varsayımı gerçekçi değildir.

İş analisti açısından proje, iş ihtiyacı ile teslimat arasında bağ kurma alanıdır. Ürün sahibi açısından ürünün gelişimini destekleyen sınırlı bir girişim olabilir. Üst yönetim açısından ise alternatif yatırımlar arasında verilmiş bir kaynak kararıdır. Bu bakışlar birlikte ele alındığında ekip “ne yapacağız?” kadar “neden yapacağız?” sorusuna da tutarlı cevap verir.

Terim nedir?

Projenin iki temel niteliği geçici olması ve kendine özgü bir sonuç üretmesidir. Geçici olması kısa sürmesi anlamına gelmez; tamamlanabileceği bir noktanın bulunması anlamına gelir. Kendine özgü sonuç ise daha önce hiç yapılmamış bir icat olmak zorunda değildir. Mevcut bir yazılımın başka bir işletmeye, farklı süreçlere ve farklı sistem bağlantılarına uyarlanması da bu niteliği taşıyabilir.

Amaç, ulaşılmak istenen değişimi anlatır. Kapsam, bu değişim için hangi işlerin yapılacağını ve hangilerinin dışarıda bırakılacağını belirler. Teslimat, ortaya çıkarılacak doğrulanabilir sonuçtur; çalışan bir entegrasyon, onaylanmış süreç tasarımı veya kullanıma hazır tesis olabilir. Kabul ölçütü, teslimatın hangi koşullarda yeterli sayılacağını açıklar. Bunlar birbirinin yerine kullanıldığında proje anlaşılır görünür, fakat uygulamada farklı beklentiler doğurur.

Proje sponsoru, girişime kurumsal destek veren ve kendi yetkisi çerçevesinde kaynak ile kritik kararların önünü açan kişidir. Proje yöneticisi yürütmeyi koordine eder. Teslimatı kullanacak iş birimi ise kabul ve sonraki işletim sorumluluklarına katılır. Bu rollerin tek kişide birleşmesi mümkündür; önemli olan sorumlulukların açık olmasıdır.

Proje, ürünün bütün yaşamını kapsamaz. Bir ürün yıllarca geliştirilebilir; onun içinde belirli bir ödeme altyapısına geçiş, başlangıcı ve sonu olan bir proje olarak yönetilebilir. Belirsizliği yüksek çalışmalarda kapsam öğrenmeyle gelişebilir. Bu durumda da hedef, karar yetkisi ve tamamlanma yaklaşımı açıklanmalıdır. Esneklik, çalışmanın süresiz ve sahipsiz kalmasını gerektirmez.

Gerçek vaka: 3M'in AWS'ye uygulama geçişi

AWS'nin yayımladığı vaka analizine göre 3M, mevcut veri merkezlerinin esneklik ve kapasite artırma konusunda yarattığı sınırlamalara karşı buluta geçiş başlattı. Kaynak, 2.200 uygulamanın 24 aylık geçiş döneminde AWS'ye taşındığını bildiriyor. Geçişler dalgalar halinde yürütüldü; her dalgadan elde edilen veriler sonraki geçişlerde sorunları azaltmak için kullanıldı. Kaynak ayrıca tasarım ve planlama dönemini geçiş döneminden ayrı anlatıyor. Bu nedenle 24 ayı bütün hazırlıkları kapsayan toplam süre gibi sunmamak gerekir.

Bu vakayı proje kavramı açısından okurken bir ayrıntı önemlidir: AWS, geniş girişimi “3M Cloud Transformation Program” olarak adlandırıyor. Program, ilişkili projelerin ortak faydalar için birlikte yönetilmesidir. Dolayısıyla bütün dönüşümü tek bir proje gibi sınıflandırmak yerine, program içindeki sınırlı geçiş çalışmalarının proje mantığını nasıl taşıdığına bakmak daha doğru olur.

Bu yazının vakadan çıkardığı ders, mevcut bir altyapıdan hedeflenen altyapıya geçişin teslimatlar ve öğrenme adımlarıyla yönetilebilmesidir. Uygulamaların taşınması ile yeni ortamın sürekli işletilmesi farklı sorumluluklar gerektirir. AWS'nin aktardığı sonuçlar sağlayıcının vaka anlatımına dayanır; burada bağımsız bir denetim sonucu olarak sunulmamaktadır.

Kaynak: AWS, Accelerating Migration at Scale Using AWS Application Migration Service with 3M Company.

Varsayımsal örnek: Kurumsal müşteriler için tek oturum açma

İşletmelere abonelikle yazılım sunan bir şirketin müşterileri, çalışanlarının şirket hesaplarıyla sisteme erişmesini istesin. Tek oturum açma, kullanıcının merkezi kimliğiyle farklı uygulamalara giriş yapabilmesidir. Satış ekibi bu ihtiyacın bazı görüşmelerde engel olduğunu, destek ekibi ise hesap yönetiminin müşterilerde ek iş yarattığını belirtiyor olsun.

“Tek oturum açmayı geliştirelim” ifadesi başlangıç için yeterli değildir. Ekip önce hangi müşteri grubunun ihtiyacını karşılayacağını, desteklenecek kimlik sağlayıcılarını ve güvenlik koşullarını belirler. Proje kapsamına giriş akışı, yönetici ayarları, testler, kurulum rehberi ve destek ekibine devir alınır. Diğer kimlik yönetimi talepleri ayrı değerlendirilir. Böylece ilgili görünen her istek otomatik olarak projeye eklenmez.

Kabul için yalnızca yazılımın yayımlanması aranmaz. Belirlenen kullanıcı senaryolarının çalışması, yetkisiz erişimin engellenmesi ve işletim sorumluluğunun devredilmesi de doğrulanır. Kurulum yükünün azalması ve satış görüşmelerindeki engelin hafiflemesi ise sonraki fayda takibinin konusudur. Bunlar ölçülmeden projenin gelir yarattığı iddia edilmez.

Yaygın üç hata

  1. Projeyi bir faaliyet listesi olarak tanımlamak

“Toplantıları yapacağız, geliştireceğiz, test edeceğiz” anlatımı hareketi gösterir; hedeflenen değişimi açıklamaz. Düzeltme, faaliyetlerden önce iş ihtiyacını ve kabul edilecek sonucu yazmaktır. Ekip bir görevin amaca katkısını açıklayamıyorsa o görevin kapsamda kalması yeniden değerlendirilmelidir.

  1. Teslimat ile faydayı aynı şey saymak

Bir portalın açılması teslimattır; müşterilerin onu kullanması ve hizmet yükünün azalması faydadır. Fayda, kullanıcı davranışına veya başka ekiplerin çalışmalarına bağlı olabilir. Bu nedenle teslimat kabulünden ayrı bir fayda sahibi, ölçüm yöntemi ve izleme zamanı tanımlanmalıdır. Proje kapanırken bu sorumluluklar kaybolmamalıdır.

  1. Kapanışı ve devri sona bırakmak

Sistem çalışsa bile desteği kimin vereceği, açık sorunların nasıl ele alınacağı ve işletim giderlerinin kimde kalacağı belirsizse devir tamamlanmamıştır. Kapanış koşulları başlangıçta konuşulmalı; eğitim, dokümantasyon ve sorumluluk kabulü planın parçası olmalıdır. Her küçük iyileştirme talebi de kapanışı süresiz ertelememelidir.

Mini uygulama: Tek sayfalık proje tanımı

Yeni bir talep geldiğinde aşağıdaki alanları doldurun. Cevapları talep sahibi, işi yapacak ekip ve sonucu kullanacak birimle birlikte gözden geçirin. Henüz bilinmeyen noktaları kesin bilgi gibi yazmayın; doğrulanacak varsayım olarak kaydedin.

İş ihtiyacı
Hangi sorun veya fırsat bu çalışmayı gerekli kılıyor?
Hedeflenen sonuç
Çalışma bittiğinde ne değişmiş olacak?
Kapsam ve kapsam dışı
Hangi işler dahil, hangi talepler ayrı ele alınacak?
Teslimatlar
Hangi somut sonuçlar ortaya çıkacak?
Kabul ölçütleri
Kim, hangi kanıtla teslimatı kabul edecek?
Sorumlular
Sponsor, yürütme sorumlusu ve işletim sahibi kim?
Kaynak ve zaman
Hangi beceriler gerekli, hangi tarihler bağlayıcı?
Bağımlılıklar
Başka ekiplerden veya sistemlerden ne bekleniyor?
Riskler ve varsayımlar
Neler gerçekleşirse planın değişmesi gerekir?
Devir ve fayda takibi
Sonucu kim işletecek, etkisini kim ölçecek?

Son kontrol olarak şu soruyu sorun: “Bu çalışmanın tamamlandığını dışarıdan bir kişi hangi kanıta bakarak anlayabilir?” Cevap yalnızca ekip kanaatine dayanıyorsa kabul ölçütleri yeterince açık değildir. Tanımı netleştirmek, ileride çıkacak kapsam tartışmalarını ve yönetim kararlarında beklemeyi azaltabilir.

İlgili terimler

Project Management Office, Proje Yaşam Döngüsü, Business Case, Project Charter, Project Sponsor, Project Governance, Program Management, Scope Baseline and Change Control, Benefits Realization Management, Organizational Change Management