Не ради ништа без јасне сврхе

Не би требало да радиш нешто осим ако нема јасну сврху. Замисли два паралелна света где је све исто осим тога што у једном свету размишљаш о ономе што радиш, а у другом не: колико би се разликовала та два света? Да ли је разлика вредна труда да се то (не) уради?

Ако ти није јасна сврха и радиш нешто само зато што и сви остали то раде, или свако каже да је важно да се то ради, онда: * Можда у твом случају то нема стваран бенефит, па стога не добијаш ништа радећи то; или * Можда у твом случају има потенцијалне бенефите, али пошто ти није јасна сврха, начин на који то будеш радио можда ти неће помоћи да оствариш те бенефите.

Пример : Портфолија и програми

Ако си укључен у избор и иницијацију пројеката, фокусирај се на бенефите и проблеме који треба да се реше пре него на производ кој треба да реализује ове ствари. Класичан пример је произвођач лифтова који је примао жалбе на брзину својих лифтова, па је покренуо више пројеката да би поправио брзину лифтова, али без потпуног успеха. Ово се настављало све док нису одлучили да се фокусирају на проблем (досађивање или нелагодност у лифту) уместо “природног” решења (бржих лифтова). Резултат је био тај да су додали огледала у лифтове и решили проблем једноставно и јевтино.

Запамти да је за пројектни менаџмент углавном важно “радити ствари на прави начин”, док је за портфолио менаџмент важно “радити праве ствари”. Није важно колико добро водиш своје пројекте; неће добро функционисати уколико радиш погрешне пројекте. Све је у сврси.

Пример : Пројекат као целина

Флексибилност производа варира од пројект до пројекта. У неким ИТ развојним пројектима, производ је потпуно флексибилан и његов финални облик зависи од повратне информације које ће уследити након инкременталних фаза производа кроз пројекат, што захтева адаптивни (Agile) приступ. У практичном смислу ово је комбинација слојева портфолија, програма и пројеката и потребан је максимум пажње посвећен крајњем циљу. Добра идеја је документовати сврху и имати је увек на дохват руке; то је једна од сврха “визије производа”, како се користи у неким Scrum пројектима. Акценат на пословну вредност у Agile пројектима је његов начин осигураног усклађивања са сврхом.

У другим врстама пројекта, где је производ релативно фиксан и постоје други механизами контроле да производ задовољи сврху, могуће је да чланови пројектног тима помере фокус са сврхе на производ (отуда принцип “фокус на производе” PRINCE2^®), али у најмању руку минимум пажње посвећен сврси је још увек потребан да би се обезбедило да оно што се ствара служи сврси, што се може остварити поређењем предвиђених и очекиваних бенефита (отуда принцип “континуалног пословног правдања” и “business case” Тема у PRINCE2^®).

Ако се пројекат ради за екстерног клијента, клијент жели своју сопствену сврху за пројекат, а ваша компанија ће имати своју сврху. Потребно је да разумете и користите обе да би стварно успели.

Пример : Мониторинг пројекта

Фокусирање на крајњу сврху је неопходно. Али можда и превише апстрактно за већину свакодневних примена. За практичну примену потребно је успоставити хијерархију покретача. Као прво, пословно оправдање и бенефити пројект дефинисани су сходно крајњој сврси, а сходно њима експлицитни и имплицитни таргети за пројектне варијабле (тј. време, трошак, квалитет) да би се задовољило пословно оправдање, што би на крају задовољило крајњу сврху. Ово су сврхе нижег нивоа које су корисне за многе од наших дневних задатака.

Када се ради о мониторингу, мониторинг нижег нивоа у пројекту пратиће варијабле ниженг нивоа, јер можда неће бити могуће пратити крајњу сврху. У овом случају, не треба заборавити на сврху: шта је сврха мониторинга?

Нормалан и прихватљив одговор је видети да ли добро пратимо план, ако не, иницирати одговарајућу реакцију која ће нас довести назад на у оквире плана или поново подесити таргете и видети да ли коначна сврха још увек може бити задовољена. Наша мерења стога треба да нам помогну око ове сврхе нижег нивоа, а одговарајућа мерења су прогнозе за пројектне варијабле на крају пројекта; нпр ., када ћемо моћи да завришимо пројекат? Колико новца нам је потребно да завршимо пројекат?

Сва друга мерења, као што су планиране и актуелне вредност на дан, само су међувредности које су нам потребне да би калкулисали прогнозу, а не коначне вредности за сврхе менаџмента.

Пример : Документи

Без обзриа који девелопмент приступ користимо у пројекту, планирање је увек неопходно. Важно питање је ниво детаља у сваком типу плана. Ако нема довољно детаља у плану, план неће моћи довољно да допринесе, а извршавање пројект засниваће се на ад-хоц одлукама пре него на интегрисаним, холистичким. Са друге стране, пуно људи покушава да буде опрезно, па додаје превише детаља у план, што га чини тешким за припрему и одржавање, и превише ригидним за неизвесности у пројекту. Као резултат, план постаје нереалан и бескористан.

Најбољи начин да се одлучи о нивоу детаља је имати сврху на уму за сваки елемент у плану. На пример, ако разматраш додавање ресурса у план, то треба да има сврху: како ћеш га користити? Како ће то помоћи пројекту? Колико напора ће то произвести? И да ли се исплати?

Понекад се ради о томе да ли желиш неки елемент у својим плановима, а некад о начину на који планираш и припремаш нешто. Било да је business case, пројектна повеља, или извештај: увек се питај зашто припремаш тај документ и како може да помогне пројекту.

Тражење разних “template”-а по wеб-у је сушта супротност чињења нечег базираног на сврси.

Пример : Статусно извештавање

Честа је појава предугих статусних извештаја у многим пројектима. Полазећи од овог НУП-а, треба да се запитамо која је сврха извештаја и како је можемо постићи без обзира шта други раде по том питању.

Ово нас у много случајева може водити ка припреми веома једноставних извештаја на једној страници које ће stakeholder-и заиста читати и разумети, за разлику од дугих извештаја. Ово је поклањање пажње сврси.

Ако припремаш извештај од једне стране, додуше неки људи могу да и то замере и мисле да немаш постављен адекватан мониторинг систем. У пракси, ово креира теби секундарну сврху (осим примарне, а то је помоћ стакехолдерима да разумеју статус пројекта), а да би то задовољили, можете просто креирати други тип извештаја који ће бити дугачак. Ипак , не мешајте ова два извештаја, јер им је и сврха различитиа.

Пример : Business case и пројектна повеља

Припреме докумената као што је business case и пројектна повеља обично је досадна, јалова, бирократска неопходност за већину људи, док сви ови документи имају ваљану сврху која важи за већину пројеката. Ако покушаш да пронађеш “темплате” и попуниш га, време је протраћено; уместо тога боље је да провериш праву сврху ових докумената, видиш да ли и како могу бити од помоћи у пројекту, а онда припремиш документ на начин како желиш, искључиво да задовољиш сврху: то ће онда бити прави документ.

Док размишљаш о начину припреме докумената да би задовољили своју сврху, можда нећеш имати на уму сваки сценарио и зато нешто пропустити. Да би то избегао, провери све ресурсе, као нпр. PRINCE2^®, PMBOK^® Gudie, p3.express, И DSDM^® сугестије, и онда евалуирај ове сугестије засновано на сврси.

Пример : Пост-пројекат

Све док пројекат има специфичну сврху (а сврху можемо преиспитивати током пројекта) , реализација сврхе углавном се вреднује на основу прогноза насталих током пројекта. Ипак , не смемо да заборавимо на то ни кад се пројекат заврши. Важно је проверити реализацију циљева након краја пројекта, јер:

• Можемо видети како се постижу крајњи циљеви и учити из тога за будуће пројекте, и,
• Понекад се циљеви остваре само ако се обаве неки додатни задаци након пројекта, а за разумевање неопходности ових екстра задатака потребан је мониторинг.

Пост -пројектни мониторинг је неопходан корак ако смо вођени сврхом. Ово је углавном одговорност система за управљање прогама и портфолиа, а пошто већина компанија нема такве нивое менаџмента, овај корак се обично занемарује. Због тога методи као P3.express и DSDM^® додају овај корак у своје методологије пројектног менаџмента.

Пример : Једноставност

Свет је комплексан и хаотичан, али наши модели су апстрактне апроксимације које одражавају делове света, па су стога једноставне. Са друге стране, једноставни системи обично функционишу боље, јер можемо да се фокусирамо на главну идеју.

Многи од нас покушавају да добију боље резултате додајући комплексност у систем, надајући се да ће одсликати комплексност света, чак и ако у пракси ово отежава рад са системом и обично нас спречава да задовољимо сврху.

Пример : Прилагођавање – “кројење”

Софтвер за streaming музике има различите услове од оног који се користи за опрему у болници или у авиону где од тога зависе људски животи, или од софтвера који ће се користити у сателитима где треба да раде много година без “пада система”. А сви поменути софтверски пројекти разликују се од изградње летње виле, ватрогасне станице, или постројења за прераду.

Ако имате сврху на уму, боље ћете разумети како прилагодите – “скројите” системе и артефакте за различите пројекте.

▼ PDF