e-mail, MS Excel, MS Word, MS Project

Maksim ChakСудя по ответам, серьезные РМы тут отсутствуют, Excel это не инструмент, Project годится только для маленьких проектиков....
Жаль :-(

Уважаемый Максим!
Судя по Вашему ответу серьезный опыт проектного управления у Вас отсутствует, т.к. делать ставку на программное обеспечение - удел новичков и дилетантов. Жаль?

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

Удачи в этом нелегком деле.

Максим,

По отзывам, данное п/о весьма неплохо себя зарекомендовало:

-- специализированное решение для строительных организаций - тыНц

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

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

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

Хорошо, поробую изложить свою точку зрения.

Т.е. все нижеизложенное - исключительно мое мнение, не претендующее на полноту и истину в последней инстанции, но подтвержденное моей практикой (что тоже не является абсолютной истиной).

Роль специализированного п/о в управлении проектами

Казалось-бы - ну чем строительный проект (или проект по организации показа мод или выпуск очередного номера журнала) отличается от ИТ?
Абстрактно - ничем. Есть цели проекта, есть бюджет, есть сроки, есть ресурсы. Бери флаг в руки и веди к победе, независимо от области приложения.
Но - отличается! Не буду растекаться мыслью по древу относительно проектов вообще - скажу за заказные проекты по разработке и внедрению информационных аналитических систем.

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

Лирическое отступление:
И здесь возникает диллема для менеджера проекта (за всех не скажу - у меня она была): "Что делать?" Да-да - именно традиционный русский вопрос!
Что делать - сохранить лояльность работодателю и сдать заказчику "уродца" в срок и в рамках бюджета, или дать людям то, что им действительно нужно?


Вы возразите: "Да, но есть и другие модели, например спиральная. Она для ИТ - то, что нужно! Почему мы говорим о каскадной?"
И за это будет мой второй тост.

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

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

Итак, нужно использовать спиральную модель (или итерационную - хотя это достаточно грубое приближение "спиральная"<=>"итерационная", предлагаю здесь не заострять на этом внимания).
Это в теории. Но, как известно, теоретически разницы между теорией и практикой нет, а практически она есть. И это так.
В чем же разница? А разница в том, что на практике все равно используют каскадную модель!
Мотивов для этого более чем достаточно:
-- культура проектного управления у заказчика (если она есть вообще) и исполнителя сильно различается и единственно понятной моделью является... правильно - каскадная!
-- для бизнес-спонсора заключать сделку выгоднее (и понятнее!), когда изначально речь идет о фиксированных суммах и сроках, что явлется прерогативой именно каскадной модели
-- для менеджера по продажам компании-исполнителя тоже проще оперировать фиксированными сроками и суммами, к тому-же он не отвечает за результат (проекта, а не сделки)
-- и т.д.

Т.е. налицо ситуация, когда и заказчик и исполнитель(!) убеждают друг-друга в том, что проект предсказуем и традиционен.

К слову (ну и для саморекламы, конечно;0) - о порочности такого подхода, рассмотренного через призму проектного плана, есть моя статья в журнале " Управление проектами ".

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

"Ну и причем здесь программное обеспечение?" - спросите вы.
А притом, что основные программные пакеты для управления проектами поддерживают именно каскадную модель. Да, для презентационного уровня они подходят, да там и не нужно никаких фич особых.
Но для реального управления - нет.

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

Результативные здесь - даты, когда мы могли предоставить результаты, интересные заказчику (оправдывающие его инвестиции грубо говоря).

Но основным инструментом была Excel таблица, которая выполняла роль статусного документа и, одновременно, являлась списком детальных задач для участников проекта. Носила эта таблица скромное название "Открытые вопросы", но реально была главным управляющим документом проекта (не считая контракта, конечно :0)).

К чему это я все написал-то?

А, да! К тому, что для управления одним проектом, имеющим динамические цели (или изменяемый контекст/рамки/границы - кому как нравится) - существующие пакеты п/о не слишком пригодны и их версия/производитель/фичи не играют решающей роли, хотя и облегчают жизнь менеджеру проекта.

При этом, если рассматривать вопрос управления программами (портфелями) проектов, то специализированное п/о может вывести на качественно новый уровень - и это тоже проверено, но писать уже лень.

Вот такое мое мнение - надеюсь, интересное даже Максиму ;0)