Project Management · 2026-05-09
Видове проекти в управлението на проекти: Продукт (Deliverable-Based) срещу Резултат (Results-Based)
Има два вида проекти в управлението на проекти — и повечето PM-ове никога не спират да попитат кой управляват. Ето разграничението между проекти тип Продукт (Deliverable-Based) и проекти тип Резултат (Results-Based) — и въпросът, който прорязва всичко.
Бил ли си в проект, в който всичко вървеше добре — изпълнени milestone-и, доставящ екип, информирани заинтересовани страни — и въпреки това нещо не беше наред?
Не с работата. Работата беше наред. Но онова натрапчиво усещане продължаваше да идва: когато приключим, аплодисментите няма да дойдат. Спонсорът няма да е доволен.
Бил съм там. Повечето опитни PM-ове са. И дълго не можех напълно да обясня защо се случва. Проектът беше доставен. Какво друго очакваха?
Оказа се — всичко.
Нека вдигна завесата на нещо, което не получава достатъчно внимание: има два фундаментално различни вида проекти в управлението на проекти — и те изискват напълно различни подходи.
Тип 1: Проекти тип Продукт (Deliverable-Based)
Този тип изглежда честен. Дори изчистен.
Знаеш какво строиш, строиш го и когато е готово — готово е. Нова офис сграда. Пътен участък. Внедряване на ERP система. Събитие за лансиране на продукт. Финишната линия е осезаема и видима. Бинарна, всъщност: или нещото съществува, или не.
Светът на PM-а тук е познат и управляем. Управляваш обхват, бюджет и времева линия. Следиш milestone-ите. Провеждаш статус срещи. Решаваш блокери. Тласкаш към финално приемане — подпис, сертификат, go-live.
Въпросите, които движат седмицата ти са: По план ли сме? Качеството правилно ли е? Обхватът разширява ли се? Ще спазим ли крайния срок?
Рисковете живеят предимно вътре в проекта. Забавен доставчик, технически блокер, промяна на обхвата — това са неща, с които добрият PM екип може да се справи.
Има определена увереност в този тип проект. Когато върви добре, го усещаш. Екипът доставя, планът се спазва и финишната линия се приближава. Просто се усеща правилно.
Тип 2: Проекти тип Резултат (Results-Based)
Този е различен. Фундаментално различен.
Не обещаваш продукт (deliverable). Обещаваш промяна. Бизнес резултат (result). Промяна в реалността, която надхвърля далеч това, което екипът ти физически произвежда.
Подобряване на удовлетвореността на клиентите. Растеж на пазара. Иновации. Ефективност на процесите. Културна трансформация. Това са резултати (results), които зависят не само от това, което екипът ти прави — но и от това как организацията го усвоява, как пазарът реагира, как хората променят поведението си.
Светът на PM-а става значително по-объркан. Финишната линия не е подпис — тя е число на табло, шест месеца от сега. Рисковете живеят в пазарните условия, в човешкото поведение, в организационната култура, в решения на хора, които дори не са в екипа ти.
Въпросите звучат различно: Решаваме ли правилния проблем? Ще променят ли хората реално начина си на работа? Измерваме ли правилните неща? Онова, което строим, свързва ли се с това как изглежда реалният резултат (result)?
И има различен вид натиск. Всичко може да изглежда зелено на плана ти — и въпреки това онова натрапчиво усещане се появява. Защото знаеш: твоят продукт (deliverable) е само входящ параметър. Онова, което се случва след това — това наблюдават те всъщност.
Примерите Казват Всичко
Ето бърз поглед към това как един и същи проект може да носи едновременно и двата вида очаквания:
Внедряване на ERP: PM доставя продукта (deliverable) → система на живо, данните мигрирани, потребителите обучени. Бизнесът очаква резултата (result) → по-ниски оперативни разходи, по-бързо отчитане, по-малко грешки. Нова офис сграда: PM доставя продукта → сграда завършена, в спецификация и бюджет. Бизнесът очаква резултата → подобрено сътрудничество в екипа, привличане на таланти, намалено текучество. Редизайн на обслужването: PM доставя продукта → нов процес документиран, екипът преобучен, инструментите внедрени. Бизнесът очаква резултата → подобрение на CSAT, по-бързо разрешаване, по-малко ескалации.
Виждаш ли модела? Лявата страна е продуктът (deliverable) — онова, което PM екипът строи. Дясната страна е резултатът (result) — онова, което бизнесът очаква. Те не са винаги едно и също — и пропастта между тях е мястото, където проектите се объркват.
Историята, която Иска ми Беше Разказана По-Рано
След придобиване на компания, ръководех част от по-голям интеграционен проект. Едното направление беше да се внедри ERP системата на дружеството-майка в новопридобитото — пълна миграция на данни, процеси и екипи.
Класически проект тип Продукт (Deliverable-Based), помислих. И беше. Работихме усилено и доставихме продукта. Системата влезе на живо. Беше отпразнувано.
Няколко месеца по-късно жалбите започнаха да пристигат. Оперативните мениджъри бяха недоволни. Висшето ръководство задаваше неудобни въпроси. Очакваните резултати (results) по отношение на ефективността не се материализираха.
Ето честата истина: никой изрично не е казал, че проектът е отговорен за ефективността. Обхватът беше внедряването — продуктът (deliverable). Ние го внедрихме.
Но бизнес очакването — онова, което висшите реално ценяха — никога не е било за ERP-то като продукт. Ставаше дума за резултата (result), който ERP-то трябваше да отключи: по-добри операции, по-ниски разходи, по-умни процеси. Доставихме превозното средство. Те чакаха дестинацията.
Несъответствието — и Клопката за PM-овете
Това е пропастта, която хваща добрите проектни мениджъри неподготвени. Проектът е описан около осезаемия продукт (deliverable). Но очакванията на спонсора — изречени или неизречени — живеят изцяло на ниво резултат (result). До момента, в който несъответствието се появи, проектът е приключил.
Важното за разбиране е следното: резултатът (result) и целта на проекта идват от бизнес стратегията и от вземащите решения — не от PM-а. Ти не измисляш критерии за успех. Те ги измислят.
Но ти си отговорен за това да ги направиш видими, изрични и договорени. Дори когато висшите не са ги артикулирали напълно. Дори когато никой не те пита. Особено тогава.
Защото ако не го направиш, ще се окажеш в моята ERP ситуация. Доставяш точно продукта (deliverable), който е поискан — а организацията е очаквала съвсем различен резултат (result).
Най-Добрият Въпрос, Който Можеш да Зададеш
"Как изглежда успехът за вас?"
Не "какъв е продуктът (deliverable)". Не "какъв е крайният срок". Как изглежда успехът — за теб, за бизнеса, за хората, които ще го оценяват когато е готово?
Отговорът казва всичко.
Ако кажат: "Напълно построена, сертифицирана сграда, доставена до Q4" — в ясна продуктова (deliverable-based) територия си. Знаеш финишната си линия.
Ако кажат: "Ами... трябва придобиването да генерира 20% подобрение на ефективността в рамките на 18 месеца" — спри. Това е очакване за резултат (result), облечено като продуктов (deliverable-based) проект. И сега имаш много по-важен разговор да проведеш, преди да е зададена и единна задача.
Това не е за избягване на отговорност. Става дума за създаването на правилния вид отговорност — такава, която е честна относно онова, което проектът може директно да контролира (продукта), и онова, което зависи от по-широкия бизнес контекст около него (резултата).
Съвети от Практиката
1. Знай в кой тип проект се намираш — тип Продукт (Deliverable-Based) или тип Резултат (Results-Based). Това оформя всичко — как планираш, как комуникираш, как измерваш напредъка и как управляваш спонсора.
2. Разбери го в самото начало. Колкото по-късно се проведе този разговор, толкова по-скъпо излиза несъответствието между продукт и резултат.
3. Питай "Как изглежда успехът?" — и настоявай докато получиш реален отговор. Неясните отговори са предупредителен знак. Там живеят скритите очаквания за резултат (result).
4. Задай правилните метрики за успех заедно с заинтересованите страни. Не само продуктови метрики (навреме, в бюджет, в обхват) — но и бизнес метрики за резултата там, където е уместно. Направи ги изрични. Запиши ги.
5. Постигни съгласие за настройката на проекта, не само за плана. Всички трябва да се съгласят за какво проектът е — и не е — отговорен: продуктът (deliverable) или резултатът (result). Този разговор защитава всички.
В реалността много проекти носят и двата типа едновременно. Строителен проект е изчистена работа тип Продукт — докато спонсорът не спомене 30% ROI за пет години. Внедряване на ERP е go-live (продукт) — докато не се очаква и трансформация на операциите (резултат). Знанието кой тип управляваш — и правенето му изрично — е едно от най-важните неща, които PM-ът може да направи преди да е зададена и единна задача.