project charter что это
Устав проекта (Project Charter)
Устав проекта (рroject charter) — один из самых мифологизированных рабочих документов проекта. Краткость описания этого документа в основном стандарте PMI PMBOK в редакциях 2000 и 1996 года, с лихвой окупается богатством интерпретаций предназначения и содержания данного документа как российскими, так и зарубежными экспертами в области управления проектами.
Если обобщить существующие в проектной практике точки зрения, то получится, что под Уставом проекта разные специалисты, в т.ч. ориентирующиеся на PMBOK, понимают:
Предназначение, содержание и порядок разработки и изменений Устава проекта в соответствие с новой редакции PMBOK от 2004 года описаны ниже. Примеры структур Уставов проектов из практики разных компаний приведены в Приложении к статье.
Предназначение документа: Устав проекта предназначен для определения проекта. На фазе инициализации, он включает в себя:
Когда разрабатывается документ: после заключения контракта (если заключается контракт с внешним контрагентом)
Кто разрабатывает документ: Устав проекта могут разрабатывать:
Кто утверждает документ: Устав проекта может утверждать:
Лицо, утверждающее Устав проекта, должно иметь полномочия по принятию основных решений по проекту, включая его финансирование.
Входы (исходные данные) для разработки документа:
Содержание документа: Устав проекта непосредственно включает в себя следующие данные или ссылки на соответствующие документы:
Порядок изменений документа: Команда проекта поддерживает Устав проекта в актуальном состоянии, получает обратную связь от участников проекта о необходимых улучшениях документа, контролирует изменения и выпускает релизы утвержденного документа.
Устав (чартер) проекта и его содержание
Устав проекта (Project Charter) – это документ, который обычно готовит руководитель проекта после получения вводных о проекте.
Зачем нужен устав проекта
Устав содержит основные характеристики проекта и согласуется основными заинтересованными лицами (как минимум – Заказчиком и Спонсором проекта). Как правило, разработка и подписание Устава несет в себе 3 основные функции:
Определить основные требования к результату проекта и основные характеристики самого проекта (бюджет, сроки).
Формально запустить проект, т. к. только после подписания проект считается действительно существующим в Компании.
Наделить руководителя проекта определенным уровнем полномочий (каким именно – зависит от Компании).
Иногда устав проекта используется для оценки выгод от его реализации и принятия решения о запуске. Хотя это не соответствует классической методологии, по которой устав готовится только для уже оцененного и утвержденного к реализации проекта.
-Чартер должен содержать ответы на следующие основные вопросы:
— что именно вы собираетесь произвести?
Программы и портфель проектов
Программа – это ряд связанных с друг другом проектов, которые работают на одну цель или преимущество. Все проекты в программе участвуют в достижении цели
Портфель – это набор проектов а также и программ, который имеется в компании. Естественно он работает на стратегию и бизнес цели компании, они также имеют приоритеты по влиянию на стратегических целей
Управление программой является централизованным, скоординированным управлением группы проектов для достижения стратегических целей программы и выгод
Задачами управления портфелем являются максимальное увеличение ценности портфеля, уравновешивание пошаговых и радикальных инвестиций и эффективное использование ресурсов портфеля
Области знаний в управлении проектами (PMBOK, PMI)
PMI– Project Management Institute, был основан в 1969 году в Пенсильвании, является международным некоммерческим институтом управления проектами, разработавшим набор международно-признанных стандартов по управлению проектами, программами, портфелями проектов
PMBOK – Свод знаний по управлению проектами (англ. Project Management Body of Knowledge) описывает практики управления проектами, выпускается Американским институтом управления проектами (PMI), который с 1996 года каждые 4 года разрабатывает и публикует новую версию PMBOK.
Шестая версия PMBOK выпущена в 2017 году.
Офис и организация управления проектом, роль руководителя проекта.
Офис управления проектами — организационная структура, стандартизирующая процессы руководства проектами и способствующая обмену ресурсами, методологиями, инструментами и методами. Сфера ответственности ОУП может варьироваться от оказания поддержки в управлении проектами до прямого управления одним или более проектами.
В организациях существует несколько типов структур ОУП :
1. Поддерживающий. ОУП играют консультативную роль, предоставляя шаблоны, лучшие практики, обучение, доступ к информации и уроки, извлеченные из других проектов. Данный тип ОУП служит в качестве хранилища проекта. Степень контроля со стороны ОУП низкая.
2. Контролирующий. ОУП предоставляют поддержку и требуют соответствия требованиям с помощью различных средств. Соответствие может предполагать адаптацию структур или методологий управления проектами, использование специфических шаблонов, форм и инструментов или соответствие требованиям руководства. Степень контроля со стороны ОУП средняя.
Руководящие ОУП контролируют проекты путем непосредственного управления данными проектами. Степень контроля со стороны ОУП высокая.
Организация управления проектом
Организации, основанные на проектах (project-based organizations, PBOs), — разнообразные формы организаций, которые занимаются созданием временных систем для исполнения работ.
Роль руководителя проекта
Компетенции в знаниях
Компетенции в исполнении
Навыки межличностного общения руководителя проекта
Стили управления проектом
-Директивный стиль управления проектом.
-Совместный стиль управления.
1. Авторитарный стиль управления состоит в том, что вся полнота власти находится у руководителя и все решения принимаются им единолично, не учитывая мнения подчиненных. В данном случае используется командный метод управления. Авторитарный стиль управления необходим в кризисной ситуации, когда решения должны приниматься быстро и быть четко скоординированы, что значительно затрудняется в условиях коллективной деятельности по разработке решений.
2. Демократический стиль предполагает делегирование руководителем части своих полномочий подчиненным и принятие решений на коллегиальной основе. Он актуален при стабильной работе предприятия и стремлении его к внедрению инноваций.
3. Либеральный стиль представляет собой управление без участия руководителя. Работники предоставлены сами себе, приходится рассчитывать на их дисциплинированность.
Как не набить шишек на старте проекта
Меня зовут Настя, я Unit Manager международной команды в компании Itransition и тренер по управлению проектами в IT-Academy. За почти 10 лет опыта в менеджменте мне довелось поработать с разными заказчиками, продуктами, командами. На старте карьеры меня удивляло, что, согласно статистике PMI, из года в год более половины проектов заканчиваются крахом.
Сейчас я охотно верю этим данным, ведь сколько IT-проектов я ни стартовала, не было ни одного, чтобы все шло идеально. Я также не знаю ни одного практикующего менеджера, у которого бы всегда все шло как по маслу (те, с кем я познакомилась на собеседованиях, не считаются). Как ни печально, многих трудностей можно было бы достаточно легко избежать, или, как минимум, облегчить ход развития событий, предприняв определенные шаги на самом старте проекта.
В данной статье речь пойдет о тех практиках и артефактах, на которые я обращаю особое внимание на старте проекта. Информация будет полезна не только начинающим, но и менеджерам с опытом работы на IT-проектах: для опытных менеджеров примеры будут более понятными, а новички, надеюсь, смогут избежать подобных сложностей в начале карьеры.
Я расскажу как об известных и достаточно банальных, но очень полезных вещах, так и том, чего не встретишь как минимум в первых пяти статьях google на тему «как стартовать проект».
О чем мало говорят, но было бы полезно использовать
Team Charter или манифест команды
Было ли у вас когда-нибудь ощущение, что вы работаете в коллективе, но не команде? У меня было много раз, к сожалению. Первым шагом на пути создания команды я чаще всего выбираю Team Charter. Мне очень нравится этот инструмент, так как он решает сразу несколько задач. При этом важен не только процесс создания манифеста/устава команды, но и получившийся артефакт.
Во-первых, Team Charter позволяет выровнять контекст и узнать о ролях в команде и целях проекта. С командой редко разговаривают о таких вещах, хотя усилий это требует совсем небольших, а эффект от искренней вовлеченности в работу и отсутствия лишних коммуникаций и ложных ожиданий может превзойти все ожидания.
Во-вторых, манифест устанавливает понятные и прозрачные правила игры, что снижает общий уровень тревожности. Старт нового проекта, как и любое изменение, – всегда стресс для всех вовлеченных ввиду большого количества неопределенности. Да, тревожно не только менеджеру. Мы не знаем, как нас примут в новом коллективе, какое поведение здесь поощряется и каким ценностям следуют.
Неопределенность создает психологическое напряжение и страх ошибки, за которым стоит страх непринятия. Это очень глубокая тема, но не хотелось бы уходить в сторону от старта проектов. Поэтому всем заинтересовавшимся рекомендую почитать труды или посмотреть видео Эми Эдмондсон, одного из ведущих исследователей психологической безопасности на рабочем месте.
В-третьих, манифест сокращает время на адаптацию новичков. Так или иначе, мы не застрахованы от смены членов команды. В таком случае манифест даст новичку информацию о том, в какую группу людей он попал, зачем и по каким правилам эта группа существует.
Onboarding Guide или руководство для новичков
Продолжая тему смены членов команды, весьма полезным будет начать создавать руководство по онбордингу для новичков с самого старта проекта. Первое время оно будет служить описанием рутинных процессов (описание проекта, отпуска, больничные, трекинг времени, тимбилдинги, манифест и т.д.) для всех членов команды.
А затем, когда команда привыкнет к этим правилам, гайд станет надежной опорой для каждого новичка. В противном случае вам придется всю эту информацию пересказывать из уст в уста, тратить на этот процесс много времени и встречать досадные неприятности из-за того, что какая-то информация все же потерялась.
Communication plan или план коммуникации
На просторах глобальной сети можно найти великое множество разнообразных шаблонов плана коммуникаций, поэтому будет небольшим лукавством сказать, что о нем мало говорят. Но говорят обычно не предметно, а скорее слишком теоретически. Я считаю этот инструмент крайне полезным, поэтому поделюсь, как я его использую в своей практике.
Обычно создаю на Confluence страницу под названием Communication plan, где располагается таблица. Ее верхняя строка представляет собой таймлайн – схему рабочей недели или месяца (зависит от продолжительности итераций, по которым выстраиваются рабочие процессы). Следующие строки посвящены инструментам коммуникации, обычно это встречи и разного рода отчеты.
Остается только отметить на таймлайне, какие из этих инструментов будут использованы и когда. Это позволяет увидеть, насколько равномерно распределены встречи, нет ли нагромождений из митингов и перерасхода времени на коммуникацию. Таблицу можно дополнять различными деталями и ссылками, а также обязательными и необязательными участниками. То же самое можно сделать в отдельном календаре Outlook, не всем удобно размещать напоминания об отчетах в этом инструменте в качестве события.
Реестр юридических документов
Здесь все просто: чтобы ничего важного не потерять и не забыть, лучше сразу все хранить в одном месте, будь то папка на Sharepoint или страничка на Confluence. Важно помечать «срок годности», чтобы вовремя обновлять необходимые документы.
Это позволит избежать ситуации, когда команда отработала очередной месяц, клиент внезапно перестал платить по счетам, а документы по оказанию услуг уже просрочены и подписывать снова их никто не собирается – средства закончились.
О чем многие знают, но часто забывают
Договор
Что является отправной точкой для старта проекта? В сервисных IT-компаниях, как правило, – подписание контракта. Но почему-то этот самый контракт менеджеры не считают нужным прочитать. Постараюсь кратко описать, что полезного там можно найти, помимо всем известных сроков и стоимости поставки:
Deliverables или объем поставляемых услуг
Сюда, бывает, не заглядывают до самого окончания проекта – и потом находят много интересного. В объем поставки, помимо кода, может входить различная документация и дополнительные услуги. Зная о таких нюансах, можно все эти артефакты подготовить заранее, в спокойном режиме.
К примеру, на одном из проектов в комплект поставки должны были входить требования в виде спецификации. Но, не обратив на это внимание, команда работала над требованиями только в виде описания Jira-тикетов. Благо, все закончилось мирно и заказчику этого оказалось достаточно, но для этого менеджеру на пару с бизнес-аналитиком пришлось приложить немало усилий.
Assumptions или допущения
Допущения, обычно, формируются на этапе оценки проекта, но не всегда оправдываются, хоть и влияют на оценку проекта. С другой стороны, зачастую assumptions – это оплот надежды менеджера не остаться крайним, когда все идет наперекосяк по каким-то внешним причинам. Допущения позволяют вести переговоры с заказчиком не с позиции оправдывающегося, а на равных. С другой стороны, допущения тесно связаны с рисками и дают нам фору в борьбе с обстоятельствами.
Например, в допущениях указано, что заказчик предоставит готовые API для разработки front-end. Соответственно, есть риск того, что это допущение окажется ошибочным. В таком случае команде придется, как минимум, приложить дополнительные усилия на интеграцию с серверной частью приложения. Задача менеджера – определить, насколько сильным будет влияние на проект риска, что допущение окажется ошибочным, и составить план «Б».
Процедура приемки
Даже когда проект идет прекрасно, команда счастлива, а заказчик вас боготворит, все может измениться на этапе приемки. Поверьте, когда вы распустите команду, ваш бэклог будет полон минорных багов, а заказчик откажется принимать проект, пока все не пофиксят, вы вспомните об этом пункте договора. Если в договоре явным образом не указывается уровень качества поставляемого программного обеспечения, обязательно внесите пункт «согласовать стратегию тестирования с заказчиком» в свой чек-лист по старту проекта.
В этом же пункте обычно описываются отчеты, которые исполнитель обязан предоставлять заказчику, а также порядок приемки этих отчетов. В данном случае не рекомендую действовать исключительно «по букве закона» и спать спокойно, если заказчик не ответил на ваше письмо с проблемным отчетом в течение оговоренного срока. Обычно это означает, что существует риск «нарваться» на еще большие проблемы и непонимание заказчика в будущем, хотя, согласно договору, отчет и считается принятым.
Я указала только три пункта, но договор нужно и важно читать полностью, вдумчиво! На моей практике были примеры, когда менеджер обещал клиенту гарантию, руководствуясь своим опытом работы с контрактами в другой компании, хотя в текущем контракте она не была прописана. Бывало, что осуществляли замену членов команды, не соблюдая условия договора, что влекло за собой праведный гнев заказчика. А ведь можно было этого легко избежать.
Устав проекта
Я очень часто слышала, что устав – это атавизм, он никому не нужен и ценности никакой не несет. Но договор доступен далеко не всей команде, а альтернативного артефакта, где указана вся основная информация о проекте, пока не придумали. Устав проекта совершенно не обязательно должен быть официальным документом – достаточно аккуратной странички на Confluence или Wiki со всеми необходимыми ссылками.
Даже если вы работаете по типу контракта dedicated team, устав заставит вас задуматься, чего же на самом деле хотят ваши стейкхолдеры. Такие мысли, подкрепленные конкретными действиями, переводят вас из разряда администраторов в управленцев. На мой взгляд, устав, как предмет гигиены, как заглавие книги, должен быть у любого проекта.
Kick-off Meeting или встреча по инициации проекта
Я бы сравнила kick-off с первым свиданием: от того, как пройдет первое, во многом зависит, будет ли продолжение. Да, отношения с заказчиком подкреплены договором, но никто не застрахован от эскалации и просьбы сменить менеджера. Только вот почему-то далеко не всегда к kick-off готовятся так же трепетно, как к первому свиданию. Я не буду говорить про повестку встречи, но вот на что я рекомендую обратить внимание:
Подготовьтесь и проведите внутренний kick-off. Это позволит вам отрепетировать звонок с заказчиком, пообщаться с командой, с pre-sales, собрать всю возможную информацию и создать список открытых вопросов. Как результат, вы будете более подготовленными и менее тревожными.
Подготовьте презентацию. Она сильно облегчит вам задачу как докладчику и позволит всем участникам встречи легче улавливать информацию, быть всегда в одном контексте. Инструментов для этого достаточно: Microsoft PowerPoint, Miro, Prezi – выбор на любой вкус.
Убедитесь, что у всех участников с вашей стороны включены камеры, налажен звук микрофона, всех хорошо видно, у всех надлежащий внешний вид. Созвонитесь за 30 минут до звонка с клиентом, чтобы все проверить. Все уже привыкли к условиям удаленки, поэтому если вдруг на заднем плане у кого-то появится кот или ребенок – это не страшно. Страшно, если вы начнете вести себя неадекватно и кричать на ребенка или кота.
Предупредите клиента о формате звонка. Обычно я высылаю презентацию заранее, чтобы он смог подготовиться, а также внести дополнения или правки при необходимости.
Вышлите follow-up и приглашения на последующие встречи. Если вы не задокументируете ваши договоренности – будьте уверены: о них забудут или, что хуже, в момент наступления проблем будут использовать не в вашу пользу.
Я видела проекты, на которых не было ни внутреннего, ни внешнего kick-off. Также видела проекты, где kick-off проходил без презентаций и качественной подготовки. Они не закрывались, но, помимо налета безразличия со стороны менеджмента, появлялись другие, более серьезные проблемы.
Например, не было выявлено, что клиент не знаком с методологией Scrum и просто не понимает роль владельца продукта, которой его «наградил» менеджер. Или выявлялись критические расхождения в понимании уровня прозрачности процессов разработки, в результате чего появлялись эскалации.
Заключение
Пока писала статью, несколько раз ловила себя за руку, чтобы не углубиться в какую-то из вышеупомянутых тем. Хоть это далеко не все, что входит в работу менеджера в начале проекта. Надеюсь, список получился полезным и поможет вам избежать некоторых трудностей с самого старта. Все эти инструменты не панацея, главное – понимать, в чем их польза и зачем менеджеру их использовать. Если вам есть чем поделиться по этой теме, буду рада обсудить в комментариях!
Как написать устав проекта?
Не спешите запускать проект, когда имеете лишь общее представление, что вас ждет впереди и как к этому двигаться. Потратьте время на создание документа, который станет и верным компасом, и бесценной шпаргалкой!
Устав проекта (УП) разъясняет,
в каком направлении будет идти ваша компания и зачем,
что изменится и какие риски при этом возникнут.
Этот документ не только содержит базовую информацию, но и отражает общее видение стейкхолдеров.
УП обычно создается на самой ранней стадии проекта, еще до формирования проектной команды (ПК). Обычно он составляется совместно с другими участниками проекта и передается на финальное рассмотрение стейкхолдерам. В большинстве случаев устав подписывается спонсорами.
Что такое устав проекта
Можно написать документ на несколько десятков страниц, наполнив его всевозможными деталями, однако вряд ли вы захотите потом это перечитывать. Поэтому лучше все вместить максимум в 3-5 страниц, идеально — 1-2 страницы.
Как пример, устав проекта может выглядеть как текстовый документ, Google-документ или презентация. Также он может выглядеть как задача с метками «Документы» и «Стратегическая» в программе управления проектами Worksection:
Что проясняет УП?
Когда создается УП?
Перед запуском проекта. В это же время с ним должны ознакомиться стейкхолдеры.
Кто разрабатывает и одобряет УП?
Разработкой УП обычно занимаются опытные ПМ. Документ одобряется спонсором проекта.
Что должно содержаться в УП?
Разработка устава проекта
Шаг 1. Определите конечную цель.
Составьте список от 3 до 5 целей поменьше, которые нужно достигнуть в ходе проекта. Убедитесь, что они конкретные, измеримые, достижимые, актуальные и ограниченные во время — то есть соответствуют критериям SMART.
Проанализируйте, как проект может повлиять на бизнес-показатели организации.
Шаг 2. Создать организационную структуру.
Определите конечных пользователей, стейкхолдеров, спонсоров, проектного менеджера, участников проектного комитета и проектной команды. Теперь вы сможете создать организационную структуру для проекта.
В Worksection всех их можно внести учасниками или гостями (статус, удобный для заказчиков, спонсоров и стейкхолдеров) в проект.
Шаг 3. Подготовить план имплементации УП.
Перечислите этапы и процессы во время жизненного цикла проекта. Отметьте ключевые точки и зависимости между процессами. Составьте список с необходимыми ресурсами: оборудованием, ПО, материалами.
Шаг 4. Предусмотрите риски и проблемные моменты.
Если они возникнут, вы уже будете готовы и будете знать, как минимизировать их влияние.
3 главные причины, почему без устава ваш проект рискует провалиться
8 вопросов для создания более эффективного УП
Как в Worksection создать устав?
Далее установите приоритет задачи, назначьте ответственного за выполнение, укажите сроки и затраты.
Определите круг подписчиков для каждой из задач — кого-то она касается прежде всего, а кого-то наоборот мало интересует. При необходимости прикрепляйте файлы и устанавливайте метки для отслеживания выполнения.
Чтобы завершить создание задачи, нажмите «Создать задачу». Если нужно разбить задачу на несколько подзадач, вы можете сразу добавить в режиме «Пакетного добавления задач».
Вы можете настраивать вид задач в Worksection, сортировать их по приоритетности, ответственным лицам, меткам и др. Также удобно отслеживать, как продвигается выполнение задач в целом и какую часть из запланированного бюджета уже потрачено.
Пример устава проекта
Обоснование
Зачем инициирован проект, какие возможности он откроет для компании?
Корпоративная методология управления проектами: основные документы
В продолжение первой публикации “Как разработать корпоративную методологию управления проектами”- в данном материале мы рассмотрим основной документ выше упомянутой методологии – Положение «О корпоративной системе управления проектами» или Корпоративный стандарт по управлению проектами, а также шаблоны следующих рабочих документов проекта, рекомендованных PMI к разработке при управлении проектом:
КОРПОРАТИВНЫЙ СТАНДАРТ ПО УПРАВЛЕНИЮ ПРОЕКТАМИ
Мы предлагаем рассматривать Положение о КСУП или корпоративный стандарт по управлению проектами (далее – корпоративный стандарт) как документ верхнего уровня в структуре внутренней нормативной документации, регламентирующей управление проектами в компании.
Следует заметить, что в практике встречаются и другие трактовки корпоративного стандарта по управлению проектами.
В некоторых компаниях под корпоративным стандартом понимают совокупность документов, регламентирующих и обеспечивающих управление проектами.
В других – для управления проектами разрабатывают несколько корпоративных стандартов одного уровня, регламентирующих различные аспекты управления проектами. Такой подход, к примеру, был принят в отношении инвестиционных проектов в управляющей компании одной из известных финансово-промышленных групп.
Подходы, описанные во втором и третьем случае, по нашему мнению, имеют определенные недостатки.
Под корпоративным стандартом обычно понимается один документ. Поэтому подобное название для совокупности документов представляется не вполне корректным и может дезориентировать тех, кто занимается разработкой корпоративной методологии управления проектами.
Разработка нескольких корпоративных стандартов одного уровня для управления теми же инвестиционными проектами может привести к созданию фрагментарной методологии. В этом случае определенные процессы и процедуры управления проектами могут быть пропущены или описаны и регламентированы в разных форматах, разными средствами в соответствие с опытом и субъективными представлениями об управлении проектами, имеющимися о разработчиков документов. Интегрировать несколько разных стандартов в единую методологию будет весьма затруднительно.
Разработке корпоративного стандарта может предшествовать создание концепции управления проектами в компании.
Создавать концепцию целесообразно по той причине, что для успешной разработки и внедрения корпоративной методологии управления проектами необходимо, чтобы собственники и руководители высшего уровня договорились между собой и согласовали свое видение и свои требования и ожидания относительно КСУП. Концепция как раз и создает хорошую основу для согласования позиций и достижения принципиальных договоренностей между лицами, принимающими ключевые решения по управлению проектами в компании.
Предназначение корпоративного стандарта по управлению проекта, по нашему мнению, заключается в том, чтобы описать саму КСУП, принципы ее построения, основные элементы, а также подход к управлению проектами, принятый в компании.
В корпоративный стандарт целесообразно включать следующие разделы:
УСТАВ ПРОЕКТА (PROJECT CHARTER)
Устав проекта (рroject charter) – один из самых «мифологизированных» рабочих документов проекта. Краткость описания этого документа в основном стандарте PMI – PMBOK в редакциях 2000 и 1996 года, с лихвой окупается богатством интерпретаций предназначения и содержания данного документа как российскими, так и зарубежными экспертами в области управления проектами.
Если обобщить существующие в проектной практике точки зрения, то получится, что под Уставом проекта разные специалисты, в т.ч. ориентирующиеся на PMBOK, понимают:
Предназначение, содержание и порядок разработки и изменений Устава проекта в соответствие с новой редакции PMBOK от 2004 года описаны ниже. Примеры структур Уставов проектов из практики разных компаний приведены в Приложении к статье.
Предназначение документа: Устав проекта предназначен для определения проекта. На фазе инициализации, он включает в себя:
Когда разрабатывается документ: после заключения контракта (если заключается контракт с внешним контрагентом)
Кто разрабатывает документ: Устав проекта могут разрабатывать:
Кто утверждает документ: Устав проекта может утверждать:
Лицо, утверждающее Устав проекта, должно иметь полномочия по принятию основных решений по проекту, включая его финансирование.
Входы (исходные данные) для разработки документа:
Содержание документа: Устав проекта непосредственно включает в себя следующие данные или ссылки на соответствующие документы:
Порядок изменений документа: Команда проекта поддерживает Устав проекта в актуальном состоянии, получает обратную связь от участников проекта о необходимых улучшениях документа, контролирует изменения и выпускает релизы утвержденного документа.
ДОКУМЕНТ, ОПРЕДЕЛЯЮЩИЙ СОДЕРЖАНИЕ ПРОЕКТА (PROJECT SCOPE STATEMENT (preliminary and detailed)
Ниже описано предназначение, содержание и порядок разработки и изменений Документа, определяющего содержание проекта, в соответствие с новой редакции PMBOK от 2004 года. В этом и в следующих разделах статьи использованы оригинальные английские термины, т.к. использование их русских аналогов, как заметил один из моих коллег, «очень часто ведет в дебри».
Предназначение документа: PROJECT SCOPE STATEMENT (preliminary или предварительный) необходим для высокоуровневого определения проекта (что должно быть сделано) и включает в себя:
Когда разрабатывается документ: После утверждения Устава проекта.
Кто разрабатывает документ: PROJECT SCOPE STATEMENT (preliminary) могут разрабатывать:
Кто утверждает документ: PROJECT SCOPE STATEMENT (preliminary) может утверждать:
Входы (исходные данные) для разработки документа:
Содержание документа: PROJECT SCOPE STATEMENT (preliminary) включает в себя:
Порядок изменений документа: Команда проекта осуществляет дальнейшую разработку PROJECT SCOPE STATEMENT (preliminary), на этапе определения содержания проекта прорабатывает данный документ более детально (статус PROJECT SCOPE STATEMENT изменяется с preliminary на detailed), а также осуществляет контроль изменений документа.
ПЛАН УПРАВЛЕНИЯ ПРОЕКТОМ (PROJECT MANAGEMENT PLAN)
Ниже описаны предназначение, содержание и порядок разработки и изменений Плана управления проектом, в соответствие с новой редакции PMBOK от 2004 года.
Предназначение документа: На базе Плана управления проектом обеспечивается определение, интеграция и координация всех составных планов проекта. План управления проектом – основное средство о том, как должен выполняться, отслеживаться и контролироваться.
Когда разрабатывается документ: План управления проекта разрабатывается после утверждения Устава проекта и PROJECT SCOPE STATEMENT (preliminary). Если последние два документа не разрабатываются, то после сбора или приобретения соответствующей информации.
Кто разрабатывает документ: менеджер проекта или команда проекта с участием других заинтересованных лиц.
Кто утверждает документ: План управления проектом может утверждать:
Входы (исходные данные) для разработки документа:
Содержание документа: План управления проектом документирует:
План управления проектом может суммировать/объединять все отдельные планы проекта или некоторые из них:
Порядок изменений документа: Изменения Плана управления проекта проходят через процесс Интегрированного управления изменениями и могут быть связаны с модификациями, дополнениями и ревизиями проекта. При этом статус Плана меняется на обновленный (updated).
Ниже приведена схема формирования рассмотренных рабочих документов проекта на разных этапах его жизненного цикла. Все использованные английские термины были раскрыты ранее, за исключением одного – Subsidiary Plans. Под этим термином понимаются отдельные планы, которые могут обобщаться или объединяться в Плане управления проектом (СМ. предыдущий раздел).
А.Ю.Сооляттэ, партнер ИП «Finexpert.ru», адрес электронной почты –info@finexpert.ru.
Приложение
ПРИМЕРЫ УСТАВОВ ПРОЕКТОВ КОМПАНИЙ
Пример 1. УСТАВ ПРОЕКТА (международная компания, занимающаяся производством компьтерной техники, разработкой программного обеспечения и проектами в сфере системного интеграции).
Примечание: В материалах данной компании специально подчеркивается, что данный документ не является Планом проекта, хотя включает в себя даты, к которым нужно стремиться в рамках проекта.
Данный документ – Устав проекта – уточняется/изменяется и утверждается заново на каждой из стадий: на стадии предложения, на стадии исполнения (после подписания контракта).
СОДЕРЖАНИЕ:
1. Обзор Устава проекта
2. Организация проекта
2.1. Менеджер Проекта по интегрированию систем
2.2. Привлеченная команда по системному интегрированию
2.3. Роли и обязанности
2.4. Полномочный орган по финансированию Проекта
2.5. Комитет спонсоров Проекта
2.6. Комитет директоров Проекта
3. Краткое изложение требований по системному интегрированию
3.1. Обзор системного интегрирования
3.2. Определение потребности в системном интегрировании
3.3. Содержание и цели системного интегрирования
3.4. Факторы и риски, влияющие на системное интегрирование
4. Краткие сведения по Проекту
4.1. Описание
4.2. Процессы Проекта
5. Деятельность по интегрированию системы и поставляемые позиции
5.1.1. Работы Этапа I
5.1.2. Поставляемые позиции Этапа I
5.1.3. Работы Этапа II
5.1.4. Поставляемые позиции Этапа II
5.1.5.Работы этапа III
5.1.6. Поставляемые позиции Этапа III
5.1.7. Работы Этапа IV
5.1.8. Поставляемые позиции Этапа IV
5.1.9. Работы Этапа V
5.1.10. Поставляемые позиции Этапа V
6. Графики хода процессов
7. Документация
Пример 2. УСТАВ ПРОЕКТА (международная компания, занимающаяся разработкой и внедрением информационных систем)
СОДЕРЖАНИЕ:
1 ВВЕДЕНИЕ
1.1 НАЗНАЧЕНИЕ ДАННОГО ДОКУМЕНТА
1.2 ИЗМЕНЕНИЯ ДАННОГО ДОКУМЕНТА
2 ОПРЕДЕЛЕНИЕ ПРОЕКТА
2.1 НАЗНАЧЕНИЕ ПРОЕКТА
2.2 ЦЕЛИ ПРОЕКТА
2.3 НЕОБХОДИМЫЕ УСЛОВИЯ ДЛЯ ДОСТИЖЕНИЯ ПОСТАВЛЕННЫХ ЦЕЛЕЙ
3 РАМКИ ПРОЕКТА
3.1 ЛОГИЧЕСКИЕ РАМКИ ПРОЕКТА НА МОМЕНТ ЕГО НАЧАЛА
3.2 ВРЕМЕННЫЕ РАМКИ ПРОЕКТА
4 ОРГАНИЗАЦИЯ И УПРАВЛЕНИЕ ПРОЕКТОМ
4.1 ОРГАНИЗАЦИОННАЯ СТРУКТУРА ПРОЕКТА
4.2 РАСПРЕДЕЛЕНИЕ РОЛЕЙ УЧАСТНИКОВ ПРОЕКТА
4.2.1 Спонсор Проекта
4.2.2 Управляющий Совет
4.2.3 Председатель Управляющего Совета
4.2.4 Руководители Проекта
4.2.5 Группа внедрения
4.2.6 Состав группы внедрения
4.3 ДОКУМЕНТООБОРОТ ПРОЕКТА
4.3.1 Общие документы
4.3.2 Отчетные документы
4.3.3 Рабочие документы
4.3.4 Периодичность подготовки отчетной документации
4.4 ПРОЦЕДУРА РЕШЕНИЯ ПРОБЛЕМ
4.5 ПОДХОД К УПРАВЛЕНИЮ ИЗМЕНЕНИЯМИ РАМОК ПРОЕКТА
5 ЗАВЕРШЕНИЕ ПРОЕКТА
ПРИЛОЖЕНИЕ 1 – ДЕКЛАРАЦИЯ ЦЕЛЕЙ ВНЕДРЕНИЯ ИИСУ НА ОАО «ХХХ»
ПРИЛОЖЕНИЕ 2 – СПИСОК ФУНКЦИЙ АВТОМАТИЗИРУЕМЫХ ПОДРАЗДЕЛЕНИЙ.
ПРИЛОЖЕНИЕ 3 – ФОРМА РЕГИСТРАЦИИ ПРОБЛЕМЫ
ПРИЛОЖЕНИЕ 4 – ЖУРНАЛ РЕГИСТРАЦИИ ПРОБЛЕМ
ПРИЛОЖЕНИЕ 5 – ИНДИВИДУАЛЬНЫЙ ОТЧЕТ О ПРОРАБОТАННОМ ВРЕМЕНИ
ПРИЛОЖЕНИЕ 6 – ОТЧЕТ РУКОВОДИТЕЛЯ ПРОЕКТА
ПРИЛОЖЕНИЕ 7 – РЕГУЛЯРНЫЙ ОТЧЕТ О СОСТОЯНИИ ПРОЕКТА
ПРИЛОЖЕНИЕ 8 – ОТЧЕТ О РЕЗУЛЬТАТАХ ЭТАПА.
Пример 3. УСТАВ ПРОЕКТА (Российская компания – системный интегратор)
СОДЕРЖАНИЕ
1. ПРОФИЛЬ КОМПАНИИ
1.1. СФЕРА ДЕЯТЕЛЬНОСТИ
1.2. АДРЕС КОМПАНИИ
1.3. КОНТАКТНЫЕ ЛИЦА
1.4. СОТРУДНИКИ
2. ЦЕЛИ И ОПРЕДЕЛЕНИЕ ПРОЕКТА
3. ПЛАН ПРОЕКТА
4. СТРУКТУРА ПРОЕКТА
4.1. ОРГАНИЗАЦИОННАЯ СТРУКТУРА ПРОЕКТА
4.2. КЛЮЧЕВЫЕ РОЛИ И ОТВЕТСТВЕННОСТЬ
4.3. ПРОЦЕДУРЫ ВСТРЕЧ И ПОДГОТОВКИ ОТЧЕТОВ О СОСТОЯНИИ ПРОЕКТА
5. РИСКИ ПРОЕКТА
6. ПЛАН ОБУЧЕНИЯ ПОЛЬЗОВАТЕЛЕЙ
7. КОНТРОЛЬ ИЗМЕНЕНИЙ И ПРОЦЕДУРЫ ПРИЁМКИ РАБОТ
7.1. УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ
7.2. ПРОЦЕДУРЫ ТЕСТИРОВАНИЯ И ПРИЕМКИ РАБОТ
7.3. СТАТУС И СОСТАВ ПРИЕМОЧНОЙ КОМИССИИ
7.4. ПЕРЕДАЧА В ОПЫТНУЮ ЭКСПЛУАТАЦИЮ
8. ЛИСТ СОГЛАСОВАНИЙ
ПРИЛОЖЕНИЯ