Правильное отношение к неудачам: как научиться извлекать уроки из ошибок. Закрытие проекта

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

хорошую работу на сайт">

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

Размещено на http://www.allbest.ru/

Закрытие проекта

1. З адачи закрытия проекта

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

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

Три главные задачи закрытия проекта:

1. Сворачивание проекта. Главное задание по сворачиванию проекта - убедиться, что проект одобрен и принят заказчиком. Прочие виды деятельности по сворачиванию включают: закрытие счетов, оплату счетов, перераспределение оборудования и персонала, поиск новых возможностей для работников проекта в плане дальнейшей работы, закрытие объекта и окончательный отчет. Широко используются вопросники (перечни) чтобы ни одно из заданий в суматохе не потерялось. Во многих компаниях львиную долю заданий по закрытию в основном выполняет ОУП в сотрудничестве с менеджером проекта. Окончательный отчет пишется одним специально назначенным членом ОУП, который собирает данные от всех участников. В меньших организациях и на небольших проектах эти виды деятельности выполняются менеджером проекта и командой.

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

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

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

2. Типы закрытия проекта

управление заключительный проект

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

Нормальное. Наиболее распространенная ситуация с закрытием проекта - просто завершенный проект. Для многих IТ-проектов развития окончание подразумевает сдачу окончательного варианта разработки в производство и создание нового продукта или услуги. Для других внутренних IТ-проектов, таких как усовершенствование (апгрейдинг) систем или создание новой системы контроля над запасами, - окончание наступает, когда результат интегрирован в текущие операции. Во время реализации могли появиться некоторые изменения в объеме, затратах и графике.

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

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

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

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

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

Изменение приоритетов. Приоритеты компании часто меняются, а стратегия приобретает иное направление. Например, во время финансового кризиса 2008-2010 гг. компании сменили приоритет - они перешли от проектов для получения прибыли к проектам по сохранению и экономии средств и снижению затрат. Группа по надзору непрерывно пересматривает отбор проектов в соответствии с изменениями в направлении развития компании. Проекты, которые не завершены, могут быть заменены или отменены. Иными словами, проект может начаться с высоким приоритетом, но его статус будет значительно снижен или отменен во время жизненного цикла, по мере того как меняются условия. Если меняются приоритеты, то и проекты могут стать ненужными.

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

3. Операции по закрытию проекта

Многие проблемы для менеджера проекта и членов команды остались позади. Для менеджера проекта и участников операции по сворачиванию проекта, без которых нельзя его завершить, часто бывают проблематичными. Это то же самое, что спросить после вечеринки: «Есть добровольцы сделать уборку?» Большая часть работ рутинна и скучна. Мотивация может стать проблемой номер один. Например, отчет о передаче оборудования и составление окончательных отчетов выглядят «тупой» административной работой для профессионалов проекта, так как они индивидуалисты, ориентированные на действия. Проблема для менеджера проекта заключается в том, чтобы заставить команду все же думать об оставшейся работе и сдаче заказчику. Передав участникам план / график закрытия и анализа заранее, вы тем самым:

1) сделаете так, что команда примет факт, что проект рано или поздно окончится, и

2) подготовите ее к переходу на другие проекты.

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

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

1. Получить «добро» от заказчика, что проект принят.

2. «Отключиться» от используемых ресурсов и высвободить их для новых проектов.

3. Объявить о новых назначениях членов команды.

4. Закрыть счета и проверить, все ли счета оплачены.

5. Сдать проект заказчику.

6. Написать заключительный отчет.

Выполнение всех деталей по закрытию проекта может показаться непосильной ношей. Некоторые компании имеют контрольные перечни, включающие более сотни пунктов! Там подробно расписано, что делать с объектами, командами, персоналом, заказчиками, продавцами и самим проектом. Фрагмент такого списка приводится ниже (табл.).

Контрольный перечень вопросов по закрытию проекта

Выполнено или нет (Да / Нет)

Команда

Готов ли график роспуска персонала проекта? Утвержден ли он?

Объявили ли членам команды, что они свободны/или получили новое назначение?

Были ли сделаны оценки работы членов команды?

Были ли персоналу предложены услуги по дальнейшему трудоустройству и консультации по карьерному росту?

Продавцы/подрядчики

Был ли проведен анализ работы каждого продавца?

Закрыли ли счета по проекту и оплачены ли они?

Заказчик/пользователи

Выдал ли заказчик документ по приемке продукта?

Состоялась ли с заказчиком беседа для анализа проекта «вглубь» и его оценки?

Опрошены ли пользователи - насколько они довольны результатом? Командой проекта? Продавцами? Обучением? Поддержкой? Техническим обслуживанием?

Оборудование и объекты

Были ли ресурсы по проекту переданы на другие проекты?

Закрыли ли договоры по аренде оборудования?

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

Пометьте те задания, которые требуют дальнейшего объяснения

4. Составление окончательного отчета

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

Отчет о проделанной работе. Этот отчет просто освещает ключевые открытия и факты, связанные с реализацией проекта. Например, были или не были достигнуты цели проекта по заказчику. Удовлетворены ли стейкхолдеры тем, что их стратегические намерения реализовались? Как среагировал пользователь на качество и результаты? Задачи проекта использовались, как было задумано, и они дали ожидаемые выгоды? Окончательное время проекта, затраты и объем. Указываются все главные проблемы, с которыми столкнулись на проекте, и как ими занимались, Ключевые уроки, которые извлекли.

Анализ. Данные о ходе проекта, эффективности руководства и извлеченных уроках изучаются с целью улучшить будущие проекты. Анализ детально описывает основополагающие причины проблем и успехов. Кратко делается разбор по «факту» - как следовали миссии проекта и целям, процедурам, как использовали ресурсы компании. Принято собирать данные, «увиденные» компанией и командой проекта. ОУП или эксперты часто используют вопросники, чтобы выбрать те вопросы и события, которые должны быть рассмотрены в дальнейшем. Например: «Была ли культура компании поддерживающей и отвечающей этому типу проекта? Почему? Почему нет?» Или: «Был ли у команды достаточный доступ к ресурсам компании - людям, бюджету, отделам, оборудованию?» ОУП также представляет графики по проекту, сравнение затрат, данные по объему и прочие необходимые данные, по которым можно составить «историю» результативности. Эта информация используется при создании окончательного отчета по проекту.

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

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

Размещено на Allbest.ru

Подобные документы

    Изучение объектов и субъектов в управлении проектов, а также их взаимодействия в процессе реализации проекта. Методы руководства и руководящие меры по обеспечению выполнения проекта. Жизненный цикл проекта и его фазы. Основные участники проекта.

    контрольная работа , добавлен 18.02.2017

    дипломная работа , добавлен 21.03.2011

    Сущность и требования к проектам в социальной работе. Фазы жизненного цикла проекта. Анализ создания и системы управления основными функциями проекта на примере проекта ГБОУ ЦВР "Раменки". Основные пути эффективного внедрения социального проекта.

    курсовая работа , добавлен 14.11.2016

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

    доклад , добавлен 18.07.2010

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

    курсовая работа , добавлен 17.11.2013

    Основные понятия и принципы управления проектами. Критические работы и пути. Расчёт резервов времени проекта. Модифицированный вариант диаграммы Ганта. Создание проекта и установка параметров. Разработка сетевого графика проекта. Оценка стоимости проекта.

    курсовая работа , добавлен 14.01.2011

    Общее понятие о жизненном цикле проекта. Основные процессы управления проектом. Анализ жизненного цикла и процессов нефтегазового проекта на примере проекта деятельности ОАО "ЛУКОЙЛ". Оценка фазы жизненного цикла проекта и рекомендации по управлению ним.

    курсовая работа , добавлен 13.01.2014

    Определение понятия "проект". Характеристики проекта как объекта управления. Функции управления проектами. Список компетенций менеджера программного проекта. Выработка концепции реализации проекта, ее апробация и экспертиза. Жизненный цикл проекта.

    презентация , добавлен 14.08.2013

    курсовая работа , добавлен 11.11.2014

    Сущность, цели и содержание контроля хода реализации проекта. Характеристика методов простого и детального контроля. Основные стадии изменения содержания проекта. Возможные варианты действий, используемые в случае отклонения проекта от намеченного плана.

  • Перевод

Данный текст создан на основе моего выступления на GRWebDev . Это история проекта, который был отменен и похоронен в GitHub, а также рассказ об уроках, извлеченных в ходе работы над ним.

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

Спустя 11 месяцев, наша команда решила прекратить работу над этим проектом.

Вырабатывайте общее видение

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

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

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

Урок 1: Формируйте единое видение продукта в команде

Определите «успех» и «поражение»

В месте, таком, как GitHub, где нет ни менеджеров, ни жестких сроков, возникает искушение верить, что «если я просто буду работать изо всех сил на „крутом“ проекте, который меня заводит», то все как по волшебству станет «хорошо и красиво». Это ложь. Успех - это МНОГО работы. Успех приходит, когда намеренно избегаешь критических ошибок и еще и много «везет».

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

Урок 2: Когда вы выработали общее видение, выработайте определение успеха, и, что не менее важно, определение неудачи (провала). Установите цели на пути к «успеху» и регулярно сверяйте состояние проекта с этими целями

Создавайте осмысленные искуственные ограничения

Наш проект страдал от серъезной нехватки ограничений. Деньги не были проблемой, во времени мы не были ограничены ничем, и мы сами определяли набор функций продукта. Не каждому в жизни выпадало такое несчастье. Без ограничений, вы не можете определить «важность». Когда «все важно», расставлять приоритеты и принимать решения невозможно.

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

То же происходит и в проектах. Разработка ПО для удовлетворения всех требований «сразу» - парализует. ПО создается «по функции за раз». Выберите ограничения, чтобы они помогали вам фокусироваться на «важном именно в данный момент».

Вехи (milestones) - одна из форм таких ограничений (некоторые называют их «дедлайнами», но я предпочитаю «вехи»). Веха - это конкретная дата, к которой вы собираетесь достигнуть некую цель. Фиксированные даты НИКОГДА не должны включать «скоуп» (набор конкретных требований). Если вы будете работать по 60 часов в неделю, чтобы уложиться в вехи, значит вы не поняли того, о чем я говорю. Ограничение не должно заставлять никого работать БОЛЬШЕ. Оно должно помогать вам работать ЛУЧШЕ.

Выберите разумную веху, например «первый бета пользователь через 2 недели, считая от сегодня», или «первая продажа через 3 месяца». Без фиксированного скоупа, дедлайны в сущности становятся целями. Людям, как правило, присуща мотивация на «достижение цели».

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

Урок 3: создавайте искусственные ограничения, которые будут способствовать избеганию неудач и помогут достигнуть успеха

Люди значат больше, чем продукт

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

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

Урок 4: если вы заботитесь о людях, проект позаботиться о себе сам. Не жалейти никаких сил, чтобы обеспечить, что каждому человеку в команде нравится то, чем он занимается. Счастливые люди создают лучшие продукты

«Провал» - не провал

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

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

Остановка (отмена) проекта - это великий и поучительный урок. Принятие решение об отмене становится результатом тщательного взвешенного анализа о том, нельзя ли применить ресурсы, потраченные на проект, с большей пользой где-либо еще. Самым трудным тут является принять это решение в наиболее ранний момент, чтобы не вкладывать ресурсы в нечто заведомо бесполезное.

Урок 5: «Неудача» - это когда вы учитесь тому, как в следующий раз сделать лучше. Мне нравятся неудачи.

Почему мы отменили проект

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

Наш слоган для github.com (сайта) звучит как «Создаем программы лучше, вместе». По мере нашего роста и развития, мы постоянно сталкиваемся с вопросом, является ли это адекватным описанием видения GitHub, Inc (компании). Мы часто говорим, что наше видение компании можно описать как «делать работу вместе более легкой, чем по одному». Учитывая что до 75% наших сотрудников работают удаленно, совместная работа становится особенно нетривиальной когда вы с коллегами в разных временных зонах. Мы сталкиваемся с уникальными, не характерными для большинства компаний, вызовами.

GitHub всегда разделял стремление open source сообщества, в нашем желании создавать программы, помогающие нам решать проблемы, причиняющие нам боль. Мы чувствуем ту боль, которая возникает при совместной (удаленной) работе, поэтому мы всегда готовы «почесать эту корочку». Но думаю, мы гораздо лучше понимаем проблемы, возникающие при совместной работе над программным кодом . Создание инструмента, который облегчал бы совместную работу в других областях, требует очень хорошего понимания различных уникальных проблем.

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

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

Защитим будущее,

извлекая уроки из прошлого

УРОКИ, ИЗВЛЕЧЕННЫЕ ИЗ АВАРИИ

Дата происшествия:

Мероприятия по локализации и устранению причин аварии:

Провести внеочередную проверку знаний руководителей, специалистов и рабочих ЗАО «КапиталАгро».

Укомплектовать штат газовой службы специалистами.

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

Извлеченные уроки:

Недопустимо отступления от проектных решений при выполнении строительных работ на объектах сетей газораспределения и газопотребления.

Штат предприятия необходимо укомплектовывать обученным и аттестованным персоналом.


Наименование организации :

ОАО «КапиталАгро»

Ведомственная принадлежность :

Место аварии:

Газопровод на вводе в здание механической очистки стоков и воздуходувной

Вид аварии:

выброс опасных веществ, взрыв, разрушение сооружений

Краткое описание аварии:

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

Последствия аварии:

(в т.ч. наличие пострадавших, ущерб)

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

Экономический ущерб составил 226 000 руб.

1. Технические причины аварии:

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

  • Урок № Тема: «Азбука дорожной безопасности»

    Урок

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

  • Урок № Тема: «История развития автомототранспорта»

    Урок

    Людей при авариях , а так же и самих аварий изготовители автомобилей... оценить ситуацию и приступить к извлечению пострадавшего из -под колес, из кабины и т. п. Делать это... причина ДТП? Урок № 9. Тема: «Зачетный урок » Цель урока : Повторение пройденного...

  • Станислав Лем Фантастика и футурология Книга 2

    Обзор

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

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

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

    Если делится, то перенимают ли остальные руководители проектов полученный опыт?

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

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

    И, так как в действительности такое бывает крайне редко, логично предположить, что уроки извлекается далеко не всегда.

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

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

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

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

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

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

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

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

    А ведь для того, чтобы создать действительно полезную базу знаний нужно не так уж и много:

    1. Учет всех извлеченных уроков

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

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

    3. Коммуникации

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

    4. Поощрять пользование базой данных

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

    5. Проверка данных

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

    6. Постоянно совершенствуйте процесс

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

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


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

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

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

    Учитесь совершать разумные ошибки

    Как таковые, ошибки можно разделить на две категории: есть глупые ошибки – это ошибки, которые совершаются людьми по причине халатного отношения к чему-либо или беспечности. А есть ошибки разумные – они совершаются в случае, когда человек идёт на осознанный риск или проводит какой-либо .

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

    Извлечённые из ошибок уроки нужно обязательно применять на практике

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

    Очень важным является также и то, что совершение ошибок должно оказывать непосредственное влияние на выработку нового . Но огромное количество людей просто забывает об извлечённых уроках. И далеко не все строят всю свою дальнейшую деятельность с их учётом. И, несмотря на то, что это кажется вполне логичным (извлекать уроки и совершать новые действия) и адекватным, в большинстве случаев люди лишь индульгируют, занимаются самобичеванием и «планируют» заняться разбором своих же полётов когда-нибудь потом. Это и является прекрасным объяснением тому, что многие так ни чему и не научаются на своих ошибках.

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

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

    Учитесь на ошибках других

    В наше время существует огромное количество материалов, посвящённых описанию жизни и деятельности известных и успешных людей. Самых неординарных результатов добивались люди, которые не обладали какими-то сврехспособностями, но те, кто совершал наибольшее количество ошибок и те, кто учился на них. Об этом говорили такие люди как Томас Эдисон, Иоганн Вольфганг Гёте, Михаил Ломоносов, Владимир Ленин, Франсуа де Ларошфуко, Максим Горький, Лев Толстой, Аристотель, Конфуций и другие выдающиеся личности.

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

    Резюмируя всё вышеизложенное, можно привести ряд приёмов, которые позволят извлекать из ошибок и неудач исключительно пользу:

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

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

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

    И напоследок небольшое напутствие:

    «Помни, что изменить своё мнение и следовать тому, что исправляет твою ошибку, более соответствует свободе, чем настойчивость в своей ошибке»

    Марк Аврелий



    Похожие публикации