Устав писать Устав

06.05.19

Управление проектом - Инструменты управления проектом

Ответы на вопросы про то, нужен ли Устав для проектов автоматизации, и если нужен, то зачем?

Анекдот

- Скажите, а что самое сложное в работе лифтера? Подъемы?
- Нет, мэм.
- Что, неужели - спуски???
- Нет, мэм.
- А что же тогда???
- Вопросы, мэм. Бесконечные, идиотские вопросы.

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

Так что продолжаем рубрику “Письма читателей”, которую я открыла некоторое время назад публикацией "Озарение после прочтения макулатуры по проектному управлению". 

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

И поговорить сегодня я хочу про документ, с которого рекомендуется начинать проекты автоматизации - а именно Устав проекта. 

Вопрос. А нужен ли вообще Устав? На мой взгляд Устав проекта - это очень «тяжелая» документация в которой велик соблазн уйти в глубины детализации проекта, потратив слишком много времени не рационально. 

Золотой круг AgileОтвет: В любых отраслях я очень не люблю категорично утверждать “вам нужно поступать так-то и так-то”. И с некоторой настороженностью отношусь к тем, кто безапелляционно что-то такое утверждает. 
Я часто вспоминаю идею, что как только мы от “простых систем” перемещаемся к “сложным системам” или “комплексным системам” (а редкий проект внедрения - ну, может быть, типовая установка стандартной конфигурации Бухгалтерии - может быть описан как “простая система”), некорректно считать, что в каждой ситуации есть ровно один правильный способ действий. В действительности, потенциально правильных способов реализовывать проект почти всегда может быть много. И это столь же относится и к вопросу создания Устава. 
Напомню, что Устав - это документ, который формально назначает руководителя проекта и запускает проект.  И создавать его можно по-разному - в каких-то проектах Устав - это длинный документ, подобный тому, шаблон которого предлагается в Профкейсе в рамках 1С:Технологии корпоративного внедрения…  В каких-то - краткое уточнение общей ситуации, подобное предлагаемому в так называемом “Золотом круге Agile” - ответ на вопросы Зачем? Как? и Что?..

По моему опыту применение любого документа целесообразно только тогда, когда выгоды от его использования превышают затраты на бюрократические процедуры оформления (про то, что получается если пренебрегать этим принципом я писала в статье на тему “Быть или казаться” - получается документация “для галочки”, не повышающая ценность реального проекта)...

Ценность Устава - в “подстраховке”. В предотвращении таких ситуаций, когда при приемке заказчик говорит “а я акты не подпишу, пока вы не переделаете всё “как следует”, при этом что входит в понятие “как следует” - остается тайной за семью печатями…  В указании на старте, какие ресурсы потребуются - и в большей весомости позиции РП со стороны исполнителя на совещаниях, посвященных этим самым ресурсам. Позволит ли Устав решить все проблемы и застраховать себя от всех сложностей? Я вас умоляю… Чудеса бывают крайне редко. Лозунг “Автоматизация хаоса приводит к автоматизированному хаосу” (М. Хаммер и Дж. Чампи) уже несколько лет висит у меня рядом с рабочим столом. Но улучшить взаимопонимание Устав может.


Вопрос: Возникли трудности с разграничением таких пунктов устава, как: 
•    Цели и их критерии 
•    Требования к одобрению проекта 
•    Критерии выхода из проекта 


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

Цели и их критерии - здесь описываем бизнес-цели. Зачем проект автоматизации затевается? Какую проблему он призван решить/какую возможность использовать? Повысить управляемость компании? Улучшить конверсию заказов в продажи? Уменьшить потери документов? Повысить привлекательность компании в силу увеличения прозрачности для выхода на IPO? Нужное подчеркнуть, недостающее вписать. В чем смысл этого пункта - он помогает увидеть лес за деревьями. Потому что внедряем-то мы прикладное решение не ради внедрения, а для каких-то бизнес-целей. 
Нам сложно сформулировать? Мы не уверены, что достигнем целей? Ну да, так в жизни обычно и бывает. Но на что-то мы же рассчитываем, когда выделяем бюджет на внедрение, допустим ERP-системы - мы же надеемся, что наши выгоды (пусть опосредованные) будут больше затрат! И ничего страшного, что бизнес-цели будут достигнуты уже после того, как проект будет завершен. И непосредственно от внедренцев достижение бизнес-целей не всегда зависит, или даже чаще всего не зависит.

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

 

Как выглядит сбор требований на проекте

 

Критерии выхода из проекта. Очередное лирическое отступление:

Еще один анекдот.

На колхозном собрании выступает председатель колхоза: — В прошлом году посадили 50 га хлеба — все пожрал поганый сусляк. В этом году — 100 га — тоже все пожрал поганый сусляк. В будущем году посадим 300 га — пусть он, гад, подавится!

Неудачный проект очень важно вовремя закрыть. 
К сожалению, нередко бывает, что начатые с большой помпой проекты продолжаются существенное время после того, как многим уже становится очевидна их нецелесообразность. В результате - затраты времени, денег и репутации с нулевым или отрицательным эффектом. Вот, опять же - застраховать себя от такого риска можно договорившись на берегу о том, в какой ситуации нецелесообразно продолжение проекта. Sunk costs are gone. Невозвратные издержки мы не учитываем.

 

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

Ответ. Еще раз напомню - если пункт Устава вам не нужен, не надо его использовать! Насколько мне известно, большинство франчайзи, которые используют шаблон Устава из Профкейса с целью “быть”, а не “казаться”, то есть пытаясь улучшить ведение проекта, а не произвести впечатление - его так или иначе под себя модернизируют. 

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

  • Описания - содержание, результат
  • Границы - спорные вещи: что входит, что не входит - чтобы потом, на выходе не ругаться “а почему этот функционал не вошел?”
  • Требования - суть, какой функционал хочет получить бизнес от продукта проекта?.

А слово “высокоуровневые” напоминает, что на старте проекта не обязательно детализировать ТЗ - оно потом можно будет...


Вопрос: Больше всего вопросов вызвал пункт "Совокупный риск проекта". Так и не понял как к нему подступиться(( . 
Совокупный риск проекта – если придерживаться техники PreMortem то просто, но внешнего заказчика это не устроит, а внутреннего в зависимости от важности проекта. 

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


Вопрос: Заранее утвержденные финансы – на момент подписи договора может поменяться, правильно понимаю, что если к договору идут дополнительные соглашение, то на практике они могут видоизменить весь устав? 

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

 


Резюме 

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

  • Назначение проекта
  • Бизнес-цели и критерии их достижения
  • Высокоуровневые описания и границы проекта
  • Высокоуровневые требования
  • Совокупный риск проекта
  • Заранее утвержденные финансовые ресурсы, временные ограничения
  • Требования к одобрению проекта
  • Критерии выхода из проекта
  • Полномочия и ответственность руководителя проекта; лица (лиц) авторизующего Устав проекта

 

Кому интересно разобрать эти и другие вопросы ИТ-проектов более подробно - последний шанс записаться на базовый курс "Управление ИТ-проектами", первый вебинар пройдет 15 мая, а первую видеолекцию нужно просмотреть до 13 мая. Присоединяйтесь, буду рада пообщаться вживую!

Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах 

См. также

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

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

01.04.2024    2599    0    MariaTemchina    6    

21

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

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

07.11.2023    1692    0    WildHare    2    

16

Компетенции и навыки РП Обучение и наставничество Инструменты управления проектом Бизнес-аналитик Руководитель проекта Бесплатно (free)

Что интересного писали про управление проектами за прошедшую неделю? Мы прочитали все публикации vc, Хабра, Инфостарта (и не только) и выбрали самые крутые и полезные.

09.10.2023    1082    0    Birby    0    

2

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

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

27.12.2022    2952    0    MariaTemchina    28    

24

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

По итогам нашего выступления на семинаре партнеров 1С в октябре 2022-го подготовили эту статью. Риски и советы по их снижению взяты из нашей непосредственной практики взаимодействия с крупными корпоративными заказчиками, в том числе из госсектора. И опыта этого, за более чем 15 лет, накоплено немало. Мы понимаем, что описанные в статье советы не являются панацеей и 100% гарантией решить сразу все полюбовно с заказчиком. Но при этом надеемся, что информация поможет лучше подготовиться как к встрече с самими рисками, так и выбрать «пути для маневра» с целью избегания рисков или, как минимум, их минимизации.

10.10.2022    1535    0    it-expertise    4    

9

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

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

07.09.2021    10400    0    MariaTemchina    0    

20

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

Некоторое время назад один из моих читателей в своем письме предположил, что есть настоящий заговор у тех, кто пропагандирует изучение PMBoK®.

30.07.2021    10480    0    MariaTemchina    13    

23

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

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

28.06.2021    5282    0    MariaTemchina    3    

10
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. bolefirenko 96 06.05.19 16:36 Сейчас в теме
Мария, спасибо, хорошо зашло!
В копилку. Для меня поучительным стал один из первых больших проектов. Года два компания в несколько попыток его запускала, но почему то ёжик не долетал он до цели.
На старте проекта я настоял и мучал себя и всех ключевых бизнес заказчиков в течение 1.5 месяцев, писали Устав. Цели, результаты, договаривались что и как будем делать, как взаимодействовать, что если задница - кто и как ее будет с ней управляться и т.д. В условиях пылающих сроков, мегавостребованности результатов бизнес заказчиков выводили из себя - давайте уже проект делать, быстрее-е-е-е!!!
И когда через пол года ровно в срок и в бюджет отмечали шампанским успешное завершение проекта, РП клиента спросил:
"Я вот одно не понимаю, ну на фига мы на Устав 1,5 месяца убили? Ведь по ходу проекта он так не разу и понадобился!"
А я говорю "потому и потратили, потому и не понадобился" )
Артано; gradi; Vladimir Litvinenko; MariaTemchina; +4 Ответить
5. MariaTemchina 1620 07.05.19 12:46 Сейчас в теме
(1) Борис, спасибо за историю!
Вчера записывала очередную видеолекцию для курса по управлению ИТ-проектами (про развитие команды), и упомянула там в числе прочего про этот твой опыт. Что договориться о правилах - это крайне важный этап, хотя иногда он и затягивается...
2. user621724_Dimav1979 408 07.05.19 09:19 Сейчас в теме
:)
Прикрепленные файлы:
rpgshnik; MariaTemchina; +2 Ответить
4. MariaTemchina 1620 07.05.19 12:44 Сейчас в теме
(2) Да, Дмитрий, спасибо. Мне тоже эта картинка нравится!... И еще вот эта, тоже похожая.
Но, на мой взгляд, это скорее про Agile, чем про классические подходы к управлению проектами.
Прикрепленные файлы:
user621724_Dimav1979; +1 Ответить
6. user621724_Dimav1979 408 07.05.19 13:02 Сейчас в теме
(4) :)
Прикрепленные файлы:
itriot11; whitedi; +2 Ответить
7. MariaTemchina 1620 07.05.19 13:07 Сейчас в теме
8. Артано 766 08.05.19 07:13 Сейчас в теме
(7) фансервис наше всё =)

Мария, мне другое интересно, а приходилось ли работать в геймдев отрасли? У нас она растёт очень бурно, но по тем примерам что знаю, ситуация еще хуже чем в 1с, по известным причинам, но всё же.
9. MariaTemchina 1620 08.05.19 10:03 Сейчас в теме
(8) Работать не приходилось, только изучала/обучала/консультировала... Те, с кем взаимодействовала, ориентировались в-основном на западный рынок.
Оставьте свое сообщение