Skip to main content
LibreTexts - Ukrayinska

1.7: Планування проекту

  • Page ID
    104543
  • \( \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}}\)

    По суті, всі моделі неправильні, але деякі корисні.
    — Джордж Бокс, Засновник Департаменту статистики, Університет Вісконсин-Медісон

    Цілі

    Прочитавши цю главу, ви зможете

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

    Великі ідеї в цьому уроці

    • Графік проекту — це спільна карта часу для успішного завершення проекту. Залежно від того, що являє собою «успіх» для проекту, графік може включати кілька жорстких термінів і бути сильно обмеженим, а може бути повністю гнучким і невимушеним.
    • Планування - це етап управління проектами, який обов'язково поєднує геометричний та живий порядок, часто поєднуючи передбачуваність критичних методів шляху з спритністю, пропонованою плануванням тягнути.
    • Оскільки графік - це інструмент комунікації та мислення, рівень деталізації, з яким він готується та спілкується, повинен бути адаптований до потреб проекту та членів команди.
    • Метод критичного шляху - неперевершений геометричний інструмент поштовху - має важливе значення для визначення заходів, які визначають очікувану тривалість складного проекту. Однак надмірна увага на аналізі критичного шляху під час виконання проекту може відвернути необхідну увагу та енергію від реалізації проекту, орієнтованого на тягу.

    7.1 Перетин мосту від планування до планування

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

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

    Перш за все, графік - це форма спілкування з усіма, хто бере участь у проекті. Увага зацікавлених сторін проекту є дефіцитним ресурсом. Тому варто прагнути, щоб ваш графік був гідним уваги вашої команди. Важливо сформувати графік відповідно до потреб і сильних сторін команди, а також культури вашої організації. Хорошим зразком для наслідування для цього типу гнучкості є джазовий і класичний музикант Вінтон Марсаліс. Коли він виконує концерт «Труба» Моцарта в D з симфонічним оркестром, він дотримується суворих правил світу класичної музики. Коли він грає на бібопі в Лінкольн-центрі, він переходить на вільну форму, імпровізаційний стиль джазового світу. Таким же чином, як керівник проекту, що працює в межах живого порядку, ви повинні бути в курсі того, що є і не підходить і не є корисним для вашого конкретного проекту і організації протягом усього життя вашого проекту.

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

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

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

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

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

    7.2 Вибір слів

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

    Термінологія настільки важлива, що уряди багатьох штатів у Сполучених Штатах публікують власні глосарії управління проектами. Коли ви приступаєте до нового проекту, вам було б розумно з'ясувати, чи склала такий глосарій організація, в якій ви працюєте, або постачальники, з якими ви будете працювати. Якщо такі організаційні ресурси існують, використовуйте їх як відправну точку для власного глосарію проекту. В іншому випадку ви завжди можете звернутися до лексикону Інституту управління проектами (доступний тут: «PMI Lexicon of Project Management Terms») або глосаріїв, наданих в Інтернеті консалтинговими фірмами або іншими ресурсами з управління проектами, такими як:

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

    • Віха: «Значна подія в проекті; зазвичай завершення великого результату» (Штат Мічиган: Департамент технологій, управління та бюджету 2013). Важливою відмінністю є те, що віха - це діяльність з нульовою тривалістю; наприклад, «прийняття програмного забезпечення клієнтом» є віхою, якій передує багато заходів, що сприяють.
    • Діяльність: «Елемент робіт, що виконуються під час виконання проекту. Зазвичай діяльність має очікувану тривалість, очікувану вартість та очікувані потреби у ресурсах» (Project-management.com 2016). Остерігайтеся, що деякі організації поділяють діяльність на завдання, а інші використовують завдання та діяльність синонімами.
    • тривалість: «Кількість часу для виконання конкретного завдання з урахуванням інших зобов'язань, роботи, відпустки тощо Зазвичай виражається як робочі дні або робочі тижні» (Штат Мічиган: Департамент технологій, управління та бюджету 2013)».
    • ресурс: «Будь-який персонал, матеріал або обладнання, необхідне для здійснення діяльності» (Project-management.com 2016).
    • вартість: «Витрати, як правило, грошей, на закупівлю товарів або послуг» (Закон 2016).
    • slack: «Розрахований проміжок часу, протягом якого подія повинна відбутися в межах логічних і накладених обмежень мережі, не впливаючи на загальну тривалість проекту» (Project-management.com 2016). Або простіше кажучи, слабкість, яка також називається float, - це кількість часу, на який завдання може бути відкладено, не викликаючи затримки наступних завдань або загальної дати завершення проекту.

    Єдине джерело інформації для вашої проектної команди

    Однією з зростаючих сфер управління проектами є віртуальні проектні середовища. Ці відносно недорогі, автономні середовища зазвичай включають вбудований планувальник проектів, а також випуски баз даних, утиліти розподілу ресурсів, менеджери завдань, інформаційні панелі тощо. Ці віртуальні середовища особливо корисні для розпорошених команд і роблять непотрібним доступ до MS Project або подібного програмного забезпечення. Найголовніше, що віртуальне середовище проекту служить єдиним джерелом інформації для важливих документів, таких як плани проектів, тим самим уникаючи проблем із застарілою або неправильною інформацією, що циркулює серед членів команди. Щоб побачити деякі приклади, виконайте пошук у Інтернеті для Smartsheet, Mavenlink та Genius Project.

    7.3 Геометричні та живі: два способи планування

    Планування - це етап управління проектами, який обов'язково поєднує геометричний і живий порядок. Іноді вам потрібно прибити до заздалегідь визначеного порядку діяльності за жорстко регламентованим графіком; іноді потрібно дозволити гнучкість, необхідну, коли одна діяльність залежить від іншої діяльності невизначеної тривалості та складності. У ситуації з істинним геометричним порядком ви, швидше за все, витратите більше часу на планування заздалегідь, ніж на оновлення пізніше. У живому порядку все навпаки. Взагалі кажучи, в геометричному порядку, push середовища, 60 відсотків зусиль може піти на планування, 10 відсотків на планування, і 30 відсотків на оновлення та перегляд графіка. У живому порядку, витягніть середовище, ці відсотки змінюються, з 30 відсотками зусиль, присвячених плануванню, 10 відсотків на планування та 60 відсотків на коригування та вдосконалення графіка.

    Техніка планування та планування, найбільш тісно пов'язана з плануванням поштовху та геометричним порядком, - це метод критичного шляху (CPM), який є «покроковою технікою управління проектами для планування процесів, що визначає критичні та некритичні завдання з метою запобігання часових рамок проблеми та вузькі місця процесів» (Rouse 2015). Ви можете використовувати CPM для виявлення впливу запропонованих змін на терміни і тривалість завдань. Ключем до CPM є виявлення послідовностей пов'язаних заходів, відомих як шляхи (Larson and Gray 2011, 662). Критичний шлях визначається як «низка заходів, що визначають якнайшвидше завершення проекту» (Project-management.com 2016).

    Техніка планування, яка найкраще ілюструє принципи життєвого порядку, - це графік розтягування, створений спільно зацікавленими сторонами, як правило, за допомогою різнокольорових нотаток Post-IT. Деталі цього типу планування були кодифіковані в Last Planner System, власній системі планування виробництва, заснованій на принципах Lean, і розроблена Гленном Баллардом і Грегом Хауеллом. Agile також використовує методи планування тягнути.

    Хоча захист критичного шляху є важливим у цих типах планування життєвого порядку, явне виявлення та моніторинг критичного шляху протягом усього проекту може викликати меншу стурбованість. Ми розглянемо, чому це правда пізніше в цьому уроці. Для початку давайте розглянемо основи CPM. Потім ми обговоримо деталі планування тяги та розглянемо способи поєднання систем поштовху та тяги для досягнення кінцевих цілей Lean: створення цінності та усунення відходів.

    7.4 Push: Метод критичного шляху (CPM)

    CPM особливо корисна для великих, складних проектів, де взаємозв'язки графіка можуть бути не очевидні. Він «ідеально підходить для проектів, що складаються з численних заходів, які взаємодіють комплексно» (Rouse 2015). Вперше використовується в промисловості наприкінці 1950-х років, CPM має своє коріння в більш ранніх починаннях, особливо на Манхеттенському проекті.

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

    Створення моделі CPM проекту включає наступні шість кроків:

    1. Визначте етапи проекту або результати.
    2. Створіть список усіх заходів у проекті, як описано в структурі розбивки робіт.
    3. Визначте тривалість для кожного виду діяльності.
    4. Побудувати мережеву діаграму, яка визначає залежності між видами діяльності.
    5. Обчисліть дати раннього початку, пізнього початку, раннього фінішу та пізнього фінішу для кожної діяльності.
    6. Визначте послідовність завдань через проект із завданнями нульового float (slack). Це критичний шлях.

    За допомогою CPM можна визначити:

    • Мінімальний загальний час, необхідний для завершення проекту, тобто критичний шлях.
    • Гнучкість, або слабкість, у графіку за іншими, некритичними шляхами.

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

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

    Уникнення підводних каменів CPM

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

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

    Успішний керівник проекту використовує CPM як засіб підтримки проекту на шляху та призначення найбільш надійного персоналу для критичних дій, при цьому маючи на увазі, що CPM не забезпечує абсолютних істин. За словами доктора Джорджа Бокса, засновника Департаменту статистики Університету Вісконсин-Медісон, «По суті, всі моделі неправильні, але деякі корисні». Це абсолютно вірно щодо CPM. Вам потрібно регулярно оцінювати моделі проектів CPM, щоб переконатися, що вони відповідають визначенню успішності проекту зацікавленими сторонами.

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

    Стиснення графіка

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

    Існує два ключових способи стиснення розкладу:

    • швидке відстеження- Техніка стиснення графіка, в якій «заходи, які були б виконані послідовно з використанням оригінального розкладу, виконуються паралельно. Іншими словами, швидке відстеження проекту означає, що діяльність працює одночасно, замість того, щоб чекати, коли кожен шматок буде завершений окремо. Але швидке відстеження може застосовуватися лише в тому випадку, якщо діяльність, про яку йде мова, насправді може бути перекрита» (Monnappa 2017). Наприклад, при будівництві нового будинку, можливо, ви зможете перекрити заливку бетону для зовнішнього внутрішнього дворика і черепицю даху, але ви не можете перекривати риття фундаменту для будинку і черепицю даху, яка ще не побудована.
    • crashing- Ця техніка передбачає додавання ресурсів, таких як понаднормова робота або більше обладнання, щоб прискорити графік. Через витрати, пов'язані з додаванням ресурсів, збої є «технікою, яку слід використовувати, коли швидке відстеження не заощадило достатньо часу на графіку проекту. За допомогою цієї методики ресурси додаються до проекту для найменших можливих витрат. Проаналізовано компроміси витрат та графіка, щоб визначити, як отримати найбільший обсяг стиснення за найменші додаткові витрати» (Monnappa 2017). Зверніть увагу, що збої, як правило, не ефективні для ІТ-проектів.

    Важливо пам'ятати при спробі стиснути графік це те, що потрібно зосередитися на стисненні критичного шляху. Це не приносить користі для прискорення завдань, які не знаходяться на критичному шляху. Згідно з ранньою, але все ще корисною статтею про CPM, ви можете думати про критичний шлях як «вузьке місце маршруту:»

    Тільки шляхом пошуку шляхів скорочення робочих місць на критичному шляху можна скоротити загальний час проекту; час, необхідний для виконання некритичних завдань, не має значення з точки зору загального часу проекту. Таким чином, часта (і дорога) практика «збою» всіх робочих місць у проекті з метою скорочення загального часу проекту є непотрібним. Як правило, лише близько 10% робочих місць у великих проектах є критичними. (Ця цифра, природно, буде відрізнятися від проекту до проекту.) Звичайно, якщо буде виявлено, що якийсь спосіб скоротити одну або кілька критичних робочих місць, то не тільки весь час проекту буде скорочено, але й сам критичний шлях може змінитися, а деякі раніше некритичні завдання можуть стати критичними. (Леві, Томпсон і Віст 1963)

    Закон Брукса та спритний розвиток

    У своїй насіннєвій книзі «Міфічний людина-місяць» Фред Брукс пояснює, що збій графіка не працює в розробці програмного забезпечення, оскільки: 1) людям потрібен час (часто багато часу), щоб досягти швидкості на проекті; 2) коли ви додаєте більше людей до проекту, ви збільшуєте кількість необхідного спілкування , що знижує продуктивність кожного; і 3) завдання розробки програмного забезпечення не можна розділити на менші завдання так, як можуть бути фізичні завдання, такі як фарбування будинку. Весь його аргумент може бути зведений до однієї широко цитованої лінії, відомої як Закон Брукса: «Додавання робочої сили до пізнього програмного проекту робить це пізніше» (1975, 25).

    Дейв Пагенкопф, директор з розробки та інтеграції додатків UW-Madison, пояснює, як розробка програмного забезпечення Agile пропонує альтернативу болісним реаліям закону Брукса:

    На початку своєї кар'єри, як і багато інженерів-програмістів, я не бачив, як Брукс Лоу може бути правдою. Але коли я почав керувати програмними проектами, я почав з перших вуст бачити проблеми, які виникають із збоєм графіка розробки програмного забезпечення. Однією з причин, чому я так віддаю перевагу Agile, є те, що підхід тримає варіанти відкритими, коли проект відстає від графіка. Щоб досягти дати в Agile проект, ви можете зменшити обсяг (маючи на увазі, що ви завжди можете додати більше обсягу пізніше). Проект Agile програмного забезпечення, який завершено на 80%, ймовірно, все ще корисний. Програмний проект водоспаду, який завершено на 80%, швидше за все, марний.

    Ось кілька порад, про які слід пам'ятати при спробі стиснути графік:

    • Залучайте всю команду до пошуку можливостей з найбільшим впливом часу та витрат.
    • Шукайте способи збільшення паралельності, а також для заходів, в яких збільшення призначених ресурсів скоротить тривалість діяльності.
    • Подумайте про пропонування стимулів для дострокового завершення. Це часто зустрічається, наприклад, у деяких проектах автомобільних доріг, в яких підрядники стягують плату за кожен день, коли смуга закрита, або бонус за дострокове завершення проекту. Це дає підрядникам стимули мінімізувати кількість закриттів смуги руху в будь-який момент часу.
    • Не всі заходи мають рівну цінність з реалізацією проекту. Деякі з них просто «приємно мати» діяльність. Це часто справедливо в відкритих проектах, таких як проекти розробки продуктів. Після того, як ви приступите до роботи, скорочуючи план проекту, ви можете бути здивовані тим, скільки ви можете вирізати, не впливаючи значно на кінцеві результати.
    • Ретельно робіть зміни стиснення графіка, завжди маючи на увазі, що стиснення графіка може додати ризик. Переконайтеся, що ви ретельно розумієте ліквідовані заходи, щоб переконатися, що ви не пропустите щось важливе.
    • Хоча CPM передбачає підхід геометричного порядку до планування та планування, він не сліпий до невизначеностей, які можуть виникнути в будь-якому проекті. Типовий графік CPM визначає слабину (або float), пов'язану з кожною діяльністю, тим самим дозволяючи свободу дій, які можуть працювати довше або зайняти менше часу, ніж очікувалося.

    7.5 Потягніть: пост-його, останній планувальник та гнучкий

    Тепер, коли ви знайомі з CPM, реакцією геометричного порядку на вимоги планування, давайте зосередимося на підході до порядку життя, потягніть планування. Графік тяги за своєю природою є незавершеною роботою. Його створення - це спільний процес, і він повинен регулярно оновлюватися у відповідь на поточні умови. Як ви бачили в Уроці 6, початковий графік витягування часто створюється під час структурованої спільної сесії з ключовими учасниками проекту, використовуючи кольорові нотатки Post-IT, які можуть бути видалені або переміщені в міру необхідності. Помаранчеві примітки на малюнку 7-1 представляють результати; жовті нотатки представляють кроки, необхідні для отримання результатів. Після того, як всі зацікавлені сторони згодні, такий графік зазвичай перекладається у цифровий формат, наприклад Microsoft Project або Microsoft Excel.

    Малюнок 7-1: Розклади витягування часто створюються з Post-It Notes на білій дошці (Джерело: Джон Нельсон)

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

    Створення розкладу витягування

    Ви можете створити розклад витягування в електронному вигляді, використовуючи будь-яку кількість програм планування. Але для заохочення таких спільних розмов, які заохочують всіх зацікавлених сторін стати мислителями, корисно почати з збору всіх зацікавлених сторін у кімнаті з великою білою дошкою (або цілою стіною), відведеною для використання в якості робочої зони розкладу. Працюючи назад від цільової дати завершення, зацікавлені сторони розміщують кольорові пост-ІТ-нотатки на графіку, щоб вказати, коли вони виконають різні завдання. Жодному учаснику не дозволяється переміщати записку іншого учасника Post-IT. Натомість, коли конфлікти планування стають очевидними, зацікавлені сторони повинні вести переговори один з одним, переставляючи пост-IT нотатки лише після того, як зацікавлені сторони узгоджують рішення кожної проблеми планування.

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

    Планування приміток після нього

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

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

    • Швидке трихвилинне введення, щоб витягнути графіки планування в будівництві: «Pull Planning: Miron Construction Co.»
    • Більш глибока, 30-хвилинна дискусія: «Планування витягування: Lean Construction. »
    • Хоча по суті оголошення для компанії, яка продає матеріали, пов'язані з плануванням тяги, це однохвилинне відео показує один спосіб організувати кімнату для планування потягу: Pull Planning Kit: Big Room Supplies.

    Різновиди планування Pull

    Планування витягування у формі системи останнього планувальника (LPS) має важливе значення для Lean. Мета LPS - «забезпечити передбачуваний робочий потік і швидке навчання в програмуванні, проектуванні, будівництві та введенні в експлуатацію проектів» (Lean Construction Institute n.d.).

    П'ять основних елементів ЛПС включають:

    • Майстер-планування (встановлення етапів та стратегії; визначення довгих позицій лідів);
    • Планування етапу «Потягніть» (уточніть здачі; виявлення оперативних конфліктів);
    • Make Work Ready Planning (дивитися вперед планування, щоб переконатися, що роботи будуть готові до монтажу; перепланування в міру необхідності);
    • Щотижневе планування роботи (зобов'язання виконувати роботу в певному порядку та певній послідовності);
    • Навчання (вимірювання відсотка завершеного плану (КПП), глибоке занурення в причини невдачі, розробка та реалізація отриманих уроків). (Lean Будівельний інститут)

    Зауважте, що ці елементи схожі на Agile scrum, що не дивно, враховуючи, що LPS і Agile вийшли з Lean. Крім того, ці п'ять елементів LPS повертаються до концепції планування рухомих хвиль, описаної в Уроці 6.

    Графіки в LPS зосереджені на останньому відповідальному моменті, який є «моментом, коли вартість затримки рішення перевершує вигоду від затримки; або момент, коли неприйняття рішення усуває важливу альтернативу» (Lean Construction Institute). Останній відповідальний момент схожий на вибір, коли робити бронювання авіакомпанії. Ви хочете чекати досить довго, щоб знати достатньо деталей, щоб уникнути дорогих змін, і ви хочете скористатися можливими цінами продажу, але ви також хочете уникнути збільшення витрат і повністю заброньованих рейсів протягом тижнів безпосередньо перед поїздкою. Ви обираєте останній відповідальний момент, щоб забронювати подорож, використовуючи отримані знання та очікування щодо майбутнього. На будівельному майданчику може бути ЛРМ для доопрацювання котловану, інший ЛРМ для встановлення форм і ще один ЛРМ для заливки бетону.

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

    При створенні графіків в умовах бережливого виробництва зменшення розмірів партій є важливою концепцією. Замість того, щоб планувати ряд завдань, які повинні бути виконані один раз на великій партії, невеликий пакетний підхід планує багато хто проходить через ту ж серію завдань. Такий підхід є більш гнучким і виключає відходи, в кінцевому підсумку підвищуючи загальну ефективність. Він успішно використовується на паперових заводах, металургійних заводах та інших галузях промисловості (Preactor 2007). Докладніше про планування малих партій див. цю публікацію в блозі: «Пакетне планування в світі бережливого виробництва. »

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

    7.6 Критичний шлях у живому порядку

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

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

    У своїй проникливій роботі «Шлюб CPM та Lean Construction» двоє досвідчених керівників компанії Boldt - Боб Хубер, менеджер з планування, і Пол Райзер, віце-президент з виробництва та технологічних інновацій - дивляться на процес планування через об'єктив Lean. Вірні своєму досвіду в технологіях бережливого будівництва, піонерами компанії Boldt, вони починають з того, що задають важливе питання будь-якого Lean підприємства: яку цінність воно забезпечує? Їх аналіз показує, що графік надає різну цінність різним зацікавленим сторонам. Для власника «цінність, отримана від графіка, - це здатність повідомляти про тривалість проекту та потреби фінансування зацікавленим сторонам вгору та вниз за течією». Значення, надане іншим зацікавленим сторонам, включає «тривалість проекту, вплив на сусідні об'єкти, очікування щодо термінів інженерних результатів, карту потоку екіпажу, можливості своєчасної доставки» (2003).

    Для зацікавлених сторін, в першу чергу зацікавлених у тривалості проекту, критичний шлях є особливою увагою. Але не всі, хто бере участь у проекті, вимагають дрібних подробиць про стан діяльності на критичному шляху. Huber і Reiser стверджують, що на будівельному майданчику, забезпечуючи постійне оновлення графіків за допомогою складного програмного забезпечення, доступного для управління графіками CPM, витрачає один з найважливіших ресурсів, доступних на будь-якому проекті: увагу зацікавлених сторін проекту.

    Вибухове зростання можливостей та вдосконалення комп'ютерного програмного забезпечення для управління проектами протягом останніх кількох десятиліть не було тісно узгоджене паралельним інтересом або необхідністю даних та аналізу, які вони надають. Особливо це стосується інтересів і потреб керівника фронтовим виробництвом на будівельному майданчику. Зусилля з планування, оскільки це вимагає часу та енергії від передових менеджерів, повинні конкурувати з повсякденними вимогами проекту щодо безпеки та екологічних міркувань, управління сферою, фінансовим управлінням, трудовими відносинами, відносинами з власниками, закупівлями, нарахуванням заробітної плати та документацією. У цьому конкурентному середовищі конкуренція полягає в тому, що для уваги керівника передового виробництва графік CPM обов'язково повинен швидко та ефективно доставляти свою цінність, або він стикається з чіткою можливістю програти іншим наполегливим вимогам до часу та уваги менеджера. Просто тому, що ми можемо створити надзвичайно детальний ресурс на основі WBS, завантажений і вирівняний графік, і тільки тому, що ми можемо повідомити про його зміст в глухому масиві діаграм, діаграм і графіків, не означає, що ми повинні. Насправді, практикується як інтерактивне обговорення потреб потоку екіпажу та координації місця, з даними, які збираються та аналізуються для узгодження з потребами проекту в режимі реального часу, процес планування CPM може виконувати покладені на нього функції дуже ефективно. Тест завжди повинен полягати в тому, чи забезпечує графік CPM цінність і легко споживається контролерами виробництва сайту. (Хубер і Райзер 2003)

    Джон Нельсон, ад'юнкт-професор інженерії в UW-Madison та ветеран багатьох років у будівельній галузі, стверджує, що надмірна увага на критичному шляху може зірвати шанси проекту на успіх: «Найбільш важливі проекти шляху не відповідають своїм віхам. Більшість проектів живого порядку, які ігнорують критичний шлях, відповідають своїм віхам. Надмірна увага на критичному шляху витрачає занадто багато енергії; кожен працює над оновленням критичного шляху, фактично нічого не роблячи».

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

    7.7 Зосередьтеся на віхах

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

    У відмінному блозі про корисність віх, Елізабет Харрін пояснює, що віхи слід використовувати «як спосіб показати рух вперед та прогрес, а також показати людям, що відбувається, навіть якщо вони не мають детальних знань про завдання, пов'язані з тим, щоб потрапити туди. У цьому відношенні вони дуже корисні для спілкування зацікавлених сторін та встановлення очікувань» (Harrin 2017). Ви можете використовувати віхи, пояснює вона, щоб відстежувати свій прогрес, зосереджуючись на

    • Початок значних етапів роботи
    • Закінчення значущих етапів роботи
    • Позначити термін для чогось
    • Щоб показати, коли приймається важливе рішення. (Квітень 2017)

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

    ~Практичні поради

    • Переконайтеся, що ви розумієте різницю між планом та розкладом: Взаємозв'язок між планом та розкладом подібний до взаємозв'язку між планом поїздки, в якому прописані загальні цілі, та маршрутом поїздки, який визначає, як і коли ви потрапите від однієї зупинки до наступної і завершити поїздку протягом доступного часу. План проекту повинен включати певний розгляд часу, але він не повинен вдаватися в деталі.
    • Створення розкладу може допомогти вам організувати свої думки: Створення графіка, як правило, практичне заняття, зосереджене на плануванні фактичної роботи. Однак ви також можете створити графік як спосіб організації своїх думок та обміну тим, що ви дізналися про проект.
    • Розробіть графік за деталями, необхідними для планування та узгодження: Планування поза необхідною деталлю не додає ніякої цінності. Графік, розміщений на занадто високому рівні, ризикує пропустити ключові заходи або виявити критичні ризики. Занадто всеосяжний графік стає тягарем для оновлення і може ускладнити членам команди відстежувати діяльність, тим самим роблячи його мало практичної цінності.
    • Подумайте про графік як інструмент спілкування із зацікавленими сторонами: Перш за все, графік - це інструмент комунікації, розроблений для того, щоб підтримувати зацікавлені сторони в курсі всіх поточних знань про проект. Це означає, що це живий документ, який не може вважатися остаточним, поки проект не буде закінчений. Графік слід регулярно оновлювати та переглядати, щоб включити останні знання та інформацію в міру просування проекту. Прагніть розробити та повідомити графік проекту таким чином, який є найбільш корисним для учасників проекту.
    • Планування ідеального виконання неминуче призводить до затримок: Завжди плануйте недосконалості реальності. Малюйте на своєму власному минулому досвіді, коли ви переглядаєте графік, щоб допомогти вам вирішити, чи це реально. Якщо у вас немає жодного відповідного минулого досвіду, то проконсультуйтеся з кимось, хто це робить. Можливо, вам буде корисно поговорити з більш досвідченим колегою. Ви також можете використовувати багато ресурсів, доступних у вашій галузі.
    • Час від часу задавайте собі таке важливе питання: яка розумна кількість заходів для одного проекту? На це питання немає жорсткої і швидкої відповіді, оскільки всі проекти різні і вимагають різного ступеня визначення активності. Але, як правило, більшість людей можуть успішно відстежувати 30-50 заходів. Більше того, і вони починають губитися в деталі. Інші члени команди можуть мати підзавдання 30-50 заходів, тобто загальний план може мати сотні згорнутих заходів.
    • Зрозумійте взаємозв'язок між розподілом ресурсів та критичним шляхом: У багатьох випадках критичний шлях дійсний лише після виділення ресурсів. Якщо ресурси надмірно розподілені, критичний шлях може дати вам помилкове відчуття безпеки.
    • Не плануйте завдання занадто рано в проекті, тільки тому, що воно знаходиться на критичному шляху: зосередження уваги на критичному шляху іноді змушує нас робити речі раніше, ніж нам потрібно, що може призвести до помилок і переробки, оскільки обмеження проекту стають зрозумілішими. У живому порядку ми розглядаємо проекти як досвід збору знань і тому уникаємо передчасного початку діяльності.
    • Графік не гарантує успіху проекту: Створення та оновлення графіка - це постійний процес, який повинен бути адаптований до зовнішніх впливів та потреб замовника та використовуватися для узгодження зацікавлених сторін.

    ~Резюме

    • Розклад - це конкретна карта, заснована на часі, призначена для того, щоб допомогти проектній команді перейти від поточного стану до успішного завершення проекту. У той час як план схожий на стратегію футбольного тренера для перемоги, графік - це все про тактику. Перш за все, це форма спілкування з усіма, хто бере участь у проекті. Він повинен містити якраз потрібну кількість деталей.
    • Переконавшись, що всі зацікавлені сторони використовують однакову термінологію, має вирішальне значення на всіх етапах управління проектами, але це особливо важливо, коли ви намагаєтеся змусити групу різних людей погодитися на графік. Важливі терміни, пов'язані з плануванням, включають віху, активність, тривалість, ресурс, вартість та слабкість.
    • Планування - це етап управління проектами, який обов'язково поєднує геометричний і живий порядок. Техніка планування та планування, найбільш тісно пов'язана з плануванням поштовху та геометричним порядком, - це метод критичного шляху (CPM). Техніка планування, яка найкраще ілюструє принципи життєвого порядку, - це графік розтягування, створений спільно зацікавленими сторонами, як правило, за допомогою різнокольорових нотаток Post-IT. Деталі цього типу планування були кодифіковані в системі останнього планувальника та в Agile.
    • Метод критичного шляху (CPM) зосереджується на визначенні критичного шляху діяльності, необхідної для забезпечення успіху проекту, а потім пильний моніторинг діяльності на критичному шляху через весь проект. CPM особливо корисна для великих, складних проектів, де взаємозв'язки графіка можуть бути не очевидні. Це кінцевий інструмент геометричного порядку для управління проектами і може заманити вас у помилкове почуття безпеки щодо передбачуваності проекту. Однак це може бути дуже корисно, коли вам потрібно стиснути графік шляхом швидкого відстеження або збою.
    • Графік тяги за своєю природою є незавершеною роботою. Його створення - це спільний процес, і він повинен регулярно оновлюватися у відповідь на поточні умови. Початковий графік витягування часто створюється за допомогою кольорових пост-нотаток, які можуть бути видалені або переміщені за потребою. Планування витягування у формі системи останнього планувальника (LPS) має важливе значення для Lean. Графіки в ЛПС орієнтуються на останній відповідальний момент і спираються на використання надійних обіцянок.
    • У деяких ситуаціях, особливо в урядовій роботі, моніторинг критичного шляху є договірним зобов'язанням. Але можна переоцінити критичний шлях, тим самим витрачаючи енергію і увагу зацікавлених сторін проекту.
    • Зосередження уваги на етапах проекту - це хороший спосіб забезпечити графік високого рівня, який корисний для більшості зацікавлених сторін.

    ~Глосарій

    • activity— «Елемент робіт, що виконуються під час виконання проекту. Зазвичай діяльність має очікувану тривалість, очікувану вартість та очікувані потреби у ресурсах» (Project-management.com 2016). Остерігайтеся, що деякі організації поділяють діяльність на завдання, а інші використовують завдання та діяльність синонімами.
    • стиснути графік— Процес прийняття графіка, який ви вже розробили, і зменшуючи його без коригування обсягу проекту.
    • cost— «Витрати, як правило, грошей, на закупівлю товарів або послуг» (Закон 2016).
    • crashing- Техніка стиснення графіка, яка передбачає додавання ресурсів, таких як понаднормова робота або більше обладнання, щоб прискорити графік. Через витрати, пов'язані з додаванням ресурсів, збої є «технікою, яку слід використовувати, коли швидке відстеження не заощадило достатньо часу на графіку проекту. За допомогою цієї техніки ресурси додаються до проекту за найменшу вартість» (Monnappa 2017).
    • критичний шлях — «серія заходів, що визначають якнайшвидше завершення проекту» (Project-management.com 2016).
    • duration— «Час, необхідний для завершення діяльності, шляху або проекту» (Ларсон і Грей 2011, 659).
    • швидке відстеження- Техніка стиснення графіка, в якій «заходи, які були б виконані послідовно з використанням оригінального розкладу, виконуються паралельно. Іншими словами, швидке відстеження проекту означає, що діяльність працює одночасно, замість того, щоб чекати, коли кожен шматок буде завершений окремо. Але швидке відстеження може застосовуватися лише в тому випадку, якщо діяльність, про яку йде мова, насправді може бути перекрита» (Monnappa 2017).
    • float— Див. слабину.
    • Last Planner System (LPS) - Власна система планування виробництва, яка відображає концепції життєвого порядку та тягне мислення; розроблена Гленном Баллардом та Грегом Хауеллом як практична реалізація принципів Lean.
    • останній відповідальний момент— «Момент, коли вартість затримки рішення перевищує вигоду від затримки; або момент, коли неприйняття рішення усуває важливу альтернативу» (Lean Construction Institute).
    • віха— «Значна подія в проекті; зазвичай завершення великого результату» (Штат Мічиган: Департамент технологій, управління та бюджету).
    • path— «Послідовність пов'язаних дій» (Ларсон і Грей 2011, 662).
    • надійна обіцянка —У Lean та Last Planner System, формальні зобов'язання між членами команди. Як визначено Lean Construction Institute, «Обіцянка, зроблена виконавцем лише після того, як самовпевнений, що обіцянка (1) компетентна або має доступ до компетенції (як майстерності, так і коштів), (2) оцінила кількість часу, яке займе завдання, (3) заблокував весь час, необхідний для виконання, (4) вільно вчиняючи і не сумнівається в приватному порядку здатності досягти результату, і (5) готовий прийняти будь-які розлади, які можуть виникнути в результаті невиконання, як обіцяли» (Lean Construction Institute n.d.).
    • resource— «Будь-який персонал, матеріал або обладнання, необхідне для здійснення діяльності» (Project-management.com 2016).
    • графік —Конкретна карта, заснована на часі, призначена для того, щоб допомогти проектній команді перейти від поточного стану до успішного завершення проекту. Графік повинен будувати значення, мати ефективний потік і керуватися тяговими силами.
    • slack — «Розрахований проміжок часу, протягом якого подія повинна відбутися в межах логічних та накладених обмежень мережі, не впливаючи на загальну тривалість проекту» (Project-management.com 2016). Або простіше кажучи, слабкість, яку також називають float, - це «кількість часу, коли завдання може бути відкладено, не викликаючи затримки» до наступних завдань або кінцевої дати завершення проекту (Santiago and Magallon 2009).
    • спринт —У Agile управління проектами короткий (як правило, двотижневий) ітераційний цикл, орієнтований на створення ідентифікованого робочого результату (наприклад, сегмента робочого коду).
    • task- Див. Діяльність.

    ~Посилання

    Брукс-молодший, Фредерік П. 1975. Міфічний людина-місяць. Бостон: Аддісон-Уеслі.

    Харрін, Елізабет. 2017 рік. «Дізнайтеся, що таке віха проекту». Кар'єра балансу. 13 жовтня. https://www.thebalance.com/what-is-a...estone-3990338.

    Хубер, Боб і Пол Райзер. 2003 рік. Шлюб CPM та бережливого будівництва. Компанія «Болдт».

    Ларсон, Ерік В., і Кліффорд Грей. 2011 рік. Управління проектами: Управлінський процес, Шосте видання. Нью-Йорк: Освіта Макгроу-Хілл.

    Право, Джонатан, ред. 2016. Словник бізнесу та менеджменту. Оксфорд: Преса Оксфордського університету. https://books.google.com/books?id=w3...page&q&f=false.

    Ощадливий будівельний інститут ім. н.д. «Глосарій». Інститут бережливого будівництва. Доступ до 1 липня 2018 р. www.leanconstruction.org/training/глосарія/ #l.

    — н.д. «Останній планувальник». Інститут бережливого будівництва. Доступ до 1 липня 2018 р. www.leanconstruction.org/trai... -останній планувальник/.

    Леві, Ф.К., Г.Л. Томпсон, і Дж. Віст. 1963. «Азбука критичного шляху». Гарвардський бізнес-огляд. https://hbr.org/1963/09/the-abcs-of-...al-path-method.

    Моннаппа, Авантика. 2017 рік. «Навчальна серія управління проектами: швидке відстеження проти збоїв». Спрощене навчання. 19 грудня. https://www.simplilearn.com/fast-tra...ashing-article.

    Преактор. 2007 рік. «Пакетне планування в світі бережливого виробництва». Преактор. Лютий. http://www.preactor.com/Batch-Schedu...acturing-World.

    Проект-менеджмент. 2016 рік. «PMO та словник управління проектами». Управління проектами PM. 16 грудня. https://project-management.com/pmo-a...nt-dictionary/.

    Роуз, Маргарет. 2015 рік. «Метод критичного шляху (CPM)». Що таке.techtarget.com. Січень. http://whatis.techtarget.com/definit...ath-method-CPM.

    Штат Мічиган: Департамент технологій, управління та бюджету. 2013 рік. «Керування проектами Ключові терміни, визначення та абревіатури». Серпень. https://www.michigan.gov/documents/s...3_431285_7.pdf.