Как да създадете план за проекта: 7 стъпки и примери

Бент Флайвбьерг проучи 258 проекта в 20 държави в продължение на 70 години. 9 от всеки 10 проекта надхвърлиха бюджета си. Средно разходите надхвърлиха прогнозираните с 28%.

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

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

Това ръководство показва как да изготвите проектен план в седем стъпки, които работят с всеки инструмент. Ще видите и реални примери от областите „Водопад“, „Аджайл“, маркетинг и строителство. Освен това ще разгледате къде всъщност се съхраняват плановете: в електронни таблици, споделени документи и специализирани инструменти за управление на проекти.

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

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

Какво не е планът на проекта

Планът на проекта не е харта на проекта. Хартата одобрява проекта и предоставя правомощия на ръководителя на проекта. Тя отговаря на въпросите „Трябва ли да направим това и кой отговаря за него?“ Планът продължава оттам, където хартата свършва, и отговаря на въпросите „Как, кога, от кого и на каква цена?“

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

5-те фази на плана за проекта

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

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

Защо проектният план е важен?

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

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

Планът е отправна точка, а не готово решение

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

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

Оттук произтичат две правила, върху които е изградена останалата част от това ръководство:

Този подход се занимава с това, което Флайвбьорг нарича „оптимистична предразположеност“: системната тенденция планиращите да подценяват разходите, сроковете и рисковете, докато надценяват ползите. Плановете, изготвени като статични прогнози, наследяват тази предразположеност още от първия ден и никога не я коригират.

Ключови компоненти на плана за проекта

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

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

Как да изготвите план на проекта в 7 стъпки

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

Стъпка 1: Определете целите си и идентифицирайте заинтересованите страни

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

Например, „Преработване на уебсайта“ е задача. „Увеличаване на коефициента на конверсия на страницата с цените с 15% преди третото тримесечие“ е цел, която определя всяко последващо решение.

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

Стъпка 2: Определете обхвата на проекта и крайните резултати

Обхватът е границата. Всичко, което попада в него, получава ресурси и се планира; всичко извън него се отлага или отхвърля изрично. Списъкът с две колони „в обхвата/извън обхвата“ предотвратява двусмислието, което по-късно води до разширяване на обхвата.

Разграничавайте крайните резултати от задачите. Крайният резултат е осезаем продукт, който заинтересованите страни получават: „мигрирана база данни“, „одобрен макет на дизайна“, „публикувана документация за API“. Задачите са работата, необходима за постигането му. Това разграничение е важно, защото заинтересованите страни се интересуват от крайните резултати, а вашият екип – от задачите.

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

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

Стъпка 3: Създайте структура на разбивката на работата

Вземете всеки резултат от Стъпка 2 и го разделите на най-малките задачи, които могат да бъдат индивидуално възложени, оценени и проследени. Тази йерархия – проект -> резултат -> работен пакет -> задача – представлява вашата структура на разбивка на работата (WBS).

Едно полезно правило: ако дадена задача отнема повече от няколко дни, вероятно може да бъде разделена на по-малки части.

WBS е основата за графика и плана за ресурсите. Ако е непълна, всичко по-нататък е ненадеждно. Графикът ви ще бъде неточен, защото сте пропуснали част от работата, а планът ви за ресурсите ще има пропуски.

Ето например как би изглеждало това в ClickUp:

Стъпка 4: Изгответе графика на проекта и основните етапи

Вземете задачите от вашата структура на разбиване на работата (WBS) и ги подредете по последователност: кои задачи зависят от предварителното завършване на други (зависимости) и кои могат да се изпълняват паралелно.

Етапите на проекта отбелязват завършването на основни фази или резултати. Те са контролни точки: „фазата на проектиране е завършена“ или „получено одобрение от UAT“. Използвайте ги, за да създадете естествени точки за преглед със заинтересованите страни. При сложни проекти визуализирайте графика като диаграма на Гант, за да изясните зависимостите и критичния път.

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

Стъпка 5: Разпределете ролите и ресурсите

Присвойте всяка задача от структурата на проекта (WBS) на конкретен отговорник. Споделената отговорност означава липса на отговорност. Разпределянето на ресурсите означава да се потвърди, че назначените лица разполагат с капацитет през предвидения период.

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

Рамката RACI (Отговорен, Отчетен, Консултиран, Информиран) изяснява кой какво прави, без да се налага прекомерно документиране. Ако проектът изисква нов софтуер или външен изпълнител, това се одобрява заедно с плана.

Стъпка 6: Оценете рисковете и планирайте комуникацията

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

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

Стъпка 7: Получете одобрение от заинтересованите страни и определете базова линия

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

Без базова линия няма как да се разграничи легитимна промяна от първоначалното споразумение.

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

Примери за планове на проекти

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

Пример за проектен план по метода „Водопад“

Планът по метода „Водопад“ се изпълнява последователно: изисквания, проектиране, разработване, тестване, внедряване. Всяка фаза завършва с официален етап на одобрение. Заинтересованите страни преглеждат работата и одобряват следващия етап. Нищо не продължава напред, докато предходната фаза не бъде одобрена.

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

Какво го отличава: Пълният обхват се фиксира още на етапа на изискванията. Диаграмата на Гант е основният инструмент, показващ всяка фаза поред. Исканията за промени са формални и скъпи. Моделът „Водопад“ заменя гъвкавостта с предсказуемост.

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

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

Пример за план за гъвкав проект

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

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

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

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

Пропуснете това, ако: заинтересованите страни се нуждаят от предварително определен обхват и краен срок. Гъвкавостта на Agile ви пречи, когато договорът е строг.

Пример за план на проект за маркетингова кампания

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

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

Какво го отличава: Маркетинговите планове включват повече заинтересовани страни, които изразяват мнение, отколкото такива, които имат право да вземат решения. Без ясен работен процес за одобрение всеки материал преминава през пет кръга редакции, а датата на стартиране се отлага. Матрицата RACI тук не е по избор. Тя е това, което гарантира спазването на датата на стартиране.

Другият значителен риск: Каналите се събират на една дата, но всеки от тях има различен срок за изпълнение. Печатните материали се нуждаят от шест седмици. Платените публикации в социалните мрежи – от две. Имейлът – от една. Ако планирате напред от старта на проекта, вместо назад от датата на пускане, каналите с дълъг срок за изпълнение вече са закъснели още от първия ден.

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

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

Пример за план на строителен проект

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

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

Какво го отличава: Графикът е основният риск, а не обхватът. Закъснението в една фаза се отразява на всяка следваща фаза. Ако изграждането на скелета се забави с една седмица, електроинсталацията, водопроводната инсталация и ОВК системата също се изместват. Строителните планове предвиждат резервно време във всяка фаза, а не в края. Защо? Резервното време в края на проекта винаги се изчерпва от етапи, които са закъснели по-рано.

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

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

Не започвайте следващия си проект от нулата. Шаблонът за проектен план на високо ниво на ClickUp ви предоставя готова за употреба структура със статуси на задачите, персонализирани полета за проследяване на одобренията и задачите на екипа, както и пет вградени изгледа, включително времева линия и списък с резултати.

Изтеглете безплатен шаблон

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

Методът определя как ще подредите работата. Инструментът определя дали планът ще оцелее след третата седмица. Имате три възможности.

Електронни таблици (Google Sheets, Excel)

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

Какво работи

Къде се проваля

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

Пропуснете това, ако: Трябва да се координират повече от два екипа или графикът се променя повече от веднъж седмично.

Споделени документи (Google Docs, Notion, Confluence, ClickUp Docs)

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

Какво работи

Къде се проваля

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

Пропуснете това, ако: Искате да видите кой има затруднения с какво днес.

Специализирани инструменти за управление на проекти (ClickUp, Asana, Jira, Monday)

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

Какво работи

Къде се проваля

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

Пропуснете го, ако: Става дума за прост проект с един отговорник, един екип, фиксиран обхват и продължителност под три седмици. Документът е по-бърз вариант.

6 причини, поради които проектният план се проваля

Повечето планове за проекти губят инерция по предвидими причини.

1. Определяне на обхвата толкова широко, че да не може да се откаже

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

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

2. Получаване на оценки от мениджърите

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

Разработчикът, който изпълнява работата, знае къде всъщност се крият пречките. Изградете WBS съвместно, иначе очаквайте преработки.

3. Да запазите целия си резерв за края

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

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

4. Неопределяне на понятието „завършено“

Когато критериите за завършване не са конкретизирани, „завършено“ има различно значение за всеки заинтересован:

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

5. Да оставите плана като прикачен файл към имейл

План, който никой не може да намери, на практика е равносилен на липса на план.

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

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

6. Разглеждане на плана като еднократен документ

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

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

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

Ние не изготвяме планове за проекти в Google Doc и не разчитаме на късмета. Нашите планове се намират в ClickUp, точно до задачите, които описват. По този начин планът никога не остарява.

Документи за обхвата и картата на заинтересованите страни (стъпки 1 и 2)

ClickUp Docs съдържа описанието на обхвата, показателите за успех и таблицата със заинтересованите страни. Тъй като документът се намира в същото работно пространство като задачите, лесно се отговаря на въпроса „това попада ли в обхвата?“. Когато някой предложи промяна, ние го насочваме към същия документ, който спонсорът е одобрил, а не към Google Doc от преди три месеца.

Задачи и подзадачи за WBS (Стъпка 3)

Изглед на Гант за зависимостите и критичния път (Стъпка 4)

Плъзнете линия между задачите в <14>изгледа „Гант“ на ClickUp, за да зададете зависимост. Критичният път е видим и когато дадена задача закъснее, следващите задачи се изместват заедно с нея. Графикът остава реалистичен, без никой да се налага да го преизчислява ръчно. Това е елементът, който най-бързо се проваля в електронната таблица и който оправдава съществуването на инструментите за управление на проекти.

Табла за базовата линия (Стъпка 7)

След като спонсорът одобри плана, таблата за управление на ClickUp извличат данни в реално време за степента на изпълнение, просрочените задачи и натоварването. Отговорът на въпроса „Къде сме?“ идва от същите данни, върху които работи екипът, а не от паралелен документ за състоянието на проекта. Заинтересованите страни проверяват таблото за управление, вместо да искат среща за обсъждане на състоянието на проекта.

Когато ClickUp не е подходящият избор

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

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

Изгответе проектен план, който вашият екип ще използва

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

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

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

Регистрирайте се в ClickUp още днес!

Често задавани въпроси относно плановете за проекти

Каква е разликата между план на проекта и план за управление на проекта?

Планът на проекта се фокусира върху конкретните резултати, графика и ресурсите за един отделен проект. Планът за управление на проекта (термин на PMI) е по-широк и включва подпланове за управление на промените, риска, комуникацията и доставките, които определят начина, по който се управлява проектът. За повечето екипи извън официалните среди на PMI терминът „план на проекта“ обхваща и двете.

Може ли да се изготви план за проекта без софтуер за управление на проекти?

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

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

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

Кой отговаря за изготвянето на плана на проекта?

Проектният мениджър отговаря за плана, но не трябва да го изготвя сам. Експертите по темата предоставят оценки за задачите, спонсорът одобрява обхвата и бюджета, а участниците потвърждават зависимостите. Плановете, изготвени по метода „отгоре-надолу“ без участието на хората, които извършват работата, системно подценяват усилията – тенденция, която изследванията на Бент Флайвбьорг са документирали в хиляди проекти.

Каква е разликата между план на проекта и график на проекта?

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

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

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