ДОКУМЕНТИРОВАНИЕ ПЛАНА ПРОЕКТА [c.383]
Группы процессов соединяются посредством производимых результатов результаты одного процесса становятся входными данными для другого. Среди центральных групп процессов связи повторяются - планирование обеспечивает исполнение документированного плана проекта еще на ранних стадиях, а затем представляет документированные изменения плана по мере осуществления проекта. Эти связки показаны на рис. 3.1. В дополнение, группы процессов управления проектами не являются дискретными одноразовыми событиями - это пересекающиеся работы, проявляющиеся с разными уровнями интенсивности внутри каждой фазы проекта. Рис. 3.2 иллюстрирует, как группы процессов пересекаются и видоизменяются внутри фазы. [c.34]
Регламентирован способ документирования изменений в Плане проекта. [c.287]
Необходимость прямого документирования допущений необходима для исключения потенциальной ошибки при трансформации Плана проекта допущения могут превратиться из предположительных условий в реально существующие условия. [c.350]
Такой архив может использоваться в разных формах. Например, включенные в него материалы могут применяться как эффективное средство обобщения опыта, иллюстрация характерных способов организации управления проектами и их документирования. При этом большое значение имеет включение в отчетные файлы базового плана для сравнения исходной и окончательной версий проекта. [c.395]
Идентификация рисков при разработке и реализации проектов объектов трубопроводного транспорта заключается в определении того, какие риски способны повлиять на проект, и документировании характеристик этих рисков. Работа по идентификации рисков должна производиться регулярно на всем протяжении реализации проекта. Идентификации должны подвергаться как внешние риски, не зависящие от действий команды управления проектом (такие как изменение политической, социальной, экономической ситуации и тому подобное), так и внутренние риски (оценка необходимых материально-технических и людских ресурсов, план поставок и так далее). Работы по идентификации рисков целесообразнее производить по двум схемам. [c.265]
Наконец, при организации разработки программного изделия следует учесть еще один инструмент, хорошо вписывающийся в индивидуальные рабочие планы, — использование стандартов. Каждый, кто занимался программированием, по достоинству оценивает пользу стандартизации в кодировании и документировании программ. В равной мере важны стандарты управления, помогающие проводить планирование, анализ результатов и оценку эффективности осуществляемых проектов. Для того чтобы иметь возможность проверять полноту планирования и проводить декомпозицию проекта на любом этапе, необходимы системные и процедурные руководства, описывающие как методику проведения разработки, так и методики выполнения связанных друг с другом функций поддержки, выпуска документации и испытаний. [c.89]
Определение целевых значений показателей с методической точки зрения может осуществляться двумя путями — интерактивно в ходе внутрифирменного семинара (совещания) или как предварительная разработка с последующим обсуждением и достижением согласия в ходе совещания. Первый путь рекомендуется использовать для подразделений низовых уровней организационной иерархии. При составлении сбалансированной системы показателей для уровня управления компанией (подразделением) предпочтителен второй путь. Его можно также комбинировать с моделированием бизнес-плана. В любом случае необходимо соблюдать следующий принцип сбалансированность целей должна отражаться в сбалансированности целевых значений. Во многих проектах построения системы BS целевые значения показателей устанавливаются не в ходе семинара, а в ходе последующей индивидуальной или групповой работы. Результаты этой работы затем обсуждаются на совещании. Следующие шаги позволяют определить целевые значения показателей разработка основы для сравнения анализ различных связей между целевыми значениями определение пороговых значений документирование целевых значений. [c.234]
Согласно учебнику РМВОК процесс изменения сферы действия может быть как официальным так и неофициальным. Я бы сказала, что этот процесс скорее неофициальный в небольших проектах, которые имеют простую структуру и одного или двух инвесторов. В больших или сложных проектах всегда предусматривается наличие плана управления сферой действия. В другом случае, что касается моего опыта относительно официального и неофициального процесса, все изменения должны быть указаны в письменном виде. У акционеров и руководителей проектов иногда очень плохая память. Все, о чем вы думаете и говорите, может не совпадать с тем, что слышит акционер, и наоборот. Документирование всех изменений исключит эти проблемы. Мы говорили о документации [c.159]
План управления рисками. План управления рисками должен описывать процедуры, которые будут использованы для управления риском во время выполнения проекта. В добавление к документированию результатов процессов идентификации риска и определению количества риска план должен охватывать следующее кто ответственен за управление в различных областях риска, как будут поддерживаться первоначальные результат ы выявления и определения количества риска, как будет применяться план непредвиденных случайностей и как будут распределены запасы. [c.127]
Требовании и ограничения — Условия (рамки), задаваемые руководством компании для проектных показателей. Например, проект при любых условиях должен быть выполнен к заданной календарной дате, бюджет проекта не должен превысить закланную величину. Документирование ограничений важно при разработке первых версий Плана проекта. Первая версия Плана имеет невысокую точность расчетов. Поэтому ограничения могут не приниматься в расчет. При разработке последующих, более детальных версий, наличие документированных смраничений позволит достаточно точно рассчитать все показатели при заданных oi раничениях. [c.323]
Ограничениями называются условия для проекта, которые задаются руководством компании и в дальнейшем являются необеуждаемыми. Примерами могут быть выполнить проект при заданной смете, в заданный срок и т.д. Ограничения могут устанавливаться еще до открытия проекта. В любом случае, ограничения возникаю на стартовом згагю проекта. Документирование ограничений необходимо, чтобы в процессе трансформаций Плана проекта ограничения были безусловно выполнены. [c.347]
План проекта (Proje t Plan) - Официальный, утвержденный документ, используемый для ведения как выполнения проекта, так и его контроля. Основополагающее использование плана проекта заключается в документировании планируемых предположений и решений для обеспечения связи между стэйкхолдерами и для утверждения документов исходного замысла, исходной стоимости и исходного расписания. План проекта может быть как обобщенным, так и подробным. [c.175]
Должностные обязанности. Организует разработку и внедрение организационных и технических мероприятий по комплексной защите информации на предприятиях, ведущих работы, содержание которых составляет государственную или коммерческую тайну, обеспечивает соблюдение режима проводимых работ и сохранение конфиденциальности документированной информации. Возглавляет разработку проектов перспективных и текущих планов работы, составление отчетов об их выполнении. Руководит проведением рабрт по организации, координации, методическому руководству и контролю их выполнения по вопросам защиты информации и разработкой технических средств контроля, определяет перспективы их развития. Обеспечивает взаимодействие и необходимую кооперацию соисполнителей работ по вопросам организации и проведения научно-исследовательских и опытно-конструкторских разработок, организует и контролирует выполнение плановых заданий, договорных обязательств, а также сроки, полноту и качество работ, выполняемых соисполнителями. Организует работу по заключению договоров на работы по защите информации, принимает меры по обеспечению финансирования работ, в том числе выполняемых по договорам. Обеспечивает участие подразделения в разработке технических заданий на выполняемые на предприятии исследования и разработки, формулирует цели и задачи работы по созданию безопасных информационных технологий, отвечающих требованиям комплексной защиты информации. Организует проведение специальных исследований и контрольных проверок по выявлению демаскирующих признаков и возможных каналов утечки информации, в том числе по техническим каналам, [c.100]
Из системы менеджмента качества Прослеживаемость распространилась на всю систему управления. Если при выполнении проекта обнаружились проблемы, то анализ документированных событий должен дать достоверный результат о причине проблемы ошибка при выборе и утверждении проекта, ошибки плана, сбои при выделении ресурсов, ошибки проектной команды и т.п. [c.75]
Смотреть страницы где упоминается термин Документирование плана проекта
: [c.196]Смотреть главы в:
Управление инвестициями Том 1 -> Документирование плана проекта