Тема: Управување со ИКТ проекти

Вовед
Вовед во управување со проекти
Современите компании, како и владините и непрофитните организации, ја препознаа
важноста на флексибилниот и одговорен бизнис, а проектниот бизнис се појавува се почесто
како доминантна форма на извршување на активности во рамките на организацијата.
Управување со проекти во современите организации подразбираат голем број активности,
вклучително и планирање, координација и контрола на сложени и разновидни активности од
различни области бизнис: продажба, маркетинг, ИТ итн. Ориентацијата кон проекти е во
пракса за големи бројни организации се покажаа како исклучително корисни, а денес најголем
број на модерни организации имаат тенденција да ги проектираат - организираат сите
активности кои имаат карактеристики на проект.
Во својата најширока смисла, управувањето со проекти е за насочување на луѓето кон
заедничка цел која треба да се постигне на систематски начин и како таква постои уште од
античко време цивилизација. За некои од големите проекти од античката историја, како што е
изградбата на пирамидите во Гиза, Кинескиот ѕид или Трансконтиненталната железница,
денес знаеме дека тие биле управувани од принципи на управување со проекти. За да се
реализираат овие проекти беше потребно да се организираат многу голем број луѓе на
систематски начин, и со расположливи ресурси да се постигне целниот квалитет.
За потеклото на проектниот менаџмент како што го знаеме денес, тоа е многу важно значаен
изглед на двете најпознати алатки за управување со проекти: CPM – Метод метод на критична
патека (Метод на критична патека) и PERT - Техника за евалуација на проектот (Проект Техника
за преглед на евалуација). Овие алатки се појавија во педесеттите години на минатиот век, а
тие првично беа користени во големи комплексни воени и владини проекти. Денес овие
алатки се користат во сите видови проекти и се погодни за употреба во сите проекти кои имаат
меѓусебно зависни активности. Од 1960-тите, областа на менаџментот проектите почнаа
интензивно да се развиваат и модернизираат. Голема улога во развојот полето на управување
со проекти го играат и професионалните организации, меѓу кои се најважниот PMI - Институт
за проектен менаџмент (Институт за управување со проекти) i IPMA - Меѓународна асоцијација
на проект менаџери (Меѓународна асоцијација за управување со проекти.)
Проектната ориентација на компанијата во спроведувањето на деловните иницијативи има
бројни придобивки, кои денес се веќе надалеку познати. Многу истражувања покажаа дека
голем број успешните компании ја препознаа важноста на проектната ориентација и
ефикасното управување проекти кои ги смета за свој приоритет. Околу 60% од водечките
директори веруваат дека тоа би било силно.
Дисциплината за управување со проекти треба да биде меѓу трите најважни стратешки
приоритети за
нивната компанија во иднина (McKinsey&Company, 2010).
Земајќи ги предвид и локалните и светските трендови на пазарот, доминантната ориентација
во управување со проекти станува реализација на ефикасност и намалување на ризикот на
проектот.
Според глобалното истражување на Институтот за управување со проекти, ризикот од
финансиски
загубите на проекти во 2013 година изнесуваа 13,5%, односно за милијарда долари,
организациите се изложени на ризик
загуба од 135 милиони долари (Институт за управување со проекти, 2013 година). Резултатот
од оваа работа
треба да придонесе за воспоставување подобри практики за управување со проекти
електронски бизнис, се со цел да се минимизира ризикот од спроведување на проектот i
воспоставување на контролирани процеси за управување со проекти.

Дефиниции за управување со проекти

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

претставува
организирање луѓе насочени кон одредена цел, која генерално вклучува претпријатија
што треба да се преземе во одреден рок, со одреден буџет и да се испорача
очекувано ниво на квалитет (Tuman, 1983). Тарнер го дефинира проектот како потфат во кој
човечките, финансиските и материјалните ресурси се организирани со цел да опфатат
единствена целина
работа со дефинирана спецификација, во рамките на временските и трошоците ограничувања,
а со цел создавање позитивна промена дефинирана со квантитативни и квалитативни цели
(Тарнер, 1999). Во еден од најприфатените водичи за управување со проекти, А
Водич за управување со проекти Тело на знаење, проектот се дефинира како привремен
претпријатие чија цел е да создаде единствен производ или услуга. Во горната дефиниција,
се издвојуваат две клучни точки: привремена, која вели дека проектот е активност која
мора да има дефиниран почеток и крај и единственост на резултатите од проектот (Проект
Институт за менаџмент, 2013 година).
Врз основа на преглед на литературата од областа на управувањето со проекти, Diallo и
Thuillier дефинираа збир на клучни димензии кои се појавуваат во дефинициите на проектот
(Diallo & Thuillier,2003):
• Три традиционални ограничувања на проектот: време, трошоци, опсег.
• Задоволство на клиентот
• Задоволување на поставените цели
• Влијание на проектот
• Институционален или организациски капацитет вграден во организацијата на проектот
• Финансиски принос
• Иновативни резултати од проектот
Концептот на управување со проекти исто така се гледа од перспектива на различни автори.
Керцнер го дефинира управувањето со проекти како планирање, организирање, насочување и
контролирање на ресурсите на компанијата за релативно краткорочна цел за која е
дефинирана исполнување на конкретни цели (Kerzner, 2009). Според PMI, проектен менаџмент
претставува примена на знаења, вештини, алатки и техники на проектни активности, со цел да
ги исполни барањата на проектот (Институт за управување со проекти, 2013).

Методологии за управување со проекти

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

постигнување на одредена цел во управувањето со проекти. Методологиите најчесто даваат
листа за проверка на клучните испораки и активности кои треба да се решат со цел да се
избегна отфрлање на основните делови во управувањето со проекти (KLR). Доколку во
управувањето проектот користи одредена методологија, потребно е сите учесници во
проектот да бидат да се запознаат со истите и да ја разберат пропишаната рамка за
имплементација. Проектните тимови кои тие користат некои од методологиите за управување
со проекти се значително поефикасни и сите проектните активности се спроведуваат со
повисоко ниво на доследност и пониско ниво на ризик. Во современото управување со
проекти, постојат две општо прифатени методологии:
PMBoK (The Project Management Body of Knowledge) и PRINCE2.
Првата верзија на методологијата за Тело на знаење за управување со проекти беше објавена
во 1996 година.
Институт за управување со проекти. PMBoK го претставува најприфатениот
методологија за управување со проекти, првенствено во Северна Америка. ПМБОК вклучува
познавање на докажани традиционални практики широко користени во менаџментот
проекти, како и знаење за иновативни и напредни методи. Според ПМБоК проекти се
се состои од процес, каде што процесот се дефинира како низа дејства кои носат резултат.
PMBoK опишува 47 процеси за управување со проекти кои се групирани во 5 групи
процес, имено (Институт за управување со проекти, 2013):
1. Процеси на иницирање
2. Процеси на планирање
3. Процеси на извршување
4. Контролни процеси
5. Затворање процеси
PRINCE2 е методологија за управување со проекти, првично развиена во 1989 година за
владата на ОК. PRINCE2 најмногу се користи во Европа, а пред се во развој
софтверски проекти. Според PRINCE2, постојат 7 типа на процеси (Murray, 2011):
1. Започнување на проект (SU - Starting Up a Project)
2. Иницирање проект (IP - Иницирање проект)
3. Управување со проекти (ДП - насочување на проект)
4. Контролирање на сцена (CS - Контролирање на сцена)
5. Управување со испорака на проекти (MP - Управување со испорака на производи)
6. Управување со граница на сцена (MB - Управување со граница на сцена)
7. Затворање на проект (КП - Затворање проект)
Освен споменатите две методологии, голем број на консултантски фирми и организации кои
професионално се занимаваат со проектен менаџмент и имаат сопствен внатрешно развиен
проект
методологија.

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

Лансирање на проектот
Започнувањето на проектот е започнување на постапка што резултира со овластување
нов проект. Може да се изведе на ниво на организација, програма или портфолио.“ (Фертаљ,
Кар, Косовиќ Нижетиќ, 2016:40). Во оваа фаза најважно е да се одреди повелбата на проектот и
неговите учесници. Утврдувањето на засегнатите страни значи избор на луѓе кои би можеле да
помогнат во спроведувањето на проектот или донесување одлуки. Гореспоменатата повелба е
документ кој го овластува користењето на ресурсите спроведување на проектот и доказ за
постоењето на проектот. Тоа главно ги содржи следните ставки:
• Цел или оправданост на проектот
• Мерливи цели или критериуми за успешност
• Барања на високо ниво
• Претпоставки и ограничувања
• Груб опис на проектот и границите
• Ризици на високо ниво...“ (Фертаљ, Кар, Косовиќ Нижетиќ, 2016:42)
При започнување на проект, дефинирањето на обемот на проектот е една од главните
компоненти. Тоа е многу важно е да се знае колку материјални и нематеријални ресурси се
потребни за реализација на проектот и кои работи ќе треба да се завршат во рамките на
имплементацијата. За да биде одобрен, секој проект мора уште од самиот почеток, покажете
ги очекуваните резултати и оправдајте ја неговата упорност. За инвеститорите
е еден од главните фактори за донесување инвестициски одлуки, веројатноста за успех на
проектот како и цената на нејзиниот пад.

Планирање на проекти
Оваа фаза вклучува:
1. Креирање на изјава за опфат - изјава за областа и обемот на проектот; содржи описи на
работни места кои се потребни за исполнување на целите на проектот.
2. Формирање на тимот.
3. Структурирање на работните места - се однесува на хиерархиската распределба на
работните места.
4. Проценка на ризик (почетна).
5. Креирање мрежен дијаграм - ¸¸Мрежен дијаграм го илустрира текот на активностите и/или
фазата на проектот. Се утврдуваат и документираат меѓусебните зависности, се утврдуваат
последователни и паралелни зависности
активности (активности за секвенционирање).“ (Фертаљ, Автомобил, Косовиќ Нижетиќ,
2016:53)
6. Пополнување на проценката - како што веќе беше наведено, многу е важно да се проценат
потребните трошоци за реализација на проектот и пресметка на буџетот.
7. Определување на критичната патека.
8. Подготовка на проектниот буџет.
9. Проценка на ризик (завршување).
10. Решенија за ризик - во ситуации на соочување со ризици, можно е да ги избегнете, да ги
прифатите,
ублажи или пренасочи.
11. План за управување со времето - ако се работи за поголем проект, менаџерите често
соработуваат со Одборот за управување со промени доколку е основан во друштвото
12. Изработка на план за комуникација.
Првата фаза вклучува развој на проектниот план. ¸¸Главната цел на документот е да создаде
основа која обезбедува информации за засегнатите страни за претпоставки, одлуки и ризици и
досег на документи, временска рамка и трошоци. Откако ќе се постигне договор
(менаџер, тим, менаџмент, корисник) проектот може официјално да започне, односно да
започне формално започнување на проектот.“ (Фертаљ, Автомобил, Косовиќ Нижетиќ,
2016:54)
Документот се состои од: вовед, менаџерски пристап, опфат на проектот, регистар на ризици,
план управување со трошоците, план за управување со времето, листа на спонзори и други
потребни елементи.
 Управување со времето

Со цел соодветно да се искористи времето и да се обезбеди доволно внимание на

активностите од големо значење за успехот на проектот, од клучно значење е да се создаде
распоред. Мнозинството пропаднати проекти пропаѓаат поради резултатите од работата во
првата фаза, а не во последната затоа што така се случи
се случува во последната, определена токму во таа прва фаза.
Процеси за управување со времето (Филипс)
Извор: преземено во целост (Фертаљ, Цар, Косовиќ Нижетиќ, 2016:62)
Како што е прикажано на слика 2, управувањето со времето се состои од дефинирање
активности и потоа редоследот на нивното спроведување, определување на нивното
времетраење, развој временски распоред и негова контрола. Во оваа фаза се креира список на
активности ги прикажува сите активности што треба да се извршат во текот на проектот, а
важно е тие да се координирани со опфатот на проектот. Процесот на креирање листа на
активности ги вклучува следните компоненти:
• WBS
- главен влез за креирање листа на активности (дефинира испораки за работа)
• Изјава за обем - опис на потребната работа
• Историски податоци - податоци од претходни (слични) проекти

1 WBS – Структура на дефект на работата

Речникот на PMI го преведува овој термин како структурен дефект на работата, што значи дека
работата треба да се дистрибуира до неколку структури според критериумот кој е соодветен за
тој проект. Може да биде географски, дистрибуиран од временски фази, фази на испорака итн.
Проектниот тим одлучува како ќе се распределат задачите.
• Ограничувања - ограничувања на менаџерот или тимот (на пр. ограничен буџет или потребен
квалитет)
• Претпоставки - на пр. достапност на ресурси
• Експертско расудување - [надворешен] експерт за одредена работа.“ (Фертаљ,
Автомобил, Косовиќ Нижетиќ, 2016:63)

Извршување, надзор и контрола на проектот

¸¸Група за извршување на процеси (Група за извршување на процеси) се состои од процеси кои

се потребни за завршување на работата дефинирана со проектниот план за исполнување на
спецификацијата на проектот. Вклучува координација на персоналот и ресурсите, извршување
на проектните активности и интеграција проектни активности во согласност со проектниот
план“ (Фертаљ, Цар, Косовиќ Нижетиќ, 2016:79).
Ова е делот од проектот кој троши најмногу финансиски средства.
Според истата група на автори, извршувањето вклучува:
1. Изведување на работа на проектот.
2. Овластување на работа на проектот - метод на одобрување на работа преку дозволи,
полномошници...
Ова ги вклучува: техниката на работна дозвола и системот на работна дозвола.
3. Барање добавувачи - процесот треба да се спроведе навреме за да се обезбедат потребните
ресурси. Добавувачите може да се добијат преку тендери, понуди и ценовници.
4. Избор на добавувачи.
5. Администрација на склучување договори.
6. Имплементација на обезбедување квалитет.
7. Обезбедување информации за реализираниот проект.
8. Обезбедување развој на тимови.
Многу е важно реализацијата на проектот да се одвива непречено и според конкретен план
надгледува секоја активност што се спроведува. Постојат неколку начини да се контролира кои
менаџери тие најчесто вршат: контрола на квалитет, контрола на промени, контрола на
трошоци, контрола на распоред, проверка на дофат, известување за перформанси.

Управување со човечки ресурси

При изборот на членовите на тимот кои ќе учествуваат во проектот, потребно е да се утврдат
критериумите што мора да исполни. Најчесто тоа се потребните знаења за одредена област,
искуство во истата област, интересот за проектот и времето во кое вработениот ќе биде
достапен. Карактеристики кои му се потребни на сите да поседуваат се подготвеност за тимска
работа, приспособливост, посветеност на работата, одржување доверба и обезбедување
поддршка, отвореност, квалитетно користење на алатки и техники кои се применуваат во текот
на извршување на активностите. Препорачливо е да побарате од менаџерот на проектот
препораки од претходните работодавачите, проверете го начинот на постапување со другите
луѓе и уверете се во неговата стручност и лидерска способност. За членовите на тимот да се
чувствуваат подобро, а со тоа и да дејствуваат поефикасно, тие се потребни да се мотивира со
парични бонуси, признание и благодарност, преку обезбедување можности за напредување,
преку обезбедување чувство на сигурност при работа и градење тим. Така што вработените
имаат чувство важност во организацијата, неопходно е да им се дозволи да учествуваат во
донесувањето на одредени одлуки. Постојат неколку модели на одлучување засновани на
критериумите за учество на членовите на тимот во одлучувањето:
а. Авторитативно - ако одлуката треба да се донесе во краток временски период тогаш
менаџерот прави без консултација со членовите на тимот. Тука може да се појави проблемот
со имплементацијата тие одлуки доколку членовите на тимот не се согласуваат со донесената
одлука.
б. Партиципативен - на овој начин го зајакнува тимот и придонесува за негова изградба
бидејќи се носат одлуки
заеднички и со тоа поддршката за одлуката е поголема отколку кај авторитативниот метод.
в. Консултативен - овој метод се смета за најдобар и најефикасен затоа што менаџерот носи
одлука по консултација со членовите на тимот.
Во текот на спроведувањето на активностите, менаџерот е задолжен за делегирање или
распоредување работни места на подредените.¸¸Позитивни ефекти од делегирањето се
резерва (резервна копија) на човечки ресурси, поголема тимски удел во спроведувањето на
проектот, повеќе време за планирање, тимски одлуки (подобро прифаќање) и намалено време
на чекање за одлуки.“ (Фертаљ, Цар, Косовиќ Нижетиќ, 2016:97). Во рамките на секоја тимски,
можни се конфликти поради различни интереси, начини на однесување, погрешни начини
комуникација и бројни други причини, а менаџерот е тој што мора да ги реши со нивно
наметнување соодветни решенија и решавање на постоечкиот проблем, постигнување
компромис или со игнорирање на конфликтот.

Управување со комуникација
Според спроведеното истражување, докажано е дека програмскиот менаџер троши дури 80%
од вашето време во комуникација со другите, без разлика дали се членови на тимот, спонзори,
донатори или забави. За да го направите ова успешно, потребно е да имате добар
комуникациски план кој содржи:
• ¸¸Пристап кон управувањето со комуникацијата – ја пренесува идејата до лидерот, на пример
внесување податоци за
на местото на потекло, следење на напредокот „во реално време“,
транспарентност/достапност
документација и публицитет на одлуките, акцент на соработката итн.
• Ограничувања – рокови, финансии, законски и други прописи, технологија итн.
• Засегнатите страни и нивните барања за комуникација
• Контакти (директориум на проектниот тим) - име, наслов, улога, телефон, eml, URL, итн.
• Методи и технологии – CPM/PERT, Sharepoint, Primavera итн.
• Комуникациска матрица
• Дијаграм за комуникација
• Препораки за состаноци - агенда, записници, улоги на учесници и сл.
• Стандарди за комуникација – формати, шаблони, имиња на датотеки итн.
• Постапка за ескалација - приоритет, проблем, одлучувач и рок.“ (Фертаљ, Цар, Косовиќ
Нижетиќ, 2016:102)
Како и во секој бизнис, така и во управувањето со проекти потребно е да се разменат
информации како
сите членови би имале соодветни и навремени информации и затоа би дејствувале ефективно.
Тоа може да се направи преку писмена или усна комуникација, електронска комуникација
или во денешно време се повеќе се користат информациски системи за управување со
проекти, како што е Microsoft Project за Windows, кој е широко користен во хрватските
компании, Рајк, Гантер...
Често преговара со членовите на тимот, како и со забавите и од таа причина менаџерот на
морето имаат добри техники за преговарање. Во случај на дистрибутивно преговарање на
двете страни тие се трудат да извлечат што е можно повеќе за себе, т.е. ситуацијата е победа-
пораз. Со оглед на начинот, договарање, доминација и агресивен и често понижувачки начин,
ова е краткорочно преговарање. Од друга страна, во интегративното преговарање, страните се
обидуваат да се договорат, победа - победа, тој е поддржувачки и помирувачки, и поради оваа
причина често е долгорочен.

Затворање на проектот
Последната фаза на проектот значи прифаќање на добиениот производ или услуга
спроведен проект. Ова е крајот на проектот кој резимира се што е направено во планот
рок и дали се постигнати планираните цели и сите активности потребни за
нивна реализација. Според Фертаљ, Цар, Косовиќ Нижетиќ (2016:111), процесите што се
случуваат во во оваа фаза се:
а. Ревизија на набавка - потребно е да се оправдаат сите трошоци што се направени
б. Завршување на верификација на опсегот - процес кој се спроведува во текот на целиот
проект и со кој
контрола на испораките
в. Затворање на договори со добавувачи - потребна е потврда за тоа како се подмирени
добавувачите a
сите нарачки испратени
г. Административно затворање - ¸¸вклучува комплетирање на сите извештаи, уверување за
потврда на клиентот
за преземање на резултатите од проектот и обезбедување информации за производот и
исполнувањето на проектот
барања“.
д. Доставување на финални извештаи - на крајот од секој проект потребно е да се достават
извештаи за статусот,
отстапување, распоред и извештај за трошоците и членовите на тимот
ѓ. Архивирање на записи од проектот
Г. Прераспределба на членовите на тимот
ч. Обележување на завршувањето – прослава на успехот на проектот кој беше реализиран и
резултатите кои беа постигнати

ИКТ ПРОЕКТИ И НИВНИ КАРАКТЕРИСТИКИ

Управување со ИТ проекти со користење на менаџментот за управување со проекти е многу

сложен предмет кој не е доволно опфатен во литературата.Од ИТ проектите најчесто се
очекува многу. Извршните менаџери во компаниите сметаат дека воведувањето на ИТ ќе
придонесе за подобрување на деловните процеси и поефикасна работа на целата
организација. ИТ проектите се такви проекти кои користат одредени хардвер, софтвер и мрежа
за создавање на ИТ производ, услуга или резултат. Ова е една од можните и општи дефиниции
за ИТ проекти. Кога зборуваме за ИТ проекти и ИТ менаџмент проектите треба да земат
предвид многу широк опсег на различни ИТ проекти. Меѓутоа, за да се зборува за процесот на
управување со ИТ проекти и употребата на соодветна методологија за управување со проекти,
неопходное да се изврши одредена класификација и категоризација на ИТ проекти во
одредени групи, кои имаат исти или слични карактеристики. Во пракса најчесто се разговара за
развојни проекти воведување на различни софтверски решенија и посложени и поголеми
проекти за воведување на информациски системи. Може да биде некоја основна
класификација,во однос на стандардизацијата на процесот на управување со ИТ проекти, што
дава основа за понатамошна анализа и елаборат, а исто така и за дефинирање на процесот на
управување ИТ проекти.
Според Snedaker [8], постојат следниве типови на ИТ проекти: • Стратешки или оперативни •
Долгорочни или краткорочни • Хардвер или софтвер • Развој или имплементација
Според Раковиќ [9], ИКТ проектите се поделени на: • Проекти за воведување информациски
системи • Софтверски проекти • Телекомуникациски проекти
Земајќи ги предвид процесите на дизајнирање и имплементација на ИТ проекти, може да се
каже дека можеме прави разлика помеѓу проекти поврзани со: • Дизајн на хардвер • Дизајн и
имплементација на софтвер • Дизајн и имплементација на информациски системи • Обука на
корисници. Оваа област исто така не е сериозно обработена во литературата, која најчесто
дава сосема општи поделби. Меѓутоа, за да се дефинира и користи методологијата за
ефикасното управување со ИТ проекти бара попрецизни поделби кои би изразиле специфични
карактеристики на овие проекти и со тоа овозможи подобро утврдување на процесот и
методологијата на управување со ИТ проекти [6]. За секој кој сака да работи на ова поле,
исклучително е важно да има добро разбирање за спецификите на софтверот како производ,
неговите квалитетни карактеристики како предуслови за задоволство на корисниците и
спецификите на развој на софтвер и процеси за управување со софтверски проекти 10.
Имено, самото пишување на програмата е прашање на техника кое ги спроведува чекорите
предвидени во постапката за решавање на набљудуваниот проблем. Сепак, истите ИТ
ПРОЕКТИ И Специфичности

СОФТВЕРСКИ ПРОЕКТИ
Управување со ИТ проекти со користење на управување со проекти
менаџментот е многу сложен предмет кој не е доволно опфатен во литературата. ИТ проектите
се најчести тој очекува многу. Извршните менаџери во компаниите сметаат дека воведувањето
на ИТ ќе придонесе за подобрување на деловните процеси и поефикасна работа на целата
организација. ИТ проектите се такви проекти кои користат одредени
хардвер, софтвер и мрежа за создавање на ИТ производ, услуга или резултат. Ова е една од
можните и општи дефиниции за ИТ проекти.
Кога зборуваме за ИТ проекти и ИТ менаџмент проектите треба да земат предвид многу широк
опсег на различни ИТ проекти. Меѓутоа, за да се зборува за процесот на управување со ИТ
проекти и употребата на соодветна методологија за управување со проекти, неопходно е
е да се изврши одредена класификација и категоризација на ИТ
проекти во одредени групи, кои имаат исти или слични
карактеристики. Во пракса најчесто се разговара за развојни проекти воведување на различни
софтверски решенија и посложени и поголеми проекти за воведување на информациски
системи. Може да биде некоја основна класификација, во однос на стандардизацијата на
процесот на управување со ИТ проекти, што дава основа за понатамошна анализа и
елаборат, а исто така и за дефинирање на процесот на управување
ИТ проекти.
Според Snedaker, постојат следниве типови на ИТ проекти:
• Стратешки или оперативни
• Долгорочни или краткорочни
• Хардвер или софтвер
• Развој или имплементација
Според Раковиќ, ИКТ проектите се поделени на:
• Проекти за воведување информациски системи
• Софтверски проекти
• Телекомуникациски проекти
Земајќи ги предвид процесите на дизајнирање и имплементација на ИТ проекти, може да се
каже дека можеме да направиме разлика помеѓу проекти поврзани со:
• Дизајн на хардвер
• Дизајн и имплементација на софтвер
• Дизајн и имплементација на информациски системи
• Обука на корисници
Оваа област исто така не е сериозно обработена во литературата, која најчесто дава сосема
општи поделби. Меѓутоа, за да се дефинира и користи методологијата за ефикасното
управување со ИТ проекти бара попрецизни поделби кои би изразиле специфични
карактеристики на овие проекти и со тоа овозможи подобро утврдување на процесот и
методологијата на управување со ИТ проекти [6]. За секој кој сака да работи на ова поле,
исклучително е важно да има добро разбирање за спецификите на софтверот
секој од нас би ги имплементирал чекорите за решавање на проблемот на свој начин, дури и
ако го користел истиот програмски јазик за да ја напише програмата. Ова значи дека
пишувањето програма, т.е. развој на софтвер содржи одредени креативна компонента која
секако ќе зависи од неа големината и сложеноста на напишаната програма. Според ISO_2382
„Софтверот е интелектуална креација кој содржи програми, процедури, правила и соодветна
документација поврзана со нечија работа систем за обработка на податоци. Иако софтверските
проекти споделуваат голем број заеднички атрибути со класичните проекти, тие сепак
поседуваат неколку карактеристики што ги прават многу различни од другите видови
инженерски проекти
• Невидливост (производот е нематеријален, т.е. претставува
логична, а не физичка креација. Физички не постои објект за работа. Влезот во проектот
претставува идеја, т.е. опис на функционалноста која се очекува како резултат од проектот.
Поради горенаведеното, како и поради високиот степен на динамичност на околината во
во кои се имплементираат проекти за развој на софтвер, резултатот од проектот често е тешко
да се предвиди.
• Комплексност - Софтверските проекти често можат
да бидат покомплексни од другите развојни проекти,
имајќи го предвид големиот број врски во самата тема
проект.
• Флексибилност - Со оглед на динамиката на околината
во кои се имплементираат електронски деловни проекти, тие мора да се имплементираат на
многу флексибилен начин, за да може да се направат прилагодувања во секој момент од
реализацијата на проектот.
• Недостаток на искуство - Софтверско инженерство е
нова дисциплина, па едноставно немаме многу
знаење за начините на управување со софтверски проекти, особено големи софтверски
проекти.
• Често се градат големи софтверски проекти врз основа на барањата на конкретен клиент
(прилагодено). Повеќето големи софтверски системи се специфични, така што искуството се
стекнува на еден проект од мала помош во вториот.
• Технологијата се менува многу брзо - На повеќето
големите софтверски проекти користат нови технологии; за многу проекти, ова е дури и
причината за постоењето. Секој кој е вклучен во развој на софтвер го знае тоа
комплексен и ризичен бизнис, а неговите учесници се секогаш во
бараат нови идеи кои ќе ги доведат до подобри резултати, подобар софтвер. За среќа,
софтверското инженерство е сè уште млада професија која се развива кои се очигледни
иновации и подобрувања секоја година во најдобрите практики.
ПРИЧИНИ ЗА НЕСУПЕЊЕ НА ПРОЦЕСОТ НА РАЗВОЈ СОФТВЕР
На почетокот, процесот на развој на софтвер беше сè за тоа
за пишување софтверски код. Подобрувања кои се
што се случи во индустријата доведе до тоа процесот да стане покомплексен и да вклучи
архитекти, аналитичари,
програмери, тестери и корисници во развојот на кодот. Иако
Знаете многу за процесот на развој на софтвер
проектите сè уште имаат најголем процент на неуспех во спроведувањето. Постојат многу
причини, но најчести се:
1. Целите на проектот не се целосно дефинирани: многу
важно е да се знае кои се потребите и очекувањата; што е тоа што
софтверот треба да обезбеди. Прецизно дефинирано
резултатите водат до подобро дефинирање на целите и може
минимизирајте ги шансите за неуспех.
2. Лошо планирање и проценки: многу е важно да се процени буџетот и временската рамка
која е реална и во
во согласност со дефинираните цели. Тоа е единственото нешто што е можно
доколку постои разбирање за функциите кои се потребни за да
обезбеди софтвер за крајните корисници.
3. Несоодветна или недостаток на проектна методологија: не треба да се потценува во
процесот на развој на софтвер
улогата на проект менаџер. Успешен развој на софтвер
тешко е да се постигне без правилно лидерство, бидејќи тоа е процес во кој е неопходно да се
координираат различните аспекти
проект. Менаџерот на проектот е задолжен за следење на процесот, предвидување на
пречките и насочување на работите
до посакуваниот пат.
4. Преземање барања - најчестиот проблем што го има
критично влијание врз имплементацијата на проектот. Ако не
одвојте доволно време за да ги разберете потребите на корисникот, се случуваат неуспеси и во
некои ситуации
потребата од невозможни корекции. Најважно е првото
да ги разбере и прифати барањата на клиентот и само после тоа,
пристапи кон прилагодување на софтверското решение. Еден од
Еден од советите за да избегнете неуспех во оваа фаза е да ангажирате деловен аналитичар,
кој ќе ги собере барањата на клиентот, земајќи ги предвид нетехничките аспекти.
5. Разбирање на јазикот – најчест проблем е тоа
ИТ професионалците и клиентите мислат дека зборуваат ист јазик,
што најчесто не е точно. Ова доведува до ситуација дека ИТ
експертот испорачува производ што клиентот всушност не го прави
Тој ме праша. Овие комуникациски проблеми се најтешки за решавање,
бидејќи тие се идентификуваат дури откако ќе заврши процесот. Бидејќи
затоа, би било пожелно да има бар во проектниот тим
едно лице кое подеднакво добро ги разбира информациите
технологии и деловни процеси.
6. Управување со очекувањата - најчесто од ИТ
експертот го очекува невозможното, бидејќи луѓето кои не го разбираат доволно процесот
мислат на софтверот како о
волшебно стапче кое ќе ги реши сите проблеми. Овде е
најважната улога на проект менаџерот, бидејќи тој би
треба да управува со очекувањата на клиентите и да ги врати на
разумно ниво 12. Поради сложената природа на софтверските проекти i
брзиот развој на технологијата вклучена во процесот,
развојот на нов софтверски производ бара систематски пристап.
Фази на успешен проект за развој на софтвер
се: анализа, дизајн, имплементација, тестирање, распоредување, одржување, мерење и
следење на напредокот, развој, автоматско адресирање, тестирање. Земајќи ги предвид
дека развојот и примената на софтверот е континуиран процес,
важно е да ангажирате професионалци кои се во чекор со
промени во технологијата. Покрај тоа, неопходно е
ангажира стручен проектен тим, предводен од проектот
менаџер и користете методологии за управување со проекти за да ја зголемите веројатноста за
успех
на овие проекти.
УПРАВУВАЊЕ СО СОФТВЕРСКИ ПРОЕКТИ
ИТ проектите претставуваат еден вид предизвик за
проект менаџери, бидејќи тие подразбираат координација
со многу засегнати страни и интеграција на различни технолошки капацитети. Во секоја фаза
од животниот циклус на ИТ
проекти, улогата на спонзорот на проектот е многу важна,
проект менаџер и проектен тим.
Успешните тимови за развој на софтвер треба да постигнат рамнотежа помеѓу брзото
испорачување на квалитетни софтверски системи, исполнувањето на барањата на засегнатите
страни, справувањето со ризиците, воведувањето промени и подобрувањето на начинот на кој
се прават работите.
кои си ја вршат работата 13. Олеснување на ефективна комуникација преку соодветни
канали и состаноци
е една од клучните работни места на софтверските професионални менаџери.
Процесот на управување со ИТ проекти се состои од голем број под-процеси. Фазите може да
се дефинираат поинаку, од различни автори, но без разлика
различни дефиниции, може да се каже дека процесот на управување со софтверски проекти се
состои од следново:
1. Концептуализација - опфаќа: избор и финансирање
проекти, идентификација на клучните чинители, определување на целта и содржината на
проектот, подготовка на проектен план
повелба
2. Дефинирање барања - подразбира идентификација и јасно изразување на барањата на
клиентот, одвојување на техничките и функционалните барања, употреба
Г. КИЛИБАРДА и сор. УПРАВУВАЊЕ СО СОФТВЕРСКИ ПРОЕКТИ
148 ТЕХНИКА - МЕНАЏМЕНТ 66 (2016) 1
различни методи за прибирање барања, развивање методологии за следење на барањата.
3. Планирање - се состои од дефинирање на клучните
компоненти на проектниот план и процесот на планирање,
создавање на WBS, креирање на временски распоред, проценка
времетраење, ресурси и трошоци, планирање на ризик и одговор
за ризици, креирање на помошни планови, вклучително
комуникации, набавки, квалитет итн.
4. Дизајн - прелиминарни и детални активности
дизајн, типична содржина на документи кои содржат техничка спецификација, употребени
техники на дизајнирање
при развивање на техничко решение, одлучување за опции
купи или направи
5. Развој - развој на проектниот тим кој ќе го развие i
испорача производ, контролни и безбедносни активности
квалитет, тестирање и следење, евалуација на перформансите
проект, развој и употреба на методологии за управување
промени во барањата, развој на стратегии на кои треба да се одговори
ризици
6. Испорака - клучни активности за испорака, развој стратегијата за верификација вклучува
прифаќање од страна на клиентот. Тоа го покажаа претходните искуства во оваа област
распоред и активности за планирање на проекти и управување со ризик се критични точки во
проектите за развој на софтвер. Проблем со распоредот проектот се состои во одлучување кој
што прави во текот на на животниот циклус на софтверски проект. Ова е клучно прашање во
практиката на софтверското инженерство, бидејќи вкупните буџетски и човечки ресурси мора
да бидат оптимални управуваат, со цел успешно завршување на проектот.
Тековните софтверски проекти обично бараат сложено управување кое вклучува распоред,
планирање и следење. Има потреба да надгледувани од луѓе и процеси и ефикасно
распределени ресурси, со цел да се постигнат конкретни цели во рамките различни
ограничувања. Целите обично се да се намали времетраењето на проектот, да се намалат
трошоците на проектот и да се зголеми квалитетот на производот. Во реалниот проект, проект
менаџерот сака план кој ќе се помири, како и да е тоа евентуално, овие три спротивставени
цели 14. Ефективно управување со софтверски проекти е клучот за постигнување успешен
исход. Цели на проектот треба да се договори на самиот почеток. По повод поставувајќи ги
целите, треба да се земат предвид нивните импликации, во однос на реалните резултати и
влијанието што тие ќе го имаат резултати имаат. Исто така, постои потреба да се разгледа
влијанието на самиот развојен процес. Проектниот тим треба да бидат добро информирани за
овие прашања и да имаат можност целосно да се разговара за нив за да можат донесуваат
свои заклучоци. Тимот треба да размисли за се импликациите на тој план, вклучувајќи ги и
етичките. Тоа ќе биде може да бара дополнителни средства внатрешно и надворешно
организации. Погрешно е да се постави премногу тесна рамка разговори, во обид да
заштедите пари и време. Во текот на проектот неизбежно ќе се појават широк спектар на
прашања. Доколку членовите на тимот се неподготвени, ќе им недостига насока и лошо ќе ја
извршуваат својата работа. Ете зошто неопходно е спонзорот на проектот да има визија и
орган, со цел да се обезбеди поддршка на проектниот тим, како и да бидат обучени да ги
разгледуваат и техничките и етичките прашања прашања.
Обуката на идните експерти за управување со софтверски проекти е тема од големо значење
15. За експертите на патот до успехот во развојот на софтверски проекти, знаењето од
областа е од големо значење управување со софтверски проекти. Сепак, внесувањето
професионална пракса во училницата е тешка задача. Често идните софтверски
професионалци немаат практична обука со реални животни ситуации. Дополнително, јасно
теоретска средина за учење, како онаа во сегашната наставни програми за управување со
софтверски проекти, тоа е прилично неинтересно за идните професионалци 16. Соодветно
на тоа, модерни професионалци неговото искуство работејќи на реални проекти, каде што
ефектите погрешен план или донесување одлуки може да доведе до неуспех на проектот или
губење на корист за компанијата за што го прават 15. Квалитет, ризик и успешен развој на
софтверски проекти се три концепти кои се непобитно испреплетени едни со други 17.
Значи, управување со софтвер проекти е збир на техники кои се користат за развој и
испорака на различни видови софтверски производи. Оваа дисциплината во развојот
традиционално вклучува технички прашања како што се: • избор на методологија за развој на
софтвер, • како да се процени големината и распоредот на проектот, • како да се обезбеди
безбедност, • кои ресурси може повторно да се користат • која развојна средина да се користи
за програмирање. Дисциплината, исто така, вклучува прашања за управување како
кои се: кога да се обучи персоналот, кои се ризиците за успехот
на проектот, и како да се одржи проектот на вистинскиот пат. Овие избори потоа се
отелотворени во план за управување софтверски проект.
Развојот на софтвер е често комплициран и вклучен многу луѓе од различни области, различни
вештини, искуства и социјални ставови. Има многу оперативни одлуки кои треба да се донесат
за време на оваа активност која одзема многу време. Исто така, постојат многу различни
пристапи за контрола на сложеноста на оваа активност. Сето ова методи, главната цел е да се
обиде да предвиди и избегнувајте ги сите можности кои можат да имаат негативно влијание
на софтверски проект. Негативните можности се тие што би ја одложило испораката на
софтверот навремен и исплатлив начин. Дополнителна цел е да се избегнат доцните промени
во системот, бидејќи што е подоцнежна промената, поскапо е.

Пристапи за управување со ИТ проекти

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

кои се релативно слична терминологија и појаснувања, но променливи; на пример.
методологија, рамка за работа (анг. рамка), метод, техника, процес; сите овие се термини кои
се користат за да се разјасни целта сфера на интерес.
Во принцип, можеме да ги разгледаме со два основни пристапи: традиционалниот пристап и
модерниот пристап;
и двете имаат свои предности и недостатоци, а околностите во кои се подобри се разликуваат.
Традиционалниот пристап користи конвенционални испробани методи и генерално е подобар
кога зборува за видовите проекти наречени „печатење по бројки“, односно за поголеми
проекти кои вклучуваат јасно дефинирани активности и фази, на пр. имплементација на нов
оперативен систем во бизнис. Се карактеризира со построги правила (за комуникација,
документација, промени план и сл.), поголема улога на проект менаџерот и откако ќе се
направи проектниот план, тоа главно не се менува до крај.
За разлика од него, модерниот или агилен или итеративен пристап е подобар за т.н проекти „Р
и Г“,
односно проекти каде барањата не се јасно дефинирани, не се знае точно какви се резултатите
проекти, а тие проекти траат помалку, на пр. развој на нов уред за комуникација само со еден
со копче (iPhone), или развој на нова платформа за социјални мрежи или развој на нов
интернет
SaaS платформи за испорака на апликации. Современиот пристап се карактеризира со помала
документација, помалку формална комуникација, поголем ангажман на крајните корисници,
помали тимови, повеќе комуникација помеѓу членовите на тимот, поголемо споделување на
знаењето, т.н повторување учество. На еден и на вториот пристап за управување со проекти,
постојат голем број на методологии кои се негови претставници и потребно е да се
прецизираат позначајни. Методологиите за управување со проекти може да се поделат на
следниве:
1. традиционалниот пристап или фазен пристап:
• Методологија на синџир на настани
• Управување со проекти со критични синџири
• Prince 2
2. модерен (англиски модерен проект менаџмент) или итеративен пристап89:
• Агилно управување со проекти
• SCRUM
• Посно управување со проекти
• Екстремно управување со проекти
6.1 Традиционален или фазен пристап
Традиционалниот или фазен пристап препознава неколку фази кои мора да се завршат за
проектот беше постигнато. Овој пристап обично вклучува пет фази90:
1. иницирање на проект
2. планирање и развој
3. извршување
4. надзор и контрола
5. затворање.
Овие фази обично се користат последователно, но исто така може да се преклопуваат. Кога
развивате софтвер, на пример, овој пристап е познат како модел на водопад. Моделот на
водопад се покажа како корисен за помалку дефинирани проекти, но не е добро за поголеми
проекти каде што не се јасно дефинирани функционалните барања на софтверот. Со цел да се
решат овие проблеми, подоцна беа објавени различни модифицирани методи на водопад.
Традиционалниот (чист) модел на водопад (слика 3.) е во софтвер индустријата преземена од
производството и градежништвото. И двете од овие индустрии се структурирани физичката
средина и сите последователни промени по испораката на производот се завршени
не е можно. За време на раните денови на софтверската индустрија, немаше формални
методологија за развој на софтвер, затоа овој модел беше усвоен
Моделот на водопад подразбира неколку фази во развојот на софтверот како што се анализа
на барањата, развој (дизајн и програмирање), тестирање, верификација и одржување (Слика
3). Овие фази се секвенцијално, односно само по завршувањето на една фаза се преминува во
друга фаза и после тоа штом софтверот ќе се пресели од една во друга фаза, не може да се
врати во претходната. Ова може да се истакне и како мана на овој модел, што доведе до
развој на модифицирани модели.

Модифициран модел на водопад

Појавата на овој модел е последица на недостатоците на традиционалниот модел на

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

Управување со проекти со критични синџири

Управување со проекти со критични синџири (CCPM; Слика 5.) беше развиен од др. Елијаху
Голдрат е првиот неколку пати претставена во книгата „Критички синџир“. Овој метод е
создаден како одговор на проблемот доцнење на голем број проекти во однос на првичниот
план, што резултира со повисоки трошоци од планираното и реализација на помала
функционалност од очекуваното. При креирањето на дизајнот од распоредот на проектот,
најчесто користени методи се CPM и PERT, кои за основа имаа дефинирање на активности,
дефинирање на редоследот на извршување на активностите и утврдување на времетраењето
на активноста. Токму при определувањето на времетраењето на одредени активности се зема
предвид зеде т.н безбедносно време кое служеше да се осигура дека распоредот на проектот
(инж. Проект распоред) беше максимално реален и немаше да попушти за време на
извршувањето на проектот. Таков начин на добивање распоредот за работа на проектот има
неколку недостатоци што доведоа до одложување на проектот94:
• задачата/активноста не се извршува додека не дојде време да се започне (англиски.
студентски синдром)
• задачите/активностите не се извршуваат на таков начин што може да се завршат до крајниот
рок, иако може да се направат заврши порано (Закон на Паркинсон)
• се избираат само задачите за кои има доволно време за завршување, т.е. има полесни
верзии (задачи за берење цреши)
Безбедносното време вклучено во извршувањето на активноста, реално, е залудно потрошено.
Покрај тоа, менаџментот често ги охрабрува вработените да работат со повеќе задачи. На тој
начин вработените се префрлаат од една активност во друга, со што се продолжува времето
што е предвидено со план: со тоа им треба многу повеќе време за извршување на одредени
активности, отколку за нивно извршување тие работат еден по еден. Покрај тоа, луѓето често
не сакаат да пријават дека завршиле задача пред време бидејќи нивната следна слична задача
е планирана според претходното искуство, т.е. нивното време е скратено планирани за идни
слични задачи. ККПМ се обидува да ги реши овие прашања на следниов начин95:
• Критичен синџир (критичен синџир) – Дефиниран е критичниот синџир (CC); тоа е најдолгиот
синџир (не патеката, како во CPM) на зависни задачи. Во овој случај, зависноста се однесува на
ресурси, на споделување на ресурси за иста активност и од логичката зависност на активноста.
Тоа е главната разлика во споредба со CPM, каде што се разгледува само логичката зависност
на активностите.
• проценки на времето на активност - да се намали губењето време поврзано со прекумерно
безбедносно време, CCPM предлага намалување на времето на активност за 50%.
• безбедност – CCPM користи безбедносни бафери за да управува со несигурностите насекаде
извршување на проектот. Безбедносното време што беше дефинирано за секоја задача е сега
поттикнати на проектно ниво. Постојат три типа на безбедносни бафери кои обезбедуваат
безбедност на спроведувањето на проектот:
1. проектен тампон – време додадено на крајот помеѓу последната задача и датумот на
завршување проект. Секое доцнење во најдолгиот синџир ќе потроши дел од тој тампон, но ќе
потроши крајниот датум останува недопрен. Се препорачува да биде половина од вкупното
времетраење безбедносно време на сите активности. На овој начин, вкупното времетраење на
проектот е на 75% од првично планирано.
2. тампон за напојување – доцнењето на патеките што влегуваат во CC или најдолгиот синџир
може да предизвикаат одложување на проектот, со одложување на некои од подактивностите
во критичниот синџир. Со цел да се ако ова е оневозможено, се додаваат бафери за
напојување помеѓу последната задача на влезната патека и CC. Се препорачува тие да бидат
половина од безбедносното време на сите активности влезен пат.
3. тампон за ресурси – може да се постави до CC за да се обезбеди доволен број луѓе i
вештини потребни за работа во CC.
• приоритети - на сите ресурси на проектот им се дадени јасни и дефинирани приоритети
поврзани со одржување на CC, во зависност од конкретниот тампон, како и од проектот како
целина. Ресурс кој има повеќе од една отворена задача, пред да заврши која било задача на
тој начин влегува во КЗ, ќе биде доделена на задачата што му се заканува на КЗ
• завршување - ресурсите се охрабруваат да ги завршат активностите што е можно побрзо
компромитирачки квалитет. Задачите не се оставени на половина готови, за да се избегнат
мултитаскинг. Промената на безбедносното време ги поттикнува ресурсите да работат
понапорно и да ги елиминираат на претходно споменатиот „студентски синдром“ и
„Паркиновиот закон“
• управување со бафери - износот на потрошувачка на секој тампон во однос на
времетраењето на проектот кажува како доцнењата влијаат на крајниот рок. Ако варијациите
на проектот се рамномерни дистрибуирани, тогаш потрошувачката на тампон ќе биде
линеарна. Резултатот ќе биде проект завршен со целиот искористен тампон. Ако
потрошувачката на тампон е поголема од напредокот на проектот, тогаш Премиерот мора да
преземе корективни мерки.
• преостанатото време - активностите се контролираат во однос на времето потребно за
завршување (колку дена да се заврши задачата), а не процентот на завршено. На тој начин
се контролираат баферите и нивното искористување.

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

Овој тип на методологија ги надополнува CPM и CCPM. Тоа е техника за моделирање на

несигурност и на мрежно планирање кое се фокусира на идентификување и управување со
настани кои можат влијае на роковите на проектот (Слика 6). Тоа помага да се намали
негативното влијание на различни настани врз извршување на проектните активности и
овозможува полесно моделирање на неизвесноста во мрежата план. Таа се заснова на
следните принципи96:
• веројатноста за појава на ризик во одреден момент од извршувањето на одредена активност
• синџир на настани (Event Chain) каде што одреден настан може да биде инициран од друг,
овој пак нови итн., што доведува до синџир на настани што може значително да влијаат на
текот на извршувањето проект
• критичен настан или синџир на настани - настан или синџир на настани кои имаат најголемо
влијание врз проектот се утврдува со анализа
• следење на напредокот на проектот преку настанот - вклучително и анализа на настанот во
извештаите за
напредок на проектот
• визуелизација на синџирот на настани преку дијаграми.

PRINCE 2
Ова е акроним за „Проекти во контролирани средини“ , развиен од владата
на Обединетото Кралство и го претставува стандардот за управување со јавни проекти во ОК.
PRINCE2 е создаден од претходен метод наречен PROMPTII и од методот PRINCE
на проектен менаџмент кој првично беше развиен во 1989 година од Central Computer и
Агенција за телекомуникации (CCTA) како владин стандард на ОК за управување со ИТ проекти.
PRINCE2 се заснова на седум принципи, седум теми на процесот. Принципите се: континуирано
деловно оправдување на проектот, учење од искуство, јасно дефинирани улоги и
одговорности,
управување по фази, управување по исклучок, фокус на производот и прилагодување
проектна средина. Седумте теми се: деловен случај, организација, квалитет, план, ризик,
промени и напредок. Принципите и темите се реализираат низ процеси. Процесите се 98:
• Започнување на проект (Започнување проект - SU)
• Иницирање проект (Иницирање проект - IP)
• Управување со проекти (Насочување на проект - ДП)
• Контролирање на фаза (Контрола на фаза - CS)
• Управување со границите на сцената (СБ)
• Управување со испорака на производи (Управување со испорака на производи - МП)
• Затворање проект (Затворање проект - КП).

Модерен или итеративен пристап

Главни претставници на современиот пристап се т.н агилни методологии. Овие методологии
беа создаденим природната потреба за зголемување на успехот на проектите. Имено, голем
број проекти кои се управуваа на традиционален начин, имаа проблеми. Познатото
истражување на Стендиш Групниот ХАОС Студиите покажаа дека многу ИТ проекти не ги
исполнуваат роковите проекти со очекуваните трошоци, а честопати не успеваат да ги
реализираат очекуваните придобивки. Овие проблеми се потврдени од многу организации, на
пр. Министерството за одбрана на САД имаше 75% од проектите на развој на софтвер кој
никогаш не заживеа или го прекина развојот пред крајот на проектот. Слично, научното
истражување ги доведе во прашање традиционалните методи на управување со развојни
проекти софтвер. Во 1998 година, Роберт Д. Остин и Ричард Л. Нолан истражувале голем
софтвер проекти кои испитуваа многу од основните идеи за управување со проекти за развој
на софтвер, а доведе до следните заклучоци:
• првата погрешна претпоставка во управувањето со проекти за развој на софтвер е дека тоа е
можно испланирајте голем проект за развој на софтвер
• уште една погрешна претпоставка е дека е можно да се заштитите од подоцнежните
промени (последователни барања)
• третата погрешна претпоставка е дека има смисла да се склучи голем проект рано, веќе во
фаза на планирање.
Вотс Хемфри, истакнат истражувач во IBM ја надоврза оваа студија со статија во која го наведе
„Принципот на несигурност на барањата“, на што посочува
помислата дека барањата за нов софтвер нема да бидат целосно познати додека корисникот
не почне да го користи. Поврзаноста помеѓу овие идеи и концептите на агилен пристап за
развој на проекти е очигледна. Ако корисниците не можат да кажат што сакаат додека не го
видат, доколку предвидуваат и планираат големи ИТ проекти не е можно и ако не може да се
заштити од барања за модификација во фазата на развој на софтвер, тогаш концептите и
идеите зад традиционалниот метод на водопад се очигледно неупотребливи. Понатаму, може
да се заклучи дека методите засновани на постепен развој и
носат значителни придобивки за прототипниот пристап.
Успехот на проектот се зголемува:
• предвремено ослободување на дизајнот на производот кон корисникот
• секојдневно додавање на нов програмски код и брзи повратни информации
• искусен и квалификуван тим за развој
• поголеми инвестиции во развојот на програмската инфраструктура.

Агилно управување со проекти

Ова е итеративен и инкрементален метод за проектирање и изградба на проектни активности
во информатичка технологија, технички проекти, проекти за производство на нов производ
или услуга и многу флексибилни проекти Најдобро функционира во проекти кои се премногу
сложени за да се специфицира функционалноста пред да се тестира самиот прототип. Агил е
роден како одговор на континуирано и константно промена на барањата за време на проекти
за развој на софтвер. Наместо да поминуваат недели или месеци во дефинирањето на
деталната спецификација на корисничките барања за целиот проект и повеќе потоа подолго на
развој на производ, потоа на тестирање при кое наоѓа стотици грешки, овој метод
специфицира помали сегменти кои можат да се користат самостојно (зголемува), ги развива и
тестира циклуси од две до четири недели. Во 21 век, тоа е еден од најпопуларните пристапи
кон управување со проекти за развој на софтвер. Агилното управување со проекти е родено од
агилно методологија за развој на софтвер дефинирана од Џим Хајсмит. Во агилно управување
проекти, целиот тим е одговорен за управување со тимот, а не само менаџерот на проектот.
Кога тоа се работи за процеси и процедури, често логиката или здравиот разум доаѓа пред
пишаните политики и процедурата. На овој начин се обезбедува непречено одвивање на
проектот, т.е. побрзо одлучување.

SCRUM

Од сите агилни методологии, SCRUM е единствен во својот емпириски контролен процес.

Scrum користи вистински проценки за напредокот на проектот, а не прогнози за напредок на
проектот или оптимистички проценки. Со Scrum, проектите се поделени на кратки работни
циклуси наречени спринтови, кои обично траат една, две или три недели. На крајот од секој
спринт, учесниците во проектот, членовите на тимот исто така се среќаваат и го оценуваат
напредокот на проектот и го планираат следниот спринт. На овој начин континуирано се
заснова и одредува насоката на проектот во однос на сработеното, а не на шпекулации и
предвидувања. Не е тешко да се претпостави дека тоа е причината за оваа методологија
популарен кај проект менаџерите и програмерите. Scrum има само три основни проектни
улоги: сопственик на производ, господар на скрум и член на тимот.
Карактеристиките се како што следува:
• сопственик на производ - тој е одговорен за пренесување на визијата на производот на
тимот, претставува интересот на купувачот така што ги дефинира барањата и приоритетите на
производот. Тоа е улогата со најголема одговорност, а со тоа има и најголем авторитет. Тој е
одговорен ако проектот не успее, или ако не ги исполнува очекувањата на купувачот. Неговиот
најголем проблем е да го најде вистинското ниво вклучување во проектот, од една страна има
голема одговорност и авторитет, од друга страна не му е дозволено премногу се мешаат во
работата, бидејќи тогаш ќе пропадне целиот пристап заснован на независноста на членовите
на тимот вода.
• господар на состаноци за скрум - модератор помеѓу сопственикот на производот и членовите
на тимот, не управува со тимот, тој ги отстранува пречките што го спречуваат тимот да ги
достигне спринтерските цели. Тоа му помага на тимот да остане креативен и продуктивен,
истовремено обезбедувајќи дека работата е правилно завршена
и транспарентно му го подарува на сопственикот на производот
• член на тимот – одговорен за завршување на работата. Според некои препораки, идеален
број на членови на тимот е 7+/- 2 различни експерти. На пример. со софтверски проекти
типичен тим би ги содржи програмери, дизајнери, аналитичари, тестери, дизајнери на UI,
администратори на бази на податоци. Тимот одредува како да го реализираат спринтот, што
им дава значителна автономија и слобода во развојот, но и одговорноста за исполнување на
спринтерските цели.

Lean project management

Се сведува на примена на посно концепти (градежништво, производство, менаџмент) во

проектот управување. Посно менаџмент е систем за управување со бизнис со користење на
дефинирани принципи, добри деловни практики и алатки за производство на поквалитетни
услуги и производи помалку грешки, користејќи помалку труд, простор, капитал и време. Тоа
имплицира задржувајќи ги само оние чекори (активности) во производството и другите
процеси кои додаваат вредност, имено: оние кои клиентот е подготвен да ги плати, оние кои
го менуваат производот или додаваат на него потребни информации, оние кои се законски
или договорно обврзувачки. Соодветно на тоа, посно управувањето со проекти има за цел да
создаде повеќе вредност со што е можно помалку отпад во проектот значење. Овој метод
потекнува од Јапонија во 60-тите години на 20 век во фабриката на Тојота, како одговор на
конкретната ситуација (авансно плаќање, недостаток на простор и квалификувана работна
сила) во која производителите на автомобили во Јапонија се најдоа по Втората светска војна.
Познат е под името Тојота Систем за производство (TPS). Откако беа демонстрирани
принципите на TPS (Тојота имаше 14 принципи).успешни во преработувачката индустрија се
проширија и во другите гранки на стопанството. Вкупно има пет клучни принципи:
идентификувајте вредности, креирајте мапа Мапирајте го протокот на вредности, создадете
проток, одредете напор, бара совршеност. Доколку се применуваат на менаџментот за
проекти, ова би значело следново:
• Идентификувајте вредност – потребно е внимателно да се „разложи проектот“ за да се
одреди кои делови од проектот се ирелевантни и може да се елиминираат,
• Мапирајте го протокот на вредност – анализирајте го тимот/тимовите и внимателно
одредете го текот на проектот за да види кои тимови се неопходни за проектот и во кое време;
на овој начин се оптимизира
трансфер на работа и ја намалува можноста за создавање тесно грло,
• Create Flow – проектот е поделен на неколку делови, односно помали задачи (активности).
кои се полесни за управување. Се мери перформансите, како се набљудува тимот или
поединците се снаоѓаат во одредени ситуации и во кои се подобри, а во кои се полоши, како
што можеле да даваат задачи во кои се најдобри,
• Воспостави Pull – пред да одлучиш како и кои активности ќе се спроведат
резултатите од проектот, потребно е истите да се потврдат кај спонзорите на проектот. Ако е
можно, се прави само она што е апсолутно неопходно,
• Барајте совршенство – неопходно е да му се даде на тимот способност да донесува одлуки,
поголема слобода во донесувањето одлуки, но и одговорност за нивните одлуки.
Континуирана и јасна комуникација со членовите тим, се промовира важноста од
континуирано учење и подобрување

Extreme project management

Екстремното управување со проекти е метод за управување со многу сложени и

небезбедни проекти. Во XPM, фокусот на управувањето со проекти е на луѓето, а не на
методи и техники на креирање на план за активности и управување со спроведувањето на
планот за активности. Кодот овој пристап нема јасно дефинирани фази на проектот, нема јасни
насоки како да се спроведе одредена проектна активност. Со XPM потребно е да се прилагоди
на проектната активност и да се изврши е на најдобар можен начин. Нема долги рокови,
дефинираните рокови се многу кратки, често пократко од две недели. Членовите на тимот
имаат многу слобода во донесувањето одлуки за тоа како да се спроведат одредена активност,
но затоа сносат одговорност за роковите и квалитетот на таа активност. Од сè има
исклучително големо влијание на човечкиот фактор при ваквиот начин на управување со
проекти. Членовите на проектниот тим во XPM имаат сосема различни улоги и одговорности
отколку во кодот традиционален пристап, така што главниот предизвик на проект менаџерот
во XPM е промената начинот на кој размислуваат членовите на тимот. Во оваа смисла, за
премиерот е важна промоцијата на одредени вредности во менувањето на системот на
размислување на членовите на тимот107:
• нормално е барањата и проектните активности да бидат хаотични,
• неизвесноста е единствената безбедна карактеристика на XPM,
• ваквите видови на проекти не можат целосно да се контролираат,
• промената треба да се прифати, а не да се спротивставува,
• чувството на сигурност се зголемува со олабавување на контролата на проектот.

ИТ проектите може добро да се имплементираат, но често тоа не е така. Студијата на Standish

Group (CHAOS) од 1995 година покажа дека само 16,2% од ИТ проектите биле успешни во
исполнувањето на целите (време и трошоци), додека над 31% од ИТ проектите биле откажани
пред да се завршат. Студијата на Pricewaterhouse Coopers покажа дека комбинираната
половина од сите ИТ проекти не успеваат, а само 2,5% од корпорациите постојано ги
исполнуваат проекциите за опсегот на проектот, времето и трошоците.
Дел од проблемот е поврзан со неможноста да се дефинираат карактеристиките на успешните
ИТ проекти. Критериумите за успех на ИТ проектите често се нејасни и без строги насоки за
успех на проектот. Во 1992 и 2003 година, двајца истражувачи, В. Делон и Е. Меклин,
анализираа неколку претходни студии за ИТ проекти за да ги идентификуваат клучните
индикатори за успех. (DeLone, W.H., McLean, E.R., 1992). Нивните наоди покажуваат дека
најмалку ИТ проектите треба да се оценуваат според шест критериуми (Pinto, J. 2013):

Квалитет на системот: Дизајнерскиот систем за снабдување мора да може да им обезбеди на

клиентите гаранција дека имплементираниот систем ќе работи како што треба. Сите системи
треба да исполнуваат одредени критериуми, така што, на пример, треба да бидат лесни за
употреба и да даваат квалитетни информации.
Квалитет на информации: Информациите генерирани од системот мора да бидат информации
засновани на податоци добиени од корисниците и со доволен квалитет за да бидат ефективни.
Со други зборови, генерираните информации не треба да бараат дополнителни информации и
сортирање на податоци. Корисниците на системот треба да го видат квалитетот на
информациите што ги произведува.
Употреба: Откако ќе се имплементира ИТ систем, тој мора да се користи. Очигледно, секој ИТ
систем е добар како што е во решавањето на проблемите, но исто така се и механизмите за
донесување одлуки и вмрежување. Критериумот за користење ја проценува вистинската
искористеност на системот преку одредување на степенот до кој тој се користи од клиентите.
Задоволство на корисниците: Откако системот ќе биде завршен, тимот мора да го одреди
задоволството на корисниците. Едно од најдобрите прашања при евалуација на ИТ проект е
дали успехот има некаква врска со одредувањето на задоволството на корисниците од
системот. Затоа, на крајот, клиентот е судија и одлучува дали проектот е ефективен. Потребно
е да се постигне одреден степен на задоволство на клиентот од самиот систем и неговиот
резултат, односно од резултатите и ефектите од работата. Исто така, при предавање на ИТ
проекти на клиентите, вообичаено е тие да доживеат почетна конфузија или да имаат
недоразбирање во врска со карактеристиките на финалниот производ. Некои купувачи
намерно ќе се воздржат од безусловно прифаќање на проект, бидејќи се плашат дека откако
ќе го одобрат, ќе ја изгубат можноста да бараат промени или корекции поради очигледни
грешки. Конечно, во зависност од тоа колку блиску проектниот тим комуницирал со клиентот
за време на развојот на проектот, крајниот производ може или не може да биде она што
клиентот всушност го сака. (Пинто, Ј., 2013).
Индивидуално влијание: Сите системи треба да бидат лесни за употреба и да обезбедуваат
квалитетни информации, но, покрај задоволувањето на овие потреби, постои и специфичен
критериум за одредување на корисноста на системот нарачан од клиентот. Дали
донесувањето одлуки е побрзо и попрецизно? Дали системот нуди повеќе информации, дали
е подостапен или полесен за асимилација? Накратко, дали системот вреди за корисниците на
начин на кој им е важен?
Организациско влијание: Конечно, давателот на системот мора да може да утврди дали има
позитивни влијанија низ клиентската организација, т.е. дали има, на пример, колективен или
синергистички ефект врз корпорацијата клиент. Исто така, треба да утврди дали има добро
влијание на системот или дали има финансиски или оперативни метрики што ја покажуваат
ефикасноста или квалитетот на системот.