Управление на проекти: традиционно, итеративно или хибридно?

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

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

Накратко, итеративните техники за разработка планират, разработват и внедряват функционалност на проекта на малки части (или итерации). Ключът към успешно итеративно изпълнение е всяка малка част на практика да работи като по-малък минипроект в рамките на целия проект. В резултат на това всяка итерация на минипроект може по-добре да планира усилията, необходими за изпълнение на двуседмична итерация, вместо на двугодишен план. Освен това, тъй като планираме на двуседмични стъпки, можем лесно да адаптираме плана за следващите две седмици, за да отчетем всички идентифицирани промени.

Казус: гъвкав срещу традиционен

Искам за кратко да спра и да опиша една нетехническа ситуация, в която беше постигнат по-голям успех с гъвкав подход, отколкото с традиционен план.

Нека използваме пример с планиране на дейностите за един пълен ден – това е проектът. Подобно на голям проект, тук има много несигурност и риск – не знаем какво ще се случи след обяд, което може да повлияе на плана ни, но традицията изисква да разработим изчерпателен план за това какво ще правим всеки час от деня – от събуждането в 6:00 ч. сутринта до лягането в 23:00 ч.

В 9:00 сме извън график, защото трафикът забави отиването ни на работа; в 10:00 сме повикани на спешна среща; а към обяд единствената изпълнена ежедневна задача е стигането до офиса и дори това е със закъснение.

Сега нека го разгледаме като гъвкав проект, при който планираме само следващата итерация: подготовката за излизане от дома (тоест истории са: душ, закуска и децата да тръгнат за училище). Всичко това беше успешно изпълнено навреме и в рамките на бюджета.

Така, с увереност, планираме следващата итерация, която е да стигнем до офиса (с кола до автогарата, влак за пътуващи до гарата и след това градски автобус до офиса).

Това не се изпълнява много добре: първата история (с кола до автогарата) има проблеми с трафика, затова променяме потребителската история да се кара до офиса и се съгласяваме, че другите две истории могат да бъдат премахнати от плана на итерацията. При пристигане планираме следващата итерация. Но в средата на цикъла на планиране се добавя нова история (спешната среща) и тя ще отнеме цялата следваща итерация.

Накрая, след обяда, нещата се успокояват и успяваме да прегледаме списъка с нерешени задачи и да започнем с тези с най-висок приоритет; през следобеда успешно завършваме две итерации, посветени на задачите с най-висок приоритет.

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

Кой е най-добрият подход – гъвкав, традиционен или хибриден?

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

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

В резултат на това много организации се затрудняват как да запазят някои ключови „традиционни процеси“, като същевременно се адаптират към итеративни методи. Отговорът е хибриден модел на доставка. Части от проекта могат да бъдат изпълнени с традиционни методи на управление, а други – итеративно.

Хибриден модел на доставка

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

В този модел разработвам традиционна йерархична структура на работата, базирана на резултатите (WBS), която определя основните резултати, необходими в организацията за одобрение на проекта, като Project Charter, Project Management Plan и Project Budget.

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

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

По всяко време, често дори ежедневно, продуктовият собственик може да добавя, изтрива и променя задачите в списъка с нерешени задачи, за да отрази променящите се бизнес нужди.

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

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

Ключ към гъвкавите принципи е възможността крайнето решение да се внедрява на малки версии. Това има предимството да можете да използвате предварителната функционалност, за да постигнете някои от очакваните бизнес ползи възможно най-бързо.

Освен това това има предимството на ранна валидация на решението, така че евентуалните корекции могат лесно да бъдат отчетени в останалите задачи от списъка с задачи за продукта. Затова, щом в итерациите бъдат завършени достатъчно истории с висок приоритет, проектът би преминал обратно към традиционен цикъл и би изпълнил стандартните дейности по внедряване, изисквани от организацията.

Изпробвайте Microsoft Project безплатно

Изпробвайте Microsoft Project (план 3) безплатно за един месец

Научете как

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

След като първото издание бъде завършено, проектът се връща към гъвкави подходи и започва да преминава през поредна последователност от итерации, за да продължи разработката на останалите истории.

Въпреки че този „поетапен“ подход за комбиниране на гъвкави и традиционни подходи е най-разпространен, можете да комбинирате подходи, за да поддържате конкретни изисквания за изпълнение на проекта. Например, ръководех проект, който изискваше изключително високо ниво на съответствие и валидация, докато внедрявахме нов продукт в много силно регулирана индустрия. Затова по-голямата част от проекта ми беше планирана и управлявана с традиционни методи.

Но имаше част от проекта за бизнес анализи, в която моята компания анализираше огромното количество данни за производителност, които системата генерираше; тази част беше най-добре подкрепена с гъвкав подход. За BI компонента на проекта (който се изпълнява паралелно с традиционната работа) бихме избрали историите с най-висок приоритет – тези, които могат да бъдат завършени в триседмичен спринт – и бихме завършили една итерация.

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

С този подход имах единен график на проекта, който гарантираше, че изпълнявам всички изисквани стъпки за отчетност и нормативно съответствие, като същевременно позволяваше изключително гъвкав подход към разработването на нерегулирания компонент за бизнес отчетност на проекта.

Когато цялата работа е в един график, това осигуряваше единен поглед върху всичко, което се случваше в този проект:

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

Възможността да се създават мощни седмични и месечни отчети за състоянието беше под ръка

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

Ключът е да се възприемат гъвкавите принципи, които ще помогнат на вашата организация да постигне успех в изпълнението, като същевременно спазва традиционните процеси, които са помогнали на вашата организация да бъде успешна досега.

Стив Кейсли има над 35 години опит в Microsoft Project и е активен потребител на Microsoft Project от първата му версия. Той е редактор на няколко книги, свързани с Microsoft Project и най-добрите практики в управлението на проекти. Той е главен консултант в Sensei Project Solutions, където помага на големи организации да постигат съвършенство в изпълнението на проекти, като използва набора от инструменти Microsoft Project Portfolio Management (PPM).

СВЪРЗАНИ ПРОДУКТИ
Office 365

Първи стъпки с Microsoft 365

Това е Office, който познавате, плюс инструментите, които да ви помагат да работите по-добре заедно, така че да можете да свършите повече работа – по всяко време и от всяко място.

Купете сега

Свързано съдържание

Управление на моята фирма

Защо ръководителите мразят ръководителите на проекти?

Прочетете повече

„Бизнес прозрения и идеи“ не представляват професионални съвети в областта на данъчното облагане или финансите. Трябва да се свържете със собствения си данъчен или финансов специалист, за да обсъдите ситуацията си.