Вопросы по управлению проектами

В очередном проекте команде управления проекта придется выступить в качестве заказчика - сторонняя организация будет поставлять, монтировать и налаживать оборудование.
Стараюсь действовать по PMBoK. Времени не хватает изучать данную книжку. И возникают вопросы:
1. Процесс "Составление технического задания" относится к планированию или реализации проекта? Мне кажется, что к планированию, но сомневаюсь...
2. А "Согласование технического задания с проектной организацией" - это уже реализация?
3. Действия заказчика являются управленческими или исполнительными?
4. Нужны ли процессы контроля деятельности подрядной организации на территории предприятия? Так как подрядчик должен поставить, смонтировать и наладить оборудование, то соответственно проект должен состоять из этапов "прием и хранение оборудования", "сопровождение монтажа", "сопровождение наладки". Или это все лишнее?
5. Техническое задание является частью плана управления проектом? Какому документу оно соответствует в PMBoK?

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

День добрый, Михайло



Правильно кажется и правильно сомневаетесь

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

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

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



Ответ тот же


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


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


Навскидку не могу ответить.


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

А по ПМБуку? Согласование техзадания идет параллельно с проектированием (обычно), тут и возникает вопрос: проектирование - это часть планирования?
А что касается достижения результата в космической отрасли - то это не результат советской школы управления, а все-таки результат технической научной мысли. ИМХО.


А разве заказчик не осуществляет функцию контроля (control scope, verify scope и т.д.)?


Техзадание = Requirements documentation + project scope statement?

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

В этом случае Ваш проект PMI характеризует не как проект, а как программу или даже как портфель проектов.


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


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

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

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

P.S. Проектирование - имеется в виду конструкторское проектирование изделия.

Здесь Вы маленько отстали от жизни.
Из википедии:

Не только. Кто виноват, что одним термином обозначают множество процессов?
Это и проектирование изделия. Это и проектирование капитального строительства всего Вашего завода.
А все стадии проекта строительства тоже есть составляющей одного инвестиционного проекта. Всего лишь несколько полосочек в диаграмме Ганта.
Я тоже регулярно попадаю в подобные ситуации. Говоришь в рабочей группе слово "проект" - и каждый профильный специалист понимает его по своему
Замените слово проект словом программа . Будет меньше путаницы.

_________________
С уважением, Андрей Стадник
Координатор [...]

Тогда будет путаница при общении с айтишниками и руководителями программ.

Андрей, спасибо, что подняли вопрос о терминологии. Честно говоря, я сколько ни искал границы между менеджментом вообще и тем что обычно называют проектами - до сих пор четкой границы найти не могу. Все что есть в таких "проектах" - можно найти в любой непроектной организации, и наоборот. Между проектной деятельностью и регулярным менеджментом существуют сколь угодно много промежуточных вариантов, и каждый разделяет их по своему вкусу. Кто-то говорит, что есть менеджмент и управление проектами, кто-то дополнительно выделяет управление программами и портфелями. При наличии вкуса к порождению сущностей, можно еще много разделов добавить.

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

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