Açık bir amaç olmadan hiçbir şey yapmayın

Açık bir amacı olmadıkça hiçbir şey yapmamalısınız. Yapmayı düşündüğünüz şey dışında her şeyin aynı olduğu iki paralel dünya hayal edin: Bu dünyalar ne kadar farklı olurdu? Fark, o şeyi yapmak için harcanan çabaya değer mi?

Aklınızda net bir amacınız yoksa ve sadece herkes yaptığı için yapıyorsanız veya herkes bunu yapmanın önemli olduğunu söylediği için yapıyorsanız, o zaman

• sizin durumunuzda gerçek bir yararı olmayabilir ve bu nedenle bundan hiçbir şey elde edemeyebilirsiniz; veya
• sizin durumunuzda yine de potansiyel faydaları olabilir, ancak aklınızda bir amaç olmadığı için, bunu yapma şekliniz faydaların farkına varmanıza yardımcı olmayabilir.

Örnek: Portföyler ve programlar

Projelerin seçilmesi ve başlatılmasıyla ilgileniyorsanız, üründen çok, faydalara ve çözülmesi gereken sorunlara odaklandığınızdan emin olmalısınız. Klasik örnek, asansörlerinin hızıyla ilgili şikayetler alan ve bu nedenle tam bir başarı olmadan hızı artırmak için birden fazla proje yürüten asansör üreticisidir. Bu sorun, “doğal” çözüm (daha hızlı asansörler) yerine soruna (insanların can sıkıntısı veya rahatsızlığı) odaklanmaya karar verene kadar devam etti. Sonuç olarak asansörlere aynalar eklediler ve problemi basit ve ucuzca çözdüler.

Proje yönetiminin temelde işleri doğru yapmakla ilgili olduğunu, portföy yönetiminin ise doğru şeyleri yapmak olduğunu unutmayın. Yanlış projeleri yapıyorsanız, projelerinizi ne kadar iyi yürüttüğünüz önemli değildir. Her şey bir amaca sahip olmakla ilgilidir.

Örnek: Bir bütün olarak proje

Ürünün esnekliği projeden projeye değişiklik göstermektedir. Bazı BT geliştirme projelerinde ürün tamamen esnektir ve ürünün nihai şekli, uyarlanabilir (Çevik) bir yaklaşım gerektiren, proje sırasındaki artımların oluşturacağı geri bildirimlere bağlıdır. Bu, pratik anlamda portföy, program ve proje katmanlarının bir birleşimidir ve nihai hedefe azami dikkat gösterilmesini gerektirir. Amacı belgelemek ve erişilebilir kılmak iyi bir fikirdir; bazı Scrum projelerinde kullanıldığı şekliyle “ürün vizyonu"nun amaçlarından biridir. Çevik projelerde iş değerine odaklanmak, amaçla hizalanmayı garantilemenin yoludur.

Ürünün nispeten sabit olduğu ve belirlenen ürünün amacı karşılamasını sağlayacak başka mekanizmaların bulunduğu diğer proje türlerinde, proje ekibi üyelerinin odaklarının büyük bir bölümünü amaçtan ürüne kaydırmaları mümkündür ( dolayısıyla PRINCE2^®’nin “ürünlere odaklanma” ilkesi). Ancak inşa edilenin amacı karşıladığından emin olmak için amaca en azından asgari düzeyde dikkat edilmesi gerekir, bu da öngörülen faydalar ile beklenen faydalar karşılaştırılarak yapılabilir ( dolayısıyla PRINCE2^®’deki “sürekli iş gerekçesi” ilkesi ve “iş durumu” teması).

Harici müşteri için bir proje yürütüldüğünde, müşterinin proje için kendi amacı ve şirketinizin farklı bir amacı olur. Gerçekten başarılı olmak için her ikisini de anlamalı ve kullanmalısınız.

Örnek: Proje izleme

Nihai amaca odaklanmak gereklidir, ancak günlük hayatta çoğu için çok soyut olabilir. Bu nedenle, daha pratik hale getirmek için bir amaç/motivasyon hiyerarşisine ihtiyaç vardır. İlk olarak, projenin gerekçesi ve faydaları nihai amaca dayalı olarak tanımlanır ve ardından gerekçeyi karşılamak için proje değişkenleri (örn., zaman, maliyet ve kalite) için açık ve örtülü hedefleriniz olacaktır ve sonuç olarak nihai amaç sağlanacaktır. Bunlar, günlük görevlerimizin çoğu için yararlı olan alt düzey amaçlardır.

İzleme söz konusu olduğunda, nihai amacı izlemek mümkün olmayabileceğinden, projenin düşük seviyeli izlemesi en düşük seviyedeki değişkenler kullanılarak yapılacaktır. Bu durumda, yine de amaçları aklınızda tutmalısınız: İzlemenin amacı nedir?

Normal ve kabul edilebilir bir cevap, doğru yolda olup olmadığımızı görmek ve değilse, bizi tekrar yola getirecek veya hedefleri ayarlayacak belirli bir tepkiyi tetiklemek ve nihai amacı hala karşılayıp karşılayamayacağını görmektir. Bu nedenle ölçümlerimiz bu düşük seviyeli amaca yardımcı olmalıdır ve uygun ölçümler, nihayi değişkenler için tahminlerdir; örneğin, projeyi ne zaman bitirebiliriz? Projeyi bitirmek için ne kadar paraya ihtiyacımız olacak?

Bugüne kadar planlanan ve gerçekleşen değerler gibi diğer tüm ölçümler, yönetim amacıyla kullandığınız nihai değerler değil, tahminleri hesaplamak için ihtiyaç duyduğunuz ara değerlerdir.

Örnek: Belgeler

Projede hangi geliştirme yaklaşımını kullanırsanız kullanın, planlama her zaman gereklidir. Asıl soru, her bir plan türündeki ayrıntı düzeyidir. Planda yeterli ayrıntı yoksa, plan yeterince katkıda bulunamayacak ve projenin yürütülmesi entegre, bütünsel kararlardan ziyade geçici kararlara dayanacaktır. Öte yandan, birçok insan dikkatli olmaya ve planlarına çok fazla ayrıntı eklemeye çalışır, bu da hazırlamayı ve bakımı çok zorlaştırır ve projenin belirsizlikleri için çok katıdır. Sonuç olarak, plan gerçek dışı ve işe yaramaz hale gelir.

Ayrıntı düzeyine karar vermenin en iyi yolu, plandaki her öğe için bir amacı göz önünde bulundurmaktır. Örneğin, plana kaynak eklemeyi düşünüyorsanız, bunun için bir amacınız olmalı: Nasıl kullanacaksınız? Projeye nasıl yardımcı olacak? Ne kadar çaba gerektirecek? ve buna değer mi?

Bu, bazen planlarınızda belirli bir öğeye sahip olmak isteyip istemediğinize, bazen de bir şeyi nasıl planlamak veya hazırlamak istediğinize karar vermekle ilgilidir. İster bir iş vakası, ister bir proje başlatma belgesi veya bir rapor olsun: yine de kendinize bu belgeyi neden hazırladığınızı ve bunun projeye nasıl yardımcı olabileceğini sormalısınız.

Bir “şablon” aramak, bir amaca dayalı bir şey yapmanın tam tersidir.

Örnek: Durum raporlama

Birçok projede gerçekten uzun durum raporlarına sahip olmak yaygındır. Bu NUP’a dayanarak, kendimize raporun amacının ne olduğunu ve diğer insanların çoğu ne yapıyor olursa olsun bu amaca nasıl ulaşabileceğimizi sormalıyız.

Bu, çoğu durumda, uzun raporlar yerine, paydaşların gerçekten okuyup anladığı çok basit tek sayfalık raporlar hazırlamamıza neden olabilir. Bu, amaca dikkat etmektir.

Ancak tek sayfalık raporlar hazırlarsanız, bazı kişiler size itiraz edebilir ve “uygun” bir izleme sisteminizin olmadığını düşünebilir. Pratikte bu sizin için ikinci bir amaç yaratır (paydaşların projenin durumunu anlamalarına yardımcı olan birinci amacın yanında) ve bunu tatmin etmek için çok uzun ikinci bir rapor türü oluşturabilirsiniz. Ancak, bunu ilk raporla karıştırmamalısınız, çünkü bu iki amaç aynı değildir.

Örnek: İş gerekçesi ve proje başlatma belgesi

İş gerekçesi ve proje başlatma belgesi gibi belgeler hazırlamak çoğu insan için genellikle sıkıcı, sonuçsuz, bürokratik bir gereklilik iken, bu belgelerin hepsinin çoğu proje için geçerli olan amaçları vardır. Bir “şablon” bulmaya çalışırsanız ve onu doldurursanız, iş boşa gider; oysa ki bunun yerine bu belgelerin gerçek amacını kontrol edebilir, projenize nasıl yardımcı olabileceklerini görebilir ve ardından belgeyi istediğiniz şekilde hazırlayabilirsiniz, sadece bu amaçları yerine getirmek için: bu doğru belge olacaktır.

Belgeleri amaçlarına uygun şekilde nasıl hazırlayabileceğinizi düşünürken, her senaryoyu düşünmeyebilir ve bir şeyleri kaçırabilirsiniz. Bunu önlemek için PRINCE2^®, PMBOK^® Guide, P3.express ve DSDM^® gibi kaynakların ne önerdiğini kontrol edebilir ve ardından bu önerileri amaçlara göre değerlendirebilirsiniz.

Örnek: Proje sonrası

Projenin belirli bir amacı olsa da, bu amacı proje boyunca göz önünde bulundurur ve amacın gerçekleşmesi esas olarak proje sırasında yapılan tahminlere göre değerlendiririz. Ancak proje bittiğinde bu amacı unutmamalıyız. Proje bittikten sonra hedeflerin gerçekleşip gerçekleşmediğini kontrol etmek önemlidir, çünkü

• nihai hedeflere nasıl ulaşıldığını görebilir ve bundan gelecekteki projeler için öğrenebiliriz ve
• bazen hedeflere ancak projenin tamamlanmasından sonra bazı ek görevler gerçekleştirdiğimizde ulaşılır ve bu ekstra görevlerin gerekliliğini anlamak, izlemeyi gerektirir.

Proje sonrası izleme, amaca yönelik olmak için gerekli bir adımdır. Bu, esas olarak program ve portföy yönetim sistemlerinin sorumluluğundadır ve çoğu şirketin bu tür yönetim katmanları olmadığı için bu adım genellikle ihmal edilir. Bu nedenle P3.express ve DSDM^® gibi yöntemler proje yönetimi metodolojilerine bu adımı ekler.

Örnek: Sadelik

Dünya karmaşık ve kaotiktir, ancak modellerimiz dünyanın parçalarını yansıtan soyut yaklaşımlardır ve bu nedenle basit olabilirler. Öte yandan, basit sistemler genellikle daha iyi çalışır çünkü ana fikre odaklanabiliriz.

Çoğumuz, pratikte çalışmayı zorlaştırsa ve genellikle amacı yerine getirmemizi engellese de, dünyanın karmaşıklığıyla eşleşeceğini umarak sistemlerimize karmaşıklık ekleyerek daha iyi sonuçlar elde etmeye çalışırız.

Örnek: Uyarlama

Müzik yayın akışı için tasarlanmış bir yazılım, insanların hayatlarının buna bağlı olabileceği bir hastanede veya uçakta ekipman için kullanılacak yazılımdan veya yıllarca çökmeden çalışması gereken bir uyduda kullanılacak yazılımdan çok farklı bir koşula sahiptir. Ve bunların hepsi bir yazlık villa, bir itfaiye istasyonu ve bir işleme tesisi inşa etmekten farklıdır.

Amaçları göz önünde bulundurduğunuzda, sistemleri ve yapıları farklı projeler için nasıl uyarlayacağınızı daha iyi anlarsınız.

▼ PDF