Skip to main content
LibreTexts - Ukrayinska

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

  1. Last updated
  2. Save as PDF
  • Page ID
    104531

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

    Готуючись до бою, я завжди виявляв, що плани марні, але планування є незамінним.
    —Дуайт Ейзенхауер, президент США (1953-1961), Верховний Головнокомандувач сил Альянсу в Європі (1943-1945)

    Цілі

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

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

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

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

    6.1 Новий спосіб думати про планування

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

    • Зміни в області застосування
    • Розклад
    • Вартість
    • Якість
    • Ресурси
    • Спілкування
    • Ризик
    • Закупівлі
    • Залучення зацікавлених сторін

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

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

    Планування - це прийняття невизначеності

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

    Рисунок 6.1: Кожне коло контексту додає до проекту свою мінливість та невизначеність.

    Як пояснили Олександр Лауфер та Грегорі Хауелл у статті для Project Management Journal, робота керівника проекту заснована в невизначеності (1993). Невизначеність не є винятковим станом в інакше передбачуваному процесі роботи, стверджують вони. Натомість це постійна риса сучасної роботи. Більше того, чим довший час між плануванням і реалізацією, тим вище невизначеність навколо індивідуальної діяльності. Природно, що чим вище невизначеність в проекті, тим складніше його планувати, і тим менш ефективними будуть плани при формулюванні дій і результатів. Нарешті, вони підкреслюють, що жоден обсяг планування не може усунути мінливість, властиву роботі складного проекту.

    Планування складності

    Олександр Лауфер та Грегорі Хауелл нагадують, що мінливість, властиву роботі складного проекту, неможливо усунути шляхом планування (1993). Але що саме являє собою складний проект? Чи всі складні проекти складні? У блозі для Team Gantt Тера Саймон пояснює: «Складний проект не обов'язково складний проект. Проекти можуть бути важкими через такі причини, як вартість або продуктивність, але це не означає, що проект є складним. Складність відноситься до проектів, які включають неоднозначність або невизначеність. Вони оточені непередбачуваністю» (2016).

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

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

    Якщо вас цікавить більш теоретичне дослідження ідеї складності, ознайомтеся з фреймворком Cynefin, який є інструментом прийняття рішень, покликаним допомогти менеджерам зрозуміти складність. Створена Девідом Сноуденом та Мері Бун, структура Cynefin дозволяє лідерам «бачити речі з нових точок зору, асимілювати складні концепції та вирішувати реальні проблеми та можливості». Він зосереджений на визначенні типу ситуації, в якій ви працюєте (простий, складний, складний або хаотичний), а потім зробіть вибір, відповідний цьому контексту.

    Для технічних керівників проектів найбільш корисним розумінням фреймворку є відмінність між складними та складними проектами. Сноуден і Бун обговорюють цю ідею в статті для Harvard Business Review:

    У складному контексті існує хоча б одна правильна відповідь. Однак у складному контексті правильні відповіді не можуть бути виключені. Це як різниця між, скажімо, Ferrari і бразильським тропічним лісом. Феррарі - це складні машини, але експертний механік може розібрати один на частини і зібрати його, не змінюючи нічого. Автомобіль статичний, а ціле - сума його частин. Тропічний ліс, з іншого боку, знаходиться в постійному потоці - вид вимирає, змінюються погодні умови, сільськогосподарський проект перенаправляє джерело води - і ціле набагато більше, ніж сума його частин. Це сфера «невідомих невідомих», і це сфера, до якої перейшла більша частина сучасного бізнесу. (2007)

    Подальше читання

    • Стаття Сноудена та Буна на основі Cynefin описує повний спектр складності проекту та містить посилання на додаткову інформацію: https://hbr.org/2007/11/a-leaders-fr...ecision-making.
    • Пост Тери Саймон про складні проекти описує навички, необхідні для вирішення складних проектів: https://www.teamgantt.com/blog/tackl...mplex-projects.
    • Цей пост Кетлін Хасс описує різноманітні складні проекти та впроваджує нову дисципліну управління проектами, комплексне управління проектами: https://www.projecttimes.com/article...ts-part-1.html

    Планування - це навчання

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

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

    Проект - це діяльність з розвитку знань.

    Після того, як ви прийняли неминучий перехід від стану незнання до стану відкриття, ви почнете ставити під сумнів можливість впевненості в плануванні проекту. Хорошим правилом є те, що якщо ви впевнені в тому, що майбутнє має для вашого проекту, ви, ймовірно, помиляєтесь або насправді не потребуєте плану проекту; простий список завдань може спрацювати. Особливо це актуально в сферах, де робота відбувається в різних місцях, при мінливих, часто непередбачуваних обставин. Як показали Дора Коенка-Залл, Олександр Лауфер та інші у своїх дослідженнях щодо планування будівельних проектів, «високий рівень невизначеності є правилом, а не винятком» (1994). Як ми обговорювали в Уроці 1, сучасні проекти розгортаються в тому, що Пітер Вайлл називає станом «постійної білої води» (Laufer 2012). Передбачити всі проблеми, які можуть виникнути протягом усього життя проекту, просто неможливо.

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

    Планування - це адаптація та співпраця

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

    У статті «Стати керівником проекту» Олександр Лауфер, Террі Літтл, Джеффрі Рассел та Брюс Маас розповідають історії про керівників проектів, які орієнтувалися на мінливі, складні проекти, сприяючи адаптації та співпраці (2018). Ці успішні менеджери об'єднали чотири основні стратегії:

    • Розвивається планування: підхід до планування проекту, заснований на навчанні, який передбачає, що команда проекту буде розширювати свої знання про проект у міру його розгортання.
    • Адаптивна спритність: Швидкі дії для вирішення проблем у міру розгортання проекту в поєднанні з чітким, сучасним спілкуванням.
    • Проактивна стійкість: кидання виклику «статус-кво, проактивно та вибірково» для запобігання потенційним проблемам.
    • Спільна командна робота: заохочення гнучкої, гнучкої та інтерактивної командної роботи.

    У Стати керівником проекту Олександр Лауфер, Террі Літтл, Джеффрі Рассел та Брюс Маас пояснюють цінність підходу рухомої хвилі до планування в нестабільних ситуаціях, в яких важко взяти на себе тверді зобов'язання. Успішні менеджери проектів розробляють плани «хвилями в міру того, як проект розгортається і інформація стає більш достовірною». Такий підхід передбачає об'єднання «детальних короткострокових планів» з 90-денними, середньостроковими планами та більш генеральними планами, що охоплюють тривалість проекту:

    Такий стиль планування не передбачає, що рішення повинні бути довільно «відкладені на потім». Швидше, це акт свідомого поділу тих аспектів планування, на які можна діяти більш доцільно в майбутньому. Застосовуючи такий підхід, уникають двох екстремальних ситуацій. Перший - це підготовка надто детальних планів занадто рано, що може призвести до швидкого старіння, оскільки деякі рішення ґрунтуються на інформації, наданій розумними здогадками, а не на достовірних даних. Інша екстремальна ситуація - затягування планування до тих пір, поки вся інформація не буде повною і стабільною. В обох випадках постраждає ефективність проекту. Своєчасні та тверді рішення можна приймати лише прийнявши стиль планування, який забезпечує більшу деталізацію на відповідному етапі проекту. (18-19)

    6.2 Підхід до геометричного порядку: поштовх

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

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

    Термін push plan використовується для опису плану проекту, заснованого на припущенні принципів геометричного порядку. Після завершення плану передбачається, що робота буде розгортатися відповідно, що призведе до заздалегідь визначеного результату проекту. (Див. Рис. 6-2.) Після того, як поштовх план приводиться в рух, зацікавлені сторони, як правило, зосереджуються на тому, щоб частини плану рухалися вперед. Термін поштовх вперше був використаний у виробництві для опису системи, в якій «виробництво базується на прогнозованому виробничому плані і де інформаційні потоки від управління до ринку, в тому ж напрямку, в якому потоки матеріалів» (BusinessDictionary n.d.).

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

    Система поштовху, як правило, будується на основі прогнозів попиту клієнтів, що може бути правильним або не може бути правильним. Однак, як тільки поштовх план приводиться в дію, фактичний попит на кінцевий продукт викликає менше занепокоєння під час виробництва, ніж необхідність тримати частини плану рухатися вперед. Пуш-план може бути доречним там, де тип проекту та заходи, які потрібно виконати, добре відомі та дуже схожі на попередні проекти. Він також доречний при виробництві товару для широкої аудиторії. У будівництві та виробництві кінцевою метою планування поштовху є виготовлення продукту за найменшими можливими витратами. У проекті push-plan субпідрядники зосереджуються на виконанні своєї роботи вчасно та за бюджетом, щоб вони могли назвати свою роботу закінченою та перейти до іншого проекту. Він побудований на основі прогнозів наявності робочої сили (див. Рис. 6- 3), які насправді важко передбачити і часто помилкові. Тим часом менеджери, як правило, оцінюються за їх здатністю відповідати заздалегідь визначеному виробничому графіку. Таким чином, індивідуальний інтерес сприяє просуванню проекту вперед, з обмеженою увагою до проекту, в якому керується робочий процес і відходи перешкоджають співпраці та координації.

    Малюнок 6-3: Планування поштовху будується на основі прогнозів доступності робочої сили, що може бути неправильним. (Адаптовано із зображення Девіда Томака.)

    Іноді ви знайдете планування поштовху, яке називається «make-to-stock» - ідея полягає в тому, що виробнича система поштовху обробляє великі партії товарів з найшвидшою швидкістю, виходячи з прогнозів попиту, а потім переміщує їх «до наступного процесу нижче за течією або в сховище» (Plex 2017). Це спрощений спосіб мислення про поштовх, але це хороший спосіб почати розуміти основну ідею. З цією метою наведемо кілька спрощених прикладів push-систем:

    • Підручники, які друкуються та відправляються на склад, де вони чекають замовлень від книжкових магазинів, які можуть знадобитися або не знадобитися. Загальна сума частково залежить від прогнозів продажів студентського попиту і частково від найменшої кількості книг, які принтер готовий друкувати.
    • Тротуарна сіль, яка виробляється та поставляється в господарські магазини в Сент-Луїсі. Така ж кількість відвантажується щороку, навіть під час виключно теплої зими, в якій температура ніколи не опускається нижче замерзання.

    Для жартівливого, але інформативного прикладу надзвичайно поганого планування поштовху дивіться знамениту сцену шоколадного обгортання від I Love Lucy, в якій бідні Люсі та Етель намагаються не відставати від все більш швидкої конвеєрної стрічки:

    Елемент YouTube був виключений з цієї версії тексту. Ви можете переглянути його онлайн тут: pb.libretexts.org/web1/? p=76

    Більш складні приклади планування push можна знайти в кожній галузі, включаючи виробництво, розробку продуктів, охорону здоров'я та будівництво. Ви можете визначити систему поштовху, подивившись на різні процеси в певній системі і визначити, що запускає той чи інший процес, щоб почати роботу. У системі поштовху процес вище за течією відповідає за натискання роботи на наступний процес нижче за течією. Наприклад, у лікарні відділення невідкладної допомоги може підштовхнути новоприбулого пацієнта вниз за течією, до хірургічного поверху, щоб чекати процедури (див. Рис. 6-4). Якщо на підлозі хірургії немає ліжок, пацієнту доведеться почекати у відділенні невідкладної допомоги, поки одне не відкриється. У цій поштовховій обстановці, де «перехід роботи є відповідальністю вищого (тобто попереднього) процесу», це до персоналу надзвичайних ситуацій, щоб керувати ситуацією, нарешті гарантуючи, що пацієнт дійсно отримує місце нижче за течією на підлозі хірургії (Інститут поліпшення охорони здоров'я н.д.).

    Малюнок 6-4: Потік пацієнтів в умовах поштовху лікарні.

    У системі поштовху відсутні явні обмеження на обсяг роботи, які можуть бути в процесі роботи в системі в будь-який час (Hopp and Spearman 2004, 142). Після початку роботи передбачається продовження, не враховуючи затримок через помилки, доступність ресурсів та інші проблеми. Таким чином, коли проблеми виникають, система сповільнюється до повзання або повністю зупиняється, оскільки їй не вистачає вбудованих механізмів оцінки та вдосконалення потоку, знайдених у Lean та інших методологіях життєвого порядку.

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

    Малюнок 6-5: Водоспад модель розробки програмного забезпечення.

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

    Модель водоспаду: трохи історії

    Модель Waterfall була вперше представлена Вінстоном Ройсом у статті 1970 року під назвою «Управління розробкою великих програмних систем». Ройс описав ідеальний процес розробки, в якому розробники займалися детальним плануванням на початку проекту, а потім написали код, щоб відповідати хвилинним специфікаціям, створюючи передбачуваний результат. Але Ройс не рекомендував це як реалістичний спосіб розробки програмного забезпечення. Насправді, речення відразу після його діаграми водоспаду говорить: «Я вірю в цю концепцію, але реалізація, описана вище, ризикована і викликає невдачу» (Royce). До його занепокоєння, його опис надмірно спрощеного методу водоспаду розірвав світ розробки програмного забезпечення 1970-х та 1980-х років, як лісова пожежа. Щоб цікаво розповісти про історію методу водоспаду, дивіться це відео Глена Вандербурга, починаючи з 9:00:

    «Реальна інженерія програмного забезпечення — Гленн Вандерберг, Lone Star Ruby Conference 2010».

    Елемент YouTube був виключений з цієї версії тексту. Ви можете переглянути його онлайн тут: pb.libretexts.org/web1/? p=76

    6.3 Підхід до живого порядку: планування витягування

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

    Мислення, що стоїть за тягою, виникло в 1948 році з Тайічі Оно, відомим як «батько виробничої системи Toyota», що, в свою чергу, призвело до Lean і Agile. Живучи в Японії після Другої світової війни, де дефіцит їжі був частою проблемою, Оно черпав своє натхнення в американських супермаркетах, з їх, здавалося б, магічною здатністю надавати все, що хотіли клієнти, коли вони цього хотіли:

    Потягніть мислення, перш ніж тягнути планування

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

    З супермаркету нам прийшла ідея розглядати більш ранній процес на виробничій лінії як своєрідний магазин. Пізній процес (клієнт) переходить до більш раннього процесу (супермаркет), щоб придбати необхідні деталі (товари) в той час і в необхідній кількості. Більш ранній процес відразу ж виробляє щойно взяте кількість (перезаправка полиць). (Жовтень 1988, 26)

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

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

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

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

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

    Малюнок 6-6: Планування витягування усуває відходи, усуваючи непотрібні кроки. (Джерело: Джон Нельсон)

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

    6.4 Розрізнення між поштовхом і тягненням

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

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

    Рисунок 6-7 ілюструє початок плану витягування для двох можливих типів відпустки - той, який залишає вас почуттям відпочинку, і той, який залишає вас почуттям бадьорості від нових вражень. Як і у всіх планах тягнути, секрет полягає в тому, щоб почати в кінці. Як ви хочете себе почувати по дорозі додому? Потім, як показано на малюнку 6-8, ви можете додати заходи до свого плану, які гарантують, що ви в кінцевому підсумку відчуєте себе таким чином. Як бачите, Post-IT Notes використовуються в обох малюнках. Хоча є багато програм планування та планування на вибір, Post-IT Notes, дуже низькотехнологічний варіант, широко використовуються в плануванні тягнути, оскільки їх легко пересуватися, тим самим заохочуючи планувальника випробувати нові ідеї.

    Малюнок 6-7: У плануванні тяги ви починаєте з бажаного кінцевого стану

    Малюнок 6-8: Після визначення бажаного кінцевого стану ви можете планувати заходи, які призведуть до цього кінцевого стану.

    Потягніть планування в дії

    Для більш широкого вступу до планування потягу див. Це одногодинне відео, створене авторами цієї книги, в якому планування відпустки використовується як спосіб пояснити основні концепції планування тяги.

    Елемент YouTube був виключений з цієї версії тексту. Ви можете переглянути його онлайн тут: pb.libretexts.org/web1/? p=76

    Коли ви навчитеся визначати поштовх і тягнути на роботі в різних середовищах, ви почнете бачити, як організації використовують той чи інший, або поєднують обидва підходи для досягнення своїх цілей. Справа в тому, що «в реальному світі немає чистих поштовх або чистих тягових систем» (Hopp and Spearman 2004, 143). Ви також виявите, що поняття push and pull використовуються для підкреслення різних проблем у різних контекстах.

    Наприклад, розглянемо, як ці терміни використовуються в світі управління ланцюгами поставок, що охоплює «всі заходи, які повинні відбутися, щоб отримати потрібний продукт в руки потрібного споживача в потрібній кількості і в потрібний час — від видобутку сировини до закупівлі споживача». (Майська бізнес-школа н.д.). В управлінні ланцюгами поставок експерти push/pull часто говорять про межу між штовхаючою частиною системи та частиною тяги (Sehgal 2009). Як і в наступному прикладі, межа між поштовхом і тягненням зазвичай виникає після того, як продукт був виготовлений в умовах поштовху, на основі загальних прогнозів споживчого попиту, і зберігається до тих пір, поки конкретні запити конкретних клієнтів не витягнуть продукт на ринок:

    Виробник продуктів харчування може зробити грибний суп, який вони брендують кількома способами - власною етикеткою плюс етикеткою кількох мереж супермаркетів. Виробник має гарне уявлення про кількість супу, яке їм потрібно щомісяця. Однак вони менш впевнені в тому, як упакувати його, щоб задовольнити попит. Як результат, вони, швидше за все, вирішать масове виробництво грибного супу та інвентаризувати його в банках без маркування, поки не здійсниться замовлення. Тоді вони можуть швидко маркувати банки та відправити їх, коли клієнти розміщують свої замовлення. (МакГінлі 2016)

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

    Потягніть публічні виступи

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

    Він узагальнює свій досвід наступним чином:

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

    6.5 Потягніть і спритний

    Спритний на допомогу

    Багато проблем, пов'язаних з розгортанням веб-сайту Healthcare.gov в 2013 році, можна простежити до спроби використовувати модель розвитку водоспаду для великого і складного проекту. Проект врятувала команда Agile розробників, багато з яких, по суті, добровільно витратили свій час, щоб запустити систему. Ви можете прочитати все про це тут: «Команда травми Обами: Як малоймовірна група високотехнологічних майстрів відродила проблемний веб-сайт Обами HealthCare.gov».

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

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

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

    Оскільки програмне забезпечення стає все більш важливим у багатьох типах продуктів, цілком ймовірно, що Agile з його циклами швидкого зворотного зв'язку та ревізій стане все більш поширеним у розробці продуктів, у тому числі серед великих виробників, таких як John Deere. Цикли розробки Agile швидше виробляють робоче програмне забезпечення, що полегшує отримання зворотного зв'язку від маркетингу та клієнтів раніше в життєвому циклі розробки продукту. Agile engineering, як називається ця нова форма розробки продукту, заохочує команди дізнатися про свій продукт і зробити поліпшення швидше, ніж вони могли б при традиційній розробці продукту. У блозі для FormLabs, виробника високотехнологічних 3D-принтерів, Joris Peels пише:

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

    За допомогою традиційних методів команди ретельно складають карти світу, а потім витрачають місяці на планування можливого маршруту через цей уявний світ. Тільки тоді вони мають продукт і дійсно знають, де вони стоять. Завдяки Agile Engineering продукти з'являються в перший тиждень розробки продукту. Команди вирушають і часто перевіряють свій компас. (2016)

    6.6 Сталий розвиток: планування постійного вдосконалення

    Постійне вдосконалення - це «метод визначення можливостей для впорядкування роботи та зменшення відходів» (LeanKit n.d.). Відомий у Lean як кайдзен (японський для вдосконалення), постійне вдосконалення є ключовою концепцією Lean та Agile, але є мотивуючою силою у всіх типах організацій. Щоб повністю включити постійне вдосконалення у філософію вашої організації, вам потрібно вбудувати її в проекти, починаючи з етапу планування. Дійсно, сам процес планування сам по собі є безперервним вдосконаленням діяльності, оскільки він передбачає погляд у майбутнє і мислення про те, як зробити речі краще.

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

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

    Поставте цілі для вдосконалення. За результатами базової оцінки фірма повинна розробити комплексний набір цілей для вдосконалення. Цілі повинні бути вимірними за встановленими показниками. Графіки... також повинні бути встановлені...

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

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

    6.7 Слово про плани на випадок надзвичайних ситуацій

    Остерігайтеся помилки планування

    Відповідно до цього цікавого та розважального подкасту, люди генетично підключені до оптимізму. Це робить нас болісно сприйнятливими до помилки планування, когнітивного ухилу, який змушує нас думати, що ми можемо закінчити проекти швидше і за менші гроші, ніж насправді реалістично: «Ось чому всі ваші проекти завжди запізнюються - і що з цим робити (Freakonomics Podcast). »

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

    Приклади питань, які можуть спричинити необхідність використання резервного фонду:

    • Неадекватні початкові оцінки
    • Дрібні предмети, не охоплені плануванням
    • Помилки в початкових кошторисах
    • Невеликі відхилення через неминучі затримки

    Зверніть увагу, що резервний фонд не призначений для управління основними відхиленнями або змінами сфери застосування.

    Простою та ефективною формою планування на випадок надзвичайних ситуацій є виділення резервного фонду, що складається з фіксованого відсотка всіх ресурсів (часу, грошей, людей) на додаток до сум, прописаних у підсумковому бюджеті. Десять відсотків - це типова сума, але вона може варіюватися залежно від розміру та типу проекту, а також типу галузі. Наприклад, цей набір настанов на випадок непередбачених ситуацій, створених Університетом штату Арізона для проектів будівництва кампусу, показує діапазон відсотків на випадок непередбачених ситуацій: «Керівні принципи проекту на випадок непередбачених ситуацій». Так само Міністерство енергетики США описує фіксований процентний підхід до планування надзвичайних ситуацій тут: «Непередбачені ситуації».

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

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

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

    • Використовуйте правильний рівень деталізації: план проекту повинен бути розміщений на потрібному рівні, з достатньою деталізацією. План дуже високого рівня з мінімальною деталізацією не буде значущим для всіх зацікавлених сторін. З іншого боку, надзвичайно складний план проекту з непотрібною деталізацією та нескінченними списками завдань може бути настільки важко оновити, що люди часто просто нехтують цим. У цей момент такий план стає гіршим, ніж марним. Як правило, план проекту потребує 15-50 заходів. Це допоможе забезпечити, щоб план був достатньо деталізований, щоб діяти далі, але керований достатньо, щоб постійно оновлюватися. Потім ви можете використовувати підплани, щоб розбити завдання до більш докладної інформації.
    • Будьте готові адаптувати свій план, щоб відобразити мінливі реалії: Плануючи проект, ніколи не припускайте, що ви намагаєтеся досягти фіксованої мети. У переважній більшості проектів мета фактично рухається. Ви повинні бути гнучкими і адаптувати свій план в міру необхідності.
    • Плануйте на належному рівні точності: Слідкуйте за тим, щоб не планувати на рівні точності, який перевищує ваше розуміння багатьох факторів, які можуть вплинути на проект. Це створює відходи двічі: спочатку в процесі планування, а потім на етапі виконання, коли ви виявите, що план потрібно переглянути, щоб відобразити реальність ситуації. Ви можете бути впевнені, що ваше планування передбачає нереальний рівень точності, якщо, наприклад, це призводить до оцінки, як $380,275,465.47. Цей рівень точності передбачає рівень точності, якого немає в реальному світі. Корисніше сказати, що такий проект коштує десь в діапазоні від 350 до 400 мільйонів доларів.
    • Використовуйте технологію планування як один із багатьох інструментів планування: Використовуйте технологічні інструменти, такі як програмне забезпечення для управління проектами, щоб усі зацікавлені сторони розуміли та знали, як отримати доступ. Але не робіть помилки, думаючи, що створення графіка - це те саме, що планування проекту. Графік - це лише один аспект плану проекту.
    • Слідкуйте за успіхом: Протягом усього процесу планування підтримуйте чіткий фокус на визначенні успіху проекту.
    • Зберіть всіх разом для планування. Якщо ваша команда розкидана по декількох географічних місцях, постарайтеся, щоб усі зустрілися в одному місці принаймні на етапі планування. Це може пройти довгий шлях до усунення непорозумінь, спричинених погано сформульованими електронними листами або конференц-дзвінками, в яких деякі зацікавлені сторони можуть домінувати більше, ніж інші.
    • Подумайте цілісно про свій план проекту: Хороший план проекту зачіпає кожен елемент проекту. Це 3,5-хвилинне відео дає короткий огляд речей, про які слід подумати при плануванні проекту: «Що входить у план проекту? »

    ~Резюме

    • У живому порядку план - це не самоціль, а скоріше стратегічна основа для планування та виконання проекту. Корисно думати про проект як діяльність з розвитку знань. Таким чином, планування проекту - це безперервний процес включення нових знань у проектний план. План проекту є інструментом для співпраці, а сам процес планування - це спільна вправа, яка часто є першим випробуванням здатності керівника команди будувати довіру між членами та скористатися численними перспективами, пропонованими різноманітною командою.
    • Планування геометричного порядку передбачає лінійну прогресію послідовних, передбачуваних дій. Термін push plan використовується для опису плану проекту, заснованого на припущенні принципів геометричного порядку.
    • Планування тяги - це практичне застосування підходу до планування проекту. Він є спільним, гнучким і рекурсивним, і особливо підходить для дуже складних проектів, в яких зацікавлені сторони повинні адаптуватися до нової інформації. Він передбачає спільну групу працівників, які регулярно координують свою роботу, оновлюючи свій план, щоб відобразити поточні умови. Він зосереджений на виробництві стільки, скільки насправді може бути завершено і не більше.
    • Agile використовує підхід до планування розвитку програмного забезпечення. Він є ітераційним і передбачає постійну адаптацію у відповідь на розвивається уявлення замовника про вимоги до програмного забезпечення.
    • Постійне вдосконалення, ключова концепція Lean та Agile, є важливою ідеєю для організацій, які прагнуть вносити системні зміни в галузі сталого розвитку, а також для окремих проектів, пов'язаних зі сталим розвитком.
    • Окрім створення плану проекту, вам потрібно створити план на випадок надзвичайних ситуацій, який стосується результатів, не прописаних у плані проекту.

    ~Глосарій

    • Agile engineering- Нова форма розробки продукту, яка використовує інтерактивні цикли швидкого зворотного зв'язку та ревізій, вперше реалізованих у розробці програмного забезпечення Agile. Це заохочує команди дізнаватися про свій продукт і робити вдосконалення швидше, ніж вони могли б при традиційній розробці продуктів.
    • когнітивне рефреймінг —процес перегляду подій та фактів, щоб побачити їх по-новому.
    • план на випадок надзвичайних ситуацій —План альтернативного шляху до успіху проекту, який може бути реалізований, якщо виникне перешкода для прогресу.
    • резервний фонд - ресурси, виділені для покриття непередбачених витрат.
    • plan —Стратегічні рамки для планування та виконання проекту. У традиційному плануванні проекту геометричного порядку план передбачає, що події будуть розгортатися передбачувано, з невеликою потребою оновлювати план. У плануванні проекту життєвого порядку план завжди є попереднім і може бути змінений.
    • упередженість планування —Когнітивний ухил, який змушує нас думати, що ми можемо закінчити проекти швидше і за менші гроші, ніж насправді реалістично.
    • планування проекту —У традиційному, геометричному порядку планування проекту, процес формування плану, який буде керувати рештою проекту. У живому порядку планування проекту, «планування проекту» також відноситься до безперервного процесу включення нових знань в початковий план проекту.
    • pull planning —Планування проекту, яке враховує непередбачуваний, постійно мінливий характер життєвого порядку. Pull планувальники починають з бажаного кінцевого стану проекту, працюючи назад, щоб визначити найбільш ефективний (найменш марнотратний) спосіб досягнення бажаного результату. Щоб бути ефективним, планування тяги вимагає спільної групи працівників, які регулярно координують, оновлюючи свій план, щоб відобразити поточні умови.
    • pull schedule —Розклад, як правило, складається з кольорових наклейок, які можуть бути видалені або переміщені в міру необхідності. Це також може бути відтворено в ряді різних програмних програм. Головне - почати з кінцевої мети, а потім працювати назад, щоб визначити завдання, необхідні для досягнення цієї мети.
    • push planning —Планування проекту, яке передбачає, що події будуть розгортатися в передбачуваному геометричному порядку. Push планування засноване на управлінських прогнозах попиту клієнтів, з великим акцентом на необхідність тримати частини плану рухатися вперед. Менеджери та субпідрядники зосереджуються на своїх окремих ділянках проекту, з обмеженою увагою до управління робочим процесом та запобігання відходів через співпрацю та координацію.
    • Управління ланцюгом поставок —Усі «заходи, які повинні відбутися, щоб отримати потрібний продукт у руки потрібного споживача в потрібній кількості та в потрібний час - від видобутку сировини до покупки споживачем» (Mays Business School n.d.).
    • модель водоспаду —Модель поштовхового плану, що використовується для програмного забезпечення, що розбиває процес розробки на набір дискретних послідовних кроків. Це передбачає передбачуваний результат проекту, з невеликою або взагалі відсутністю можливості для коригування в міру розгортання проекту.

    Додаткові ресурси

    • Це одногодинне відео, створене авторами цієї книги, використовує планування відпустки як спосіб пояснити основні концепції планування тяги: https://go.wisc.edu/livingpm.
    • Глосарій Lean Будівельного Інституту, з визначеннями «штовхати» та «тягнути»: визначення «штовхати» та «тягнути».
    • У цій книзі Пітер Вайлл вводить термін «постійна біла вода:» Управління як виконавське мистецтво: нові ідеї для світу хаотичних змін (1989).
    • У цьому відео учасники семінару будують два будинки з пластикових блоків, перший, дотримуючись традиційного плану поштовху, а другий, використовуючи елементи планування тяги: «Майстерня планування тяги: Коледж Сан-Дієго Меса». Ви не будете здивовані, дізнавшись, що будинки з плануванням витягування були завершені швидше, з більшою співпрацею та більшим загальним задоволенням серед членів команди.

    Посилання

    Бізнес-словник. н.д. «Система поштовху». Бізнес-словник. Доступ до 1 липня 2018 року. http://www.businessdictionary.com/de...sh-system.html.

    Кохенка-Залл, Дора, Олександр Лауфер, Авіад Шапіра та Грегорі Хауелл. 1994 рік. «Процес планування під час будівництва». Журнал будівельної інженерії та менеджменту, вересень: 561-578. tx.Technion.ac.il/~Avishap/Du... n-Planning.pdf.

    Хопп, Уоллес Дж., і Марк Л.Спірмен. 2004 рік. «Тягнути чи не тягнути: в чому питання?» Управління виробничими та сервісними операціями 133-148.

    Інститут вдосконалення охорони здоров'я. n.d. «Використовувати системи тяги для поліпшення потоку». ihi.org. Доступ до 1 липня 2018 р. www.ihi.org/Ресурси/Сторінки/C... llSystems.aspx.

    Лауфер, Олександр. 2012 рік. Оволодіння лідерською роллю в управлінні проектами: практики, які дають чудові результати. Верхня річка Сідла: FT Press.

    Лауфер, Олександр, Террі Літтл, Джеффрі Рассел та Брюс Маас. 2018 рік. Стати лідером проекту: планування, спритність, стійкість та співпраця для реалізації успішних проектів. Нью-Йорк: Палгрейв Макміллан.

    LeanKit. n.d. «Що таке постійне вдосконалення?» LeanKit. Доступ до 1 липня 2018 року. https://leankit.com/learn/kanban/con...s-improvement/.

    Лемке, Клаус. 2016. — «3 простих правила ефективного планування витягування». LeanProject. 15 грудня. http://www.leanproject.com/news/3-si...pull-planning/.

    Mays Business School. н.д. «Що таке управління ланцюгами поставок?» Бізнес-школа Мейса, Техаський університет A&M. Доступ до 1 липня 2018 року. http://mays.tamu.edu/department-of-i...in-management/.

    МакГінлі, Білл. 2016 рік. «Як визначити, коли використовувати планування виробництва Push або Pull». Карпедія. 24 жовтня. http://carpedia.com/blog/determine-u...on-scheduling/.

    Меррілл, Роберт, інтерв'ю Енн Шаффер. 2017 рік. Старший бізнес-аналітик, Університет Вісконсин-Медісон (2 жовтня).

    Оно, Тайічі. 1988 р. Виробнича система Toyota: поза великомасштабним виробництвом. Кембридж, Массачусетс: Продуктивність преса.

    Пілс, Йорис. 2016 рік. «Чому Agile Engineering - це майбутнє дизайну продуктів». FormLabs. 7 березня. Доступ до 5 2017 р., жовтень. https://formlabs.com/blog/agile-engi...t-development/.

    Плекс. 2017 рік. «Виробництво Push проти Pull: Чи підходить система витягування Kanban для вашої компанії?» Тиждень промисловості, 28 липня. http://www.industryweek.com/cloud-co...t-your-company.

    Ройс, W.W. 1987. «Управління розвитком великих програмних систем: концепції та методи». ICSE '87 Матеріали 9-ї міжнародної конференції з програмної інженерії. Монтерей: Преса комп'ютерного товариства IEEE. 328-338.

    Сегал, Вівек. 2009 рік. «Натиснути або потягнути?» Ланцюги поставок. 7 жовтня. http://www.supplychainmusings.com/20...h-or-pull.html.

    Саймон, Тера. 2016. 5 цінних навичок, необхідних для вирішення складних проектів, як професіонал. 5 грудня. Доступ до 10 2019 р., вересень. https://www.teamgantt.com/blog/tackl...mplex-projects.

    Сноуден, Девід Дж., і Мері Бун. 2007. «Рамки лідера для прийняття рішень». Гарвардський бізнес-огляд. https://hbr.org/2007/11/a-leaders-fr...ecision-making.

    Томак, Девід. 2018 рік. «Вступ до Lean та реалізації проектів». Відеолекція для CEE 498: Управління будівництвом. Університет Вісконсин-Медісон, Інженерний коледж, 20 квітня.

    Томсен, Чак, Джоел Даррінгтон, Денніс Данн та Вілл Ліхтіг. н.д. «Управління інтегрованою доставкою проектів». LeanConstruction.org. Доступ до 26 вересня 2018 року. https://www.leanconstruction.org/wp-...Delivery_1.pdf.

    Уоллес, Білл. 2005 рік. Становлення частиною рішення: Посібник інженерів зі сталого розвитку. Вашингтон, округ Колумбія: Американська рада інженерних компаній.