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

Помните про Алису: Если все равно куда надо попасть, то все равно в какую сторону надо идти. Поэтому в том, чтобы что-то да написать нет никакого смысла.

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

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

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

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

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

Всем доброго дня!

У нас в Локальной команде было 20 человек (FI - 6, CRM - 3, SCM - 3, PPM - 2, BW - 2, AMS - 2, HR - 2) и 20 с глобальной стороны. Правда наша компания (HILTI) по всему миру внедряет SAP. На имплементацию было выделено всего 10 месяцев. Самые сложные процессы в FI и SCM были, особенно с миграцией данных это связано.

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

Модуль желательно комплектовать минимум из 2-х человек
1) Специалист-предметник (руководитель модуля)
2) Инженер-программист

В процессе внедрения 1 и 2 обмениваются знаниями, в результате есть вероятность получения личностей 3-го типа - "Консультант"

1) Руководитель проекта со стороны заказчика(тут важно учесть то что он должен быть выведен из орг. структуры предприятия)
2) Руководитель проекта внедрения системы со стороны интегратора
3) Весь TOP-менеджмент
4) Стенографистка-оператор для составления документации
5) Администратор проекта (IT - составляющая)

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

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

P.S. Стоимость использования ресурсов... Сравните.

А просто - диктофон не пробовали использовать?
И необязательно перепечатовать, когда можно утвердить что вавчики емеют статус в проекте и их можно просто слшать, а не читать

Вопрос:
Кто то всякие технические новшества использует для проведения совещаний команды проекта.
Речь про скайпи и видеоконференции

1. Не стенографистка, а администратор проекта, нужен обязательно. На проекте возникает очень много административных, рутинных и пр. вопросов - заказать пропуска, билеты, гостиницу, пройтись с протоколом - собрать подписи, подготовить акты, обработать таймшиты и пр. Если всем этим будет заниматься руководитель проекта, то когда он будет заниматься своей работой?
2. Диктофоны - пустое баловство. Сколько ни пользовались диктофонами, никакой реальной пользы от них нет. Никто не будет потом прослушивать полуторачасовую запись совещания, чтобы найти в ней какой-то тезис. Разве что если в суде оправдываться собираетесь? Ценным продуктом является протокол совещания - уже обработанный и пропущенный через мозг консультанта материал - систематизированный, фиксирующий итоги. На него потом и сослаться можно, и процитировать.
3. Просто секретарша качественный протокол совещания не напишет. Ей как минимум надо понимать суть вопросов и терминологию. И если секретарша сможет грамотно зафиксировать решение по принятой методике учёта затрат, то это уже не секретарша . Это консультантская работа.
4. Видеоконференцсвязь - вещь незаменимая для территориально распределённых предприятий. Экономит бешенное количество времени и денег, которые иначе пришлось бы потратить на командировки. Не понимаю как до сих пор не все компании это поняли? Скайп - принципиально ничего нового - просто ИП-телефон. Если заказчик не даёт нормальной связи, может иногда выручить.

А как вы учитываете время администратора? Это почасовка или оклад?

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

Много чего уже сказано, можно я резюмирую?
1. Проекту нужен спонсор. Это мужик (или женщина) который(ая) может открыть проект ( те предоставить полномочия всем остальным и выделить средства в необходимом объеме), а так же закрыть проект, т.е выгнать ВСЕХ, т.е. абсолютно всех, и внутренних и внешних исполнителей. Если такого нет, ищите. Без спонсора проект обречен.

2. Найти и назначить руководителя проекта.

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

4. Найти архитекторов решений. Это такие яйцеголовые, которые прошли уже не один проект и формируют главное направление в тех или иных функциональных решениях.

5. Внутренние и внешние консультанты (на одно функциональное направление, как минимум один внутренний, один внешний )
6. Программисты (разные, ABAP, JAVA, третьи системы и т.д.)
7. Администраторы (базис, БД, сети и т.п.)
8. Администратор проекта - критически важный ресурс

Сказаны слова правильные! но не новые!
У нас данные постулаты окровавленными ногтями высребаны на скрижалях. PMBOK - наш отец и наш мать!

Но есть парачка вопрос к общественности.

Что бы быстро ехать на проекте, не лучше ли "день потерять", да научиться летать? То бишь, научить Закачика вести проектное управление.

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

А осуществлял ли кт ото это на практике?
Сколько времени потребовалось?
Одного собрания КП явно недостаточно...

Весьма неожиданная идея. А кого, собственно, со стороны заказчика Вы собираетесь учить проектному управлению? Кроме руководителя проекта это особо никому не нужно. А если РП не знаком с сией дисциплиной, то это тяжёлый случай, хотя и распространённый. Но врядли имеет смысл проводить индивидуальные занятия со своим коллегой-напарником со стороны клиента.
Обычно приходится просто разъяснять ключевым людям последовательность и суть работ и почему нельзя сначала поехать а потом завести.

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