Ви працюєте над проектом? Або те, що ви робите, є частиною щоденних операцій вашого бізнесу? Обидва необхідні в організації та однаково дійсні, але це допомагає зрозуміти, над чим ви працюєте, щоб ви могли краще побачити, де це вписується в загальну стратегію.
Існує п’ять основних відмінностей між проектною роботою та звичайною роботою (часто скорочено BAU). Пам’ятаючи про ці вказівки, має бути легко зрозуміти, чи працюєте ви над проектами чи BAU, чи обома.
Прив’язаний до часу vs. Триває
Проекти мають початкову, серединну та кінцеву дати та є одноразовою подією. Це життєвий цикл проекту. Насправді найбільш визначальною характеристикою проекту є те, що він має кінець. У цей час керівник проекту та команда працюють над проектом. Наприкінці команда зазвичай розпускається.
BAU триває. Ви, звичайно, можете закрити функцію або зупинити процес, якщо він більше не потрібен для бізнесу, але навіть це зазвичай робиться як проект. Функція BAU створює поточну роботу без передбачуваної дати завершення.
Творці змін vs. Зміна ідентифікаторів
Існує різниця в тому, як обробляються зміни в роботі проекту та BAU. Команди BAU визначають потребу в змінах, а команди проекту впроваджують ці зміни.
Оскільки команди BAU керують бізнесом, вони також перші дізнаються, коли існуючі процеси не працюють і більше не корисні. Коли це відбувається, вони виявляють потребу в змінах.
У рамках стратегічного аналізу керівник може запропонувати, які зміни необхідно внести, щоб підрозділ досяг своїх цілей. Або член команди може запропонувати зміни. На іншому кінці спектру ви можете мати повне бізнес-обгрунтування, розроблене старшим менеджером, щоб внести зміни, необхідні для того, щоб допомогти їх підрозділу досягти своїх річних цілей. Ті, хто працює на посадах BAU, також можуть усвідомити, що зміни є важливими через зміни в нормативно-правовій базі або як частину конкурентного середовища для організації.
Команди проекту допомагають впроваджувати всі ці необхідні зміни. Проекти вносять зміни до функцій BAU та через них за допомогою керування проектами. Зазвичай це відбувається після того, як проект проходить обґрунтування та процес затвердження вищим керівництвом.
Управління проти Зменшення ризику
Щоб звичні функції були ефективними, ви побачите, що команди BAU намагаються зменшити всі ризики для операцій. Вони працюють над тим, щоб усунути невизначеність у бізнесі для кращої організаційної стабільності та повторюваних процесів.
Оскільки проекти є унікальними та невизначеними, вони вимагають певного ризику. Компанія робить певний стрибок у невідоме, просто реалізовуючи проект, оскільки він вносить зміни та забезпечує те, чого не було раніше.
Таким чином, проектні групи підходять до ризику інакше, ніж команди BAU. Менеджери проектів прагнуть керувати ризиками — як позитивними, так і негативними — для отримання найкращих результатів. Це може включати пом’якшення ризику, щоб спробувати обмежити ймовірність того, що це станеться, але також включає інші стратегії управління ризиками.
Вживання великої літери проти Некапіталізація витрат
Зазвичай проекти можна капіталізувати, але часто BAU неможливо, оскільки ви покладаєтеся на операційні витрати для поточної роботи як у звичайній роботі. Іншими словами, методи бухгалтерського обліку для проектів та інших завдань різні.
Фінансування проекту часто стосується введення активу в експлуатацію, тобто витрати можна капіталізувати. У деяких випадках, залежно від того, у якій точці світу ви перебуваєте, і від ваших місцевих правил бухгалтерського обліку, ви навіть можете взяти витрати на проект нижче межі.
Витрати BAU зазвичай вважаються операційними витратами та відстежуються у звітах про прибутки та збитки компанії.
Фінансування проектів і фінансування бізнесу загалом є дуже спеціалізованою сферою, тому завжди краще отримати пораду від ваших фінансових експертів, перш ніж приймати рішення про те, що слід, а що не слід використовувати у вашому організації. Правила бухгалтерського обліку відрізняються залежно від країни та навіть від організації, де окремі підприємства мають певні процеси та способи роботи.
Крос-функціональні vs. Функціональні команди
Нарешті, є велика різниця в складі проектних команд і команд BAU. У проектах, як правило, залучаються міждисциплінарні команди експертів, які збираються разом для досягнення конкретного результату.
Проектні команди складаються з людей, які виконують певні ролі. Це не назви посад, а посади в рамках проекту з окремими обов’язками. Основні ролі в команді проекту:
- Спонсор проекту
- Керівник проекту
- Старший постачальник (організація, відповідальна за виконання роботи, якою може бути внутрішня команда, як-от ІТ, або зовнішній підрядник чи постачальник)
- Замовник (це може бути внутрішній замовник, наприклад інший менеджер відділу, або, в організації, що надає послуги клієнтам, замовник, для якого ви виконуєте проект)
- Експерти з предметних питань (люди, залучені до команди на час виконання проекту або її частини, які використовують свій досвід, щоб сприяти успіху проекту).
Роботою BAU, з іншого боку, керують функціональні групи. Вони самі по собі є експертами, але об’єднані в один підрозділ. Зазвичай існує менше міжфункціонального збігу з іншими відділами, і вони матимуть визначені цілі та бачення ролі, яку відділ відіграє в компанії. Прикладом може бути команда обслуговування клієнтів, яка працює як частина більшого відділу обслуговування клієнтів, обробляючи дзвінки та електронні листи від клієнтів щодо вашого продукту.
Може бути певне збігання, оскільки людей із команд BAU запрошують до участі в проектних групах.
BAU та конфлікти проектів
Робота над проектом і робота BAU можуть добре поєднуватися одна з одною, але часто може виникати напруга. Це відбувається тому, що проекти намагаються змінити статус-кво.
По-друге, коли ви просите людей приєднатися до вашої команди проекту, вони можуть постраждати від конфлікту лояльності. Чи є їхній головний обов’язок за щоденну роботу чи за проект? Тут можуть допомогти чіткі цілі та сильна відданість проекту з боку керівництва, а також підтримувати комунікаційні лінії відкритими, щоб вони знали, якими мають бути пріоритети.
По-третє, підтримка бізнесу завжди є пріоритетом. Це має наслідки для проектних команд, які можуть скоротити фінансування, а ключові ресурси повернути до BAU ролі та часові рамки затримуються, оскільки підтримувати повсякденну роботу організації важко фокус.
