Съдържание на статията
Управлението на времето – ключ за успешната реализация на проекта
стр.2 - Сроковете. Как да построяваме план на проекта (Гант диаграма)във времето?
стр.3 - Критичен път на проекта.Какво трябва да да следим по време на изпълнение на проекта?
Всички страници

Ежедневното координиране и синхронизиране на дейностите е важен аспект от управлението на проекта, който обаче често се игнорира. Прилагането на някои изпитани подходи дава възможност на ръководителите да преценят по-лесно и по-точно кога и какви усилия ще са нужни, кои задачи могат да бъдат отлагани и кои не .

Управлението на проекти често се разбира само като планиране на ресурсите и отчитане на резултатите. Тези две фази наистина са много важни – с тях започва и завършва всеки проект. Доброто планиране позволява да представим проекта на инвеститора, да го заинтересуваме и убедим да се ангажира с него. Коректното и изчерпателно отчитане на резултатите е ключово за запазването на интереса към проекта. Но между тези две фази има още една – ежедневното координиране и синхронизиране на дейностите по проекта. Често знанията на българските ръководители на проекти в тази област съществено отстъпват спрямо другите две.

В много случаи за “управлението на времето” се прилага следния подход: „Ей-й-й, ние имаме етап другата седмица! Иванов, ти знаеш ли, че имаш да предаваш етап?“. След „успешното предаване“ на етапа се прави кратко събрание, обсъжда се кой какво трябва да прави оттук нататък и нещата замират до следващия път. По повод на подобна ситуация един консултант заяви: „Научихме се да печелим проекти, но след това често ги губим, защото не можем да ги координираме“.

Отразяване на времевите зависимости

Управлението на проекта е игра във времето. Тя започва със създаването на тъй наречената мрежова диаграма (network diagram) - това предполага разбиване на цялата дейност по проекта на отделни задачи, определяне на срокове и задаване на зависимости между задачите.

Отделен проблем е детайлността на разбиването по задачи. Можем да подготвим изключително „фин“ план с детайлно описание на всяка малка задача, а можем също да планираме „на едро“ - обобщени задачи, обхващащи серия от малки подзадачи. И двата подхода имат своето място в зависимост от конкретния проект, квалификацията на участниците и взаимното доверие между ръководителя и изпълнителите.

На фигура 1 е представена примерна мрежова диаграма. Стрелките между задачите означават зависимости във времето – задача Т2 трябва да започне след като Т1 е приключила; Т5 трябва да изчака приключването на Т2, Т4 и Т6. Зависимостите във времето могат да бъдат от различен тип.

 

 

Например:

  • „край-начало“ - това е най-разпространената зависимост. При нея една задача изчаква завършването на една или няколко предхождащи я задачи. Този тип зависимост се използва, когато по-късната задача (наричана още „зависима задача“ - „dependent task“) се нуждае от резултатите, получени при изпълнението на предхождащите задачи;

  • „начало-начало“– при този тип зависимост започването на една задача автоматично стартира друга;

  • „начало-край“– ако започне изпълнението на една задача работата по друга (или други) задачи спира;

  • „край-край“– ако бъде прекратена една задача, спира и работата по други, например ако една фирма спре предлагането на дадена стока или услуга, рекламирането й също трябва да спре.

Последните два типа зависимости се срещат доста по-рядко, отколкото първите два.
Създаването на мрежова диаграма, отразяваща мрежовите зависимости има не само „академично“ значение. Непосредствената практическа полза от нея се проявява при създаването на Гант диаграмата на проекта, която също ще разгледаме. Освен това, самата структура на диаграмата ни дава информация колко трудно (или лесно) ще бъде координирането на проекта. По принцип, колкото повече задачите зависят от повече от една предходна задача, толкова по-трудна е координацията. Например за да стартира задача Т5 от фигура 1 трябва да координираме изпълнението на Т2, Т4 и Т6. Обратно, ако една задача стартира няколко други като например Т1, координацията не е проблем.

Така мрежовата диаграма ни дава визуална представа къде трябва да съсредоточим усилията си и къде задачите ще се координират повече или по-малко автоматично. Има няколко „крайни“ типа мрежови диаграми:

  • Тип „I“: поредица от последователни задачи – най-лесният тип за управление – просто следим, когато свърши текущата задача, следващата да започне;

  • Тип „V“: в началото на проекта има една, или няколко последователни задачи, после диаграмата се разклонява в два или повече клона. Проект с такава диаграма е също лесен за координиране, защото задачите не зависят от няколко предишни;

  • Тип „Т“: производен на „V“ - почти до края задачите образуват верига, а в края се разклоняват в няколко къси поредици;

  • Тип „обърнато Т“: в началото се изискват няколко едновременни подготвителни дейности и после задачите вървят последователно. Необходими са координационни усилия в началото, за да може да тръгне успешно стълбчето на обърнатото „Т“. Този тип се среща най-често в производството, свързано с асемблиране от готови елементи, както и в сферата на услугите;

  • Тип "ламбда" (или „А“): това са най-трудните за координиране проекти, особено във варианта „рибена кост“ („fishing bone“). Няколко поредици задачи се вливат в основната поредица. Необходимо е внимателно координиране във всяка точка на вливане. Проекти с такава диаграма най-често се срещат в производството.

Разбира се, можем да наблюдаваме различни комбинации на основните типове диаграми. Например често срещана е мрежовата диаграма от тип „диамант“ („diamond“). Реалните проекти изключително рядко могат да бъдат вписани в схема от “чист” тип. По-скоро различните етапи на проекта „приличат“ на различни базови типове. Все пак, познавайки мрежовите диаграми и техниките за тяхното използване ръководителите на проекти могат по-лесно да преценят кога какви усилия ще са нужни за координиране на дейностите.


Сроковете

Задаването на срокове за изпълнение на всяка задача е друга важна характеристика на мрежовата диаграма. Преди да направим това ние разполагаме само с графика на логическите зависимости между задачите. Поставянето на срокове за изпълнение ни позволява да представим мрежовата диаграма върху оста на времето.

Самото определяне на реалистични срокове е „деликатна задача“, с много особености, повечето от които изобщо не са свързани с конкретната дейност, а по-скоро са в сферата на човешкото поведение. Тези аспекти са извън обхвата на настоящата статия. Да предположим все пак, че по някакъв начин сме определили сроковете на задачите (например по 5 дни за всяка от тях). Така вече можем да създадем диаграмата на Гант (Gantt graph) за нашия проект.

Неслучайно голяма част от мениджърите започват и завършват координирането на проекта с Гант диаграма. Това средство действително осигурява много информация за последващото координиране на проекта – кои дейности да следим отблизо, кои можем да не наблюдаваме, кои срокове са критични и кои не, как можем да разместваме дейностите във времето (например при недостиг на хора и ресурси) и как това ще повлияе на общото изпълнение на проекта. С други думи, Гант диаграмата е не просто картинка, с която да бъде впечатлени инвеститорите, а работен инструмент за ежедневното управление на дейностите. Ако сме в състояние да извличаме скритата в нея информация, можем силно да опростим координирането на проекта.

Как построяваме план на проекта (т.е. Гант диаграма) във времето?

Можем да постъпим по следния начин - определяме началната дата на проекта и планираме първата задача (или първите няколко). Планираме всички зависими задачи да започнат веднага след като тези които ги предшестват приключат и така до края на проекта. Така получаваме план, който е максимално сгъстен наляво по оста на времето. На фигура 2а е представена такава схема на нашия примерен проект. Това всъщност е обичайният начин на планиране, който изглежда най-естествен. Началните дати на задачите, получени по този начин се наричат най-ранни стартове (early start) на задачите.

 

 

Но този подход не е единственият възможен. Можем да постъпим точно обратно. Започвайки от датата на завършване на проекта се движим назад във времето: позиционираме във времето последните задачи така, че да завършват в последния ден от определения срок. След това последователно поставяме техните предшественици пред тях и така до началото на проекта. По този начин получаваме най-късните стартове на задачите (late start) – т.е. най-късните дати, на които задачите трябва да започват за да не закъснее проекта. При този подход задачите започват максимално късно във времето (на Фигура 2b се променят Т2, Т6 и Т7).

На пръв поглед, схемата с максимално късен старт няма практически смисъл, но това не е така. Ето няколко случая, в които късният старт е за предпочитане:

  • Ресурсоемки дейности. Представете си, например, че една задача изисква много финансови ресурси. Тя може да бъде започната сега или след 3 месеца и изпълнението й трае 1 месец. Кога предпочитате да я започнете? Ако я започнете сега ще „затворите“ парите си веднага, а полученият резултат ще ви трябва чак след четири месеца – не е много изгодно, нали?

  • Резултатът от изпълнението на задачата може да “остарее” докато се наложи да бъде използван. Класически „жив“ пример са държавните търгове за информационни системи: хардуерът се закупува в първите 1-3 месеца, после 2-3 години се разработва софтуерът, който ще работи върху него.

  • Изпълнението на задачата зависи от някакъв външен променлив фактор. Например ако има вероятност клиентът да промени изискванията си (нещо, което става много по-често, отколкото ни се иска!), а сме избързали със започването на работата, реална е опасността да пропилеем ресурси за преработване на част от създаденото.

Основен недостатък на планирането с късен старт е, че всяко закъснение, независимо в коя задача се появи, води до закъснение на целия проект. Затова то практически никога не се прилага в чист вид. Използва се или само за отделни задачи, или в комбинация с други методи (различни видове буфериране на плана), които рязко снижават опасността от закъснения.


Критичен път на проекта

Ако се вгледаме в двете диаграми на фигура 2, ще забележим, че има задачи, за които ранният и късният старт съвпадат. Това са задачите T1, T3, T4, T5 и T8 (отбелязани са с по-тъмен цвят). Такива задачи се наричат критични. Всяко закъснение в тяхното изпълнение води до общо закъснение на проекта.

Може да се докаже, че във всяка мрежова диаграма, която не съдържа цикли, съществува път от началото до края на проекта съставен само от критични задачи. Този път се нарича „критичен път на проекта“. Това е най-дългата по време верига от взаимно зависими задачи. Продължителността на проекта е равна на сумата от сроковете на задачите от критичния му път. Всяко закъснение на задача от критичния път влече след себе си общо закъснение на проекта.

Тук трябва да направим едно важно уточнение. Задачите от критичния път се определят от мрежовата диаграма. Те не са непременно най-важните задачи по други критерии. Например, ако организирате семинар за който компетентният лектор е известен професор най-критичната задача е да го убедите да дойде – иначе няма да има семинар, но тази задача може да не е на критичния път (например, това може да бъде задача Т6). Дори се препоръчва най-критичните за успеха задачи да се планират така, че да стоят извън критичния път.

От друга страна, задачите, които не са на критичния път имат определен времеви резерв (float или slack). Да разгледаме например задача Т2 от фиг. 2а. Ако тя закъснее например с 2 дни, това няма да се отрази на проекта по никакъв начин, защото следващата задача Т5 и без това трябва да изчака завършването на поредицата T3+T4, която е по-дъга по време. Т2 има свободен резерв от време (free float) от 5 дни. Този резерв се определя от времето, с което може да бъде забавено изпълнението на една задача без това да доведе до закъснение на която и да било друга задача от проекта.

Освен свободния резерв се дефинира и „пълен резерв“ (total float) – времето, с което една задача може да закъснее без това да доведе до общо закъснение на проекта. Пълният резерв е равен на разликата във времената за най-ранен и най-късен старт.

Какво трябва да да следим по време на изпълнение на проекта?

След всички разгледани инструменти и подходи стигаме до този чисто практически въпрос. Синтезираният отговор е:
  • на първо място, всички задачи от критичния път. Всяка дейност, която стои на критичния път трябва да получава автоматично зелена светлина и пълно ресурсно обезпечаване. Закъснението по критичния път може да се навакса само от останалите задачи по критичния път закъснения в задачите извън критичния път не са опасни докато са в рамките на свободния им резерв, но в никой случай не трябва да надвишават пълния резерв.

  • можем да спокойно отлагаме началото на задачи извън критичния път в рамките на техния свободен резерв и с по-голям риск – в рамките на пълния им резерв

всяко синхронизиране на две или повече задачи изисква нашето внимание, особено ако става дума за част от критичния път (както това е при задача Т5).

Валентина Николова

Виж оригинала