Слідами “Project Rhapsody»

11-12 квітня 2019 пройшла 13-а Microsoft Project Conference “Project Rhapsody”. Конференція організована нашим партнером, «LEO Consulting», і традиційно виділяється підбором професійних спікерів і високим рівнем проведення.

Зупинимося на деяких цікавих можливостях і ідеях з виступів.

Нашу увагу привернула можливість інтегрувати діаграми і моделі процесів, створені в Microsoft Visio, і dashboards, створені в Power BI. Така функціональність буде корисною для побудови системи контролю та моніторингу бізнес-процесів, коли ви зможете відслідковувати і показники ефективності процесу (PPI) в цілому, і його окремо взятих елементів: завдання, розвилки, підпроцеси. Перейдіть за посиланням, і ви побачите, як все вищенаведене виглядає «вживу». Клікнувши мишкою по елементам діаграми Visio і графікам в Power BI, ви побачите, як вони взаємодіють один з одним.

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

Дещо про Gamification. Створення своєї проект-історії з образами відомих кіно- і мультгероїв викликає у учасників проекту відчуття причетності, особливого внеску в спільну справу, інтересу до досягнення будь-яких вигадано-реальних цілей. А також гейміфікація може бути використана як один із способів усунення негативних ситуацій в проектах. Уявіть, що ваш QA асоціює себе, наприклад, з героєм коміксів Marvel, Беном Гриммом. Володіючи неймовірною фізичною силою, він може годинами безперервно сидіти і тестувати, тестувати, тестувати – він же герой і робить свою роботу на благо людства. Щоб відповідати образу свого героя, QA буде з більшою віддачею і енергією працювати в проекті, підтверджуючи свою «силу». Грайте і ваш проект буде яскраво виділятися серед безлічі інших.

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

Не секрет, що сьогодні компанії конкурують не продуктами, а моделями управління і здатністю швидко змінюватися, тобто бути гнучкими. Гнучкість же досягається, в першу чергу, за допомогою знань. А знаннями потрібно керувати. Завжди робіть «розбір польотів» протягом і в кінці проекту. Для цього можна використовувати 5 питань:

  1. Що мало статися?
  2. Що сталося не так, як спочатку планувалося?
  3. Що вийшло добре і чому?
  4. Що не вийшло і чому?
  5. Чому ми можемо навчитися?

Чим частіше будете проводити «розбір польотів», тим більше часу в майбутньому ви заощадите при реалізації інших проектів. Варто нагадувати собі, що 1 година навчання економить 2 години роботи.

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

Приєднуйтесь до нас на наступній конференції, буде цікаво обмінятися враженнями.

  ,
Поділитися з друзями

Радимо прочитати

Agile: революція чи… еволюція?
Agile: революція чи… еволюція?
На тренінгах з управління проектами та управління бізнес-процесами ми часто отримуємо запитання про agile-практики і їх безальтернативність в сучасному швидкоплинному світі. Ми детально розповідаємо про переваги та обмеження agile.І навіть йдемо далі: демонструємо, як проекти і процеси доповнюють один одного і чому agile-практики можна чудово застосовувати для оптимізації бізнес-процесів. Давайте спробуємо історично простежити, чому agile-практики близькі до процесного управління і які концепції передували їх появі. Поява Agile У 2001 році група розробників програмного забезпечення (ПО) зібралася в м.Юта (США), щоб запропонувати нову методологію управління проектами з розробки ПЗ на противагу класичним «бюрократичним і важким» підходам. Прийти до консенсусу по методології не вдалося, зате з'явився «Agile-маніфест», який позиціонувався як радикально новий підхід до управління проектами. З легкої руки Кена Швабера (Ken Schwaber) Agile починають називати революцією в управлінні проектами. Ідеї, які лягли в основу Agile-маніфесту, з'явилися задовго до 2001 року. Звернімося до історії (див. мал.1). Мал.1  PM/BPM Timeline Фредерік зустрів Генрі Коріння Agile йдуть в 1878 рік, коли Фредерік Тейлор (Frederick Taylor) представив теорію «Наукового менеджменту». Тейлора асоціюють зі стандартизацією праці на виробництві та підвищенням продуктивності бізнес-процесів. Однак його внесок в розвиток інструментів управління проектами та процесами цим не обмежується. Справа в тому, що в 1887р. Фредерік Тейлор найняв помічником Генрі Гантта (Henry Gantt), який на початку 20 століття запропонував знайомий багатьом спосіб візуалізації план-графіка проекту (див. мал.2). Через 100 років діаграма Гантта все ще залишається популярним інструментом серед керівників проектів. Мал.2 Діаграма Гантта Народження Lean та ітеративних практик Праці Тейлора дали поштовх подальшому вивченню бізнес-процесів. Френк і Ліліан Гилбрет (Frank and Lilian Gilbreth) в 1921р. запропонували використовувати діаграми процесу (process charts) для його візуалізації, аналізу та удосконалення. В основі їх рекомендацій по оптимізації лежали: стандартизація процесу, усунення втрат (waste) і спрощення роботи співробітників. У 1930р. Ліліан Гилбрет презентувала спосіб візуалізації потоку робіт за допомогою інструменту, відомого сьогодні як Kanban-дошка: «We had three rows of hooks, one marked "Jobs to be done", one marked "Jobs being done" and a third marked "Jobs completed" with tags which were moved from hook to hook to indicate the progress of the task. (Джерело: 1930 Speech by Lillian Gilbreth to National Federation of Business and Professional Women's Clubs in New York)». Мал.3 Kanban-дошка Через деякий час, після завершення другої світової війни, в 1950 році на зустрічі з японською спільнотою вчених й інженерів, доктор Едвардс Демінг (Edwards W. Deming) представив ідеї статистичного контролю процесу (Statistical Process Control) і циклу PDCA (Plan-Do-Check- Act). Цикл PDCA має на увазі ітеративну роботу над поліпшенням бізнес-процесу: починається все з планування, потім слідує реалізація ініціатив щодо поліпшення, перевірка отриманих результатів і рішення про подальші дії на наступній ітерації. Найбільш популярний agile-фреймворк Scrum пропонує фактично аналогічний підхід до організації роботи проектної команди (мал. 4). Використання agile-практик в проектах по оптимізації бізнес-процесів виходить настільки органічним саме тому, що agile є еволюцією циклу PDCA. Мал.4 Two-week sprint Кіічиро Тойода (Kiichiro Toyoda) познайомився з роботами Гілбретів в 1929 році під час поїздки в США і Європу. У 50-х роках компанія Тойота стала піонером в адаптації ідей Гілбретів і Демінга. Виробнича система Тойота (Toyota Production System) увібрала в себе ідеї стандартизації роботи, усунення втрат, безперервного вдосконалення за ітеративним принципом, канбан та ін. На хвилі зростання інтересу до японських автовиробників в 80-х роках в США з'явився термін Lean Production (бережливе виробництво). Lean - маркетингова назва принципів виробничої системи Тойота. Підхід швидко набрав популярність, і незабаром з'явилися адаптації Lean для інших галузей. Концепція Lean software development стала однією з перших agile-методологій по розробці програмного забезпечення. В цей же час в Японії розвивалися фабрики розробки ПО (Software factories). По мірі слабшання бар'єрів в торгівлі та глобалізації бізнесу доводилося адаптувати практики паралельної розробки для географічно розподілених команд. Ідеї усунення втрат (elimination of waste), стандартизації ролей і спрощення процесу дісталися до самої прогресивної, на сьогоднішній день, галузі через 60 років після виникнення. «Залізний» трикутник, інкрементальні і ітеративні практики Повернемося до «класичного» управління проектами і згадаймо діаграми процесів Гілбретів. Саме їх компанія DuPont адаптувала і поклала в основу свого Critical Path Method (CPM). Діаграма Гантта, критичний шлях і «залізний» трикутник стали популярними інструментами керівників проектів в 60-х роках минулого століття. Через 40 років ідею трикутника стали використовувати послідовники agile для пояснення відмінностей класичного управління проектами та agile-практик (див. мал. 5).   Мал.5 Agile-підхід У 60-х роках виникли перші згадки про інкрементальні і ітеративні практики управління проектами. Вперше це сталося в проекті Меркурій, який реалізувала NASA в 1958-1963 рр. Трохи пізніше, з 1968 року, почалася адаптація ітеративних практик під проекти розробки ПЗ. Через деякий час ітеративні практики включили в фреймворк PROMPT (праобраз сучасного PRINCE2) і керівництво PMBOK (згадується як спіральний життєвий цикл проекту, spiral project lifecycle). З нашої точки зору, концепція Agile стала закономірним продовженням еволюції підходів, які використовувалися раніше, наприклад, в проектах по розробці ПЗ та оптимізації бізнес-процесів. Історія показує, що більшого успіху досягають ті компанії, які комбінують різні інструменти і методології, в залежності від специфіки проекту і контексту, в якому він реалізується. Судячи з усього, в недалекому майбутньому agile-практики також будуть еволюціонувати і в управлінні проектами з'являться нові «революційні» ідеї.   При підготовці статті використовувалися матеріали: McKenna T, Whitty SJ. (2013) Agile is Not the End-Game of Project Management Methodologies. In: Proceedings of the Annual Project Management Australia Conference Incorporating the PMI Australia National Conference (PMOz), Melbourne, 17-18 September 2013. Читати далi 
Lviv PM Day 2018 і два виступи від Дмитра Лук’янова
Lviv PM Day 2018 і два виступи від Дмитра Лук’янова
10 листопада 2018 року у Львові відбулася конференція PM Day Lviv 2018. PM Day Lviv завершив серію «PM Day», яка щорічно проходить в Одесі, Харкові, Львові та Києві. Керуючий партнер «Бюро проектного менеджменту» Дмитро Лук'янов потішив відразу двома виступами. У потоці «Agile і гнучкі методології» він презентував тему «Історичний слід» в японській методології управління проектами: від «Книги п'яти кілець» до стандарту «Р2М». Дмитро провів аналогії між «Шляхом воїна» і «Шляхом проектного менеджера» з урахуванням цінностей Scrum і кожної з «П'яти книг» М.Мусасі: книг «Землі», «Води», «Вогню», «Вітру» і «Порожнечі». У потоці «Product Management» обговорили "Звідки з’являються Product Owner`и - ними народжуються чи стають?". Дмитро провів інтерактивне дослідження. В результаті спільної роботи з учасниками вийшли профілі «Власника Продукту» і «Керівника Проекту» за моделлю PAEI Адізеса. А також народилося спільне бачення того, як змінюється рольова модель команди по Белбіну з урахуванням тренда на діджиталізацію. Нагадаємо постулат Іцхака Адізеса про те, що не існує «ідеального менеджера», у якого всі чотири ролі - P, A, E і I - представлені на однаково високому рівні. Дмитро запропонував розкласти профілі «Власника Продукту» і «Керівника Проекту» і подивитися, як вони взаємно поєднуються. В учасників сесії народилася «ідеальна пара» - модель PaEi «Власника Продукту» відмінно доповнюється моделлю pAeI «Керівника Проекту». Так сам по собі вирішилось і одне з питань дискусії - наскільки гарна ідея поєднувати ці дві ролі в одній людині, а також і питання про те, чи можна очікувати успішної трансформації PM'а в PO'а і навпаки. Рекомендації Дмитра: Давати співробітникам ті ролі, до яких вони природно схильні. На різних етапах життєвого циклу в організації затребувані різні типи менеджерів. Необхідно враховувати специфіку організації та типи проектів, що ведуться. Використовувати кілька методик у визначенні рольових переваг, розглядати команду під різними кутами. Добре зарекомендувала себе на практиці методика М.Белбіна. Табл.1 Функції і ролі менеджменту, життєвий цикл організації Джерело Презентації можна знайти тут: Японська методологія і цінності Srum Product Owner Читати далi 
Тренди в управлінні проектами
Тренди в управлінні проектами
Надокучив agile/scrum? Поговоримо про нові тренди в управлінні проектами. Цифрова трансформація. Вже не одноразово писали про цей тренд. Він охопив практично всі галузі і напрями бізнесу. Управління проектами не є винятком. Наслідком проникнення цифрових технологій стає, наприклад, поступово- зворотне зміщення компетенцій керівника проекту від «м'яких» навичок (soft skills) до технічних (hard skills), хоча soft skills продовжують домінувати. Зниження ролі ІТ-директорів в компаніях. Взаємозв'язок між потребами бізнесу і інформаційними технологіями посилюється. Це вимагає від ІТ-директорів глибшого розуміння бізнесу, а від функційних керівників більш глибокого розуміння ІТ. Згідно досліджень Gartner, все частіше ІТ-бюджети передають в управління представникам бізнес підрозділів. З розвитком хмарних технологій, мобільних додатків, low-code додатків ІТ-директора, які недостатньо глибоко розбираються в бізнесі, будуть втрачати авторитет серед топ-менеджменту компаній. Зростання популярності гібридних практик (hybrid practices) управління проектами. Незважаючи на хайп навколо agile-підходів, вони так і не стали лідируючою методологією в управлінні проектами. Однак завдяки їхньому впливу, згідно з дослідженням PMI Pulse of the profession, в 2019 році гібридні практики випередили і Agile, і DevOps. Мал.1. Дослідження PMI Pulse of the profession 2018   Мал.2. Дослідження PMI Pulse of the profession 2019   Слідкуйте за нашими публікаціями, будемо розповідати докладніше про гібридні практики. Читати далi