Приказ о начале проекта пример
Приказ о начале проекта примерСкачать файл - Приказ о начале проекта пример
Имя пользователя или e-mail. Запуская новые проекты, мы часто задаёмся вопросом — С чего начать? На самом деле всё просто. Так и с проектами, хочешь запустить новый проект — начни выражать свои идеи о проекте буквенно-цифровым и графическим способом, на бумаге, на компьютере — не важно! Всё начинается с замысла. Замысел может быть выражен на бумаге или не выражен, но его главное отличие от идеи в том, что им можно делиться. Замысел — это идея, одинаково понимаемая всеми участниками проекта. В замысле мы должны чётко сформулировать проблематику, вызвавшую проект, и задачу которую предстоит решить. На основе замысла формируются цели проекта. Главная характеристика целей — они должны быть измеримыми. Невозможно достичь того, что нельзя измерить! Хотя, конечно, измеримость цели — это не единственная её характеристика. В идеале нужно иметь SMART-цели. Если потрудиться и описать цели в таком контексте, то всем участникам будет однозначно понятно что, когда и зачем будет появляться в результате проекта. В каком документе всё это отобразить? Практически все методологии и стандарты управления проектами определяют, в качестве первого документа, Устав проекта. Но здесь есть одна зарытая собака! Дело в том, что тот Устав , который описан, например, в PMBOK , нормально работает только в достаточно зрелых системах управления проектами. Для создания действующих Уставов нужно понимать суть данного документа и смысл его использования в проектах. Вчитайся и вдумайся в каждое слово! Именно часть власти первых лиц организации должна быть передана руководителю проекта, чтоб от мог нормально выполнять проект. Итак, если процессы управления проектами в компании только зарождаются, достаточно будет некого письменного Приказа о начале проекта , изданного первым лицом организации. В этом Приказе указать, какие цели нужно достичь, и кто имеет полномочия и ответственность по их достижению. Если система достаточно зрелая, то, не мудрствуя лукаво, берём Устав описанный в PMBOK или в ISO и заполняем следующие разделы:. Эта информация и документы могут применяться как все вместе, так и всего один из них. А вот Информация о доступности ресурсов , является жизненно необходимой для проекта. Проект-менеджер без команды как один в поле воин; как тренер футбольной команды, который сам, в одиночку выбежал на поле защищать честь клуба. Итак, проектному менеджеру ПМ нужно получить человеческие ресурсы, требуемые для выполнения проекта. Если в компании проекты идут на потоке, то уже на этапе инициации проекта, ПМ может определить, кого и когда нужно привлечь к работе по проекту, а также как и когда они будут высвобождены из проекта. Если это новый проект, который в компании ни кто ранее не делал, то ПМ-у следует сформировать команду хотя бы на этап планирования проекта, во время которого прояснится, какие ещё люди понадобятся. Когда требуемых специалистов нет внутри компании, следует рассмотреть возможность найма дополнительных трудовых ресурсов на рынке труда или проведения субподрядных работ силами другой организации. Если всё-таки принимается решение по найму дополнительного персонала на время планирования и реализации, то должны быть определены их место работы, обязательства, роли и ответственность, порядок предоставления отчётности и внутри командного взаимодействия. Данная информация отражается в Трудовом контракте. Когда в команду будут назначены соответствующие лица, можно переходить к планированию проекта. Уже не для кого не секрет, что мы живём в VUCA-мире. Если для кого-то это ещё секрет, то как раз по секрету рассказываю: VUCA — это аббревиатура слов volatility , uncertainty , complexity и ambiguity нестабильность , неопределённость , сложность и неоднозначность используемых для описания неких условий и ситуаций. Чуть позже, процессы, технологии и события на планете Земля стали тоже подходить под VUCA-описание, а многие военные повыходили на свою раннюю пенсию и продолжили свои карьеры в бизнесе. Вот тогда-то данный термин и перекочевал в корпоративный и консалтинговый сектор. Проекты и сами по себе являются временными, сложными и нестабильными по своей сути, а тут ещё и проектное VUCA-окружение. Поэтому успех проекта сегодня определяется не столько в умении реализовать проект в рамках ограничений по содержанию, срокам, стоимости, качеству, ресурсам и риска, сколько в умении согласовывать изменения с заказчиком и вышестоящим руководством. Вот для того, чтоб знать, кто из этих заинтересованных сторон заинтересован в успехе проекта, а кто в провале, и создаётся Реестр заинтересованных сторон или стейкхолдеров. Причём создаётся он на самой ранней стадии, а именно на этапе инициации проекта. Реестр стейкхолдеров включает определение, оценку и классификацию заинтересованных сторон проекта. В Реестре стейкхолдеров также отражается анализ заинтересованных сторон проекта. Табличная часть Реестра заинтересованных сторон выглядит примерно так: Последовательность заполнения таблицы и анализа ЗС:. Только следует обязательно засекретить этот документ от того, кто указан как противоборствующая сторона проекта. Поскольку, эти стейкхолдеры могут не осознавать, что они мешают твоему проекту, а когда увидят этот документ, начнут реально гадить. В следующей статье я расскажу, как документировать процесс планирования объёмов работ проекта. Для отправки комментария вам необходимо авторизоваться. Поддержать проект PMDoc Полистать документы PMDoc Шаблоны документов PMBOK Руководство по документированию. Praxis - Курс прикладного управления проектами. Тренинг практического использования методологии управления проектами сочетает интенсивную подачу материала с закреплением полученных знаний на практических примерах, в ходе индивидуальных и групповых упражнений, а так же деловых игр. На тренинге, участники прорабатывают выбранный ими проект; применяют инструменты, техники и методы запуска, планирования, выполнения, контроля и завершения проектов, разбираясь в сущности этих инструментов и принципах их самостоятельного применения на практике Risks - Курс управления рисками проектов и программ. Курс предназначен для получения системных знаний в области управления возможностями и угрозами. На тренинге Вы научитесь разрабатывать стратегию управления рисками, идентифицировать и анализировать риски, планировать мероприятия по реагированию на риски, а также контролировать риски в проекте или программе и подводить уроки опыта для использования в будущих проектах и программах Страна Другие Азербайджан Армения Беларусь Болгария Германия Казахстан Кыргызстан Латвия Молдова Россия Узбекистан Украина Эстония. Главная Документация Руководство по документированию проектов бесплатно ОСУП. Комплект Услуги Документирование проектов Разработка регламентов УП Обучение документированию Внедрение систем УП Тренинги По методологии pm. Prince2 По инструментам Redmine По лидерству pm. People Прокачай команду проекта Мастерство вести за собой Школа УП Календарь тренингов Отзывы Наши инструкторы Анатолий Савин, PMP Александр Сень, MCP, MCT Николай Митько, PMP, CSM Екатерина Решта Воркшопы w. Stakeholders Все остальные Education-by-Expedition 3 вершины ПМ 1-я вершина 2-я вершина 3-я вершина pm. Trekking О портале Инфо Контакты. Документирование проекта на старте 2 комментария. Подписывайтесь на группу PMDoc в Facebook, и обсуждайте с коллегами вопросы документирования проектов Меня зовут Анатолий Савин. Я эксперт по документированию проектов. На сегодняшний день я провожу единственный русскоязычный тренинг по документированию проектов. Я начинаю цикл статей по управленческому документированию проектов. Устав проекта В каком документе всё это отобразить? Если система достаточно зрелая, то, не мудрствуя лукаво, берём Устав описанный в PMBOK или в ISO и заполняем следующие разделы: Назначение или обоснование проекта , то есть для чего и зачем инициируется данный проект. Проект запускается если есть: Эти пункты можно назвать проблемами, благоприятными возможностями или требованиями бизнеса. Главная идея заключается в том, что руководство должно решать, какой должна быть ответная реакция компании и какие проекты следует авторизовать, зафиксировав их в Уставах. Измеримые цели проекта и соответствующие критерии успеха. Как уже упоминалось выше, это как раз тот раздел, в котором описывается, как и чем будем измерять результаты проекта. Критериями оценки могут быть стандарты, правила или тесты, на которых может основываться решение или суждение, или с помощью которых можно оценить продукт, услугу, результат или процесс. Также в данном разделе указывается, что составляет успех проекта, кто решает, что проект оказался успешным, и его критерии приёмки результатов проекта. Высокоуровневые требования , удовлетворяющие потребности, пожелания и ожидания Заказчика, Спонсора и других участников проекта. На что должны быть направлены работы; какую стратегическая позиция следует занять; какую задачу следует решить; какой результат нужно достичь; какой требуется произвести продукт; или какую услугу необходимо оказать. Здесь нужно обратить внимание, что в Уставе проекта указываются только высокоуровневые требования. Полный перечень требований должен быть отображён в специальном документе по требованиям, например, в Матрице отслеживания требований. Допущения, ограничения и исключения проекта , способные оказать воздействие на реализацию проекта. Допущения — это факторы, которые для целей планирования считаются верными, реальными или определёнными без предоставления доказательств или демонстрации. Ограничения — это сдерживающие факторы, влияющих на ход исполнения проекта, программы, портфеля или процесса. Исключения — это пакеты работ, которые в данном проекте выполняться точно не будут, чтоб не раздувать объёмы работ проекта. Следует обратить внимание, что в Уставе проекта указываются только высокоуровневые допущения, ограничения и исключения. Полный перечень должен быть представлен в Описании содержания проекта во время планирования содержания. Высокоуровневые риски , где указывается насколько компания готова рисковать то есть уровни толерантности Спонсора и Заказчика проекта к рискам ; что или кто может помешать реализации проекта; как это повлияет на сроки, бюджет, качество и объёмы работ проекта; а также даётся краткое описание, каким образом будет осуществляться управление рисками проекта. Также как и с прошлыми двумя пунктами, полный перечень рисков должен быть отображён в специальном документе Реестре рисков на этапе планирования рисков. Сводное расписание контрольных событий вех , как правило задаваемое контрактом или другими требованиями указывающими, в какие именно сроки должны произойти те или иные вехи проекта, и кто ответственен за их происхождение. Здесь тоже указываются только высокоуровневые вехи. Для самопроверки, отвечают ли вехи, описанные в данном разделе, требованиям высокоуровневости разделов Устава , можно задать себе три простых вопроса, на которые должен быть получен положительный ответ: Это действительно важные моменты или события проекта? Имеется необходимое и достаточное количество вех, чтобы контролировать последовательный то есть без авралов и длительных простоев ход проекта? Известно кто и когда должен достичь вехи? Сводный бюджет , указывающий во сколько обойдётся проект и сколько денег спонсор проекта готов предоставлять ежемесячно или ежеквартально, еженедельно, …. Как говорилось выше, это самый важный раздел Устава , который содержит информацию о назначенном Руководителе проекта, его уровне ответственности и полномочий, то есть кто отвечает за успешную реализацию проекта и что ему для этого необходимо. Конечно же, рекомендуется, чтобы Руководитель проекта участвовал в разработке Устава проекта , так как данный документ наделяет его полномочиями использовать ресурсы организации для выполнения проекта и ответственностью за достижение целей проекта. Шаблон Устава проекта можно полистать здесь: Бизнес-план или ТЭО разработанные некими стратегами в компании, где отображается не только финансовый анализ затрат и выгод, но также и соответствие проекта стратегиям, целям и задачам бизнеса. Шаблоны всех этих документов можно полистать здесь: Инициация по ISO Назначение команды Итак, проектному менеджеру ПМ нужно получить человеческие ресурсы, требуемые для выполнения проекта. Шаблоны документов по организации команды можно полистать здесь: Последовательность заполнения таблицы и анализа ЗС: Определить все потенциальные заинтересованные стороны проекта и существенную информацию о них, такую как роли, отделы, интересы, знания, ожидания и уровни влияния. Таким образом заполняются первые 5 колонок указанной выше таблицы. Ключевые ЗС, такие как спонсор или заказчик, выявляются легко. Остальные обычно определяются во время общения с выявленными стейкхолдерами. Желательно в Реестре ЗС указать всех потенциальных заинтересованных сторон. Градуировав таким образом шкалу власти, расставляем остальным стейкхолдерам процентовки по власти, просто попарно сравнивая их друг с другом. Имеется ввиду интерес к успеху проекта, который может быть, как положительным, так и отрицательным. Максимальная заинтересованность в провале проекта может быть у конкурента, или у некого врага нашего ПМа, всё зависит от частной ситуации. Градуировали шкалу интереса, расставляем проценты остальным ЗС. Затем в MS Excel или в чём ты там составлял Реестр ЗС? И получаем примерно такой вид: Визуально объединяем ЗС в кластера и формируем для них стратегии управления: Причём желательно информировать пассивно. Создайте какую-нибудь рассылку, или подобие соцсети для этих людей, или повесьте большой монитор над входом в комнату команды проекта, и забрасывайте информацию туда. Это именно те люди, которые в итоге решат был ли проект успешен или нет. И не нужно бояться излишнего участия этих стейкхолдеров в делах проекта. Шаблон Реестра заинтересованных сторон проекта можно полистать здесь: Устав проекта , который определяет цели проекта и предоставляет руководителю проекта власть над ресурсами. Реестр заинтересованных сторон , определяющий перечень людей, на интересы которых повлияет проект или его результат; а также определяющий стратегию поведения команды по отношению к каждому классу ЗС. Полный пакет шаблонов, созданных на основе PMBOK 5-й редакции можно получить здесь: Пакет шаблонов, созданных на основе ISO Все примеры и шаблоны документов портала PMDoc, связанные с инициацией различных проектов, можно получить здесь: Видео-урок по документированию проекта на старте: Документирование проекта на старте: Добавить комментарий Отменить ответ Для отправки комментария вам необходимо авторизоваться. Июль Пн Вт Ср Чт Пт Сб Вс 1 pm. Praxis - Курс прикладного управления проектами pm. Praxis - Курс прикладного управления проектами Risks - Курс управления рисками проектов и программ pm. Risks - Курс управления рисками проектов и программ Agile ISO MS Project OnLine pm. Кинозал PMBOK PMP Документирование Завершение Заинтересованные стороны Закупки ИСУП Инициация Исполнение КСУП Качество Киризис Менеджмент Коммуникации Методология Мониторинг и Контроль Мысли ОСУП ОУП Планирование Портфели Прикладное УП Программы Проекты Риски СМК СУДП Содержание Сроки Стоимость Тренинги УП от домохозяйки Управление проектами Человеческие ресурсы Школа УП Экспедиции Экстремальное обучение. Сайт работает на WordPress. Имя пользователя или e-mail Пароль Запомнить меня Регистрация Забыли пароль? Подписывайтесь на группу PMDoc в Facebook, и обсуждайте с коллегами вопросы документирования проектов. Меня зовут Анатолий Савин.
Приказ об открытии проекта. Скачать (MS Word)
Подробная карта самарской области для навител
Запрос на изменение
Дрожжевое тесто время приготовления
Расписка об отсутствии претензий к работодателю образец
Как готовить шурпу в домашних условиях
Документирование проекта на старте
Антагонист финиша сканворд 5 букв