Раководењето (или управување) со проекти е дисциплина^[1] на планирање, организирање и управување со ресурсите што придонесува за успешно исполнување не специфични проектни цели.

Проект претставува определена задача (која има определени почетни и завршни датуми) која се презема за да се создава уникален производ или услуга кој придонесува за позитивна промена или додадена вредност. Овие определни одлики на проектите се во контраст со оние на процесите^[2], или операциите, кои претставуваат, долготрајна функционална работа со која се повторува истиот процес на призводство на некој производ или услуга. Во практиката, начинот на управувањето со овие два система е најчесто многу различен, и поради тоа потребно е да се развијат специфични технички способности и примена на различен тип на управување.

Главниот предизвик на раководењето со проекти е реализација на поставените проектни цели^[3] во однос на проектните ограничувања,^[4] како што се опфатот, времето и буџетот.^[5] Второстепениот, и поамбициозен, предизвик е да се оптимализира алокацијата и интеграцијата на инпутите кои се потребни за да се постигнат претходно дефинираните цели.

Историја на раководењето со проекти

Како дисциплина, раководењето со проекти се развило од различни полиња на апликации вклучувајќи ги конструкција, инжинерство и одбрана.^[6] Во САД, двајцата татковци на раководењето со проекти се Henry Gantt, кој уште се нарекува таткото на техниките за планирање и контрола^[7], кој е најмногу познат по употребата на Гант Чартот како алатка за раководење со проекти, и Henri Fayol за создавањето на шесте раководни функции, кои го создаваат скелетот за основата на знаењето поврзано со проектниот и програмското раководење.^[8]

И двајцата Gantt и Fayol, биле познати како студенти на Frederick Winslow Taylor, и ги проучувале неговите теории за научното раководење. Неговата работа им претходи на модерните алатки за раководење со проекти вклучувајќи ги тука и Work Breakdown Structure (WBS) и алокацијата на ресурси.

Педесеттите години на минатиот век го одбележуваат почетокот на новата модерна ера на раководењето со проекти. Претходно раководењето со проекти се сметало за како посебна дисциплина која се одделува од раководењето.^[9] Во САД, уште пред педесеттите години на минатиот век, проектите биле управувани на «ад хок» основа со користење најчесто на Гант Чартови и неформални техники и алатки. Во тоа време биле развиени два модела за математичко планирање на проектите, «Методот на критичен пат» (на англиски Critical Path Method-CPM) кој заедно го развиле DuPont Corporation и Remington Rand Corporation за управување на проекти за одржување на фабрики, и «Техниката за Евалуација и Преглед на Програми» (на англиски Program Evaluation and Review Technique-PERT) развиена од страна на Booz-Allen & Hamilton како дел од програмата за подморници на морнарицата на САД, во соработка со Lockheed Corporation;^[10] Овие математички техники набрзо биле разделени помеѓу повеќе приватни компании.

Во исто време, технологијата за предвидување на проектните трошоци, управување со трошоците, и инженерската економија се развиваат, со пионерската работа на Hans Lans и други. Во 1956 година, Американската Асоцијација на Инженери за Трошоци (на англсики American Association of Cost Engineer, сега позната како AACE International; the Association for the Advancement of Cost Engineering) беше формирана од страна на првите практиционери на раководењето со проекти исто како и специјалистите за планирање и распоредување, предвидување на трошоци, и трошочна контрола (проектна контрола). AACE продолжи со својата пионерска работа и во 2006 година го издаде првиот некогаш интегриран процес за портфолио, програмско и проектно раководење (Рамка за Целосно Управување со Трошоците, на англски Total Cost Management Framework).

Во 1969 година, Институт за Проектено раководење (англ. Project Management Institute-PMI) беше формиран за да им служи на интересите на индустријата на раководењето со проекти.^[11] Основата на ИПМ е дека алатките и техниките на раководењето со проекти се широко прифатени дури и помеѓу многубројните проектни апликации од софтверската индустрија сè до конструкционата индустрија. Во 1981, одборот на директори на ИПМ го одобри развојот на тоа што денес е познато како Водич Низ Оснаовата На Знаењето на раководењето со проекти (англ. A Guide to the Project Management Body Of Knowledge-PMBOK Guide), кој ги содржи стандардите и насоките за практична примена кои се користат низ целата професија.

Меѓународното здружение за раководење со проекти-МЗРП (на англиски The International Project Management Association-IPMA), која беше основана во Европа во 1967 година,^[12] ги презема сличните чекори и ја развива ИАПМ основата за компетенција (на англиски IPMA Competence Baseline-ICB).Фокусот на ICB исто така го има знаењето како основа, и разработува определни искуства, меѓународни вештини, и компентенции. И двете организации сега соработуваат во развојот на ISO стандардите за раководење со проекти (ISO 10006).

Приоди на раководењето со проекти

Постојат неколку приоди кои можат да бидат користени за управување со проектни активности, вклучувајќи ги тука експедитивните, интерактивните, растечки приоди и приоди по фази.

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

Традиционален пристап

Традиционалниот пристап се состои од серија на чекори којшто треба да бидат завршени. Кај «традиционалниот пристап» се разликуваат 5 делови на проектот (4 фази плус котрола) во развивањето на еден проект:

Фази во развојот на проектот:

иницирање на проектот
планирање или дизајн на проектот
извршување на проектот или продукциона фаза
мониторинг на проектот и системи на контрола
завршна фаза на проектот

Не сите проекти ќе ги "посетат « сите фази, затоа што одреден проект може да заврши пред да стигне до завршната фаза. Некои проекти пак немаат планирање или мониторинг. Некои проекти пак ќе поминат низ 2, 3 и 4 фаза неколкупати.

Многу индустрии користат варијации на овиe фази. На пример, при дизајнирање на некој архитектонски објект, проектите најчесто проаѓаат низ фазите како што се Пред-планирање, Концепциски дизајн, Шематски дизајн, Развој на дизајнот, Конструкциски нацрти, и Конструкциска Администрација. Во софтврскиот развој овој модел е познат како модел на водопад,^[13] односно една серија на задачи по друга во линеарна секвенца. Во развојот на софтвер многу организации го користат Рационалниот Унифициан Процес (на англиски Rational Unified Process-RUP) за да биде прикладен за оваа методологија, и покрај тоа што РУП не ја бара или препорачува оваа пракса. Моделот на водопад може да функционира за мали тесно дефинирани проекти, но за големи проекти каде што опсегот не може да биде дефиниран или не е познат, не е толку препорачлив. Основата на неизвесноста објаснува дел од ова, како што планирањето преземено во почетните фази на проектот страда од висок степен на неизвесност. Ова се потврдува во оние случаи каде што развојот на софтвер е најчесто реализација на нов производ, овај метод е широко познат како неефективен за софтверски проекти каде што потребите се непознати на почетокот и промената е малку веројатна. Иако називите може да се разликуваат од една до друга индустрија, фазите најчесто ги следат следниве чекори за решавање на проблемот — „дефинирање на проблемот, разгледување на алтернативи, избор на алтернатива, имплементација и евалуација“.

Rаководењето со проекти на критичен синџир

Rаководење со проекти на критичен синџир е метод на планирање и управување на проекти кој става поголемо значење на потребните ресурси за извршување на проектните задачи. Тоа е апликација од Теоријата на Ограничувања на проектите. Целта е да се зголеми степенот на постигнување (или завршниот степен) на проектите во една организација. Во примената на првите три од петте чекори на ТНО, системско ограничување за сите проекти се ресурсите. За употребата на ограничувањето, задачите коишто се наоѓаат на критичниот синџир добиваат приоритет пред сите други активности. Проектите се планирани и управувани за да се осигура дека активностите на критичниот синџир се подготвени да започнат најбрзо што можат кога потребните ресурси ќе станат достапни, овозможувајќи сите други ресурси да бидат достапни за критичниот синџир.

За специфични проекти, проектниот план треба да претрпи Израмнување на ресурсите, и тогаш најдолгата секвенца на задачи којшто имаат ограничени ресурси се идентификува како критичен синџир. Во околини со повеќе проекти, израмнувањето на ресурсите се извршува за сите проекти. Но, најчесто е доволно да се идентификува (или едноставно да се избере) еден ресурс — ресурс којшто претставува ограничување за повеќе проекти, и да се постават проектите врз основа на достапноста на тој единствен ресурс.

Екстремнo раководење со проекти

Во критичните студии за раководењето со проекти, забележано е дека неколку од овие основни модели засновани на Техниката за евалуација и преглед на програми не одговараат на денешното окружување во кое работат компаниите истовремено работејќи на повеќе проекти. Повеќето од нив се наменети за многу големи, не рутински проекти кои се случуваат само еднаш, а денеска сите видови на раководење се претставуваат како проекти.

Со користење на сложени модели за „проекти“ (или подобро кажано „задачи“) со продолжување на неколку недели е докажано дека се предизвикуваат непотребни трошоци и низок степен на маневрирање во неколку случаи. Наместо тоа, експертите во раководење со проекти се обидуваат да идентификуваат различни „полесни модели“, како што се експедитивните методи за раководење со проекти којшто ги вклучуваат екстремното програмирање за развој на софтвер и Скрум техниките.

Генерализација на екстремното програмирање на друг вид на проекти е ектремнoto раководење со проекти, кој може да се користи во комбинација со процесното моделирање и принципите на раководење на раководење со човечка интеракција.

Методологија на синџир на настани

Методологијата на синџир на настани е наредното подобрување во однос на методот на критичен пат и раководењето со проекти на критичен синџир.

Методологијата на синџир на настани е техника за моделирање на неизвесноста и мрежна анализа на распореди која се фокусира на идентификување и управување на настани и синџири на настани кој имаат влијание врз распоредот на проектот. Методологијата на синџир на настани помага да се намали негативното влијанието на психлошките предрасуди, како и да овозможи лесно моделирање на неизвесноста во распоредување на проектите. Методологијата на синџир на настани се заснова на следниве принципи:

Можен момент на ризикч,
Синџир на настани,
Критични настани или синџири на настани,
Визуелизација на синџирот на настани.

ПРИНЦ2

ПРИНЦ2 е структуриран пристап кон раководењето со проекти, кој беше издаден 1996 година како генеричен проектен метод.^[14] Тој овозможува метод за управување со проекти во склоп на добро дефинирана рамка. ПРИНЦ2 објаснува процедури за координирање на луѓе и активности во еден проект, како да се дизајнира и надгледува еден проект, и што да се прави ако проектот треба да биде прилагоден или ако не се развива според планираното.

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

ПРИНЦ2 овозможува да се пронајде заеднички јазик за сите учесници во еден проект. Многубројните управувачки улоги и одговорности којшто се вклучени во еден проект се целосно објаснети и можат да се прилагодат за да се приспособат на сложеноста на проектот и одликите на организацијата.

Рационален унифициран процес

Рационалниот Унифициран Процес (РУП) е рамка на итеративен процес за развој на софтвер создадена од страна на Rational Software Corporation, дивизија на IBM уште од 2003 година. РУП не е само еден конкретен процес, туку прилагодлива процесна рамка, со намера да биде кроена од страна на организациите и софтверските проектни тимови кои ќе ги одберат елементите на процесот кои одговараат на нивните потреби. Ова се фазите на РУП:

Почеток — Се идентификува почетниот опсег на проектот, потенцијалната архитектура за системот, и добивање на почетни финансии и прифаќање од страна на стајкхолдерите.
Елаборација — Испробување на архитектурата на системот.
Конструкција — Градење на софтвер за работа на регуларни, растечки основи кој ги достигнува највисоките приоритетни потреби на стејкхолдерите.
Транзиција — Потврдување и поставување на системот во продукциона околина.

Развојни фази на проектите

Вообичаено, развојот на проектите вклучува бројни елемент: четири или пет фази, и систем за контрола. Без разлика на методологијата која се користи, процесот за развој на еден проект ќе се состои од следниве фази:^[15]

инцирање,
планирање и развој,
производство или извршување,
мониторинг и контрола, и
затворање.

Иницирање

Фазата на иницирање ги определува природата и опсегот на развојот. Ако оваа фаза не се изврши добро, малку е веројатно дека проектот успешно ќе ги задоволи бизнис потребите. Клучните проектни контроли потребни овде се разбирањето на бизнис околината и осигрување дека сите потребни контроли се вклучени во проектот. Какви било недостатоци треба да бидат пријавени и препораки треба да бидат упатени за да тие бидат поправени.

Фазата на иницирање треба да вклучува целосен план кој ги вклучува следниве полиња:

Студија која ги анализира бизнис потребите во мерливи цели.
Преглед на веќепостоечките операции.
Концептуален дизајн на операцијата на финалниот производ.
Опрема и договорни потреби вклучувајќи и претпоставка за „long-lead“ предмети.
Финансиска анализа на трошоците и придобивките, вклучувајќи и буџет.
Анализа на стејкхолдерите, вклучувајќи ги и корисниците, и помошниот персонал за проектот.
Проектен договор кој вклучува трошоци, задачи, етапни резултати, и распоред.

Планирање и дизајн

По фазата на иницирање, системот е дизајниран. Понекогаш, малечок прототип од финалниот производ е направен и испробуван. Испробувањето најчесто се извршува со комбинација на тестери и крајни корисници, и може да се преземе откако прототипот е направен или истовремено. Контролата треба да биде поставена така што гарантира дека финалниот производ ќе ги исполни спецификациите од проектниот договор. Резултатот на фазата на дизајнирање треба да го вклучува следниот дизајн:

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

Извршување

Извршувањето се состои од процесите користени за да се заврши работата дефинирана во планот за да се постигнат проектните барања. Процесот на извршување вклучува координирање на луѓе и ресурси, како и интегрирање и извршување на активностите на планот. Етапните резултати се произведени како крајни аутпути од извршените процеси како што е дефинирано во планот.

Мониторинг и контрола

Мониторингот и Контролата се состојат од оние процеси којшто се извршуваат за да се надгледува извршувањето на проектот така што потенцијалните проблеми можат да бидат идентификувани на време и корективни акции да бидат преземени, кога е потребно, за да се контролира извршувањето на проектот. Најважната придобивка е дека изведбата на проектот е надгледувана и мерена за да се идентификуваат варијации од планот.

Мониторингот и Контролата вклучуваат:

мерење на активностите кој веќе се извршуваат (каде сме);
мониторинг на проектните променливи (трошоци, труд,…) наспрема проектниот план и основата за проектна изведба (каде треба да бидеме);
идентификување на корективни акции за да правилно се адресираат проблемите и ризиците (како да се вратиме назад и да работиме според планот);
Влијание врз факторите кои можат да ја заобиколат интегрираната контрола на промените така што само одобрени промени да бидат имплементирани.

Во проекти со повеќе фази, процесот на мониторинг и контрола исто така овозможува фидбек помеѓу проектните фази, со цел да се имплементираат корективни или заштитни акции за да се донесе проектот во согласност со планот.

Проектното одржување е континуиран процес, кој вклучува:

целосна поддршка од крајните корисници
поправка на грешки
обновување на софтверот од време на време

Кругот на мониторинг и контрола

Во оваа фаза, ревизорите треба да обрнат внимание на тоа колку делотворно и брзо се решаваат проблемите на корисниците.

За време на изведувањето на било кој конструкциски проект, опсегот на работата се менува. Промените се нормален и очекуван дел од конструкцискиот процес. Промените може да бидат резултат на потребни модификации на дизајнот, различни услови, достапност на материјалите, промени побарани од страна на контрактор и други. Покрај извршување на промената на дело, промената треба да биде документирана за да се покаже што всушност било конструирано. Ова е познато како раководење со промени. И покрај тоа што сопственикот претежно бара зафршен извештај на кој ќе бидат забележани сите промени или пак, поточно, секоја промена која што се однесува на допирливите делови од завршената работа. Извештајот се вклучува во документите на договорот, најчесто, но не секогаш, е ограничен на нацртите за дизајнот. Потребите за снабдување на овој извештај се норма во конструкциските договори.

Кога промени ќе настанат во некој проект, изводливоста на проектот треба да биде повторно разгледана. Важно е да не се изгубат првичните цели и таргети на проектот. Кога промените ќе се акумулираат, предвидениот краен резултат може да не ја оправда инвестицијата.

Затворање

Затворањето вклучува формално прифаќање на проектот. Административните активности вклучуваат архивирање на податотеките и документирање на тоа што се научило од грешките. Фазата на затворање се состои од две фази:

Затворање на проектот: да се финализираат сите активности низ сите групи на процеси за формално да се затвори проектот или пак некоја проектна фаза,
Затворање на договорот: потребно за завршување на секој договор, вклучувајќи ги тука решавање на некои отворени прашања, и затворање на секој договор поврзан со проектот или некоја проектна фаза.

Системи за проектна контрола

Проектната контрола е елемент на проектот кој овозможува проектот да се одвива според планот, на време и според предвидениот буџет. Проектната контрола започнува со планирањето и завршува со пост-имплементирачки преглед на проектот, исто така имајќи голем удел низ сите фази на процесот. Секој проект треба да биде подложен на правилното ниво на контрола кое е потребно: големата контрола одзема многу време, од друга страна пак малата контрола е многу ризична. Доколку проектната контрола не е имплементирана правилно, трошоците на бизнисот треба да бидат гледани како грешки, поправки или доплнителни хонорари.

Контролните системи се потребни за трошоци, ризик, квалитет, комуникација, време, промени, набавка, и човечки ресрси. Дополнително, ревизорите треба да земат предвид колку е проектот важен за финансиските извештаи, колку се стејкхолдерите релевантни за контрола, и колку контроли постојат. Ревизорите треба да го прегледаат процесот на развој и процедурите како се тие имплентирани. Процесот на развој и квалитетот на крајниот производ може, исто така, да бидат испитани ако е тоа потребно или се побара.

Бизнисите понекогаш употребуваат процеси за формален развој на системите. Ова помага за да се осигураат дека системите се развиени успешно. Формалниот процес е поефективен во создавање на силна контрола, и ревизорите треба да го испитаат овој процес за да потврдат дека е добро дизајниран и дека се применува во пракса. Добар план за развој на формалните системи вклучува:

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

Наводи

↑ David I. Cleland, Roland Gareis (2006). Global project management handbook. McGraw-Hill Professional, 2006. ISBN 0-07-146045-4. p.1-4": Project management was formally recognized in the 1950s as a distinct discipline arising from the management discipline
↑ Paul C. Dinsmore et al (2005) The right projects done right! John Wiley and Sons, 2005. ISBN 0-7879-7113-8. p.82 and further.
↑ Lewis R. Ireland (2006) Project Management. McGraw-Hill Professional, 2006. ISBN 0-07-147160-X. p.110.
↑ Joseph Phillips (2003). PMP Project Management Professional Study Guide. McGraw-Hill Professional, 2003. ISBN 0-07-223062-2 p.354.
↑ Chatfield, Carl. "A short course in project management". Microsoft. http://office.microsoft.com/en-us/project/HA102354821033.aspx.
↑ David I. Cleland, Roland Gareis (2006). Global project management handbook. "Chapter 1: "The evolution of project management". McGraw-Hill Professional, 2006. ISBN 0-07-146045-4
↑ Martin Stevens (2002). Project Management Pathways. Association for Project Management. APM Publishing Limited, 2002 ISBN 1-903494-01-X p.xxii
↑ Morgen Witzel (2003). Fifty key figures in management‎. Routledge, 2003. ISBN 0-415-36977-0. p. 96-101.
↑ David I. Cleland, Roland Gareis (2006). Global project management handbook. McGraw-Hill Professional, 2006. ISBN 0-07-146045-4. p.1-4": Project management was formally recognized in the 1950s as a distinct discipline arising from the management discipline.
↑ Booz Allen Hamilton - History of Booz Allen 1950s
↑ F. L. Harrison, Dennis Lock (2004). Advanced project management: a structured approach‎. Gower Publishing, Ltd., 2004. ISBN 0-566-07822-8. p.34.
↑ Bjarne Kousholt (2007). Project Management‎ –. Theory and practice.. Nyt Teknisk Forlag. ISBN 87-571-2603-8. p.59.
↑ Winston W. Royce (1970). "Managing the Development of Large Software Systems" in: In: Technical Papers of Western Electronic Show and Convention (WesCon) August 25-28, 1970, Los Angeles, USA.
↑ OGC - PRINCE2 - Background
↑ VA Office of Information and Technology (2003) Project Management Guide US DEPARTMENT OF VETERANS AFFAIRS. 3 март 2005.

[1] David I. Cleland, Roland Gareis (2006). Global project management handbook. McGraw-Hill Professional, 2006. ISBN 0-07-146045-4. p.1-4": Project management was formally recognized in the 1950s as a distinct discipline arising from the management discipline

[2] Paul C. Dinsmore et al (2005) The right projects done right! John Wiley and Sons, 2005. ISBN 0-7879-7113-8. p.82 and further.

[3] Lewis R. Ireland (2006) Project Management. McGraw-Hill Professional, 2006. ISBN 0-07-147160-X. p.110.

[4] Joseph Phillips (2003). PMP Project Management Professional Study Guide. McGraw-Hill Professional, 2003. ISBN 0-07-223062-2 p.354.

[5] Chatfield, Carl. "A short course in project management". Microsoft. http://office.microsoft.com/en-us/project/HA102354821033.aspx.

[6] David I. Cleland, Roland Gareis (2006). Global project management handbook. "Chapter 1: "The evolution of project management". McGraw-Hill Professional, 2006. ISBN 0-07-146045-4

[7] Martin Stevens (2002). Project Management Pathways. Association for Project Management. APM Publishing Limited, 2002 ISBN 1-903494-01-X p.xxii

[8] Morgen Witzel (2003). Fifty key figures in management‎. Routledge, 2003. ISBN 0-415-36977-0. p. 96-101.

[9] David I. Cleland, Roland Gareis (2006). Global project management handbook. McGraw-Hill Professional, 2006. ISBN 0-07-146045-4. p.1-4": Project management was formally recognized in the 1950s as a distinct discipline arising from the management discipline.

[10] Booz Allen Hamilton - History of Booz Allen 1950s

[11] F. L. Harrison, Dennis Lock (2004). Advanced project management: a structured approach‎. Gower Publishing, Ltd., 2004. ISBN 0-566-07822-8. p.34.

[12] Bjarne Kousholt (2007). Project Management‎ –. Theory and practice.. Nyt Teknisk Forlag. ISBN 87-571-2603-8. p.59.

[13] Winston W. Royce (1970). "Managing the Development of Large Software Systems" in: In: Technical Papers of Western Electronic Show and Convention (WesCon) August 25-28, 1970, Los Angeles, USA.

[14] OGC - PRINCE2 - Background

[15] VA Office of Information and Technology (2003) Project Management Guide US DEPARTMENT OF VETERANS AFFAIRS. 3 март 2005.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

Раководење со проекти

Содржина