30 saniyede özet

Proje yaşam döngüsü, projenin başlangıcından kapanışına kadar geçtiği aşamaların bütünüdür. Bu aşamalar, çalışmanın niteliğine göre fizibilite, tasarım, geliştirme, geçiş ve devir gibi adlar alabilir. Yaşam döngüsü hangi işin ne zaman yapılacağını, hangi kanıtla ilerleme kararı verileceğini ve tamamlanmanın nasıl kabul edileceğini açıklar. Başlatma, planlama, yürütme, izleme ve kontrol, kapanış ise yönetim süreç gruplarıdır; yaşam döngüsü aşamalarıyla birebir aynı değildir. İyi bir yapı, belirsizlik azaldıkça kararları günceller ve projenin nasıl kapanacağını baştan görünür kılar.

Neden önemli?

Bir projede ekipler aynı kelimeleri kullanıp farklı şeyler anlayabilir. “Tasarım tamamlandı” ifadesi bir ekip için ekranların çizilmesi, başka bir ekip için güvenlik ve veri akışlarının onaylanması demektir. Bu fark konuşulmadığında sonraki çalışmalar eksik bilgiyle başlar. Sorun ancak geliştirme veya test sırasında görünür hale gelir ve önceki kararları yeniden açmak gerekir.

Yaşam döngüsü, çalışmayı anlamlı karar ve teslimat bölümlerine ayırarak bu belirsizliği azaltır. Teslimat, ortaya çıkarılacak doğrulanabilir sonuçtur. Her aşamada gereken teslimatlar ve bunların kabul koşulları belirlenir. Böylece yönetim yalnızca ne kadar zaman geçtiğini değil, sonraki işe başlamak için yeterli hazırlığın bulunup bulunmadığını da değerlendirebilir.

Üst yönetim açısından yaşam döngüsü, kaynak taahhüdünü bilgi olgunluğuyla ilişkilendirir. Fikri araştırmak için verilen izin ile kapsamlı uygulamaya ayrılan bütçe aynı karar olmak zorunda değildir. İlk incelemede yatırım anlamlı görünürken sonraki bulgular gerekçeyi zayıflatabilir. Bu durumda kapsamı değiştirmek, beklemek veya durdurmak mümkün olmalıdır. Aşamalar, yalnızca projeyi ilerleten değil, gerektiğinde yeniden değerlendiren karar noktaları da oluşturur.

Terim nedir?

Proje yaşam döngüsü, bir projenin başından sonuna izlediği aşama yapısıdır. Her sektör ve çalışma türü için tek bir zorunlu aşama dizisi yoktur. Bir tesis projesinde tasarım, yapım ve devreye alma öne çıkabilir. Bir yazılım geçişinde keşif, hazırlık, aktarım, doğrulama ve devir kullanılabilir. Aşamaların adları, ekibin yaptığı işi ve yönetimin kontrol ihtiyacını anlaşılır biçimde yansıtmalıdır.

PMI, proje yönetim süreç gruplarının proje aşamaları olmadığını özellikle belirtir. Planlama ve izleme gibi yönetim faaliyetleri projenin farklı aşamalarında tekrar uygulanabilir. Örneğin tasarım sırasında da planlama yapılır, riskler izlenir ve değişiklikler değerlendirilir. “Planlama bitti, artık yalnızca yürütme var” düşüncesi, değişen koşullar karşısında planın güncel tutulmasını zorlaştırır.

Öngörücü yaklaşımda kapsam ve teslimat yolu büyük ölçüde önceden belirlenir. Uyarlanabilir yaklaşımda ise öğrenme ve geri bildirim, sonraki işleri düzenli biçimde şekillendirir. Karma yaklaşım bu özellikleri ihtiyaca göre birlikte kullanır. Örneğin altyapı geçişinin zorunlu tarihi sabitken kullanıcı arayüzü kısa geliştirme döngüleriyle olgunlaştırılabilir. Yaklaşım seçimi, yalnızca ekibin alışkanlığına değil, belirsizliğe ve değişimin maliyetine dayanmalıdır.

Çıkış ölçütü, bir aşamanın yeterli biçimde tamamlandığını gösteren koşuldur. Karar kapısı ise eldeki kanıta bakılarak devam, yeniden çalışma, bekletme veya durdurma kararının verildiği noktadır. Her küçük çalışma ağır bir kurul gerektirmez. Yine de kimlerin hangi kanıtla karar vereceği açıklanmalıdır. Aksi halde onaylar kişisel kanaate veya toplantıya katılanların ısrarına bağlı kalabilir.

Yaşam döngüsü, ürünün bütün yaşamıyla da karıştırılmamalıdır. Proje kapanabilir; ortaya çıkan ürünün geliştirilmesi ve işletimi devam edebilir. Beklenen iş faydaları daha sonra oluşacaksa ölçüm sorumluluğu uygun kişiye devredilir. Bu durum projeyi belirsiz süreyle açık tutmayı gerektirmez; kapanışın yanında fayda takibinin nasıl sürdürüleceğini belirlemeyi gerektirir.

Gerçek vaka: Newcastle Üniversitesi'nin bulut geçişi

AWS'nin 2021 tarihli vaka anlatımına göre Avustralya'daki University of Newcastle, uygulamalarını buluta taşımak için başlangıçta hedef iş yüklerine yönelik 18–24 aylık aşamalı bir yolculuk planladı. Ancak veri merkezinin yıkım programı nedeniyle tesisin Eylül 2020'ye kadar boşaltılması gerekiyordu. Bu koşul, geçiş yaklaşımını ve takvimi değiştirdi.

Kaynak, 139 uygulamanın geçişi için dokuz aylık sıkı bir takvimden söz ediyor. Üniversite, AWS ve ortakları birlikte çalıştı; planlar ve ilerleme takip edildi, iş birimleriyle etki değerlendirme çalışmaları yapıldı. Vaka anlatımına göre proje Haziran 2020'de tamamlandı. Dolayısıyla ilk planlanan süreyi gerçekleşen proje süresi olarak sunmak doğru değildir.

Bu vakadan çıkarılabilecek ders, dış koşullar değiştiğinde yaşam döngüsündeki kararların ve hazırlıkların yeniden ele alınması gerektiğidir. Kaynak üniversitenin bütün aşama kapılarını ayrıntılı biçimde vermediği için burada belirli bir yaşam döngüsü şablonu uyguladığı iddia edilmiyor. Vaka, teknoloji sağlayıcısının yayımladığı anlatımdır; sonuçlar bu kaynak çerçevesinde aktarılmaktadır.

Kaynak: AWS, University of Newcastle Digitises Its Student and Researcher Experience on AWS, 2021.

Varsayımsal örnek: Ödeme sayfasını yenileme

Bir e-ticaret şirketi, müşterilerin ödeme adımında zorlandığına ilişkin destek kayıtları nedeniyle ödeme sayfasını yenilemek istesin. İlk aşama keşiftir. Ekip kullanıcı davranışını, hata kayıtlarını ve ödeme sağlayıcısının koşullarını inceler. Bu aşamanın çıkış ölçütü, belirli bir tasarımın beğenilmesi değil, müdahale edilecek sorunun yeterli kanıtla açıklanmasıdır.

Çözüm hazırlığında alternatifler değerlendirilir, güvenlik gereksinimleri belirlenir ve geliştirilecek kapsam karara bağlanır. Geliştirme ile doğrulama kısa döngüler halinde yürütülebilir. Her döngüde plan güncellenir ve bulunan sorunlar değerlendirilir. Böylece test, bütün geliştirme bittikten sonra yapılan tek bir son kontrol olmaktan çıkar.

Geçiş öncesinde kritik ödeme senaryolarının çalıştığı, izleme araçlarının hazır olduğu ve gerektiğinde önceki sürüme dönülebileceği doğrulanır. Kademeli yayın, çözümün önce sınırlı bir kullanıcı grubuna açılmasıdır. Bu yaklaşım seçilirse hangi bulgunun yayını genişleteceği veya durduracağı önceden belirlenir.

Kapanışta teslimat kabul edilir, açık işler sahiplerine aktarılır ve işletim ekibi devri onaylar. Ödeme başarısının veya kullanıcı deneyiminin geliştiği ise ölçümle değerlendirilir. Sonuçlar henüz görünmüyorsa sonraki incelemenin tarihi ve sorumlusu kaydedilir. Kodun yayımlanması, beklenen faydanın gerçekleştiğine tek başına kanıt değildir.

Yaygın üç hata

  1. Süreç gruplarını değişmez aşamalar gibi kullanmak

İzleme ve kontrolü yürütmeden sonraya bırakmak, sapmaların geç fark edilmesine yol açar. Planlama da yalnızca başlangıçta yapılan bir faaliyet değildir. Yaşam döngüsü aşamalarını teslimat yapısına göre belirleyin; yönetim faaliyetlerini bu aşamalarda gerektiği kadar tekrar uygulayın.

  1. Aşama onayını belge teslimine indirgemek

Dokümanın gönderilmiş olması, içeriğinin yeterli veya uygulanabilir olduğunu göstermez. Her çıkış ölçütü için aranacak kanıtı ve kabul yetkisini açıklayın. Örneğin test raporu kadar, açık kritik sorunların durumu ve bunlara ilişkin karar da ilerleme değerlendirmesinde dikkate alınmalıdır.

  1. Kapanışı en sona kadar tasarlamamak

Destek sorumluluğu, eğitim ve erişim ihtiyaçları son gün konuşulursa çalışan bir çözüm devredilemeyebilir. Kapanış koşullarını erken belirleyin. Açık işlerin devri ve ileride ölçülecek faydalar için sahip atamak, projenin gerçekten tamamlanmasını kolaylaştırır.

Mini uygulama: Aşama ve karar şablonu

Bir proje seçin ve her aşama için aşağıdaki alanları doldurun. İlk aşamalarda bilinmeyenleri varsayım olarak kaydedin; karar verildikçe güncelleyin.

Aşama adı
Hangi anlamlı iş bölümü yürütülecek?
Amaç
Bu aşama hangi belirsizliği azaltacak veya sonucu üretecek?
Teslimatlar
Hangi doğrulanabilir çıktılar hazırlanacak?
Giriş koşulları
Başlamak için hangi bilgi ve kaynak gerekli?
Çıkış ölçütleri
Tamamlanma hangi kanıtla anlaşılacak?
Karar sahibi
İlerlemeyi kim yetkilendirecek?
Seçenekler
Devam, yeniden çalışma, bekleme veya durdurma nasıl değerlendirilecek?
Devir
Sonraki aşama veya işletim ekibi neyi kabul edecek?

Şablonu son kontrol olarak şu soruyla sınayın: “Takvimde aşama sonuna geldik ama gereken kanıt yoksa ne yapacağız?” Cevap belirsizse aşama yapısı henüz karar vermeyi desteklemiyordur. Tarihleri ve teslimatları birlikte değerlendiren bir yaklaşım, planın uygulanabilirliğini daha görünür kılar.

Kavramsal kaynak: PMI, What Is a Project?

İlgili terimler

Proje, Project Governance, Business Case, Project Charter, Stage-Gate, Scope Baseline and Change Control, Risk Register and Response Planning, Benefits Realization Management, Lessons Learned and Knowledge Transfer