30 saniyede özet
Project intake, proje fikirlerinin ortak kurallarla kayda alınması ve değerlendirmeye hazırlanmasıdır. Project selection ise hangi taleplerin araştırmaya, yatırıma veya uygulamaya geçeceğinin seçilmesidir. Talebin kaydedilmesi, proje olarak onaylandığı anlamına gelmez. Önce ihtiyacın açıklığı, mevcut çalışmalarla ilişkisi, beklenen faydası ve uygulanabilirliği değerlendirilir. Seçim ile önceliklendirme de farklıdır: Seçim hangi işlerin yapılacağını, önceliklendirme bunların göreli önemini belirler. Başlatma zamanı ise kapasite ve bağımlılıklara bağlıdır. İşlevsel bir süreç, fikrin karara nasıl dönüştüğünü ve talep sahibine hangi gerekçeyle cevap verildiğini görünür kılar.
Neden önemli?
Bir yönetici doğrudan yazılım ekibinden geliştirme ister, satış ekibi müşteri için ayrı bir taahhüt verir, operasyon ekibi kendi otomasyonunu başlatır. İşlerin her biri yararlı olabilir. Ancak ortak görünüm bulunmadığında aynı uzmanlara verilen sözler birbiriyle çatışır. Yönetim, resmî proje listesinde olmayan çalışmalar nedeniyle kapasitenin neden tükendiğini anlamakta zorlanır.
Talep toplama süreci bu görünmezliği azaltır. Başvuran kişiyi yalnızca form doldurmaya yönlendirmek yeterli değildir. İhtiyacın anlaşılması, uygun çalışma türüne yönlendirilmesi ve kararın izlenmesi gerekir. Bir hata düzeltmesi destek sürecine, küçük ürün iyileştirmesi ilgili ürün ekibine, kapsamlı sistem geçişi proje değerlendirmesine gidebilir. Her talebin proje haline gelmesi gerekmez.
Üst yönetim açısından seçimin değeri, sınırlı kaynaklar için bilinçli tercih yapılmasıdır. İyi hazırlanmış bir fikir doğrudan tam yatırım almak zorunda değildir; önce belirsizliği azaltacak araştırma yapılabilir. Zayıf bir çözüm önerisinin altında önemli bir ihtiyaç da bulunabilir. Bu nedenle değerlendirme, talep sahibinin sunum becerisinden çok sorunun kanıtına ve çözüm seçeneklerine dayanmalıdır.
Terim nedir?
Project intake, taleplerin tanımlı giriş noktalarından alınması, kaydedilmesi, ilk incelemeden geçirilmesi ve uygun karar yoluna yönlendirilmesidir. Ortak kanal mutlaka tek bir ekran anlamına gelmez. Farklı başvuru yolları kullanılabilir; önemli olan taleplerin ortak kayıt ve kurallara bağlanmasıdır. Talep sahibi kendi önerisinin durumunu ve bir sonraki adımı anlayabilmelidir.
İlk incelemede sorunun ne olduğu, kimleri etkilediği, hangi kanıtın bulunduğu ve mevcut bir çalışmayla karşılanıp karşılanamayacağı araştırılır. Çözüm önerisi ayrı kaydedilir. “Müşteri portalı yapalım” bir çözüm fikridir; müşterilerin rapora geç ulaşması ise araştırılabilecek ihtiyaçtır. Bu ayrım, öneriyi reddetmeden farklı çözüm yollarını değerlendirmeyi mümkün kılar.
Project selection, değerlendirilmiş seçenekler arasında kaynak ayrılacak girişimlerin seçilmesidir. Karar yalnızca kabul veya ret olmak zorunda değildir. Ayrıntılı inceleme, sınırlı deneme, mevcut çalışmayla birleştirme veya bekletme de uygun sonuçlar olabilir. Her kararın gerekçesi ve sorumlusu kaydedilir. Bekletilen talepler için yeniden değerlendirme koşulu belirlenmezse liste zamanla unutulmuş fikirler arşivine dönüşebilir.
Business case, yani iş gerekçesi, yatırımın faydalarını, maliyetlerini, risklerini ve alternatiflerini birlikte değerlendirir. İlk talepte bütün ayrıntıların kesinleşmesi beklenmez. İncelemenin derinliği, girişimin büyüklüğüne ve belirsizliğine göre artırılabilir. Başlangıçta yaklaşık kaynak ihtiyacı bilinmiyorsa, bu bilgi uydurulmak yerine araştırılması gereken alan olarak tutulmalıdır.
Önceliklendirme, değerlendirilen işler arasındaki göreli önemi gösterir. Yüksek öncelik, işin hemen başlayabileceği anlamına gelmez. Kapasite, belirli dönemde kullanılabilir zaman ve beceridir. Bağımlılık ise ilerlemenin başka bir teslimata veya koşula bağlı olmasıdır. Seçim kararının uygulanabilir hale gelmesi için bu ikisi değerlendirilmelidir. Yeni işin mevcut taahhütleri nasıl etkilediği de açıklanmalıdır.
Proje Yönetim Ofisi, kısaca PMO, kayıtların tutarlılığını ve karar hazırlığını destekleyebilir. İş analisti ihtiyacı netleştirir, ilgili ekipler uygulanabilirliği değerlendirir, yetkili yönetici veya kurul yatırım kararını verir. Acil talepler için hızlandırılmış yol tanımlanabilir. Hızlandırma, kararın ve gerekçenin hiç kaydedilmemesi anlamına gelmemelidir; istisnalar da görünür olmalıdır.
Gerçek vaka: MetLife'ta iş gerekçesine dayalı seçim
PMI'nin yayımladığı Matt Schur imzalı, Şubat 2018 tarihli MetLife yazısı, bilgi teknolojileri yatırımlarının seçimini ele alıyor. Kaynağa göre önceki seçim yaklaşımında taleplerin zamanlaması, değerinden daha belirleyici olabiliyordu. 2013'te PMO kurulduğunda, 500 bin doların üzerindeki proje ve programların iş gerekçelerinin yalnızca yüzde 11'i inceleniyordu.
Yazı, yayımlandığı dönemde bütün iş gerekçelerinin değerlendirmeye alındığını belirtiyor. Onay sürecinde planlanan kapsam, bütçe, stratejik uyum ve hedeflenen faydalar inceleniyordu. Girişimler puanlanıyor ve değerlendirme üst yönetime sunuluyordu. Kaynak, daha disiplinli seçim yaklaşımının PMO'nun kuruluşundan itibaren 125 milyon doların üzerinde gelir artışı ve maliyet azalması sağladığını aktarıyor.
Bu tutar, yayın içindeki kurum anlatımına dayanır; bütün hesaplama ayrıntıları paylaşılmadığından burada bağımsız olarak yeniden doğrulanmış bir finansal sonuç sayılmıyor. Vakadan çıkarılabilecek ders, talepleri ortak iş gerekçesi üzerinden karşılaştırmaktır. Kaynak, tek bir başvuru formunun bu sonucu ürettiğini söylemiyor; daha geniş bir portföy ve karar düzenini anlatıyor.
Varsayımsal örnek: Danışmanlık şirketinde raporlama talebi
Bir danışmanlık şirketinde müşteri portalı, rapor hazırlama otomasyonu ve müşteri ilişkileri sistemi değişikliği talepleri gelsin. Talepler ortak kayda alınır. İlk incelemede portal ve otomasyon fikirlerinin aynı rapor hazırlama sorununa bağlı olabileceği görülür. İki ayrı proje açmak yerine iş analisti mevcut süreci ve müşteri erişim ihtiyacını birlikte inceler.
Danışmanlar raporları hazırlamak için farklı kaynaklardan veri topluyor; müşteriler de güncel dosyayı bulmakta zorlanıyor olsun. Portal, veri hazırlama işini kendiliğinden azaltmayabilir. Otomasyon ise müşterinin doğru dosyaya erişmesini tek başına çözmeyebilir. İhtiyaçlar ayrıştırılarak mevcut süreci iyileştirme, hazır çözüm kullanma ve özel geliştirme seçenekleri değerlendirilir.
Belirsizlik yüksekse yönetim önce sınırlı araştırmaya kaynak ayırabilir. Müşteri kullanım beklentisi, veri erişimi ve işletim ihtiyacı incelenir. Bu aşamanın onayı, bütün portal geliştirmesinin onayı olarak yorumlanmaz. Araştırma sonucunda yatırımın kapsamı ve gerekçesi hazırlanır; yetkili karar sahipleri seçenekleri karşılaştırır.
Müşteri ilişkileri sistemi talebi aynı uzmanlara ihtiyaç duyuyorsa başlatma sırası ayrıca değerlendirilir. Seçilen girişimin ne zaman başlayacağı, hangi koşullara bağlı olduğu ve hangi işin bekleyeceği talep sahiplerine bildirilir. Böylece kayıt, seçim ve kaynak taahhüdü birbirine karıştırılmadan uygulanabilir karar alınır.
Yaygın üç hata
- Kaydı onay gibi göstermek
Talep numarası verilmesi veya listeye eklenmesi, ekibin işe başlayacağı izlenimini yaratabilir. Durumları ve anlamlarını açık tanımlayın. Araştırma izni, yatırım onayı ve başlatma kararı arasındaki farkı talep sahibine açıklayın. Tarih taahhüdü ancak uygun yetki ve kaynak değerlendirmesiyle verilmelidir.
- İlk başvuruda gereksiz ayrıntı istemek
Kesin maliyet ve ayrıntılı plan olmadan fikri kabul etmemek, erken ihtiyaçların görünmesini engelleyebilir. İlk inceleme için gerekli asgari bilgiyi belirleyin. Araştırma ilerledikçe ayrıntıyı artırın. Eksik bilgiyi bilinmeyen olarak kaydetmek, güven vermek için uydurulmuş tahmin kullanmaktan daha yararlıdır.
- Kararı talep sahibine gerekçesiz bırakmak
Cevapsız bekleyen talepler, ekiplerin gayriresmî yollara yönelmesine neden olabilir. Ret veya bekletme gerekçesini anlaşılır biçimde paylaşın. Yeniden değerlendirme için hangi bilgi ya da koşulun gerektiğini belirtin. Karar süresini izlemek, sürecin darboğazlarını görmeye yardımcı olur.
Mini uygulama: İlk talep ve karar şablonu
Yeni bir fikir için aşağıdaki alanları doldurun. Talep sahibi ile değerlendiricinin sorumluluklarını ayırın; bilinmeyenleri araştırma ihtiyacı olarak işaretleyin.
- İhtiyaç
- Hangi sorun veya fırsat var?
- Etkilenenler
- Hangi kullanıcı veya iş birimleri etkileniyor?
- Kanıt
- İhtiyacı hangi gözlem veya veri destekliyor?
- Öneri
- Talep sahibinin çözüm fikri nedir?
- Alternatif
- Mevcut çalışma veya farklı yol var mı?
- Fayda
- Hangi değişim bekleniyor?
- Zaman
- Tarih ihtiyacının gerekçesi nedir?
- Kaynak ve bağımlılık
- Hangi uzmanlık ve koşullar gerekli?
- Karar
- Araştırma, seçim, bekletme veya ret mi?
- Takip
- Kararın sorumlusu ve sonraki adımı kim?
Son kontrolde şu soruyu sorun: “Bu talep seçilirse hangi taahhüdümüz değişecek?” Cevap verilmeden başlangıç sözü sunmak, görünür kayıtların arkasında uygulanamaz bir iş yükü yaratabilir. Talep sürecinin değeri, fikirleri toplamak kadar kaynak kararlarını anlaşılır ve izlenebilir hale getirmesidir.
İlgili terimler
Business Case, Problem Statement, Business Objective, Strategic Alignment, Project Portfolio Management, Prioritization and Weighted Scoring, Feasibility Study, Resource Capacity Planning, Project Governance, Project Charter