Skip to main content
LibreTexts - Ukrayinska

1.18: Завершення проекту

  • Page ID
    16983
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)

    Кожен проект повинен закінчитися, і саме про це йде завершення проекту на останній фазі життєвого циклу проекту. Вся суть проекту полягає в тому, щоб доставити те, що ви обіцяли. Доставляючи все, що ви сказали, ви переконуєтеся, що всі зацікавлені сторони задоволені і всі критерії прийняття були дотримані. Як тільки це станеться, ваш проект може закінчитися.

    Завершення проекту часто є найбільш запущеним етапом життєвого циклу проекту. Як тільки проект закінчиться, легко упакувати речі, кинути деякі файли в ящик і почати рухатися прямо в фазу ініціації наступного проекту. Тримайтеся. Ти ще не закінчив.

    Ключовими видами діяльності в завершенні проекту є збір записів проекту; поширення інформації для формалізації прийняття продукту, послуги або проекту; і виконання закриття проекту. Як керівник проекту, вам потрібно буде переглянути проектні документи, щоб переконатися, що вони актуальні. Наприклад, можливо, були реалізовані деякі запити на зміну обсягу, які змінили деякі характеристики кінцевого продукту. Інформація про проект, яку ви збираєте на цьому етапі, повинна відображати характеристики та технічні характеристики кінцевого продукту. Не забудьте також оновити призначення ресурсів. Деякі члени команди прийдуть і пройдуть хід проекту. Потрібно ще раз перевірити, що всі ресурси і їх ролі та обов'язки відзначені.

    Після того, як результати проекту будуть задокументовані, ви запитаєте офіційне прийняття від зацікавлених сторін або замовника. Вони зацікавлені в тому, щоб знати, чи продукт або послуга проекту відповідає цілям проекту, поставленим для виконання. Якщо ваша документація актуальна, ви будете мати під рукою результати проекту, щоб поділитися з ними.

    Закриття контракту

    Контракти завершуються так само, як проекти закінчуються. Закриття контракту стосується завершення та врегулювання умов договорів, орендованих для проекту. Він підтримує процес завершення проекту, оскільки процес закриття контракту визначає, чи виконана робота, описана в контрактах, точно та задовільно. Майте на увазі, що не всі проекти виконуються за контрактом, тому не всі проекти вимагають процесу закриття контракту. Очевидно, що цей процес стосується лише тих етапів, результатів або частин проекту, які були виконані за контрактом.

    Закриття контракту оновлює записи проекту, деталізуючи кінцеві результати роботи над проектом. Контракти можуть мати конкретні терміни або умови для завершення. Ви повинні знати про ці умови, щоб завершення проекту не затримувалося, оскільки ви пропустили важливу деталь. Якщо ви самі керуєте контрактом, обов'язково запитайте у свого відділу закупівель, чи є якісь особливі умови, про які ви повинні знати, щоб ваша проектна команда ненавмисно не затримувала закриття проекту контракту.

    Однією з цілей процесу закриття контракту є надання офіційного повідомлення продавцю, як правило, у письмовій формі, про те, що товари є прийнятними та задовільними або були відхилені. Якщо товар або послуга не відповідають очікуванням, постачальнику потрібно буде виправити проблеми, перш ніж видавати офіційне повідомлення про прийняття. Перед закриттям контракту будь-які незначні предмети, які потрібно відремонтувати або завершити, поміщаються в список перфораторів, який є списком усіх предметів, знайдених клієнтом або командою або менеджером, які ще належить зробити. Сподіваємось, аудити якості були проведені протягом проекту, і постачальнику була надана можливість внести виправлення раніше в процесі, ніж на етапі закриття. Не дуже гарна ідея дочекатися самого кінця проекту, а потім навесні всіх проблем і питань на постачальника відразу. Набагато ефективніше обговорювати проблеми з вашим постачальником у міру просування проекту, оскільки це дає можливість для виправлення, коли виникають проблеми.

    Потім команда проекту працюватиме над усіма пунктами списку перфораторів, будуючи невеликий графік, щоб завершити роботу, що залишилася. Якщо кількість позицій у списку перфораторів занадто велика або обсяг робіт значний, команда проекту продовжує роботу над проектом. Після того, як список перфораторів стає меншим, керівник проекту починає закривати проект, підтримуючи лише достатню кількість персоналу та обладнання для підтримки команди, яка працює над списком перфораторів.

    Якщо товар або послуга дійсно відповідають очікуванням проекту і є прийнятними, потрібне офіційне письмове повідомлення продавцю із зазначенням того, що договір завершений. Це формальне прийняття і закриття договору. Ви несете відповідальність як керівника проекту, щоб документувати офіційне прийняття договору. Багато разів положення про оформлення приймання і закриття договору прописані в самому договорі.

    Якщо у вас є відділ закупівель, який займається адмініструванням контрактів, вони очікуватимуть, що ви повідомите їх, коли контракт буде завершений, і, в свою чергу, дотримуватимуться офіційних процедур, щоб повідомити продавця про завершення контракту. Однак ви все одно зазначите завершення контракту у своїй копії записів проекту.

    Звільнення проектної команди

    Випуск членів команди проекту не є офіційним процесом. Однак слід зазначити, що по завершенні проекту ви звільните членів своєї проектної команди, а вони повернуться до своїх функціональних менеджерів або отримають призначення на новий проект. Ви захочете тримати їх керівників, або інших менеджерів проектів, в міру наближення до завершення проекту, щоб вони встигли адекватно спланувати повернення своїх співробітників. Дайте їм знати на кілька місяців раніше часу, як виглядає графік і як скоро вони можуть планувати використання своїх співробітників на нових проектах. Це дає іншим менеджерам можливість розпочати планування діяльності та планувати дати діяльності.

    Остаточні платежі

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

    Якщо постачальник виконав всі договірні зобов'язання, включаючи виправлення проблем і проведення ремонту, як зазначено в перфолисті, проектна група підписує договір і подає його в бухгалтерію для остаточної оплати. Постачальник повідомляється про те, що останній платіж є остаточним і завершує договірну угоду з проектом.

    Оцінки після проекту

    Перш ніж команда буде розпущена і почне зосереджуватися на наступному проекті, проводиться огляд, щоб відобразити уроки, які можна витягти з цього проекту, який часто називають нарадою, вивченою уроками або документом. Команда досліджує, що пройшло добре, і фіксує процеси, щоб зрозуміти, чому вони пройшли добре. Команда запитує, чи можна передати процес іншим проектам. Команда також досліджує, що не пройшло добре і що люди навчилися з досвіду. Процес полягає не в тому, щоб знайти провину, а навчитися.

    Управління якістю - це процес постійного вдосконалення, який включає навчання з минулих проектів та внесення змін для вдосконалення наступного проекту. Цей процес задокументований як доказ того, що використовуються методи управління якістю. Деякі організації мають формальні процеси для зміни робочих процесів та інтеграції уроків, отриманих з проекту, щоб інші проекти могли отримати користь. Деякі організації менш формальні в підході і очікують, що люди переймають досвід і переймають досвід до свого наступного проекту і ділитися тим, що вони дізналися з іншими в неформальному вигляді. Який би тип підходу не використовувався, слід оцінювати наступні елементи та підсумувати результати у звітах для зовнішнього та внутрішнього використання.

    Ефективність довіри та вирівнювання

    Керівництво проекту розглядає вплив довіри або відсутності довіри до проекту та ефективність зустрічей щодо вирівнювання при формуванні довіри. Команда визначає, які проблеми могли бути передбачені та пом'якшені, а які не можна було розумно передбачити. Які сигнали були пропущені командою, які вказували на виникнення проблеми? Що могла зробити команда, щоб краще прогнозувати та запобігти проблемам довіри?

    Управління графіком і бюджетом

    Початковий графік заходів і мережева схема порівнюються з фактичним графіком подій. Події, які спричинили зміни в графіку, переглядаються, щоб побачити, як використання резервів на випадок надзвичайних ситуацій та пом'якшувало порушення, спричинене цими подіями. Початкові оцінки часу надзвичайних ситуацій переглядаються, щоб визначити, чи були вони адекватними і якщо оцінки тривалості та плавання були точними. Ці заходи необхідні команді проекту для розвитку експертизи в оцінці елементів графіка в майбутніх проектах - вони не використовуються для обвинувачення.

    Огляд кошторису бюджету на вартість запланованих робіт порівнюється з фактичними витратами. Якщо кошториси часто відрізняються від фактичних витрат, розглядається вибір методу оцінки.

    Пом'якшення ризиків

    Після завершення проекту оцінки ризику можна переглянути і порівняти з подіями, які фактично відбулися. Чи відбувалися події, які були непередбачені? Які підказки існували, які, можливо, дозволили команді передбачити ці події? Чи були надзвичайні ситуації проекту достатніми для покриття непередбачених ризиків? Навіть якщо нічого не пішло не так в цьому проекті, це не є доказом того, що зменшення ризику було марною тратою грошей, але корисно порівняти вартість уникнення ризику з вартістю несподіваних подій, щоб зрозуміти, скільки коштує уникнути ризику.

    Контракти закупівель

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

    Задоволеність клієнтів

    Розглядаються відносини з клієнтом і обговорюються рішення про включення клієнта в проектні рішення і узгодження зустрічей. Клієнту надається можливість висловити задоволення та визначити сфери, в яких комунікація проекту та інші фактори можуть бути покращені. Часто старший менеджер з організації проводить співбесіду з клієнтом для розробки зворотного зв'язку про ефективність команди проекту.

    Загальний звіт, який надає огляд проекту, створюється для надання зацікавленим сторонам резюме проекту. Звіт містить оригінальні цілі та завдання та заяви, які показують, як проект досяг цих цілей та завдань. Підсумовуються показники за графіком та бюджетом та надається оцінка задоволеності клієнтів. Версія цього звіту може бути надана клієнту як зацікавлена сторона і як інший засіб отримання зворотного зв'язку.

    Керівництво вищої ланки

    Звіт вищому керівництву містить всю інформацію, надану зацікавленим сторонам у короткому резюме. У звіті визначені практики та процеси, які можна вдосконалити, або уроки, які були засвоєні, які можуть бути корисними для майбутніх проектів.

    Архівування документа

    Документи, пов'язані з проектом, повинні зберігатися в безпечному місці, де їх можна буде отримати для подальшого використання. Підписані договори або інші документи, які можуть бути використані в податкових перевірках або судових позовах, повинні зберігатися. Організації матимуть правові політики зберігання та пошуку документів, які застосовуються до проектних документів і повинні дотримуватися. Деякі проектні документи можуть зберігатися в електронному вигляді.

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

    • Статутні документи
    • Заява про сферу застосування
    • Оригінальний бюджет
    • Змінити документи
    • Рейтинги DPCI
    • Короткий зміст менеджера - отримані уроки
    • Остаточний рейтинг DPCI
    • Was this article helpful?