Коллеги, привет. На днях услышал историю от знакомого руководителя IT-отдела, как компания решила внедрить новую CRM-систему. Выделили команду, назначили ответственного, раздали задачи. Через три месяца выяснилось, что сроки "уехали", бюджет вырос почти вдвое, а результата нет.

Когда стали разбираться: половину времени команда не занималась внедрением системы, а разруливала типовые инциденты — слетели права, завис сервер, сотрудники забыли пароли. То есть параллельно вела операционную поддержку старого софта, но называла это «проектными работами».

Спор был жарким: прожект утверждал, что это и есть часть внедрения системы, СТО призывал текучку выносить за скобки. В итоге сошлись на одном: если бы изначально отделили проект от того, что остаётся в операционке, сэкономили бы пару месяцев и кучу нервов.

Давайте пробежимся по главным отличиям, чтобы не попадать в такие же ловушки.

Как отличить на практике? Проект легко узнать по трём атрибутам: срок, результат, команда. — Проект всегда конечен. У него есть дата старта и дата, когда всё заканчивается, даже если это agile со спринтами. В операционке же нет естественного финиша: пока компания жива, бухгалтерия будет закрывать месяц за месяцем, а техподдержка — отвечать на заявки. — Результат проекта уникален. Вы не делали точно такую же CRM до этого. Операционка штампует одинаковый результат — будь то отчёты, детали на конвейере или ответы на типовые вопросы клиентов. — Команда проекта — временное явление. Люди приходят из разных отделов или компаний, а после завершения проекта расходятся обратно. В процессном управлении структура постоянная, иерархия фиксирована, роли прописаны на годы вперёд.

Практическая польза. 1. Три вопроса, чтобы не спорить — проект перед вами или операционка:

— Будет ли этот результат использоваться больше одного периода (месяца, квартала) без доработок? Если да — это процесс.

— Можем ли мы чётко назвать дату, когда работа будет полностью завершена и команда распущена? Если нет — скорее всего это процесс.

— Риски уникальны или мы их уже проходили десять раз? В проекте каждый раз риски меняются. В операционке они предсказуемы.

Проверьте на своей текущей задаче. Если ответы неочевидны — вы в серой зоне, и её лучше формализовать, иначе проект затянется, а операционка начнёт тормозить.

2. Что делать, если одно маскируется под другое? Бывает, что проект вынужденно содержит кусок операционки (как в кейсе с CRM). Или наоборот: в операционный процесс залетает уникальная задача (проект), которую продолжают делать «по накатанной».

Простой рецепт: выделяйте операционку в отдельный фонд времени. Закладывайте в план проекта только уникальные работы, а всё повторяющееся отдавайте на поддержку — в отдельный бюджет и отдельному ответственному.

Самые активные проектные зоны, как показывает практика:

— Строительство — каждый объект уникален, но на стройплощадке полно типовых операций (подвоз бетона, ежедневный контроль).

— IT-разработка — вечная битва между «сделать новую фичу» и «починить баги в старом».

— Производство — запуск новой линейки (проект) vs серийный выпуск (операционка).

— Маркетинг — рекламная кампания под новый продукт (проект) vs ведение соцсетей (операционка).

— Госсектор — целевые программы с чёткими сроками, внутри которых сотни повторяющихся отчётностей.

В каждой из этих сфер проектный офис или хотя бы его распределённая модель поможет не спутать твердое с горячим.

В следующих постах разберём отраслевые чек-листы, как оценивать проектных менеджеров на собеседовании, какие метрики ставить в строительстве, а какие — в IT, где брать шаблоны для быстрого старта и многое другое.

Подписывайтесь на «Ваш проектный офис», чтобы не пропустить полезные материалы — @pmo_club.

А если у вас тоже были случаи, когда проект путали с операционными процессами и это выходило боком, поделитесь в комментариях — будет полезно всем.

#ПроектныйОфис #PMO #УправлениеПроектами #ОперационнаяДеятельность #проект #процесс