30 saniyede özet

İş kırılım yapısı, İngilizce adıyla Work Breakdown Structure veya WBS, proje kapsamını daha küçük ve yönetilebilir parçalara ayırır. Önce üretilecek sonuçları görünür kılar; faaliyet, süre ve kaynak planları bu sonuçlar üzerinden geliştirilir. En büyük katkısı, “Çalışıyoruz” ifadesini “Hangi teslimat hangi koşulla tamamlanacak?” sorusuna dönüştürmesidir. İyi bir kırılım, eksik işleri ve sorumluluk boşluklarını erken gösterir. Proje yönetim ofisi, yani PMO, ortak kurallar sağlayabilir; içeriği ise işi yapacak ekipler ve teslimatı kabul edecek taraflarla birlikte oluşturmak gerekir.

Neden önemli?

Bir yönetici “Entegrasyon ne durumda?” diye sorduğunda “Büyük ölçüde tamamlandı” yanıtını alabilir. Oysa veri aktarımı çalışırken hata yönetimi tasarlanmamış, kullanıcı kabulü yapılmamış ve operasyon ekibine devir planlanmamış olabilir. Sorun yalnızca iyimser raporlama değildir. “Entegrasyon” başlığının herkes için aynı işi ifade etmemesidir.

İş kırılım yapısı bu belirsizliği azaltır. Hangi sonuçların teslim edileceği açık olduğunda tahminlerin sınırları, ihtiyaç duyulan uzmanlıklar ve tamamlanma kanıtları daha sağlıklı tartışılır. Böylece bütçe görüşmesi yalnızca toplam tutarın pazarlığı olmaktan çıkar; hangi teslimata hangi kaynağın ayrılacağına ilişkin bir karara dönüşür.

Junior bir iş analisti için kırılım, gereksinimlerin proje içinde nerede karşılandığını sorgulama aracıdır. Ürün sahibi için bir özelliğin geliştirme dışında test, geçiş ve işletim ihtiyaçlarını fark etmeyi sağlar. Yönetici için ise projenin tek bir toplam ilerleme ifadesi altında gizlenen risklerini açığa çıkarır. Kritik bir teslimatın tamamlanmaması, başka teslimatlardaki ilerlemeyle telafi edilemeyebilir.

Bu nedenle WBS hazırlamak, bir planlama yazılımına başlık girmekten daha fazla düşünme gerektirir. Ekibin ortak kapsam anlayışını sınar. Bir başlığın altına hangi işin gireceği konusunda anlaşamıyorsanız, teslimatın sınırlarında da muhtemelen açıklığa kavuşmamış bir nokta vardır.

Terim nedir?

WBS, proje hedeflerine ulaşmak için gerekli ürün, hizmet ve diğer teslimatları hiyerarşik biçimde ayrıştırır. İş paketi, bu yapının tahmin ve kontrol için kullanılabilen en alt düzey parçasıdır. İş paketini tamamlamak için gereken faaliyetler daha sonra takvimde tanımlanır. Örneğin “Onaylanmış veri eşleme dokümanı” bir sonuçtur; dokümanı hazırlama, inceleme ve düzeltme toplantıları bu sonucu üreten faaliyetlerdir.

Yüzde 100 kuralı, kırılımın onaylı kapsamın tamamını içermesini ve kapsam dışındaki işleri içermemesini anlatır. Her üst başlığın kapsamı, altındaki parçalarla karşılanmalıdır. Aynı iş farklı dallarda tekrar sayılmamalıdır. Proje yönetimi ve gerekli destek işleri de görünür olmalıdır.

WBS sözlüğü, başlıkların anlamını ve sınırlarını açıklar. İş paketinin içeriği, kapsam dışında kalanlar, kabul koşulları ve sorumlulukları burada tanımlanabilir. WBS tek başına işlerin sırasını, bağımlılıklarını veya tarihlerini göstermez. Bunlar takvim planında ele alınır. Her dalın aynı ayrıntı seviyesinde olması da gerekmez; yeterli yönetim ve kontrol sağlayan derinlik seçilir.

Kavramsal başvuru: NASA, Work Breakdown Structure Handbook.

Gerçek vaka: İtalyan telekom operatöründe fizibilite çalışmasının planlanması

Giancarlo Duranti’nin PMI tarafından yayımlanan 2016 tarihli vaka çalışması, adı açıklanmayan büyük bir İtalyan telekom operatörünün dönüşüm hazırlığını anlatır. Gelecekteki programın fizibilitesini değerlendiren çalışma beş ay sürmüş; iş ve teknik birimlerden 55’ten fazla kişi katılmıştır.

Çalışmanın karmaşıklığı ve yönetimin belirlediği sıkı takvim, ayrıntılı bir WBS hazırlanmasını gerektirmiştir. Gereksinim çalışmaları müşteri, teklif, satış ve satış sonrası akışlarına ayrılmıştır. Paralel yürütülen bu akışlarda kullanım senaryoları belirlenmiş; atölyeler, görüşmeler ve odak gruplarıyla bilgi toplanmıştır. Gereksinim çalışma planı, sponsorla kaynak görüşmelerinde ve risklerin değerlendirilmesinde de kullanılmıştır.

Vakadan çıkarılabilecek ders, kırılımın yalnızca uygulama geliştirme için kullanılmadığıdır. Analiz ve fizibilite işi de yönetilebilir bir yapıya ihtiyaç duyar. Bununla birlikte çalışma, WBS sayesinde elde edilen ayrı bir tasarruf oranı veya süre kazanımı açıklamaz. Dolayısıyla bu kullanımı, tek başına ölçülmüş bir verimlilik sonucu gibi sunmak doğru olmaz.

Kaynak: Giancarlo Duranti, “Best Practices from a Business Analysis Telco Project”, PMI, 13 Mayıs 2016.

Varsayımsal örnek: Pazaryeri entegrasyonunu teslimatlara ayırmak

Ekip, kapsamı katalog aktarımı, stok güncelleme, sipariş işleme, iade yönetimi ve operasyon hazırlığı gibi teslimat alanları üzerinden yeniden ele alır. Katalog aktarımının altında ürün alanı eşlemeleri, doğrulama kuralları ve aktarım hatalarının ele alınması tanımlanır. Operasyon hazırlığında ise destek prosedürü, sorumlu ekip eğitimi ve devir kabulü görünür olur.

“Stok güncelleme” iş paketinin kabul koşulu, sadece bağlantının kurulması değildir. Onaylanmış senaryolarda stok bilgisinin doğru aktarılması, başarısız aktarımın fark edilmesi ve yeniden denemenin beklenen davranışı göstermesi gerekir. Kesin performans eşikleri, iş ihtiyacı ve teknik değerlendirme sonucunda belirlenir; taslağa rastgele değer yazılmaz.

Finans ekibi toplantıda ödeme mutabakatı ihtiyacını gündeme getirir. Ekip önce bunun onaylı kapsamda bulunup bulunmadığını kontrol eder. Varsa eksik kırılım tamamlanır. Yoksa talep değişiklik değerlendirmesine alınır. WBS’yi ayrıntılandırmak, yeni işi kendiliğinden onaylamak anlamına gelmez.

Bu yapıdan sonra faaliyetler ve bağımlılıklar planlanır. Katalog alanlarının onayı gecikirse hangi iş paketlerinin etkileneceği anlaşılır. Yöneticiye “Proje ilerliyor” demek yerine tamamlanan teslimatlar, açık kabul koşulları ve karar bekleyen noktalar raporlanabilir.

Yaygın üç hata

  1. Departman adlarını teslimat sanmak. “Yazılım ekibi”, “Pazarlama” ve “Operasyon” başlıkları kimin çalışacağını gösterebilir, ancak ne üretileceğini açıklamaz. Birden fazla ekibin katkıda bulunduğu teslimat bu yapıda parçalanıp sahipsiz kalabilir. Önce sonucu ve sınırını tanımlayın, ardından sorumluluğu bağlayın. Sorumlu kişinin bulunması, diğer ekiplerin katkısına ihtiyaç olmadığı anlamına gelmez.
  2. Her şeyi aynı ölçüde ayrıntılandırmak. Bütün dalları aynı sayıda seviyeye indirmek biçimsel bir düzen yaratabilir, fakat yönetim ihtiyacını karşılamayabilir. Çok geniş iş paketleri belirsizliği saklar; gereksiz küçük parçalar ise takip yükü üretir. “Bu parçayı tahmin edebiliyor, sorumlusunu belirleyebiliyor ve tamamlanmasını doğrulayabiliyor muyuz?” sorusu, ayrıntı seviyesini değerlendirmek için daha kullanışlıdır.
  3. Çalışılmış süreyi tamamlanmış teslimatla karıştırmak. Bir pakete çok emek verilmiş olması, kabul koşullarının karşılandığını göstermez. Eksik veri, başarısız test veya beklenen onay ilerlemeyi sınırlayabilir. Raporlama yöntemi baştan belirlenmelidir. Birkaç tamamlanmış paketten hareketle bütün projenin ilerleme oranını hesaplamak da paketlerin büyüklük ve ölçüm yöntemleri dikkate alınmadan yanıltıcı olur.

Mini uygulama: Bir iş paketini karar verilebilir hale getirmek

Mevcut projenizden “Entegrasyon”, “Raporlama” veya “Geçiş” gibi geniş bir başlık seçin. Önce bu başlığın teslim etmesi gereken sonuçları yazın. Ardından her sonuç için aşağıdaki kısa kartı doldurun.

İş paketi kodu ve adı
—
Bağlı olduğu üst teslimat
—
Üretilecek sonuç
—
Kapsama dahil işler
—
Kapsam dışında kalan işler
—
Sorumlu kişi veya rol
—
Kabul edecek kişi veya rol
—
Kabul koşulları ve kanıtları
—
Gerekli girdiler ve dış bağımlılıklar
—
Tahminin dayandığı varsayımlar
—
Açık riskler ve belirsizlikler
—

Kartları işi yapacak ekip ve teslimatı kullanacak tarafla birlikte gözden geçirin. Üst teslimat için gerekli olup hiçbir karta girmeyen işi ve birden fazla kartta tekrar edilen işi arayın. Ardından faaliyetleri ve tarihleri planlayın. PMO, bu kartların biçimini standartlaştırabilir; kaliteyi belirleyen ise başlık sayısı değil, kapsamın ekipler arasında aynı anlamı taşımasıdır.

İlgili terimler

Scope Baseline, Scope Statement, WBS Dictionary, Work Package, Decomposition, Acceptance Criteria, Responsibility Assignment Matrix, Dependency Management, Schedule Baseline, Cost Baseline, Change Control, Requirements Traceability