Устав проекта - это "скорлупа яйца". Курс по управлению проектами, часть 5

13.09.18

Управление проектом

Устав проекта – это один из ключевых планов, “скорлупа яйца”. Это единственный неизменный план на проекте, в котором фиксируются ключевые ограничения: сроки, бюджет, содержание работ.   В PMBoK определение устава иное: в нем написано, что устав – это издаваемый инициатором проекта документ, формально авторизующий существование проекта и наделяющий менеджера проектов полномочиями использовать организационные ресурсы в работах по проекту. Если перефразировать «по-человечески», то устав – это договор спонсора и менеджера.

Продолжение моего учебного курса по проектному управлению. Предыдущие материалы: 

1. Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера 

2. Три фундаментальных принципа проектного управления

3. Роли в проектном управлении

4. Управление заинтересованными сторонами 

 

Устав появляется в конце этапа инициации.
В уставе мы определяем, какой именно дом собираемся строитьИнициация – это стадия, на которой вы думаете, запускать ли проект или нет, и определяетесь, что именно в проект войдет. Будем ли мы строить дом или нет? Будем строить сами или с помощью подрядчика? Может быть, мы позовем подрядчика только на какие-то отдельные работы, например проектирование, а остальное сделаем сами? То есть инициация - стадия, когда какие-то обсуждения по проекту уже идут, но еще не принято решение - запускать проект или не запускать. А когда у вас готов устав, проект запущен, переходим к планированию. Обратите внимание, что инициация может ничем не кончиться. Вы могли думать-думать, но в итоге решить, что проект сложный, сроки нереальные, и запускать его не стоит. Так что инициация может закончиться ничем, и это нормально. Но если вы решили взяться за проект, то у вас должен появиться устав. Нет устава – нет проекта, вам не за что отвечать.
 
В интернете есть шаблоны, которые можно заполнить по своему проекту. Моя практика показывает - какой бы шаблон вы не использовали, очень трудно написать устав хорошо с первого раза. У устава есть особенность: его качество нельзя оценить сразу. То, что у вас плохой устав, вы понимаете, когда на проекте начинаются проблемы. В самом худшем случае вы узнаете об этом при закрытии. Устав – это такой забавный документ - и пока вы не понимаете, зачем он придуман, его почти невозможно нормально заполнить, какой бы вы шаблон не взяли. Чтобы объяснить, зачем нужен устав проекта, используем метафору.
 
Прежде чем играть в футбол, нужно договориться о правилахПредставьте, что вы с мальчишками после школы решили поиграть в футбол. Сидите и ждете, когда прозвенит звонок с последнего урока, чтобы выйти на школьный двор и погонять мяч. Допустим, мяч у вас есть, звонок прозвучал, вы собираете поиграть. Вы разбились на команды, у вас есть мячик, поле. Чего не хватает? Ворот, конечно. Но поскольку это школьный футбол, то ворота обычно делают из двух портфелей. Все, можно играть. И обычно игра начинается сразу, как только принесли мячик и сделали ворота. Чего ждать-то? Уроки закончились, давно хочется начать игру. А дальше, как это часто бывает, каждые полторы минуты мяч улетает в соседний двор. И двое ребят – по одному из каждой команды – убегают за мячом и долго гоняют по соседнему двору, продолжая бороться за мяч. Потом через несколько минут усталые и довольные возвращаются, а все остальные в это время стоят и ждут. Мячик отсутствует всего несколько минут, но эти минуты очень сильно портят игру всем остальным. Потому что, когда несколько минут ты играешь в футбол, время быстро пролетает, а когда ты ждешь, то кажется, что время идет очень долго. И такая борьба двух мальчишек за пределами импровизированного поля всех раздражает.
 
Или другой вариант развития игры – кто-то из команды противника становится возле ваших ворот и ждет, когда мяч проскочит, чтобы забить гол. И у него получается, поскольку промахнуться невозможно. Такое поведение тоже всех раздражает, потому что все бегают, играют в футбол, а один умный просто стоит и забивает голы.
 
Вот на этом-то этапе игроки понимают, что забыли один очень важный момент - забыли договориться о правилах. Потому что без правил играть оказывается неудобно. К примеру, договариваются, что если мяч улетает в соседний двор, его берут в руки, кладут на край поля и вводят в игру. Или договариваются о наличии специальной штрафной площади, чтобы «умные» не могли стоять у ворот соперника.
 
Другими словами – вы придумываете правила футбола. И правила – это прямая аналогия устава. Думайте об уставе, как о правилах игры, например, в футболе.
 
Что пишут в правилах? Это очень лаконичный документ, в котором половину занимают наглядные картинки, а вторая половина посвящена описанию игры.
 
Что такое хорошие правила? Представьте, что человек, который не знает правил и никогда не бывал на футболе, впервые попадает на матч (он - зритель). Сможете вы объяснить ему в чем суть игры так, чтобы он через 2-3 минуты уже с интересом следил за игрой? И даже начал болеть за какую-то команду по своему выбору?
Технически - да. Футбол простая игра и за пару минут вы сумеете объяснить все нужное (скажем, в бейсболе это было бы невозможно).
Что вы будете рассказывать в эти две минуты? Ключевые правила. Те, которые нужны для понимания игры, без которых футбола не получится.
Это прямая аналогия с уставом. То есть в уставе нужно указать только те аспекты, которые точно не изменятся, например, никогда нельзя будет игрокам брать мяч руками или забегать на трибуны за улетевшим мячом.
 
Что не пишут в правилах и уставе, соответственно? Подробные установки на игру. Например, не описывают, что ты пойдешь на третьей минуте на середину поля, на 3,5 минуте дашь пас к воротам, потом вернешься, а на 4-ой минуте снова отправишься на середину поля. Таких деталей в уставе быть не должно.
 
Еще раз: устав – это документ, в котором фиксируют только неизменные аспекты. Установки для команды в нем не описаны, только правила игры.
 

 

 

 

 

Кто формирует устав проекта? Чаще всего это менеджер проекта и спонсор, потому что у них договор о реализации проекта. Причем, формирует, пишет устав менеджер, а спонсор, скорее, его утверждает. А как участвует заказчик? В PMBoK предлагается, чтобы заказчик тоже участвовал в этом процессе, но есть оговорки.
 
Фактически устав дает всем сторонам четкое понимание, что это за проект, что на нем делают и что нужно каждой из сторон, чтобы работа была доведена до ума. Обычно спонсор не бегает за менеджером проекта. Потому что спонсор - ему и так хорошо, безо всяких уставов. Он начальник, он сам назначает правила. Сначала поручил, а потом передумал. А менеджера проекта устав спасает от того, чтобы он с командой не попал в ситуацию, когда спонсор поменял правила игры посреди матча и требует от него невозможного.
 
Поговорим про состав устава проекта. Какие разделы всегда необходимо включать в устав?
 
1. Сроки. Их менять нельзя. Их обычно устанавливает спонсор, но менеджер должен проверить, насколько они реалистичны. Как правило, фиксируют сроки окончания всего проекта. Но есть и промежуточные сроки. Например, идет строительство дома. Сам дом должен быть готов, допустим, через год, но через полгода у спонсора заканчивается аренда земли, и с этого момента по площадке не сможет двигаться строительная техника. Значит, в уставе нужно упомянуть 2 срока: первый – срок, когда надо сдать дом, – через год, второй – срок, когда дом должен быть накрыт крышей, чтобы всю технику можно было отпустить с площадки. Иначе придут контролирующие органы и могут возникнуть проблемы.
 
Если спонсор указал конкретные сроки, менеджеру ничего придумывать не надо. Задача менеджера проекта - услышать, чего хочет спонсор.
 
2. Деньги. Как  и сроки, этот раздел не подлежит изменению после начала проекта. По правилам классического проектного управления, если возникла необходимость внести изменения в любой раздел Устава, то надо перезапускать проект. Если вы разрешите футболистам играть с мячом руками, это уже не совсем футбол. Надо остановить игру, и начать новый матч, по новым правилам. Устав меняться не может, поэтому и сроки, и деньги описывают очень коротко и в терминах «не позже чем», «не больше чем». Например, строим 9-этажный дом в течение года. Тогда срок записывается так: «не больше чем  12 месяцев». А бюджет – «не больше 1 млн долларов». То есть это какие-то рамки, за которые ни в коем случае нельзя выйти, иначе проект теряет смысл.
 
3. Цель. Очень часто в уставах пишут плохие цели. Например, проект по созданию и внедрению IT-системы. Цель – “создать и внедрить IT-систему”. Жуть. Самосбывающаяся цель. Нельзя копать яму, с целью копать яму. КОпать яму для чего-то. Чтобы что-то произошло. Цель создания и внедрения ИТ-системы не “создать и внедрить”, а в чем-то еще. Проверяйте свои цели внимательно (среди них часто попадаются очень слабые).
 
4. Содержание. Записывает очень коротко, буквально в пяти абзацах. Больше – вряд ли найдется. Содержание описывается в терминах «что делаем» (продукт проекта), «что не делаем» (исключено из проекта). Допустим, 9-этажный дом строим, но придомовую территорию не облагораживаем.
 
К слову, какого объема должен быть весь устав? На самом деле, это не очень важно. Но норма – 3-5 страниц. Больше бывает редко, но чаще всего это и не нужно. Потому что на проектах не бывает столько неизменных параметров, чтобы устав занимал много страниц. На практике, люди иногда называют уставами и более объемные документы. Часто такое случается в государственных компаниях. Там берут какой-то план-график на календарный год, называют его «устав проекта», создают распоряжение о создании рабочей группы и начинают проект. Вот такое получается проектное управление.
 
И еще: объем устава не зависит от размера проекта. Не важно, строите вы  газопровод или делаете IT-систему. Все равно ключевых неизменных аспектов мало.
 
5. Риски. Менеджер проекта управляет рисками, закладывает на них определенные резервы. Нюанс в том, что схема, используемая в большинстве компаний, на практике не работает. Определение резерва на риски сверху нельзя считать осуществлением управления рисками.
В устав имеет смысл включать только ключевые риски, самые страшные, которые могут угрожать успеху всего проекта. Например, бюджет проекта в рублях, а половина закупок – в долларах. И можно договориться: если рубль упадет, и курс окажется больше 100 рублей за доллар, то денег на проект не хватит, и проект придется досрочно завершить как нецелесообразный. В устав можно записать ключевые терминирующие риски: курсовая разница и какая именно, поломка ключевого станка или сервера (если менеджер едва ли может на нее повлиять) и т.п. Если это случится, то ни менеджер, ни команда не виновата. Придется менять какие-то из ограничений проекта – например, бюджет, или содержание.
 
6. Команда, ресурсы. У вас ресурсы могут быть выражены в деньгах, которые позволят нанять людей и закупить нужные вещи. А могут быть выражены в конкретных людях. То есть вам могут выделить на проект конкретное количество людей. 
 
Если у вас ресурсы в людях, то в уставе, как в неизменном документе, необходимо указать только тех людей, без которых проект невозможен. Если уход специалиста не критичен, его фамилию можно не записывать в уставе. Но общее количество людей все равно надо указать, например, для проекта необходимо 5 электриков I разряда или 6 программистов определенного уровня. И когда есть договоренность со спонсором о количестве специалистов конкретного уровня, не обязательно перечислять какие-то фамилии.
  
Это основные разделы устава. Догмы нет, устав можно менять под себя, но методология рекомендует добавлять все перечисленные разделы.
 
Теперь разберемся, как устав фиксировать: в электронном виде или на бумаге с подписью и печатями, в нескольких экземплярах?
 
Иногда спонсоры противятся уставам, и не поддерживают их составление. Но менеджеру необходимо, чтобы такой документ был - как мы уже обсуждали выше, это элемент его безопасности. Устав обязательно должен быть в печатном виде, но его не надо где-то регистрировать или ставить на нем печать. Потому что это не юридический документ. Устав – это договор о том, что спонсор предоставляет ресурсы на проект, а менеджер выполняет поставленную задачу, имея определенные временные рамки и бюджет.
 
Почему не надо ставить печать на уставе? Представьте, что начальник обещал выделить ресурсы на проект, но не предоставил их. Вы пойдете жаловаться в Гаагский трибунал? Нет, конечно. Потому что устав – это внутренний документ, который за пределы компании никогда не выйдет. Он помогает не забыть, о чем договорились стороны.
 
Что касается подписи спонсора, то она нужна обязательно. Когда работаешь в компаниях с низким уровнем зрелости проектного управления, часто сталкиваешься с ситуацией, что спонсор не хочет подписывать устав. Мол, менеджер – бюрократ, и подпись - это условность. Но когда спонсор собирается подписать конкретную бумажку, конкретно в тот момент, когда он заносит над ней ручку - у него иначе включается мозг, и он уже внимательно вычитывает каждый раздел. Именно такого эффекта нам и надо достичь: чтобы спонсор ознакомился с основными разделами, если у него есть претензии, сразу их высказал. Зато потом, в ходе реализации проекта, проблем уже будет меньше. Спонсору придется выделять ресурсы или еще что-то делать, потому что он уже подписал устав.
 
Обратите внимание. Если менеджер борется за реализацию проекта в рамках треугольника (время, деньги, содержание работ), то спонсор ходит по периметру треугольника, снаружи.  И в приличном обществе он должен отгонять всех от проекта, в том числе самого себя. Что это значит? Это значит, что если он обещал команду в 15 человек, то пусть 15 и даст. 15, а не 12 или 14. Если в уставе были прописаны какие-то особые люди со сверхъестественной квалификацией - пусть спонсор даст именно их. Или пусть перезапускает проект, меняя сроки и содержание (да, нужен будет новый устав). Потому что если обещали 1 миллион долларов, а дали только полмиллиона, то построить такой же дом уже не получится. Так и с людьми. Ключевой аргумент российского менеджмента – «очень надо». Например, у вас команда из 10 человек, приходит спонсор и говорит, что ему очень нужны 3 из них. Резонно спросить: мы вообще делаем проект или нет. Если делаем – оставь команду в покое. Если тебе нужны люди, давай этот проект свернем и сделаем другой – поменьше.
 
А теперь попробуем разобраться, в каких ситуациях нельзя показывать устав проекта заказчику. Ответ – в содержании устава, его разделах. Что может смутить заказчика?
 
Конечно, деньги. Представьте себе ситуацию проекта для внешнего заказчика с высокой маржинальностью. Допустим, клиент заплатил за проект 1 миллион долларов. Вам спонсор согласовал 10 000 долларов бюджет проекта. И если клиент (заказчик) увидит это, у него случится инфаркт. Он поймет, что его просто ограбили. Или заказчик увидит какие-то другие подробности проекта, из которых поймет, что его хотят обмануть. Поэтому когда заказчик платит вам деньги, а у вас в уставе указан бюджет, и этот бюджет существенно расходится с тем, что он вам платит, лучше проявить благоразумность и не показывать ему устав. Но ему можно показывать отдельные разделы документа.
 
Подводя итог, напомним. Инициация проекта заканчивается принятием решения о том, будем мы делать проект или не будем, если будем, то в каком виде. Все правила записываются в устав. Это короткий лаконичный документ, неизменный план, где указано только то, что точно не будет меняться в ходе проекта.
 
С уставом менеджер сверяется в конце, когда проект завершен. По тому, насколько удалось уместиться в неизменные рамки с тройственным ограничением, можно определить, был ли проект успешным. Если устава нет, то сложно определить, получилось ли достичь поставленных целей. В таком случае непонятно, за что платятся бонусы менеджеру, ведь неясно, сумел ли он работать в рамках треугольника. Поскольку проект – это вещь сопряженная с конфликтами, менеджеру всегда сложно. И если он получает бонусы за проект, выполненный по планам, которые сам же переписывает по ходу, или по субъективному мнению высшего руководства, то это уже совсем другая история, а не проектное управление. В этом случае руководство прокачивает в людях неумение управлять проектами, а умение нравиться. А это не сложно – понравиться одному человеку, начальнику. Даже если все время проект проваливаешь. Но в итоге в таких компаниях часто выращивают целую плеяду людей, которые умеют строить отношения внутри компании, но не умеют управлять проектами.
 
После того, как подписали устав, вышли из условного кабинета спонсора проекта и закрыли за собой дверь - вы теперь “главный”. Спонсор теперь ждет, когда появится результат проекта. Он свое дело сделал: задачу поставил, и ему не очень интересно, что дальше, он не будет бегать за вами. А дальше ваше дело, какие планы вы будете строить, как вы будете их строить. Вам решать как лучше планировать. Как мотивировать команду. Как проверять контрольные точки и так далее. Главное - попадите в устав, в треугольник, достигните цели и удовлетворенности ключевых заинтересованных сторон.
 
Методологи придумали некий алгоритм. Они считают - если использовать его, то вероятность попасть в треугольник и удовлетворить ключевые ожидания повышается. Но никто, и даже PMI не считает это алгоритм “догматичным” и обязательным. Если нужно - переделывайте. “Допиливайте” под себя, дорабатывайте напильником. Нет идей как “допиливать” - попробуйте использовать в чистом виде. :)

 

Место Устава в проекте 

 


И первое, что начинает делать менеджер, – начинает работать с содержанием. Но об этом мы поговорим в следующих статьях.

Предыдущая часть курса: Управление заинтересованными сторонами. Курс по управлению проектами, часть 4

Следующая часть курса: Алгоритм управления содержанием проекта. Курс по управлению проектами, часть 6

Начало курса: Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера. Курс по управлению проектами, часть 1

 

Если вас интересует тема "Управления проектами" и вы хотите самостоятельно подготовиться к экзамену на сертификат Project Management Professional, то приглашаем пройти новый видеокурс Ивана Селиховкина "Подготовка к экзамену РМР"

См. также

10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Кейсы проектов Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    2779    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14308    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    5856    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    4706    0    andironenko    2    

31

На что похож ваш продукт: на Аквариум или на Муравейник? 

Инструменты управления проектом Бесплатно (free)

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

27.12.2022    2750    0    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4188    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Цикл статей о том, почему акушер-сантехник широкого профиля - это ПЛОХО. Расскажу плюсы специализации на одной предметной области. Рассмотрим понятные аналогии из других областей. Проанализируем пару вакансий, естественно без указания компании.

09.09.2022    10682    0    biimmap    79    

75

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Архитектура Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    13096    0    Evil Beaver    17    

117
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. rpgshnik 3633 14.09.18 04:07 Сейчас в теме
Полностью не читал.
Умилила последняя картинка, я как понимаю это резюме публикации.
Что я вижу.
Любой проект начинается через ж..., долго очень долго делается и выходит не естественным путём.
Всё это время заинтересованные лица находятся в ж..., устав близко к ж....
Бюджет по всей видимости раздуется и раздуется, судя по циклу.
Всё это время появляется куча других планов, вроде их выполнение.
Там же новые требования, сдвигаются сроки.
Рано или поздно через не естественный выход происходит закрытие проекта.
Лицо удава схоже с упоротым наркаманом, а это видимо лицо проекта.
Поправьте если не прав, извините если обидел.
limm28; ЧерныйКот; Vyatcheslav; Interrupted; Pine-river; sCHTASS; dabu-dabu; AerinSwift; LynxX; user621724_Dimav1979; forseil; EliasShy; +12 4 Ответить
2. Art1387 4 14.09.18 07:56 Сейчас в теме
(1)Иногда проект начинается вполне оптимистично в другом месте, но в ж... он побывает обязательно!
DanilinaNatalya; user621724_Dimav1979; rpgshnik; AlX0id; +4 Ответить
3. user621724_Dimav1979 401 14.09.18 09:50 Сейчас в теме
(1) и часто заканчивается там где и начался
rpgshnik; +1 Ответить
4. MariaTemchina 1594 14.09.18 10:14 Сейчас в теме
(1)
Полностью не читал.

Это из серии "не читал, но не согласен".

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

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

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

Всё это время заинтересованные лица находятся в ж..., устав близко к ж....

Что вам это анальное отверстия покоя не дает, прости Господи! На схеме просто показано, что Устав и реестр заинтересованных сторон создаются в самом начале проекта до запуска остальных процессов.

Бюджет по всей видимости раздуется и раздуется, судя по циклу.

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

Рано или поздно через не естественный выход происходит закрытие проекта.

А как бы вы предлагали нарисовать? Удава в другую сторону? Тогда вы бы еще больше острили.

Лицо удава схоже с упоротым наркаманом, а это видимо лицо проекта.

Коллеги, ну чего вы хотите от карикатуры! Хорошо, давайте не будем смешные картинки размещать, если аналогии вызывают такие трудности в восприятии, а будем иллюстрировать скучными схемами из учебника.

Поправьте если не прав, извините если обидел.

Я бы на месте Ивана, пожалуй, обиделась. Да, многие проекты проваливаются, факт. Кто же с этим будет спорить? Грамотное применение проектных методологий (ключевое слово - грамотное) повышает шанс, что проект завершится не в столь полюбившемся вам месте, а более успешно. Вот статьи как раз и рассказывают как это сделать, а не каким должно быть выражение морды удава, я вас умоляю.
vova196; pro-rok; Rudakov_D; Valerych; serge_focus; slavap; awk; vrednyi_glavred; A_Kriulina; Артано; AerinSwift; +11 3 Ответить
5. profiprog1c 248 14.09.18 12:31 Сейчас в теме
Почему то мне эти "любители" PMBOK чем то напоминают любителей гербалайфа
user630388_optimasm; rpgshnik; user621724_Dimav1979; acanta; +4 Ответить
6. user621724_Dimav1979 401 14.09.18 15:54 Сейчас в теме
Как говорил один Паша с канала ТНТ, все што дальше уральских гор (дальний восток) это как в в сериале Игра пристолов...до гор это Старки, Ланнистеры и т.д...все што за ними это одичалые.
Так вот на практике скажу как руководитель не одного десятка проектов, што УСТАВ нужен "кланам", чтобы тыкать в него лицом "одичалым" за неисполнение своих обязательств. И довольными умывать свои руки.

Устав дает "свободу неисполнения обязательств" исполнителю и сковывает руки заказчика. Увы, но моя практика такая.
chng; LynxX; EliasShy; rpgshnik; acanta; +5 Ответить
7. Артано 760 17.09.18 04:51 Сейчас в теме
(6)
дальше уральских гор (дальний восток) это как в в сериале Игра пристолов...до гор это Старки, Ланнистеры и т.д...все што за ними это одичалые


А вот сейчас обидно стало. Привет из Хабаровска от одичалых
rpgshnik; user621724_Dimav1979; +2 Ответить
8. user621724_Dimav1979 401 17.09.18 05:11 Сейчас в теме
(7) привет из Иркутска :)
9. acanta 17.09.18 21:14 Сейчас в теме
Ага, прикинь, приходишь в контору.. Ужас что творится. АД. Сидишь с ними и без них ночами, что -то пилишь, пишешь, чистишь. Проект сдали. За чаем довольные и ощасливленные дамы начинают откровенничать и рассказывать о том, что у них сын/дочь и прочие родственники в Москве 1С программистами работают и от ста тыщ получает, и не жалуются. Надо ж делать, чтоб не хуже получилось.
11. Артано 760 18.09.18 07:08 Сейчас в теме
(9) Остатыщ в Москве уже давно не показатель успешности. Остатыщ еще в регионах могут порадовать. По другим регионам не знаю, но в Хабаровске 60-90 для миддла. 90-130к для сеньора. ЗП менее 50к для человека отличающего цикл от рекурсии не встречал. Возможно если почитать газету, то можно найти, но порядок цен примерно таков.

К реплике мол "мы кто-то из местных" отношусь негативно. Мог понять это лет 30-40 назад. Сейчас же, современные технологии доступны в любой точке страны где есть электричество и интернет. Вопрос в желании, а не возможностях
10. acanta 17.09.18 21:58 Сейчас в теме
Это я к тому что мы не одичалые. Мы "какие-нибудь местные". Так и представляю себе разговор мамы с ребенком лет 40. У него своя жизнь, он посоветовал найти каких нибудь местных. Но он всегда проконсультирует ее в чем местные могут быть слабоваты. И за ему, неизвестному, спасибо.
12. andukin 23.09.18 10:51 Сейчас в теме
Это значит, что если он обещал команду в 15 человек, то пусть 15 и даст. 15, а не 12 или 14. Если в уставе были прописаны какие-то особые люди со сверхъестественной квалификацией - пусть спонсор даст именно их. Или пусть перезапускает проект, меняя сроки и содержание (да, нужен будет новый устав). Потому что если обещали 1 миллион долларов..

мощно. огромный опыт автора в реализации проектов витает осязаем настолько что кажется его можно потрогать.
объем устава 3-5 страниц и электрики I разряда не оставляют и тени сомнений..
:)
13. acanta 23.09.18 11:05 Сейчас в теме
15. andukin 23.09.18 13:40 Сейчас в теме
(13) не остается сомнений в огромном опыте автора - реализации различных проектов, включая строительство газопровода (ц)
14. acanta 23.09.18 11:18 Сейчас в теме
Проект типа каша из топора. Устав из одного пункта пустить переночевать. Ну вот не окажется у старухи масла, он что, останется доваривать топор?
16. artemusII 12.11.19 11:22 Сейчас в теме
Содержание описывается в терминах «что делаем» (продукт проекта), «что не делаем» (исключено из проекта). Допустим, 9-этажный дом строим, но придомовую территорию не облагораживаем.


Не согласен, что надо описывать «что не делаем» (исключено из проекта). Исключения условно не ограничены, в таком случае необходимо включить абсолютно все, что не касается проекта, ведь в противном случае могут придраться. Следует руководствоваться принципом, подобным "что не разрешено, то запрещено".
Оставьте свое сообщение