Отправляет email-рассылки с помощью сервиса Sendsay

Совет недели менеджеру проекта

Подписаться Бесплатная «Серебряная» новостная рассылка Подписчиков 398 RSS
←   Июнь 2011   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


За последние 60 дней ни разу не выходила


Сайт рассылки: http://tenstep.com.ua/open/miscpages/94.4Sign-Up.htm
Открыта: 18-06-2008

Автор
TenStep Inc.

Статистика

398 подписчиков
0 за неделю
←   Все выпуски   →

Совет недели менеджеру проекта: Дата завершения проекта


Содержание рассылки формируется из материалов Процесса Управления Проектами TenStep Project Management ProcessTM, с которыми можно познакомиться ближе на сайтах www.TenStepRussia.ru и www.TenStep.com.ua.

ТенСтеп расширил свое признание в PMI

Пройдя очередной аудит PMI, TenStep подтвердил свой статус зарегистрированного поставщика обучения (PMI R.E.P.) на период до 2013 года, а также зарегистрирован PMI как поставщик консталтинговых услуг (RCP) по управлению проектами.

Являясь разработчиком одной из наиболее популярных гибких методологий управления проектами на основе стардарта PMI "PMBOK® Guide", TenStep в апреле и мае текщего года подтвердил соответствие критериям PMI, предъявляемым к поставщикам обучения и консалтинга в области управления проектами. В рамках стартовавшей в апреле программы PMI Registered Consultant Program, TenStep был включен в реестр RCP под номером 6.

Пройдя эти шаги, мы в очередной раз подтвердили высокое качество продуктов и услуг ТенСтеп, которые доступны нашим клиентам в 35 странах мира.

Подробнее о наших услугах >>>
Подробнее о нашем обучении >>>

Присоединяйтесь к бесплатному вебинару

27 июня TenStep проводит бесплатный вебинар по сбору требований к проекту (The TenStep Approach for Gathering Business Requirements).

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

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

Зарегистрироваться можно здесь >>>.


Поделитесь этим письмом с друзьями. Адрес формы для подписки на еженедельную рассылку: http://www.TenStepRussia.ru/open/miscpages/94.4Sign-Up.htm

Даты начала и завершения проекта

(Первая часть статьи находится в архиве рассылки)

Даты завершения проекта

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

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

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

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

Далее приведены несколько распространенных подходов к определению даты завершения проекта.

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

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

Интересные ссылки:

По управлению проектами - Кейс: управление ожиданиями заинтересованных сторон - http://yplakhov.blogspot.com/2010/02/blog-post.html
Интересная/забавная - StockTwits - http://stocktwits.com

В избранное