Термин послепроектный анализ (или обзор) относится одновременно к процессу и документу, схватывающим критически важную информацию о том, что было сделано хорошо и что было сделано плохо в ходе выполнения проекта. Основная идея здесь заключается в том, чтобы найти способ использовать эту полученную информацию таким образом, чтобы избежать совершенных в прошлом сознательных или неосознанных ошибок и повторить успехи – ради улучшения исполнения проектов в будущем. Поскольку люди подвержены ошибкам и склонны совершать неверные действия, проекты изобилуют недочетами и потенциальная возможность обучения с помощью послепроектных обзоров весьма значительна. Как следствие этого многие расценивают послепроектные обзоры как формальную часть управления знаниями [1]. На рис. 15.5 предлагается пример документа послепроектного анализа.

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

•руководство по проведению послепроектного анализа;

•примеры прошлых послепроектных анализов;

•проектная документация.

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

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

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

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

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

Рис. 15.5.Пример послепроектного анализа (как документа)

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

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

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

•реконструкция фактической временной шкалы проекта и сравнение ее с базовым планом;

•слабые места проекта, то есть те части проекта, выполнение которых было неудовлетворительным;

•сильные места проекта, то есть те части проекта, выполнение которых было хорошим;

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

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

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

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

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

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

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

•рассмотреть и проранжировать проблемы;

•задать вопрос о том, что шло неправильно;

•задать вопрос о том, что следует делать иначе в будущем;

•задать вопрос о том, что шло правильно;

•выстроить рекомендации в приоритетном порядке.

На первом шаге участники должны рассмотреть и проранжировать проблемы, которые оказали преобладающее влияние на выполнение проекта. Для придания обсуждению правильного направления очень полезно раздать участникам контрольный список проблем (проблемы в списке должны быть размещены в пределах одной и той же страницы) перед началом совещания или, по крайней мере, во время совещания. Как показано в приводимом ниже заштрихованном прямоугольнике «Примеры вопросов из контрольного списка послепроектного совещания», вопросы могут охватывать очень широкий круг, например: планирование проекта, календарное планирование и бюджетирование, организация команды, проектирование продукта, что делает, по сути дела, каждую область проектной работы открытой для обсуждения. Такой широкий и открытый подход требует направления энергии участников в нужное русло. Так, в одной технологической компании для этого используется следующий подход: каждого участника просят просмотреть контрольный список, в котором выделить 5 основных проблем или неудач проекта. Выделенные проблемы отображаются на лекционном плакате, проясняются теми людьми, которые их выделили, и ранжируются методом голосования для получения окончательной «групповой» пятерки наиболее важных вопросов, которые переносятся на следующий шаг.

«Что пошло неправильно в данном основном вопросе и привело к возникновению этой основной проблемы?» – это главный вопрос второго шага. Например, в одной компании, ориентированной на минимизацию времени выхода на рынок, основным вопросом послепроектного анализа являлось соскальзывание расписания, поэтому вопрос звучал так: «Что пошло не так с расписанием?» В обеспечение дискуссии проектная команда заблаговременно до совещания подготовила сравнительную диаграмму фактического и базового расписаний, сопроводив ее временной шкалой и информацией о количестве рабочих часов, израсходованном каждым участником проекта. Не важно, готовится диаграмма заранее или на месте. Важно, чтобы она была размещена на стене, как в нашем случае, чтобы направить энергию участников на обсуждение того, что пошло неправильно. Существуют различные методы генерации списка того, что пошло не так. Один из них – обыкновенный мозговой штурм, в ходе которого участникам предоставляется возможность высказывать любые идеи, которые приходят им в голову в ходе обдумывания вопроса. При использовании формальной техники групповой работы участники выполняют молчаливый письменный мозговой штурм, а ведущий просит каждого из них излагать по одному комментарию / суждению за раз – до тех пор, пока комментарии не будут исчерпаны. Еще один вариант – предложить участникам изложить свои комментарии на небольших листках бумаги (один листок – один комментарий), которые затем подвергнуть сортировке и классификации с целью построения аффинной диаграммы.

•Были ли бизнес-цели проекта ясны для вас?

•Были ли действия других функциональных групп (разработки, маркетинга, производства) ясны для вас?

•Были ли цели по части содержания, сроков, стоимости и качества ясны для вас?

•Насколько адекватным и полным был план проекта, когда фактическая работа была начата?

•Был ли услышан голос заказчика и был ли он учтен при планировании, разработке дизайна (проектировании) и практической реализации проекта?

•Находились ли процесс проекта, продукт проекта и предметы поставки проекта в соответствии с ожиданиями заказчико (клиентов, заинтересованных сторон, спонсора)?

•Было ли информационное взаимодействие с заказчиком эффективным?

•Удовлетворены ли вы продуктом проекта? Другими предметами поставки проекта?

•Каковы отклонения между фактическим и запланированным продуктом и другими предметами поставки?

•Насколько эффективны были действия по контролю этих отклонений?

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

•Была ли она проведена вовремя?

•Знала ли каждая функциональная группа о том, каким участком функционального проекта по предметной части она владеет?

•Были ли кросс-функциональные интерфейсы в разработке дизайна / спецификаций четко определены?

•Были ли базовые планы расписания и бюджета реалистичны? Достаточно детальны? Подкреплены достаточными ресурсами?

•Насколько помогли контрольные события при отслеживании расписания / бюджета?

•Имели ли место значительные отклонения между базовыми и фактическими расписанием / бюджетом?

•Работала ли система показателей измерения прогресса проекта?

•Была ли организация проекта адекватной? Была ли она функциональной? Матричной? Выполнялся ли проект выделенной командой?

•Хорошо ли работала команда?

•Имела ли команда необходимые навыки? Ресурсы?

•Были ли роли членов команды и функциональных групп четко определены? Выполнялись ли они?

•Были ли идентифицированы риски, связанные с процессом, продуктом и предметами поставки?

•Насколько верными оказались предположения о рисках?

•Насколько эффективными оказались действия, предпринимавшиеся в ситуациях наступления риска?

•Насколько эффективна была коммуникация с руководством? С функциональными группами, осуществлявшими поставку ресурсов? С другими проектными командами?

•Насколько эффективна была коммуникация внутри команды?

•Была ли отчетность своевременной? Проактивной? Полезной? Слишком времяемкой?

•Были ли руководители вовлечены в основные обзорные совещания проекта? Были ли они эффективны?

•Доводились ли до вашего сведения решения руководства?

•Были ли эти решения ясными? Достаточно быстрыми? Понимали ли вы, как именно они делались?

•Насколько они помогли вам выполнить вашу работу?

•Как работала методология управления проектами компании – планирование проекта, контроль изменений, поддержка спонсора и т. д.?

•Насколько эффективны были программные средства управления проектами, использовавшиеся в проекте?

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

И хотя этот шаг – определение того, что пошло неправильно в том или ином основном вопросе – кажется медленным, при надлежащих действиях ведущего он может быть выполнен за 5 – 10 минут. Далее акцент переносится на третий шаг. В неменьшей, если не в большей степени важно не только определить, что пошло не так, но и выработать пути исправления этих недочетов в будущих проектах. Вопрос о том, что в будущем следует сделать иначе в отношении первой проблемы, представляет собой суть третьего шага (отметим, что мы все еще имеем дело с первой проблемой). Для каждого из недочетов участники должны задать [4] следующие вопросы:

•Были ли какие-нибудь сигналы раннего предупреждения, извещавшие о том, что что-то идет неправильно?

•Что нам следовало сделать иначе, чем мы сделали?

Генерация и выбор нескольких возможных стратегий исправления могут быть осуществлены методом сбора и выделения наиболее существенных недочетов. И снова отметим, что все еще анализируется первая проблема, это подразумевает, что шаги 2 и 3 должны быть повторены для всех остальных значительных недочетов.

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

•Какие методы сделали возможным наступление этих удач?

•Какие из этих приемов не использовались в проектах раньше и рекомендуются к включению в выполнение будущих проектов?

•Какие из этих приемов использовались в проектах раньше и рекомендуются к продолжению использования в будущих проектах?

По завершении четвертого шага участники оказываются обладателями:

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

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

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

Документирование обзора.Завершение послепроектного анализа без написания послепроектного отчета – частая практика, особенно в небольших компаниях. Хотя послепроектный анализ без финального документа – это лучше, чем отсутствие послепроектного анализа вообще, наличие такого документа обеспечивает значительные преимущества. В частности, оно дает возможность распространять полученную в ходе обзора информацию (в соответствии с тем, как это описано в последующем подразделе). Следовательно, для того чтобы начать процесс документирования, необходимо назначить ответственное за это лицо, по возможности, раньше, еще на стадии подготовки послепроектного анализа. В это же время следует определиться с содержанием документа (в случае, если в организации отсутствует стандарт на него), чтобы сэкономить время тех, кто будет писать этот документ, и обеспечить согласованность и сравнимость документов, относящихся к разным проектам. Например, финальный документ послепроектного анализа может состоять из тела и приложения. В имеющее одностраничный формат тело может быть включено: временная шкала, распределенный во времени бюджет (в форме сравнения фактического и планового бюджетов), список присутствовавших, набор рекомендаций и основные показатели проекта (например, данные о производительности, достигнутой при написании программного кода, или меры в терминах выполненной стоимости). Подобный подход применен в примере на рис. 15.5. Назначение многостраничного приложения заключается в том, чтобы сохранить как можно больше аутентичных комментариев участников, зарегистрированных до, во время и после послепроектного совещания. При написании этого документа жизненно важно, чтобы все участники изучили его и предложили уместные, с их точки зрения, измерения.

Использование уроков, извлеченных из послепроектного анализа.Когда результаты послепроектного анализа не используется, то на ум приходят слова Джорджа Сантаяны: «Тот, кто не помнит свое прошлое, обречен повторять его». Именно это может запросто произойти с любой проектной командой, которая выполняет послепроектный анализ, документирует его, а потом – забывает о нем. И это при том, что команды и организации, в которых они действуют, имеют ряд великолепных возможностей превратить полученное в ходе послепроектного анализа знание в капитал. Они могут применить полученные в ходе послепроектного анализа уроки для того, чтобы избежать подобных ошибок в следующих проектах, ослаблять риски других проектов или улучшать процессы управления проектами в масштабах всей организации, – и это лишь малая часть возможностей [1]. Например, в одной организации в сфере информационных технологий существует требование, чтобы планирование каждого нового проекта начиналось с изучения послепроектного отчета предыдущего проекта и использования его в качестве средства самоконтроля. Еще в одной организации принято извлекать из послепроектных отчетов информацию об основных проблемах и их решениях и помещать ее в информационную базу проблем, использующую Web-технологии. От всех проектов требуется выполнение регулярной проверки своего состояния и в случае, если дела идут не так, как должны, рассмотрение стратегий ослабления рисков, принятых ранее по отношению к аналогичным проблемам, уже включенным в базу. В одной производственной компании в сфере высоких технологий каждый усвоенный урок ассоциируется с пакетом работ в стандартизованной СДР, которая должна использоваться при планировании каждого нового проекта. Возможно, наивысшая ценность послепроектного анализа проистекает от оценивания изложенных в нем рекомендаций на предмет их применимости к более чем данному конкретному проекту и несения соответствующих изменений в общий процесс управления проектами [5].

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

Время выполнения.Принятые в различных компаниях политики в отношении длительности послепроектных совещаний различаются. В одних принято проведение таких совещаний в течение одного-двух дней, в то время как в других – не более 4 часов, даже если это значит, что совещание придется разбивать на 2 отдельных совещания [4]. В случае больших проектов это становится возможным, если значительная часть работы выполняется за пределами собственно совещания. В отличие от больших проектов, малые проекты обычно стараются обходиться очень короткими обзорными совещаниями, длящимися от получаса до часа.

Выгоды.Ценность послепроектного анализа имеет под собой достаточно простое логическое объяснение: даже будучи неформальным, послепроектный анализ ускоряет обучение, улучшая исполнение проектов. Ряд исследований однозначно подтвердили эту ценность и рассматривают послепроектные обзоры как уникальную возможность обучения, направленного во благо исполнения будущих проектов [6 – 8]. Выявляя удачи и недочеты проекта, такое обучение позволяет определить, что подлежит улучшению (предпочтительно в форме плана действий). Еще одна ценность заключается в том, что послепроектный анализ обеспечивает закрытие проекта. Для тех, кто в течение многих месяцев упорно трудился и достиг целей проекта, значимость закрытия состоит в неоспоримом признании успеха. Несмотря на предоставляемые послепроектным обзором выгоды, во многих проектах была упущена эта бесценная возможность – учиться быстрее. Отказ от проведения послепроектного анализа – это мелочность, это ограниченный и глупый подход, который могут себе позволить, быть может, только самые невежественные компании, часто извиняющие отсутствие послепроектного анализа необходимостью перебрасывать людей на новые проекты, которые, вероятно, будут обречены на повторение ошибок, сделанных в предшествующих проектах. Вот она – цена отказа от послепроектного анализа.

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

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

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

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

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