Анекдот
- Скажите, а что самое сложное в работе лифтера? Подъемы?
- Нет, мэм.
- Что, неужели - спуски???
- Нет, мэм.
- А что же тогда???
- Вопросы, мэм. Бесконечные, идиотские вопросы.
Мне повезло существенно больше, чем герою этого английского анекдота. Во-первых, слушатели базового курса по Управлению ИТ-проектами задают преимущественно умные вопросы. Иногда непростые, иногда подковыристые, иногда приходится разбираться и вникать, чтобы на них ответить. А, во-вторых, я на вопросы отвечать люблю.
Так что продолжаем рубрику “Письма читателей”, которую я открыла некоторое время назад публикацией "Озарение после прочтения макулатуры по проектному управлению".
Учитывая, что последний набор на базовый курс по управлению проектами завершается уже через несколько дней, попробую здесь ответить на несколько вопросов по курсу… А то обидно, что многие яркие дискуссии остаются на закрытых форумах.
И поговорить сегодня я хочу про документ, с которого рекомендуется начинать проекты автоматизации - а именно Устав проекта.
Вопрос. А нужен ли вообще Устав? На мой взгляд Устав проекта - это очень «тяжелая» документация в которой велик соблазн уйти в глубины детализации проекта, потратив слишком много времени не рационально.
Ответ: В любых отраслях я очень не люблю категорично утверждать “вам нужно поступать так-то и так-то”. И с некоторой настороженностью отношусь к тем, кто безапелляционно что-то такое утверждает.
Я часто вспоминаю идею, что как только мы от “простых систем” перемещаемся к “сложным системам” или “комплексным системам” (а редкий проект внедрения - ну, может быть, типовая установка стандартной конфигурации Бухгалтерии - может быть описан как “простая система”), некорректно считать, что в каждой ситуации есть ровно один правильный способ действий. В действительности, потенциально правильных способов реализовывать проект почти всегда может быть много. И это столь же относится и к вопросу создания Устава.
Напомню, что Устав - это документ, который формально назначает руководителя проекта и запускает проект. И создавать его можно по-разному - в каких-то проектах Устав - это длинный документ, подобный тому, шаблон которого предлагается в Профкейсе в рамках 1С:Технологии корпоративного внедрения… В каких-то - краткое уточнение общей ситуации, подобное предлагаемому в так называемом “Золотом круге Agile” - ответ на вопросы Зачем? Как? и Что?..
По моему опыту применение любого документа целесообразно только тогда, когда выгоды от его использования превышают затраты на бюрократические процедуры оформления (про то, что получается если пренебрегать этим принципом я писала в статье на тему “Быть или казаться” - получается документация “для галочки”, не повышающая ценность реального проекта)...
Ценность Устава - в “подстраховке”. В предотвращении таких ситуаций, когда при приемке заказчик говорит “а я акты не подпишу, пока вы не переделаете всё “как следует”, при этом что входит в понятие “как следует” - остается тайной за семью печатями… В указании на старте, какие ресурсы потребуются - и в большей весомости позиции РП со стороны исполнителя на совещаниях, посвященных этим самым ресурсам. Позволит ли Устав решить все проблемы и застраховать себя от всех сложностей? Я вас умоляю… Чудеса бывают крайне редко. Лозунг “Автоматизация хаоса приводит к автоматизированному хаосу” (М. Хаммер и Дж. Чампи) уже несколько лет висит у меня рядом с рабочим столом. Но улучшить взаимопонимание Устав может.
Вопрос: Возникли трудности с разграничением таких пунктов устава, как:
• Цели и их критерии
• Требования к одобрению проекта
• Критерии выхода из проекта
Ответ. Возвращаемся на шаг назад. Не смотря на обилие различных шаблонов (и я делюсь вариантами на курсе, и в Профкейсе найти можно, и вообще вариантов масса), напомню важную идею - что стоит добавлять в документы те пункты, добавление которых принесет вам выгоду. То есть, если пункты не нужны - их стоит смело выбросить. Я предлагаю следующие пункты Устава интерпретировать следующим образом:
Цели и их критерии - здесь описываем бизнес-цели. Зачем проект автоматизации затевается? Какую проблему он призван решить/какую возможность использовать? Повысить управляемость компании? Улучшить конверсию заказов в продажи? Уменьшить потери документов? Повысить привлекательность компании в силу увеличения прозрачности для выхода на IPO? Нужное подчеркнуть, недостающее вписать. В чем смысл этого пункта - он помогает увидеть лес за деревьями. Потому что внедряем-то мы прикладное решение не ради внедрения, а для каких-то бизнес-целей.
Нам сложно сформулировать? Мы не уверены, что достигнем целей? Ну да, так в жизни обычно и бывает. Но на что-то мы же рассчитываем, когда выделяем бюджет на внедрение, допустим ERP-системы - мы же надеемся, что наши выгоды (пусть опосредованные) будут больше затрат! И ничего страшного, что бизнес-цели будут достигнуты уже после того, как проект будет завершен. И непосредственно от внедренцев достижение бизнес-целей не всегда зависит, или даже чаще всего не зависит.
Требования к одобрению проекта - здесь мы на берегу договариваемся о том, как будут работу внедренцев на выходе принимать. Потому что, как известно, у каждого человека своя “картина мира”, и чем лучше нам удалось синхронизировать требования в начале, тем больше шансов на успех в конце. А над всем известной серией картинок про взаимодействие заказчика и исполнителя… Кто проекты внедрял, тот над ней не смеется.
Критерии выхода из проекта. Очередное лирическое отступление:
Еще один анекдот.
На колхозном собрании выступает председатель колхоза: — В прошлом году посадили 50 га хлеба — все пожрал поганый сусляк. В этом году — 100 га — тоже все пожрал поганый сусляк. В будущем году посадим 300 га — пусть он, гад, подавится!
Неудачный проект очень важно вовремя закрыть.
К сожалению, нередко бывает, что начатые с большой помпой проекты продолжаются существенное время после того, как многим уже становится очевидна их нецелесообразность. В результате - затраты времени, денег и репутации с нулевым или отрицательным эффектом. Вот, опять же - застраховать себя от такого риска можно договорившись на берегу о том, в какой ситуации нецелесообразно продолжение проекта. Sunk costs are gone. Невозвратные издержки мы не учитываем.
Вопрос. Высокоуровневые описания и границы проекта – это то, что может кардинально измениться. Почему не использовать для этих целей пункты: назначение проекта, измеримые цели проекта и критерии успех, высокоуровневые требования.
Ответ. Еще раз напомню - если пункт Устава вам не нужен, не надо его использовать! Насколько мне известно, большинство франчайзи, которые используют шаблон Устава из Профкейса с целью “быть”, а не “казаться”, то есть пытаясь улучшить ведение проекта, а не произвести впечатление - его так или иначе под себя модернизируют.
Напомню, что я предлагаю рассматривать пункты “назначение проекта и цели проекта” для того, чтобы посмотреть на проект “сверху вниз” - с позиции бизнес-целей. А вот пункты “высокоуровневые описания, границы и высокоуровневые требования” - они уже да, про конкретно саму содержательную часть проекта - что мы делаем-то?...
Причем во всех трех пунктах разные фокусы внимания:
- Описания - содержание, результат
- Границы - спорные вещи: что входит, что не входит - чтобы потом, на выходе не ругаться “а почему этот функционал не вошел?”
- Требования - суть, какой функционал хочет получить бизнес от продукта проекта?.
А слово “высокоуровневые” напоминает, что на старте проекта не обязательно детализировать ТЗ - оно потом можно будет...
Вопрос: Больше всего вопросов вызвал пункт "Совокупный риск проекта". Так и не понял как к нему подступиться(( .
Совокупный риск проекта – если придерживаться техники PreMortem то просто, но внешнего заказчика это не устроит, а внутреннего в зависимости от важности проекта.
Ответ. Совокупный риск - это общие шансы проекта на успех. Оценить совокупный риск не просто. Одна из простых схем: если проект проходящий, привычный - то его можно считать низкорисковым. Если аналогичных проектов никогда раньше не делали - то надо честно признаться себе, что проект высокорисковый.
Здесь может возникнуть щекотливый момент - если исполнитель в самом начале честно признается заказчику, что считает проект рискованным, то есть риск, что заказчик передумает и откажется от работы. В чем, естественно, исполнитель не заинтересован. Что на это могу ответить? Ну, во-первых, даже если исполнитель не готов все риски обсуждать с заказчиком, важно как минимум себе честно отдавать отчет в имеющихся рискам. Во-вторых, открытая и честная коммуникация - это правильный подход, и он способствует росту доверия. Ну и вообще, этичное поведение далеко не всегда оказывается наиболее выгодным - на то оно и этичное. Как вам поступать в той или иной ситуации - это уже решайте сами.
Вопрос: Заранее утвержденные финансы – на момент подписи договора может поменяться, правильно понимаю, что если к договору идут дополнительные соглашение, то на практике они могут видоизменить весь устав?
Ответ. Во-первых, у нас не всегда четко понятны финансовые ресурсы на старте. Мне кажется, что самый работающий вариант - когда у нас на старте есть рамочное соглашение, а дальше мы уже его уточняем при помощи доп.соглашений. Во-вторых, Устав может быть изменен - если по завершении какой-то фазы мы пересмотрели цели, критерии успеха, и общие запросы бизнес-заказчика - глупо держаться за устаревшие данные. Существенная часть проектов внедрения на выходе оказывается больше и дороже, чем планировалось изначально - и не из-за несовершенной работы, а из-за уточнения запросов - чтобы максимально достичь тех самых бизнес-целей заказчика.
Резюме
Устав может помочь улучшить взаимодействие на вашем проекте, договориться на "берегу" про ответственность, границы, требования, критерии приемки. Устав будет полезен в первую очередь тогда, когда вы понимаете, в чем выгода от его использования. В Устав можно включить следующие пункты:
- Назначение проекта
- Бизнес-цели и критерии их достижения
- Высокоуровневые описания и границы проекта
- Высокоуровневые требования
- Совокупный риск проекта
- Заранее утвержденные финансовые ресурсы, временные ограничения
- Требования к одобрению проекта
- Критерии выхода из проекта
- Полномочия и ответственность руководителя проекта; лица (лиц) авторизующего Устав проекта
Кому интересно разобрать эти и другие вопросы ИТ-проектов более подробно - последний шанс записаться на базовый курс "Управление ИТ-проектами", первый вебинар пройдет 15 мая, а первую видеолекцию нужно просмотреть до 13 мая. Присоединяйтесь, буду рада пообщаться вживую!
Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах
