Проектный офис в Agile: как мы потеряли все ценности

Привет, читатель!

Хочу, чтобы мы с тобой в серии статей вместе построили проектный офис в кровавом enterprise в отдельно взятом бизнес-Юните, где трудится порядка 1000 человек.

В целом, эффективно работающий проектный офис - это то, что позволяет организации достигать своих целей быстрее и эффективнее.

Построение проектного офиса, это тоже проект! Но если копнуть глубже, то это уже скорее продукт.

Да-да, я предлагаю нам все воспринимать его, как продукт.

Чтобы нам сразу понять друг друга, я скажу, что процесс еще на самом старте, у меня еще нет ответа о том, что сработает, а что нет.

Будет круто, если вы в комментариях поделитесь опытом и подскажите пару идей.

На старте, нам нужно понять, что мы имеем. Как в школе, начнем, с «дано»

1. Есть 10 проектных менеджеров, которые ведут разного размера и длительности проекты: от 3-х месяцев, до 3-х лет. От 3-х команд разработки, до 200.

2. Менеджеры как-то работают, проекты им приношу обычно я - руководитель проектного офиса.

3. Сам я проекты получаю от СТО, разных штабов (бизнес-штаб, ИТ-штаб), бизнес лидера юнита, смежных команд, кто пытается занести нам много доработок.

4. Команды внутри нашего юнита привыкли к детальной постановке по задачам.

5. Часть задач в работу уходит внутреннему вендору.

6. Собственно, проекты ведутся как получится, но, к счастью успешно. Этапом старта проекта является тот факт, что я об этом попросил менеджера.

7. Закрытием проекта является тот факт, что менеджер отчитался о том, что он его закрыл.

8. Работает так уже лет 5.

Какие проблемы боли я вижу для себя

1. Да почему я должен стартовать именно этот проект?

2. Когда, исходя из загрузки команд, архитекторов и далее по списку я могу его стартовать?

3. А что делать, если едут сроки? Как понять, с кем его нужно согласовать.

4. Внутренний вендор - срок оценки по задаче более 21 дня после того, как все друг другу пожали руки и согласились, что поняли требования!

5. Какие приоритеты по проектам? Как проекты влияют друг на друга?

6. Продуктовые команды выдают оценки только после финализации архитектуры. Да сколько можно то?!

7. Хм…а как нам подтверждать, что проект закрыт?

Чтобы было понятно, конечно, у нас есть определенные формальные процедуры по запуску и закрытию и контролю проектов, но, в целом, уровень зрелости именно в таких вопросах не высокий.

В чем трудности:

1. Органзация работает по Agile. Ну в таком, формате enterprise.

2. Вся разработка продуктовая. То есть, ты, как менеджер, не имеешь выделенной команды разработки. Значит, ты постоянно конкурируешь с продуктовыми задачами команды, с задачами из других проектов.

3. Мы, как бы, Agile. Значит никто не хочет возврата к старым тяжелым проектным подходам. Значит важно найти гибкость.

4. Команды не хотят трансформации

5. У людей аллергия на проекты, на agile, в общем, уже не понятно, кто и как хочет работать.

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

Кто мои клиенты:

СТО, менеджеры штабов, менеджеры проектов, бизнес лидеры юнитов и РО команд.

Какие их боли я могу решить:

- Прозрачный статус по проекту в любой момент

- Планирование ресурсов команд он-лайн

- Скорость поставки результатов проекта.

- Понятные всем процессы = снижение конфликтов.

С чем я столкнусь (как менеджер, не могу не думать о рисках):