Этап подготовки проекта в теории

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

Что же такое проект?

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

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

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


У каждого проекта существуют 3 ключевых измерения – бюджет, время и качество, которые должны быть сбалансированы для успешного управления проектом. Поэтому главной задачей при управлении проектами как раз и является соблюдение баланса этих измерений – уложиться в выделенный бюджет, при этом не выйти за рамки временных ограничений и обеспечить приемлемое качество. Отсюда и вытекают 3 основных признака неудачи проектов:
  • проект не уложился в рамки бюджета;
  • проект занял большее время, чем было запланировано;
  • проект завершен в рамках бюджета и намеченного времени, но не удовлетворяет по качеству.


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

Часто встречающиеся недостатки в реализации проектов:

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


На основании своих исследований Элбейк и Томас указали 10 факторов, которые многие определяют как критические для успеха проекта (расположены в соответствии с приоритетами):

  1. ясно поставленные цели;
  2. четкое планирование и контроль;
  3. высокая квалификация менеджера проекта;
  4. хорошая административная поддержка;
  5. достаточное количество времени и ресурсов;
  6. выполнение своих обязательств всеми участниками;
  7. широкое привлечение потребителей;
  8. хорошие коммуникации;
  9. хорошая организация и структура проекта;
  10. возможность прекратить реализацию проекта.


Определение границ проекта


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

3 фазы в определении потребностей:
  1. Появление потребностей — все заинтересованные стороны должны предупреждать и предвидеть потребности, реагируя на них проактивно;
  2. Признание потребностей — осознание потребностей на основе сбора информации и обсуждения с ЗС. Главная задача на этом этапе – превращение возникающей потребности в цели, которые начнут определять результаты проекта;
  3. Формулирование потребностей — прояснение понимания потребности с помощью более точного описания ее характерных особенностей. Формулировка того, что должно быть сделано, т.е. определение границ, формулировка проекта.


Проблемы недостаточно точного определения потребностей:

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


Для того, чтобы понять масштабы проекта необходимо иметь следующую информацию:

  1. Кто является заинтересованными сторонами (ЗС) и каковы их потребности в проекте?
  2. Каковы цели и задачи проекта и каким образом их собираются осуществить в рамках соответствующих ресурсных и временных ограничений? (предназначение и цели)
  3. Каковы возможности проекта и угрозы для его успешной реализации?


ЗС и их потребности

Наиболее важные ЗС для проекта:
  1. Покровитель проекта – человек или группа людей, которые инициируют и поддерживают проект, обеспечивают ресурсами и поручают Вам его реализацию;
  2. Команда проекта – группа людей, готовых выполнять поставленные задачи и осуществлять необходимые виды деятельности; 3.Функциональные менеджеры и другие люди, которые управляют необходимыми Вам ресурсами и обладают полезными для Вас опытом и знаниями;
  3. Влиятельные люди или группы, которые, вероятно, подвергаются воздействию проекта или его результатов


В зависимости от особенностей проекта многие другие группы или отдельные люди могут быть заинтересованы в нем:

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


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

Определение предназначения и целей проекта

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

Цели должны соответствовать критериям SMART:

  • конкретными (specific) – т.е. Вы должны ясно представлять себе, чего хотите достичь;
  • измеримыми (measurable) – Вы должны разработать критерии для измерения процесса достижения целей;
  • достижимыми (achievable) – т.е. Вы должны быть уверены в достижении поставленных целей в существующем окружении и при имеющихся ресурсах;
  • реалистичными (realistic) – т.е. Вам не следует пытаться достичь невозможного;
  • определенными по времени (timebound) – т.е. сроки достижения поставленных целей должны диктоваться реальными потребностями


Поставленные цели дают возможность определить шаги, с помощью которых может быть реализовано предназначение проекта и не позволить сбиться с правильного пути; использоваться для того, чтобы убедиться, что проект хорошо вписывается в деятельность организации.
Ясность целей важна для понимания того, что должно быть сделано. Если поставлены четкие цели, то это значит, что имеется определенная система взглядов на конечный результат. На основании поставленных целей происходит структурирование проекта с тем, чтобы его можно было эффективно контролировать и управлять им. Однако иногда возникает необходимость в пересмотре целей, поскольку в процессе осуществления проекта могут возникнуть новые обстоятельства, неизвестные на стадии планирования. Поэтому цели не должны быть «каменными».

Возможности и угрозы

Исследование возможностей и угроз на начальной стадии проекта может быть важным для определения его масштаба. Постоянные обсуждения с ЗС могут выявить многие потенциальные возможности и угрозы, связанные с проектом. Управление рисками (возможными угрозами проекту) будет рассмотрено ниже.

Проверка осуществимости проекта



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


Затраты и выгоды для оценки проекта


Для составления бюджета проекта финансовые затраты делят на две главные категории:
  • стоимость разработки- затраты, возникающие в период между началом проекта и моментом, когда начато производство продукции. Они присущи всем проектам и обычно включают в себя затраты на команду проекта.
  • операционные затраты – затраты, возникающие с началом выпуска продукции и обеспечивающие поддержание данного процесса (пример – ежедневно расходуемые материалы, используемый капитал). Они не возникают в проекте, в котором продукт продается один раз сразу после завершения проекта.

Выгоды в управлении проектами делятся также, как в финансовом учете на:
  • осязаемые выгоды — прямые, видимые и измеряемые выгоды, обычно базирующиеся на денежных потоках, которые поступают в организацию или больше не уходят из организации;
  • неосязаемые выгоды — косвенные, неопределенные и менее легко измеримые с финансовой точки зрения выгоды (более высокое качество услуги, возросший ассортимент).

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

Оценка проекта дает возможность прояснить, будет ли стоимость результатов проекта превышать стоимость ресурсов, используемых для проекта. Тем не менее, очень важно оценить проект не только с экономической т.з. – проект должен быть рассмотрен в контексте предназначения организации, её политических и социальных обязанностей и забот, её стратегического направления и того, как рынок или общественное мнение отреагируют на решение организации начать проект.
Несмотря на то, что проекты имеют определенные уникальные характеристики, большинство из них имеет сходную финансовую структуру – стоимость разработки должна быть оплачена до получения выручки, т.е. необходим временный источник денег. В краткосрочных проектах вопрос затрат и выгод решается довольно просто. В случаях более сложных, особенно при наличии неосязаемых выгод, необходимо выносить суждения, основанные на сопоставлении ценностей. У многих проектов существует или большой интервал между платежами и поступлениями, или необходимость в крупном авансе, или и то и другое. С финансовой т.з. деньги, более точно капитал, который нужно вложить в проект для оплаты стоимости разработки, может быть установлен, поскольку обычно привлекается из внешних или внутренних источников. Его стоимость включается в оценки осуществимости проекта, а также в бюджеты и отчеты по проекту. Для оценки финансовой стоимости проекта нет необходимости проводить различие между прибылью и денежными потоками, можно сконцентрироваться только на анализе денежных потоков.
Существует несколько методов оценки денежных потоков по проекту (подробно рассматриваться здесь не будут):
  • Чистая текущая стоимость (Net Present Value — NPV);
  • Внутренняя норма отдачи (internal rate of return — IRR);
  • Срок окупаемости;
  • Анализ эффективности затрат.


Риски и ситуационное планирование


Риск – возможность неблагоприятного воздействия на проект, ИЛИ событие или ситуация, которые могут повергнуть опасности весь проект или его часть. Риски могут быть внутренними, т.е. возникающими в рамках проекта, так и внешними, появляющимися из самого контекста или окружения проекта.
Существуют 4 стадии управления риском:
  1. Выявление риска – определение, какие риски могут влиять на проект, и описание характеристик каждого из них.
  2. Оценка влияния – оценка риска с точки зрения диапазона возможных результатов, касающихся проектов, и потенциального влияния каждого из них.
  3. Планирование запасных вариантов с целью снижения влияния наиболее вероятных рисков.
  4. Обеспечение того, что риски всегда находятся в поле зрения.


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


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

Оценка риска и анализ влияния: ключевые вопросы


Оценка риска — измерение вероятности превращения риска в реальность; анализ влияния – измерение чувствительности проекта к каждому определенному риску. Ключевые вопросы состоят в следующем:
  • что такое риск – как я его узнаю, если он возникнет?
  • какова вероятность его осуществления – высокая, средняя или низкая? насколько серьезную угрозу он представляет для проекта – высокую, среднюю или низкую?
  • каковы признаки или причины риска, которые нам следует искать?

Стратегии обращения с рисками:
  1. Избежание риска — например, отказ от контракта;
  2. Снижение риска — например, регулярные проверки могут снизить вероятность производства продукта низкого качества;
  3. Защита от риска — например, страхование от возможных случайностей;
  4. Управление риском — например, использование письменных соглашений в тех сферах деятельности, где возможны разногласия;
  5. Перемещение риска — например, передача ответственности за выполнение рискованного задания в рамках проекта другой организации, у которой больше опыта.

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

Основание для действий по проекту



После того, как были рассмотрены и обсуждены предназначение и цели проекта, а также после проверки его осуществимости, необходимо разработать документ, являющийся основанием для действий по проекту. В этом документе должна быть указана точка отсчета всей будущей работы по проекту, и он будет основой для выводов о том, оказался ли проект успешным в итоге или нет. Иногда этот документ называют проектным договором, однако часто в нем содержится конкретизирующая информация в виде резюме проекта. Его обычно создает менеджер проекта, но очень важно, чтобы оно обсуждалось с покровителями проекта и всеми основными ЗС. Оно должно фиксировать согласованную точку зрения по ключевым характеристикам проекта:
  • ожидаемым результатам;
  • ресурсам, которые будут вложены для достижения этих результатов;
  • времени, необходимому для достижения этих результатов.

Типичное резюме проекта дает подробное описание как целей проекта, так и практических рекомендаций по достижению его результатов. В нем должны быть кратко записаны соглашения, на которых базируется проект, и таким образом, оно предлагает обоснование для расходования времени и усилий.
Перечень заголовков резюме:
  • Название проекта;
  • Покровитель проекта;
  • Местоположение – адрес покровителя, местоположение проекта, контактные адреса;
  • Имя менеджера проекта и название его организации, если она отлична от организации, спонсирующей проект;
  • Дата согласования резюме с покровителем проекта;
  • Дата начала и завершения проекта;
  • Обоснование и предназначение проекта с обзором основных идей;
  • Основные цели с указанием критериев качества и успеха;
  • Подробное описание того, как достижение этих целей принесет выгоды бизнесу или организации, спонсирующей проект;
  • Масштаб и границы проекта;
  • Ограничения;
  • Предположения;
  • График проекта;
  • Основные результаты и соответствующие им даты (вехи проекта);
  • Оценка затрат;
  • Механизмы обеспечения ресурсами;
  • Механизмы отчетности и мониторинга;
  • Механизмы принятия решений – полномочия и подотчетность менеджера проекта и проведение повторных переговоров;
  • Механизмы и каналы коммуникаций;
  • Подпись покровителя проекта с указанием даты, звания и должности


Заключение


В данной статье, как можно более кратко и конкретно, были рассмотрены теоретические основы этапа подготовки проекта. Для этого использовалась литература Школы бизнеса МИM ЛИНК, выпускником которой и является автор. В учебном курсе данной школы подробно изучается шестиэтапная модель управления проектом, и если появится заинтересованность со стороны хабрасообщества, можно будет продолжить серию статей на эту тему.
Метки:
Поделиться публикацией
Комментарии 31
  • 0
    Спасибо за хорошую статью!
    Статья еще раз показала, что очень важно учитывать все предложенные принципы в любом начинании)
    • 0
      Хоть и довольно общая статья, но все же полезная.
      Спасибо!
      • +6
        По моему Вы вкратце изложили суть руководства PMBOK (Руководство к своду знаний по управлению проектами) которая изложена на 400 страницах )
        • 0
          З.Ы. Не заметил Вашего заключения )
          • +3
            честно скажу, PMBOK не изучал, но, думаю, что общие принципы управления проектами в различных методологиях достаточно одинаковы. Отличия — в нюансах и конкретных подходах
            • 0
              Вы правы. Одно отличие уже вижу, в PMBOK 9 этапов модели управления проектом )
              • 0
                Точнее, 9 областей знаний и 5 «этапов».
        • 0
          Заинтересованность есть! Обязательно продолжайте.
          • 0
            Спасибо — утащил в закладки.

            • 0
              Спасибо, это очень полезная информация. Но я думал что на Хабре выкладываю что свое… эдакое, а это же просто скан книги, хорошо, что книга очень не плохая.
              • +7
                Детально не знаком с подходом такой авторитетной организации в области управления проектами, как БШ МИМ ЛИНК, но вижу по этой заметке, что PMI PMBoK накроет ее методику как петух курицу.

                С т.з. менеджера проектов (МП), инициация и планирование проекта (т.е. то, о чем заявлена заметка) — это примерно половина всего объема работ МП в проекте. У Вас же очень обще описана дай бог четвертая часть работ МП на этих этапах.

                Примерно представляя себе, как стряпаются материалы по курсам (в данном случае, явно непрофильным для ЛИНК), рекомендую Вам все-таки черпать информацию и подходы в серьезных источниках.

                Методология управления проектами, описанная в PMI PMBoK, представляет собой комплексный системный подход (рамочную методологию) к управлению крупными распределенными проектами с большими бюджетами и большими полномочиями/ответственностью менеджеров проектов. Предлагаемый там состав, содержание и последовательность процессов/активностей (а также устоявшаяся общепризнанная терминология) является своего рода лучшей практикой в управлении проектами, т.е. «большинство опытных менеджеров проектов считают их полезными в большинстве случаев для большинства проектов».

                Вместе с тем, есть много хороших, достойных и интересных книг по управлению проектами, но в них описан частный субъективный взгляд автора на управление проектами особых типов (напр., айтишных или строительных, в зависимости от бэкграунда автора), и даются рекомендации применительно к конкретному контексту. В PMBoK же каждый шаг, этап, activity, структуры, показатели… обсасываются огромным количеством практикующих профессионалов из разных областей до тех пор, пока они не придут к консенсусу. По поводу концептуальных вещей проводятся огромные семинары и конференции.

                Теперь конкретно о том, что Вы написали, несколько замечаний. По финансовым деталям. Менеджер проекта (по меньшей мере, в понимании PMI) НЕ ОТВЕЧАЕТ ЗА ЭКОНОМИЧЕСКИЙ ЭФФЕКТ ПРОЕКТА (NPV, IRR, срок окупаемости и т.д.). За это отвечают люди, находящиеся выше МП и ставящие/инициирующие проектные задачи МП. МП, естественно, должен быть в курсе этих задач для правильной подготовки (НЕ ПРИНЯТИЯ) соотв. решений, но он отвечает ТОЛЬКО за сроки, бюджет, качество (удовлетворенность) и ряд других. Соответствующие метрики проекта (у Вас отсутствуют) — earned value, SPI (schedule performance index), CPI (cost performance index), соответствующие planned, actual, earned, variance, forecast/estimation и т.д. Либо тогда надо говорить, что МП выполняет в компании, так уж повелось, функции, связанные с инвестиционным и бизнес-планированием.

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

                Т.к. это Ваша первая общая обзорная статья в цикле статей, особо дальше придираться не буду, хотя поводов огромное количество. Спасибо.
                • 0
                  По правде говоря, когда я начал читать PMBoK, то перед тем имел опыт изучения более кратких методик и был очень изумлен тем, что в PMBoK жуется буквально каждая мелочь. По входам и выходам каждого процесса имеется полное объяснение, которое дает полнейшее понимание происходящего. Это мне сильно понравилось, настолько что не мог пропустить ни одной страницы книги по диагонали.
                  • +1
                    Планировал написать, да забыл — где WBS и вообще schedule? Без этого вообще говорить не о чем на этапе планирования проекта. Где HR management — а это основная российская проблема и важная причина провала проектов (упомянуто вскользь).

                    За что важное на этапе планирования проекта ни хватись, этого в заметке либо нет, либо совсем уж только упомянуто.

                    Ну и наконец, что должно быть результатом работы МП? Какие документы и с какой структурой? Хороший, кстати, способ объяснения, что должен сделать МП — набор шаблонов документов по управлению проектами, и чтобы их правильно заполнить, МП вынужден будет ответить на все важные вопросы и провести соотв. работы.

                    Пример PMBoK4-aligned шаблонов:
                    www.oregon.gov/DHS/admin/bpm/pmo/PPO_Tools_Templates.shtml
                    • 0
                      этап планирования только впереди, поэтому здесь о нем упомянуто вскользь.
                      еще раз повторюсь, это не PMBoK, а другой, более простой и менее детализированный подход
                      ну а результатом работы МП на этом этапе должно быть резюме проекта
                      за шаблоны PMBoK спасибо!
                      • +2
                        Резюме проекта.

                        Во-первых, что это за название? Резюме — это краткая сводка. Т.е. я делаю вывод, что это приблизительный аналог Project Charter в PMI PMBoK. Подробное описание — это Устав Проекта (в российской практике) или Project Management Plan в PMI PMBoK. Судя по структуре документа, резюме у Вас это что-то среднее — первая половина — Project Charter, все вместе — фрагменты PM Plan'а.

                        Во-вторых, пункт в резюме «масштаб и границы проекта» и все что ниже (особенно, график проекта) — Вы готовы подписать у спонсора (покровителя в Вашей терминологии) все это без этапа планирования? Коли у Вас еще до планирования дело не дошло. Финализация и утверждение PM Plan'a и Project Schedule (графика проекта) — это самый последний шаг этапа планирования, непосредственно перед началом исполнения проекта.

                        Мой совет — возьмите PMBoK, хорошие книги типа Kerzner H. Project Management. A Systems Approach to Planning, Scheduling, and Controlling, 10e, изучите, получите опыт хороший в управлении проектом в позиции менеджера проекта (а не снизу-сбоку) с тем, чтобы описанные там вещи наполнились для Вас конкретным смыслом — и тогда Вашим размышлениям об управлении проектами цены не будет. Пока же это бессистемная обрывочная плохо затеоретизированная каша, ЛИНКу жирный минус. Вам спасибо за старания и интерес к теме.
                    • 0
                      во-первых, здесь речь идет только о подготовке (инициации) проекта — чтобы понять, а нужен ли вообще тот или иной проект? Поэтому планирование проекта будет только следующим этапом.
                      во-вторых, здесь описана не столько работа МП, сколько просто общие принципы подготовки — на что обратить внимание, что посчитать, с кем обсудить и т.д. А уж кто это будет делать — решать вам.
                      В учебном курсе ЛИНКа в плане управления проектами изучается 6-ти этапная модель — и конечно же объемы не такие, как в PMBoK. Согласен, что эта одна из самых подробных и цельных методологий, но так как я с ней не знаком, то писал о том, что мне известно более-менее. Если кто-то решится написать серию статей по PMBoK, то сам с удовольствием почитаю
                      • +2
                        Вы уж извините, но я от Вас не отцеплюсь )).

                        «В данной статье рассмотрены теоретические основы важнейшего этапа в управлении проектами – именно его подготовки.»

                        «здесь речь идет только о подготовке (инициации) проекта — чтобы понять, а нужен ли вообще тот или иной проект».

                        Подготовка и инициация — это не одно и то же.

                        Результат подготовки проекта — как ни странно, подготовленный проект )) Подготовленный к чему? Два варианта:

                        1) Проект подготовлен к непосредственному исполнению (execution в PMBoK), т.е. понятно, что подготовка в этом случае включает в себя планирование (initiation + planning);
                        2) Проект подготовлен к старту. Т.е. предварительные работы проделаны — инициатива экономически просчитана (ТЭО либо бизнес-план), предпроектный анализ проведен, либо договор с клиентом заключен — проекту можно давать зеленый свет. Сразу же после этого первый шаг — инициация (формальное объявление о существовании проекта в компании, например, это приказ/распоряжение по компании, в котором как правило сразу менеджера проекта назначают). И дальше МП, махая этой бумажкой, начинает: разбирается с переданным ему business case (описанием деловой ситуации, проблемы, из-за которой/для решения которой затеян проект), собирает первичные требования и первичные (высокоуровневые) риски, формирует измеряемые цели и задачи, идентифицирует стейкхолдеров и работает с ними, пишет и утверждает очень высокоуровневое описание базовых параметров проекта — Project Charter. Потом фаза Planning…

                        Иными словами, в первом случае подготовка — это initiation + planning, во втором случае — предпроектный этап до initiation (и до planning, естественно).

                        Насколько я понял, Вы имели в виду какой-то третий вариант. И вообще, у Вас и методология другая (ЛИНКовская), и под терминами вы что-то другое понимаете. Тогда подискутировать в формате хабра у нас не получится, т.к. нужно будет на конкретных примерах брать и смотреть, чем чреват пропуск тех или иных этапов в управлении проектом.

                        В этом-то как раз и заключается одна из сильных сторон PMBoK — все люди во всем мире одинаково понимают, о чем идет речь. Плюс к этому терминология очень аккуратная и увязанная, сам фреймворк очень системный. Естественно, под каждый проект МП его каждый раз плющит под себя, но в качестве основы, повторюсь, PMBoK — лучший вариант.
                        • 0
                          постараюсь кратко
                          мы с вами на разных языках разговариваем, хотя пишем на одном! не нужно критиковать только потому, что в PMBoK не так. Он ведь тоже не есть истина…
                          Цель этой заметки состоит НЕ в предложении лучшей практики, а в том, чтобы натолкнуть людей на мысль (особенно новичков), что просто одной хорошей (или гениальной идеи) мало — для того, чтобы проект запустить, необходимо помнить о таких вещах как:
                          1. цели
                          2. ЗС, их требования и ожидания
                          3. возможности и угрозы

                          и начать следует именно с этого анализа. А с помощью каких практик и методологий — вопрос второй.
                          И про резюме вопрос не принципиальный, просто как его не назови, нужно помнить, что такой документ необходим для успешной реализации проекта, а не является просто объемной ненужной бумажкой
                          если говорить в ваших терминах, то здесь описан «предпроектный этап до initiation (и до planning, естественно)».
                          • 0
                            Я Вас понял. До момента, когда менеджер проекта приступает к проекту (т.е. до, собственно, управления проектами) мы еще не добрались. Пока описываются предпроектные активности, связанные с инвестиционным и бизнес-планированием, частично активности бизнес-аналитика (не айтишного, а в понимании The International Business Analysis Institute, theiiba.org), organizational/business development, business transition management и прочие процессы, в которых могут порождаться и оцениваться проектные инициативы.
                    • +1
                      Ох, сколько же здесь воды, почти каждое преложение просто кричит своей вопиющей бесполезной академичностью.

                      Почему нельзя всё живенько на примере описать? Или еще лучше, как у Купера, – свести всё в одну табличку?

                      И последнее, вы сами как-нибудь это используете в своей деятельности? Если да, то как? Ну, например, каждый раз проходитесь по всем пунктам и проверяете их наличие.
                      • 0
                        по-моему, любая академичность на первый взгляд кажется бесполезной. Но вот когда начинаешь наступать на одни и те же грабли — берешь книжки в руки и понимаешь, не так уж она и бесполезна!
                        Конечно, описать реальный пример — это лучшее учебное пособие, но под рукой примера «правильной» подготовки проекта, увы, нет — а вот обратных примеров — куча!
                        Досконально по всем пунктам не прохожусь (да может это быть и нужно в различных контекстах), но анализ требований ЗС делаю, NPV считал, в составлении журнала рисков учавствовал. А также объяснял своему руководству, что важно чувствовать себя именно покровителем проекта, а не просто его контролёром.
                        • +1
                          Не знаю как автор, но, например, я аналогичную методику давно использую в своей практике. И такой подход, — академичный, как вы его назвали, — всегда помогал делать мне успешные проекты.
                          • 0
                            Не отрицаю, что может и я тормоз, и не встретил применимого для себя академ. подхода к проектированию. Всё больше использую простые и внятные целеориентированные подходы из того же «Проектирования взаимодействия» Купера.

                            А как вы используете методику?
                            • 0
                              «Как» или «какую»? Ответ на второй вопрос — синкретическую, основанную на положениях ГОСТов, MSF, PMBoK, OnTarget и собственной многолетней практике работы. Ответ на первый вопрос — достаточно успешно, судя по имеющимся результатам, но предела совершенству нет :)

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

                          А подобные методы работают только на типичных конвеерных проектах. Либо на тех, где предметная область изучена досконально и в наличии большой штат экспертов по ней.
                          • 0
                            не соглашусь, работает не только «на типичных конвеерных проектах»
                            это же в принципе общие правила, применимые к любому проекту и деятельности вообще: сначала поставь четкие цели, затем обсуди с ЗС, выяви риски, проверь осуществимость… И если решение принято, что ЭТО нам нужно, то дальше запускаем проект
                            и вот отсюда можно идти разными путями: Scrum, PMBoK, 6-ти этапная модель, и т.д.
                          • 0
                            Хочется спросить у BegeMode: а реальными проектами по методике ЛИНК вы управляли? Насколько они были успешными? Могу точно сказать, что на практике указанные Магнусом нюансы имеют большую ценность, так как помогают найти выход в тумане. PMBOK — хоть и теория, но без лишнего. И еще большую практическую ценность имеют, на мой взгляд, ее «трактовки» вроде книжки Rita Mulcahy.
                            • 0
                              да, у меня есть и такая практика, и обратная (когда все делалось наобум)
                              однажды проект сильно тормозил… просто из-за сопротивления одной из влиятельных ЗС — с ней-то на этапе обумывания проекта никто и не посоветовался!
                              и это вылилось в такие палки в колеса! а «всего-то» нужно было — уделить ему внимание и слегка изменить требования к будущей системе…
                              Постановка СМАРТ-целей тоже помогает в работе, но является большим искусством, ибо многие не особо различают сами цели от решаемых задач
                            • 0
                              вот так и губят интересные идеи!
                              • 0
                                При чтении раздела о рисках удивился тому, что в понятие риска заложено только «возможность неблагоприятного воздействия на проект...» в отличие от того же PMBoK, уже упоминавшемся в комментариях.
                                А есть ли место в изложенной модели для возможности благоприятного воздействия на проект?

                                • 0
                                  риск в данном тексте рассмативается именно как угроза проекту.
                                  а вот возможности — это и есть благоприятное воздействие. возникают из поиска различных вариантов реализации проекта, обсуждения с ЗС…

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.