Взаимосвязанное управление проектами разных уровней

[es3000]

Здравствуйте!
Подскажите, пожалуйста, как организовать 'многоуровневое' управление проектами?

Схема наверное стандартная:
На плановый период (например 2-3 года) намечается ряд целей. Для достижения этих целей формулируется ряд проектов.
1-й уровень. На этом уровне объектами управления являются эти проекты. То есть на этом уровне проекты для нас являются операциями, которые мы выстраиваем в сетевой график, назначаем грубые оценки ресурсов и финансов. Результат выполнения этих проектов - достижение наших целей.
2-й уровень. Ответственными за проекты назначаются заместители директора. Проекты детализируются на задачи. На этом уровне операциями являются задачи проекта. Сетевые графики составляются по этим задачам для каждого проекта.
3-й уровень. Задачи проектов из предыдущего пункта назначаются начальникам подразделений. Они уже детализируют поставленные задачи на своих сотрудников.

Вопросы у меня такие:
Хочется разобраться как этот весь процесс правильно реализовать с точки зрения методологии?
Вообще с точки зрения управления проектами описанная схема является корректной?
Можно ли реализовать эту схему в вашем продукте Spider Project?
Как в этом случает 'стыковать' между собой проекты разных уровней?

Мы пробовали все это 'заводить' в один большой проект.
Получается очень неудобно: нужно ведь отслеживать и 1-й уровень, и 2-й и 3-й уровни.
А когда мы завели все в один большой проект, то задачи 1-го и 2-го уровней стали просто как суммарные задачи - и их не получается отслеживать.

Поделитесь пожалуйста опытом, советами.

[Галина Третьякова]

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

[es3000]

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

Спасибо! Как я понял, вы говорите о реализации описанной проблемы в Spider Project?
Можно ли где-то более подробно прочитать об этом?

[Галина Третьякова]

Да, я действительно писала о реализации проблемы в Spider,
как это смоделировать можно прочитать в справке, а методология разрабатывается в каждой организации своя

[es3000]

Да, я действительно писала о реализации проблемы в Spider,
как это смоделировать можно прочитать в справке, а методология разрабатывается в каждой организации своя

Если пользоваться Desktop-версией, то функциональность портфелей проектов будет недоступна.
Можно ли как-то реализовать это в Desktop-версии?

[es3000]

а методология разрабатывается в каждой организации своя

А можете дать ссылку на пример такой методологии?

[Галина Третьякова]

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

[es3000]

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

как правильно сформулировать запрос в поисковике?
"методология управления проектами разных уровней"?

[Галина Третьякова]

Начните с методологии управления проектом, а дальше методологию управления портфелем проектов

[es3000]

Начните с методологии управления проектом, а дальше методологию управления портфелем проектов

Это не совсем то, что меня интересовало.
Это очень широкие темы, по ним у меня есть информация.

Мой изначальный вопрос более "узкий": как "стыковать" друг с другом проекты верхнего и нижнего уровней.
То есть вопрос касается их синхронизации, а не управления проектами вообще.
По этому вопросу посоветуйте что-нибудь?

[Сергей Никитенко]

Первый пункт Вашего вопроса - это Гантт проектов. В нем все проекты выглядят одной операцией. Только вот связывать их там в сетевой график нельзя. Для этого проекты необходимо собрать в Гантте работ портфеля и там проставить связи между проектами.
А второй и третий пункты Вашего вопроса - это обычные 2-й и 3-й уровни в Гантте работ проекта. На одном уровне на фазах ответственные это Ваши заместители директора, на следующем - начальники подразделений.
Прошу пояснить вот эту фразу:

Получается очень неудобно: нужно ведь отслеживать и 1-й уровень, и 2-й и 3-й уровни.

У вас все уровни живут самостоятельной жизнью? На первом уровне цель уже достигнута, а на уровне сотрудников еще и работать не начинали? Факт он для всех уровней один.
Информация аккумулируется снизу вверх. Как наработали на задачах, так и соберется на всех вышестоящих фазах вплоть до Гантта проектов, где на одной полоске будет видно - сколько в данном проекте фактически сделано. И замы и начальники увидят каждый на своей фазе - сколько конкретно выполнено в его зоне ответственности.

[demleon]

Я не думаю, что такая методология есть в открытом доступе) Те, у кого она работает, не горят желанием ей делиться с возможным конкурентом.

Чем отличается Ваша задача от детализации проекта "набегающей волной"?
1 вариант - превращать операции из 1 этапа в фазы на 2 этапе, оставаясь в границах времени и иных критериев (финансов, ресурсов и т.д.). Некоторые для удобства еще работают с контрольными событиями, чтобы каждая фаза начиналась и заканчивалась через контрольное событие. Тут неудобство, что информация на фазах будет ограничена.
2 вариант - оставлять все 3 уровня детализации в одной модели, создав 3 структуры. Можно также через контрольные события. Тут неудобство, что при внесении факта вам надо будет вносить факт по 3 уровням и не допустить разности в подсчете, чтобы сроки не поплыли.

[es3000]

Прошу пояснить вот эту фразу:

Получается очень неудобно: нужно ведь отслеживать и 1-й уровень, и 2-й и 3-й уровни.

У вас все уровни живут самостоятельной жизнью? На первом уровне цель уже достигнута, а на уровне сотрудников еще и работать не начинали?

Опишу весь процесс управления выше- и ниже-стоящими проектами, как это видится в нашем понимании.
(Здесь я имею ввиду под "проектом" - это не понятие "проекта" в Spider Project, а проект как совокупность работ)
Как нам кажется, на каждом уровне управления, должно быть три списка "задач":
1) задачи, поступившие на выполнение с вышестоящего уровня - назовем их "поступившие" задачи
2) задачи, порученные на выполнение нижестоящему уровню - "исходящие" задачи
3) задачи, которые должны быть выполнены на данном уровне для решения "поступивших задач" - это "внутренние" задачи.

Порядок работы с проектами:
1. Сначала мы в соответствии с целями организации намечаем ряд проектов. Затем делаем их грубую оценку.
Затем выполняем грубое планирование этих проектов. В этом плане каждый проект - это одна большая операция, у которой есть ответственный (заместитель директора), планируемые сроки, ресурсы.
То есть результат этого этапа - это сетевой график (или диаграмма Ганта) операций-проектов.
На этом уровне управления работа осуществляется с этим графиком. В принципе это должен делать директор - работать и отслеживать сетевой график всех проектов организации.
"Поступившие" задачи на этом уровне - это цели организации.
"Исходящие" задачи - это проекты.

2. На следующем шаге ответственный за проект (заместитель директора) детализирует порученные ему проекты, разбивает на задачи.
Этим задачам заместитель директора назначает ответственными исполнителями подразделения.
И строит сетевой график этих задач, и далее работает с этим сетевым графиком.
На этом уровне:
"Поступившие" задачи - это проекты, порученные заместителю директора
"Исходящие" задачи - это задачи, которые он поручил выполнять подразделениям.

3. То же самое делается на следующем уровне в подразделениях.
Здесь "поступившие" задачи - это задачи от заместителей директора.
"Исходящие" задачи - это задачи, поставленные начальниками подразделений своим подчиненным.

То есть планирование выполняется как бы поэтапно, все более детализируясь.
Получается что "поступившие" задачи на каком-либо уровне - это "исходящие" задачи вышестоящего уровня.
На каждом уровне управления ответственный следит за ходом выполнения "исходящих" задач, и в соответствии с ним (ходом выполнения) обновляет статус "поступивших" задач.

Конечно это было бы очень удобно, чтобы факт выполнения самой мелкой задачи в подразделении сразу отражался бы на всех уровнях.
Но возможно ли это?
Нам кажется это трудно реализовать.
Далее я поясню почему.

Факт он для всех уровней один.
Информация аккумулируется снизу вверх. Как наработали на задачах, так и соберется на всех вышестоящих фазах вплоть до Гантта проектов, где на одной полоске будет видно - сколько в данном проекте фактически сделано. И замы и начальники увидят каждый на своей фазе - сколько конкретно выполнено в его зоне ответственности.

Это возможно только в том случае, если все проекты, задачи и операции всех уровней структурированы в одну большую иерархическую структуру работ, в один большой проект (здесь проект - это термин Spider Project).
Нам кажется это трудно реализовать.

В этом варианте мы видим следующие трудности:
1) Первая трудность - обеспечить, чтобы каждый уровень видел только свои "поступившие", "исходящие" и "внутренние" задачи.
Теоретически это наверно можно сделать различными фильтрами, сортировками и т.д.
Но мне кажется это сложно.

2) Вторая трудность. Все задачи в этой большой ИСР превращаются из "нормальных" задач превращаются в фазы, кроме операций самого нижнего уровня.
Это значит, что мы не будем иметь сетевого графика ни на каком уровне, кроме самого нижнего.
Разве можно построить сетевой график фаз? И рассчитать критический путь фаз?
А ведь каждый уровень должен работать со своим сетевым графиком.

3) Еще одна трудность - это обеспечение "правильности" (не нашел другого слова) построения ИСР на каждом уровне.
То есть, если мы хотим чтобы все эти уровни были в одном большом проекте, нужно чтобы вся ИСР строилась по жесткому правилу:
нужно чтобы каждая фаза этого большого проекта соответствовала либо "поступившей" либо "исходящей" задаче (кроме самого нижнего уровня).
Но этого трудно добиться, как это обеспечить?
Ведь исполнитель на каждом уровне, скорее всего, будет строить ИСР так как ему удобно: кроме "обязательных" фаз для "поступивших" и "исходящих" задач, он может создать какие-то промежуточные фазы, вспомогательные задачи и т.д., которые в общей ИСР будут как несущественные детали, и их нужно будет как-то "прятать".

4) Ну и еще одна трудность.
А если команда является распределенной? Ну или каждый уровень - это разные компании\подрядчики.
Например, недавно читал про организацию управления проектами в Организационном комитете Олимпийских Игр в Сочи.
Там же ведь невозможно было физически в одной ИСР увязать все проекты, начиная с верхнего уровня до проекта постройке например какого-то стадиона.
Как это реализуется в жизни?

Надеюсь, я понятно все изложил, все наши сомнения.
Поэтому, учитывая эти трудности, мы и решили обсудить возможность управления проектами на каждом уровне по отдельности.
И сразу встал вопрос о синхронизации этих уровней друг с другом.

Возможно, мы в чем-то неправы, чего-то не учитываем.
Пожалуйста, посоветуйте ваше решение, давайте обсуждать.

[Сергей Никитенко]

Прошу прощения, а что тут обсуждать?
Ознакомитесь со статьей про организацию групповой работы в Spider Project http://www.spiderproject.ru/ru/index.p ... /groupwork
Вы описываете работу с портфелем, в котором обычно никаких трудностей нет.
Верхние задачи - проекты в Гантте проектов. У каждого свое текущее время, у каждого свои сроки окончания, начала, свой текущий факт исполнения.
Внутри проект может быть укрупненный, даже из одной операции. Вам уже написали про "набегающую волну".
Проекты можно собрать в сетевой график устанавливая логические связи между ними в портфеле. После этого они на верхнем уровне встанут как вам нужно.
Внутри каждого проекта связи ставятся между операциями и в соответствии с суммарными данными перемещаются по календарю фазы. Никакие связи между фазами не нужны.
Строить иерархию можете какой угодно мерности и дробности. На любой фазе любого уровня можно назначить ответственного (человека, организацию) и отправлять им только эту фазу для работы и учета. Или наоборот - вставлять в Ваш проект разработанные кем-то фазы.
Директор смотрит на Гантт проектов - видит полоски проектов, их сроки и бюджеты, а также факт имеющийся по проектам.
Замы смотрят каждый на заголовок своего проекта и видят то же самое, но по проекту.
Начальники смотрят каждый на свою фазу и видят только свои данные.
И так далее.
Для рассматривания разных уровней есть выпадающий список "детализировать до". Раскладывайте или складывайте проект до любого уровня иерархии.

Это возможно только в том случае, если все проекты, задачи и операции всех уровней структурированы в одну большую иерархическую структуру работ, в один большой проект (здесь проект - это термин Spider Project).
Нам кажется это трудно реализовать.

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

Про "критический путь фаз". Это Вы как себе представляете?

[es3000]

Прошу прощения, а что тут обсуждать?

Тот механизм, который вы расписали - это стандартное "двухуровневое" или правильнее "трехуровневое" управление проектами:
- на первом (верхнем) уровне портфель проектов
- на втором уровне - проекты
- на третьем уровне операции.

Я же говорю о много-уровневом управлении.
Когда есть портфель проектов, проекты, подпроекты, под-подпроекты и т.д.

Как я понял, вы предлагаете стандартное решение - сделать эти подпроекты и под-подпроекты фазами проектов:

Строить иерархию можете какой угодно мерности и дробности. На любой фазе любого уровня можно назначить ответственного (человека, организацию) и отправлять им только эту фазу для работы и учета.

Мне кажется, это не совсем правильно, так как ответственный за под-проект, если он (под-проект) реализован как фаза, уже не может управлять ею как проектом.
Что вы имеете ввиду под "отправлять им только эту фазу для работы и учета"?
Какую работу может выполнять ответственный с фазой?

Я же привел пример Организационного комитета Олимпийских Игр в Сочи.
Вряд ли там строили одну большую иерархию.

Сделайте каждому Вашему начальнику всех уровней его отдельный маленький укрупненный проектик с его задачами, чтобы он там мог видеть сетевой график

Давайте попробуем на примере. Допустим есть всего два проекта: Проект1, Проект2.

Замы их детализируют:
- Проект_1
--- Задача_1_1
--- Задача_1_2
- Проект_2
--- Задача_2_1
--- Задача_2_2

Замам нужен укрупненный сетевой график из 4-х задач: Задача_1_1, Задача_1_2, Задача_2_1, Задача_2_2.
Эти задачи (Задача_1_1, Задача_1_2, Задача_2_1, Задача_2_2) - это операции для замов.

Но одновременно эти задачи являются проектами (Проект_1_1, Проект_1_2, Проект_2_1, Проект_2_2) для начальников подразделений.
Начальники их дальше дробят:
- Проект_1_1
--- Задача_1_1_1
--- ...
--- Задача_1_1_10
- Проект_1_2
--- Задача_1_2_1
--- ...
--- Задача_1_2_10
- Проект_2_1
--- Задача_2_1_1
--- ...
--- Задача_2_1_10
- Проект_2_2
--- Задача_2_2_1
--- ...
--- Задача_2_2_10

Начальникам нужны сетевые графики их задач по каждому под-проекту:
- Задача_1_1_1 - Задача_1_1_10;
- Задача_1_2_1 - Задача_1_2_10;
- Задача_2_1_1 - Задача_2_1_10;
- Задача_2_2_1 - Задача_2_2_10.

Как обеспечить, чтобы и замы и начальники имели указанные сетевые графики и могли с ними работать?

[Сергей Никитенко]

Опишите пожалуйста подробно "работу" зама с Задачей_1_1.
Конкретно - что он с ней делает, помимо того, что на нее смотрит.

Мне кажется, это не совсем правильно, так как ответственный за под-проект, если он (под-проект) реализован как фаза, уже не может управлять ею как проектом.
Что вы имеете ввиду под "отправлять им только эту фазу для работы и учета"?
Какую работу может выполнять ответственный с фазой?

И прочитайте описание групповой работы в Спайдере по указанной ссылке.
У вас, так скажем, легкое недопонимание принципа работы с рассылками-сборками.

[es3000]

Опишите пожалуйста подробно "работу" зама с Задачей_1_1.
Конкретно - что он с ней делает, помимо того, что на нее смотрит.

Начнем с того, что Зам назначен ответственным за несколько проектов: Проект_1 и Проект_2.
Далее он делает стандартную работу по управлению этими проектами. В общих словах:
а) Сначала детализирует эти проекты на задачи, чтобы понять содержание работ, выясняет логические взаимосвязи между задачами. В результате получает список задач: Задача_1_1, Задача_1_2, Задача_2_1, Задача_2_2. И их сетевой график. Отмечу, что это достаточно "крупные" задачи. Зам не детализирует свои проекты до мелких операций на каждого рядового работника.
б) Затем Зам выполняет оценку трудоемкости этих задач, подбор ресурсов и исполнителей, таким образом, чтобы уложиться в назначенные "сверху" ограничения по срокам и стоимости. Здесь под исполнителями имеются ввиду "крупные" единицы: подразделения, подрядчики. Задачи могут быть конечно назначены и кому-то персонально, но все-таки на этом уровне это должны быть "крупные" задачи.
в) Затем, когда все параметры его устраивают, он поручает эти задачи на исполнение выбранным исполнителям.
г) Регулярно получает от исполнителей отчеты и предпринимает дальнейшие действия в соответствии с ними.

Каждый исполнитель, получив задачу от Зама, делает с ней тоже самое, только на своем уровне.

И прочитайте описание групповой работы в Спайдере по указанной ссылке.
У вас, так скажем, легкое недопонимание принципа работы с рассылками-сборками.

Я читал. Спайдера у меня нет, попробовать описанную методику групповой работы я не могу.
Но как мне кажется, суть я понял.
Составляется одна большая модель проекта для всех уровней от самого верхнего до самого нижнего исполнителя.
Исполнителям нижних уровней рассылаются их фрагменты этой большой модели проекта, а они возвращают планировщику фактические результаты.
Правильно?

Но такая схема нам кажется не удобной.
Самое главное, что не подходит: то, что изначально составляется одна большая модель проекта.
Мы думаем, что на каждом уровне должна быть своя отдельная модель задач-проектов только "своего" уровня, с детализацией только до исполнителей и ресурсов только своего уровня.
В этой модели текущего уровня не должно быть детализации до самых "элементарных" операций самых "элементарных" исполнителей до самого последнего уровня.
И вместо того, чтобы разрабатывать одну большую модель, лучше организовать между моделями разных уровней взаимодействие.
Вы согласны с этим?

[Сергей Никитенко]

Спайдера у меня нет, попробовать описанную методику групповой работы я не могу.

Можете. Демо версия доступна всем. В профессиональной демо можете собрать портфель, посмотреть как производится иерархическая рассылка-сборка и т.д.

Исполнителям нижних уровней... Правильно?

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

Самое главное, что не подходит:

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

И вместо того, чтобы разрабатывать одну большую модель, лучше организовать между моделями разных уровней взаимодействие.
Вы согласны с этим?

Если вам так удобнее - согласны. Если вашу концепцию не может реализовать наша программа - не согласны. У программы есть определенные правила описания моделей и работы с ними.
Бесплатно методологию персонально для вас никто ни на каких форумах не выложит. Компании тратят годы и миллионы, чтобы отработать внутренние механизмы по работе с моделями так, как им необходимо.
Данный вопрос здесь неоднократно поднимался.
Напишите подробно проработанное ТЗ на ваше видение системы, без абстрактно-разговорных формулировок, и посмотрите какой софт из представленных на рынке может это реализовать. Может быть вообще никакой.
Если это не философская отвлеченная беседа, а действительно потребность вашей компании в решении вопроса - заключайте договор на консультации, приглашайте специалистов.

[es3000]

Исполнителям нижних уровней... Правильно?

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

Да, вы правы.
Я выразился не точно. Но все-таки рассылаются фрагменты одной большой модели проекта.

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

Что-то не понял. Разъясните, пожалуйста, еще раз этот момент.
Вы пишите: "... синхронизации группы проектов разной детализации без объединения их в единую модель..." - "...это можно реализовать при помощи имеющихся в программе инструментов...".
Какие инструменты вы имеете ввиду?
И тут же вы пишите: "...не устраивает, что проекты нужно сводить воедино...".
То есть получается: есть инструменты, которые позволяют выполнять синхронизацию проектов без объединения их в единую модель, но для этого их нужно свести воедино?
Какое-то противоречие.

Напишите подробно проработанное ТЗ на ваше видение системы, без абстрактно-разговорных формулировок, и посмотрите какой софт из представленных на рынке может это реализовать. Может быть вообще никакой.

Вот мы этим и занимаемся: поиском ПО.
Только действительно похоже на то, что нашу методику никакой софт не реализует.
Поэтому мы и думаем: почему, как это объяснить? Ведь наш подход вроде бы естественный: сверху-вниз.
Если наш подход неправильный - мы хотим понять в чем он неправильный.
Если правильный - почему производители софта его не реализуют?

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

Если это не философская отвлеченная беседа, а действительно потребность вашей компании в решении вопроса - заключайте договор на консультации, приглашайте специалистов

Потребность есть, а миллионов нет.
И получается, что проблема действительно философская, вернее методологическая.
Поэтому я вопрос задал не в раздел форума по Spider-у, а в раздел "Общие вопросы"

[rstm]

RTFM