Ne csinálj semmit nyilvánvaló ok nélkül

Ne tegyél semmit, hacsak nincs egyértelmű célja. Képzelj el két párhuzamos világot, ahol minden ugyanaz, kivéve azt a dolgot, amit éppen fontolgatsz: Mennyiben lennének mások ezek a világok? Megéri ez a különbség az erőfeszítést?

Ha nincs világos célod, és csak azért csinálsz valamit, mert mindenki más csinálja, vagy mindenki azt mondja, hogy fontos,

• nem biztos, hogy valódi haszna van a Te esetedben, és ezért lehet, hogy nem kapsz belőle semmit; vagy
• előfordulhat, hogy a Te esetedben még mindig vannak potenciális előnyei, de mivel nem a célt tartod szem előtt, nem ismered fel az esetleges előnyöket.

Példa: Portfóliók és programok

Ha részt veszel a projektek kiválasztásában és kezdeményezésében, az előnyökre és a megoldandó problémákra összpontosíts, nem pedig arra a termékre, amely ezeket a dolgokat megvalósítja. A klasszikus példa a felvonók gyártója, akik korábban panaszokat kaptak felvonóik sebességével kapcsolatban, így több projektet is végrehajtottak a sebesség növelésére, bármiféle siker nélkül. Ez addig folytatódott, amíg úgy döntöttek, hogy a problémára (az emberek unalmára vagy kényelmetlenségére) összpontosítanak a “természetes” megoldás (gyorsabb liftek) helyett. Az eredmény az volt, hogy tükrökkel szerelték fel a lifteket, és ez egyszerűen és olcsón megoldotta a problémát.

Ne felejtsd, hogy a projektmenedzsment főként a dolgok helyes elvégzéséről szól, míg a portfóliókezelés a helyes dolgokról. Nem számít, milyen jól vezeted a projektjeidet; nem fognak jól működni, ha nem a megfelelő projekteket csinálod. Az egész arról szól, hogy legyen egy cél.

Példa: A projekt egésze

A végtermék rugalmassága projektenként változó. Egyes informatikai fejlesztési projektekben a termék teljesen rugalmas, és a végleges formája attól függ, hogy a projekt során milyen visszajelzések érkeznek a termék korai verzióira. Ez egy adaptív (Agilis) megközelítést igényel, ami a gyakorlatban a portfólió, a program és a projekt rétegeinek kombinációja, és a végső célra való maximális figyelmet igényel. Ajánlott a célt dokumentálni és mindenki számára hozzáférhetővé tenni. Ez a “termék vízió” egyik célja az egyes Scrum projektekben. Az Agilis projektekben az üzleti értékre való figyelemmel a végcélhoz való igazodást biztosítják.

Más típusú projekteknél, ahol a termék viszonylag rögzített, és más mechanizmusok is biztosítják, hogy az azonosított termék megfeleljen a célnak, a projektcsapat tagjai gyakran a fókuszuk nagy részét a célról a termékre helyezik át (innen ered a PRINCE2^® “fókuszálás a termékekre” alapelve). De az továbbra is szükséges, hogy a célt legalább minimális mértékben, de szem előtt tartsuk, hogy az épülő termék megfeleljen ennek a célnak, ami az előrejelzett termékelőnyök és a várható haszon összehasonlításával valósítható meg (mint a “folytatásos üzleti indoklás” elve és az “üzleti eset” témák a PRINCE2^®-ben).

Ha egy projektet egy külső ügyfél számára készítenek, akkor az ügyfélnek lesz egy saját, a Te cégednek pedig egy másik célja ezzel. Mindkettőt értened és használnod kell a valódi siker eléréséhez.

Példa: Projekt monitoring

Szükséges a végső célra való összpontosítás, de ez esetleg túlságosan elvont lehet a mindennapi használathoz. Ezért van szükség az egyes mozgatórugók hierarchiájára, amely egy gyakorlatiasabb képet mutat a projektről. Először is a projekt indokoltságát és előnyeit a végső cél alapján kell meghatároznunk, majd explicit és implicit célokat kell kitűznünk az egyes projektváltozókra (pl. idő, költség és minőség) úgy, hogy azok kielégítsék az projekt indoklást, ami viszont így kielégíti a projektcélt. Ezek a projektváltozókra irányuló alacsonyabb szintű célok, amelyek számos napi feladatunknál hasznosak.

Ami a monitoringot illeti, a projekt alacsony szintű monitorozása a legalacsonyabb szintű változók felhasználásával történik, mert előfordulhat, hogy nem lehet nyomon követni a végső célt. Ebben az esetben ezeket az alacsonyabb szintű célokat kell szem előtt tartanod. Mi a monitorozás célja?

A normális és elfogadható válasz az, hogy megnézzük, jó úton járunk-e, és ha nem, akkor kiváltunk egy bizonyos reakciót, amely visszavezet minket a helyes útra, vagy módosítjuk a célokat, és megnézzük, hogy ez még mindig teljesíti-e a végső célt. Ennek megfelelően a méréseinknek támogatniuk úgy kell ezt az alacsony szintű célt, hogy a megfelelő mérések az egyes változók záráskori várható értékei legyenek. Pl.: Mikor tudnánk befejezni a projektet? Mennyi pénzre lenne szükségünk a projekt befejezéséhez?

Az összes többi mérés, például az eddigi tervezett és tényleges értékek csak köztes értékek, amelyekre az előrejelzések kiszámításához van szükség, nem pedig a vezetői célokra használt végső adatok.

Példa: Dokumentumok

Nem számít, milyen fejlesztési megközelítést alkalmazol a projektben, a tervezés mindig szükséges. A lényeges kérdés az egyes tervek részletessége. Ha nincs elég részlet a tervben, a terv nem tud kellőképpen hozzájárulni a projekthez, és a végrehajtás ad-hoc döntéseken fog alapulni, nem pedig integrált, holisztikus megközelítésen. Másrészt sokan próbálnak óvatosak lenni, és túl részletes tervet készítenek, ami túlságosan megnehezíti az előkészítést és karbantartást, illetve túl merev a projekt bizonytalanságaihoz képest. Ennek eredményeként a terv irreálissá és haszontalanná válik.

A részletesség meghatározásának legjobb módja, ha a terv minden eleméhez meghatározunk egy célt. Például, ha erőforrásokat rendelsz a tervhez, akkor annak legyen valami célja: Hogyan fogod ezt használni? Hogyan segíti a projektet? Mekkora erőfeszítést igényel? És megéri?

Néha arról van szó, hogy egy bizonyos elemet beépítesz-e a terveidbe, néha pedig arról, hogy miként tervezel meg valamit. Legyen szó üzleti esetről, projektalapító dokumentumról vagy jelentésről: továbbra is fel kell tenned azt a kérdést magadban, hogy miért készíted el ezt a dokumentumot, és ez hogyan segítheti a projektet.

A “sablon” keresése valamihez pont az ellentéte a céltudatosságnak.

Példa: Státuszjelentés

Sok projektnél gyakori eset, hogy nagyon hosszú státuszjelentések készülnek. Ezen NUP alapján fel kell tennünk magunknak a kérdést, hogy mi a jelentés célja, és hogyan érhetjük el ezt a célt, függetlenül attól, hogy a legtöbb ember mit csinál.

Ez sok esetben oda vezethet, hogy nagyon egyszerű, egyoldalas jelentéseket készítünk, amelyeket az érintettek valóban elolvasnak és megértenek a hosszú jelentések helyett. Ez a célra való koncentrálás.

Ha azonban egyoldalas jelentéseket készítesz, lesznek olyanok, akik tiltakoznak, és azt gondolhatják, hogy nincs “megfelelő” felügyeleti rendszered. A gyakorlatban ez egy második célt is generál a számodra (az első cél mellett, amely segít az érdekelt feleknek megérteni a projekt állapotát), és ennek kielégítésére egyszerűen létrehozhatsz egy új, második típusú jelentést, amely nagyon hosszú. Ezt azonban nem szabad összekeverni az első jelentéssel, mert a két cél nem ugyanaz.

Példa: Üzleti eset és projektalapító dokumentum

Az olyan dokumentumok elkészítése, mint például az üzleti eset és a projekt alapító általában unalmas, eredménytelen, bürokratikus szükséglet a legtöbb ember számára. Azonban ezek a dokumentumok mindegyike fontos céllal készül, és az adott projektre vonatkoznak. Ha megpróbálsz egy “sablont” keresni és kitölteni, a munkád csak időpocsékolás lesz. Inkább ellenőrizd ezeknek a dokumentumoknak a valódi célját. Vizsgáld meg, hogy hasznosak lehetnek-e, és ha igen, milyen módon. Ezután tetszőlegesen elkészítheted ezeket a dokumentumokat, hogy megfeleljenek a feladatnak: ez lesz a megfelelő dokumentum.

Miközben azon gondolkozol, hogyan készítheted elő a dokumentumokat a céljaik kielégítésére, előfordulhat, hogy nem gondolsz minden eshetőségre és valamit kihagysz. Ennek elkerülése érdekében ellenőrizd, hogy milyen eszközöket javasolnak például a PRINCE2^®, PMBOK^® Guide, P3.express és DSDM^®, és értékeld ezeket a javaslatokat a célok alapján.

Példa: Poszt-projekt

Míg a projektnek meghatározott célja van, és ezt a célt a projekt során végig szem előtt tudjuk tartani, addig a cél megvalósulását elsősorban a projekt során készített előrejelzések alapján értékeljük. Azonban erről a projekt végeztével sem szabad megfeledkeznünk. Fontos, hogy a projekt befejezése után ellenőrizzük a célok megvalósulását, mert

• láthatjuk, hogyan valósulnak meg a végső célok, és tanulhatunk ebből a jövőbeli projektekhez, és
• néha a célok csak akkor valósulnak meg, ha a projekt befejezése után további feladatokat hajtunk végre, és ezek szükségességének megértése monitorozást igényel.

A projekt utáni monitoring szükséges lépés a célorientált szemlélet eléréséhez. Ez elsősorban a program- és portfóliókezelési rendszerek felelőssége, és mivel a legtöbb vállalat nem rendelkezik ilyen szintű menedzsmenttel, ezt a lépést általában figyelmen kívül hagyják. Ezért az olyan módszerek, mint a P3.express és a DSDM^®, hozzáadják ezt a lépést a projektmenedzsment módszertanához.

Példa: Egyszerűség

A világ összetett és kaotikus, de a modelljeink absztrakt közelítések, amelyek a világnak csak egyes részeit tükrözik, ezért lehetnek egyszerűek is. Másrészt az egyszerű rendszerek általában jobban működnek, mert a fő gondolatra tudnak koncentrálni.

Sokan megpróbálunk jobb eredményeket elérni rendszereink komplexitásával, abban a reményben, hogy az megfelel a világ összetettségének, bár a gyakorlatban ez megnehezíti a rendszerrel való munkát, és általában megakadályozza a cél elérését.

Példa: Testreszabás

Egy zenei streamelésre szolgáló szoftver kialakítása nagyon eltér attól, amelyet egy kórházban vagy egy repülőgépen használnak olyan berendezésekhez, ahol emberek élete múlhat rajta vagy attól a szoftvertől, amelyet egy műholdon használnak majd, ahol évekig működnek anélkül, hogy összeomolnának. Ezenkívül ezeknek mindegyike különbözik attól, mint amikor egy nyaralót, egy tűzoltóállomást vagy egy feldolgozó üzemet építenek.

Ha a célokat tartod szem előtt jobban megérted, hogyan szabhatod testre a rendszereket és az egyes dokumentumokat a különböző projektekhez.

▼ PDF