Вече установихме, че класическите методи за планиране и управление на строителни проекти не са ефективни. Сега трябва да си зададем въпроса: „Какво искаме да променим?“
1. Проектите често надхвърлят времето, определено в графика.
2. Често проектите прехвърлят бюджета.
3. Често в проектите се правят компромиси относно обхвата, времето и бюджета.
4. В многопроектните компании често има борба за ресурс.
5. Продължителността за изпълнение се увеличава.
6. Правят се много промени.
7. Много проекти са отменени преди да са били завършени.
8. Работата по проекти е стресираща.
Ние търсим решение, което ще се справи с всички тези нежелани ефекти. Нека да започнем с най-важното: „Каква е целта на вече стартирал проект?“. Целта на един стартирал проект е да бъде завършен колкото се може по-рано. За да имаме изпълнен навреме проект, ние трябва да изпълним в срок всяка задача от проекта. За да изпълним всички задачи навреме, ние трябва така да ги планираме, че във всяка задача да е включен запас от време, защото знаем, че при изпълнението има несигурност. Дори когато проектният мениджър пита за необходимото време за изпълнение на дадена задача, той очаква да получи като отговор времето плюс защитен времеви буфер. 
Проектните мениджъри, като цяло са съгласни техните бригадири и работници да предават задачите си изпълнени в зададения срок, т.е. те имат поставена крайна дата. Хората приемат, че в техните организации, ако някой работник приключи задача навреме, е оценен като добър работник, а ако закъснее, ще бъде окачествен като лош. 
Върху всеки проектен мениджър има голям натиск, той така да планира проекта, че да бъде завършен колкото се може по-бързо. Всички знаят, че по-кратките срокове ще ни намалят оперативните разходите и ще имаме по-добра оферта или по-малка инвестиция. Поради тези причини проектният мениджър трябва да планира така, че да има най-краткия възможен критичен път. За да постигне този кратък път, той трябва да заложи минимални буфери или дори никакви в задачите. Тогава как ще се справи с несигурността, която задължително съществува при тези проекти? Ето, имаме първия конфликт: „Да залагаме ли запас във времето на задачата или не?“. Това всъщност е основният конфликт, който води до редица други конфликти и нежелани ефекти. Ако той не е решен в ситуация „аз печеля - ти печелиш“, той ще носи разрушаващи последствия след себе си.
Колко често работниците приключват задачите си по-рано? Голяма част от задачите се изпълняват точно навреме; 80% се издават точно на крайната дата. Не ви ли се струва странно? Оказва се, че те са били готови по-рано, но не са съобщили на никого. Това явление се нарича Закон на Паркинсон. Потенциалните причини за неизползването на малките позитивни вариации са:
1. Хората работят стриктно към зададените крайни дати и не разбират ползите от предаването на завършените задачи по-рано.
2. Работата се разтяга в срока, за да заеме всичкото време и бюджет.
3. Има вярване, че следващият ресурс няма да е готов за работа по задачата.
4. Има глоби за закъсняване, а няма награди за приключване по-рано.
Става така, че дори да приключат по-рано, никой няма да съобщи. Това е вторият конфликт: „Да приключа ли по-рано задачата си или не?“
Тук трябва да споменем и Синдрома на студента - тъй като знаем, че имаме добавено защитно време, в началото на периода имаме малък ентусиазъм да работим по задачата, но той бързо приключва. След това известно време нищо не правим по проекта и когато наближи крайният срок, усилията ни стигат своя връх. Предполагам, че и адреналинът е на високо ниво тогава. Когато попитах един проектен мениджър дали в тяхната компания се проявява синдромът на студента, той ми каза, че те са го измислили този синдром.
Друг проблем, който пречи на работата, е многозадачността. Ако някой работник работи по задача 1 и преди да я е завършил бригадирът му нареди да започне работа по задача 2, после по задача 3 и след това да се върне на 1, това се нарича лоша многозадачност. Ако всяка задача изисква 1 час и времето да се подготви за смяна между задачите е 15 минути, то при многозадачност времето за изпълнение на трите задачи ще е 255 минути, вместо 210 минути, ако ги изпълнява последователно.
Това води до следващия конфликт: „Да приемам ли нови задачи, защото съм лоялен работник или да не приемам, за да успея да си изпълня ангажимента?“.
Нашето решение за управление и планиране на проектите трябва да може да се справи с тези конфликти. Основният конфликт води до едно заключение, което още Деминг е постулирал: „Ако всички части на системата работят добре, това не означава, че цялата система е ефективна“. Основният конфликт води до win-lose ситуации между работниците и проектния мениджър.
Каква искаме да е промяната?
1. Проектите винаги да приключват навреме или по-рано.
2. Проектите да изпълняват бюджета или да са под него.
3. Проектите винаги да бъдат предавани в пълен обхват.
4. Проектите да имат много малки промени.
5. Проектите да получават нужните ресурси без вътрешни борби.
6. Продължителността да става все по-кратка.
7. Всички проекти да се изпълняват.
8. Работата по проект да осигурява win-win решения.
Една от стъпките, които трябва да предприемете, е да концентрирате несигурността от няколко задачи от проекта и да я поставите в края. Нека този буфер да го наречем проектен буфер. Имаме четири задачи А, B, C и D. Всяка отнема 1 час, но всеки ресурс е заложил още 1 час буфер, в края на задачата. В голяма част от задачите хората включват 100% запас. Общо време 8 часа.
Първата стъпка е да намалим времето на задачите наполовина. Общо време 4 часа.
В този случай обаче нямаме никаква защита от несигурност. Ние не живеем в идеален свят и знаем, че несигурността е част от живота и трябва да се защитим. Трябва да добавим защитни буфери, но не искаме те да са включени към всяка задача, а да са накрая. Друго, което искаме, е този буфер да е малък. Има различни методи за изчисляване на размера на буфера. Единият се нарича 50%, т.е. вземаме цялата дължина и я делим на две. Следователно проектният буфер е равен на 2 часа. Общото време става 6 часа.
В следващия брой ще разгледаме другите видове буфери, които защитават пътищата различни от Критичната Верига.
Успех на всички! 
Използван източник:
Leach, L. 2005. „Critical Chain Project Management“
https://vladyvelikov.wordpress.com/