Контроль исполнения документов. 5

 

ФЕДЕРАЛЬНОЕ АГЕНСТВО СВЯЗИ

Государственное образовательное  учреждение

высшего профессионального  образования

 

Московский  технический университет связи  и информатики

Кафедра философии и истории

 

 

 

 

 

КОНТРОЛЬНАЯ РАБОТА

 

 

По дисциплине 

 

♦♦Управление проектами♦♦

(Матрица ответственности в управлении проектами.

Процессы завершения проекта.)

 

 

 

 

 

 

                                  Выполнила: Скоробогатова О.Д.

                                                                  студентка 2 курса ЗОТФ

                                                    группа БЭМ1151

                                                                                  студенческий билет ЗБЭМ 11008

 

                           Преподаватель:  Т.В. Сидорова

 

                                                            Москва,2012г.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Матрица ответственности

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

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

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

После этого остается продумать  и письменно закрепить роль каждого  участника или группы лиц:

 О – ответственный исполнитель,

 С – согласовывает решение, 

И – должен информироваться,

 К – должен оказывать консультационные услуги,

У – право окончательного утверждения.

 

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

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

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

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

 

Построение матрицы ответственности

  1. Перечислить основные работы проекта.

По вертикали в матрице отражаются только основные работы проекта (не ниже уровня 2-3 ИСР), но с достаточной степенью детализации для обеспечения возможности указывать разные роли, необходимые для выполнения этих работ. Когда речь идет о крупных проектах и программах, может возникнуть необходимость разработать несколько матриц ответственности с различной степенью детализации.

  1. Перечислить группы/роли внутри проектной команды.

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

  1. Закодировать матрицу ответственности.

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

На коды, используемые в матрице ответственности, каких-либо ограничений не существует, но наибольшее распространение получил метод RACI (Responsible (R), Accountable (A), Consulted (C), Informed(I)), в котором приведено описание соответствующих кодов.

  1. Инициировать использование матрицы и включить процедуру использования матрицы ответственности в документ "План управления проектом".

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

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

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

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

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

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

 

Спонсор проекта

Директор проекта

Менеджер проекта

Команда проекта

Руководящий совет

Устав проекта

У

У

C

Р

У

План коммуникаций

У

Р

C

Р

У

Спецификация требований

У

Р

Р

C

У

Статус - отчеты

Р

Р

C

Р

Р


  • "У" означает, что данная роль утверждает результат.
  • "Р" означает, что данная роль рассматривает результат.
  • "С" означает, что данная роль создает результат. Как правило, только один человек отвечает за создание результата, хотя участвовать в этом может множество людей.

 Устав проекта создается  менеджером проекта, утверждается  спонсором проекта, директором  проекта и руководящим советом,  а также рассматривается командой  проекта. Спецификация требований  создается командой проекта, рассматривается  менеджером и директором проекта,  а утверждяется спонсором проекта и руководящим советом.

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

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

  • У - утверждает результат
  • Р - рассматривает результат (и дает отзыв)
  • C - создает результат (может быть C(1) - основной, C(2) - заместитель)
  • П - Помогает (принимает участие) в создании
  • И - Информируется о готовности результата
  • О - Обслуживает результат (например, администратор хранилища документов или конфигурационный менеджер)

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

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

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

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

Решив данную задачу, можно стимулировать  повышение качества управления посредством  обоснованного премирования. Может  оказаться целесообразным, чтобы  премию за качество стратегического  управления автоматически   начисляла   S'BM.

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

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

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

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

Матрица ответственности может  называться также:

•           матрицей распределения ответственности;

•           матрицей назначения ответственности;

•           таблицей ответственности;

. • схемой распределения ответственности.

Среди англоязычных наименований наиболее распространенными являются:

•           Responsibility Assignment Matrix (матрица назначения ответственности);

       

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

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

Степеней ответственности может  быть много. Например, РМВОК определяет 4 вида ответственности:

1. Ответственный (О)- полностью отвечает за выполнение задачи и вправе принимать решения по способу ее реализации

2. Исполнитель (И) - исполняет задачу, но в обшем случае, не несет ответственности за способ ее решения.

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

4. Наблюдатель (Н) - то же самое что и консультант, но ответственности не несет.

Матрица ответственности выглядит таким образом:

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

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

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


 

 Процессы  завершения проекта

В самом общем виде методология  проектного менеджмента определяет и формализует процедуры, методы и инструменты реализации пяти групп  управленческих процессов (согласно стандарту PMBOK Guide):

  • Инициации проекта
  • Планирования
  • Организации исполнения;
  • Контроля исполнения;
  • Завершения проекта.

Группы процессов управления проектами  
(согласно стандарту PMBOK Guide 3-d Edition)

В своей работе я остановлюсь  на одном из пяти процессов, а именно, на процессе завершения проекта.

Завершение проекта – процесс формального окончания работ и закрытия всего проекта..

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

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

Не допускается изменение формата  и имен файлов, содержащих перевод.

1. 

При окончательной сдаче не допускается  разбиение исходного файла на части.

2. 

Сдаваемый файл должен быть полностью  переведен. Для каждого сегмента допускается только один вариант  перевода. Одновременное наличие  в тексте нескольких вариантов, выбор  из которых оставлен на усмотрение редактора, равно как и отсутствие перевода, категорически запрещено. Не допускается также оставлять  в тексте области, выделенные заливкой, а также любые иные пометки  для редактора. В целях комментирования  необходимо использовать файл QueryLog.xls (см. пункт 5 раздела 2).

3. 

Текст должен предоставляться переводчиком в виде, готовом к отправке заказчику.

4. 

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

Порядок проведения расчетов

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

Способ и форма расчета определяется до начала сотрудничества.

 Работа над отзывами заказчика

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

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

Штрафные санкции

 Отказ от выполнения проекта  после подтвержденияОтказ переводчика от выполнения подтвержденного проекта негативно влияет на перспективы работы с бюро. При отказе переводчика от подтвержденного проекта бюро имеет право удержать часть невыплаченного переводчику гонорара для покрытия своих издержек.

 

При принятии решения о наложении  штрафа учитывается объем сданного переводчиком материала (если применимо).

 Срыв срока сдачи (промежуточной  сдачи) проекта

В случае срыва сдачи проекта  менеджер проектов вправе наложить следующий  штраф (от стоимости проекта) на переводчика:

• 

15% при задержке до 1 час;

• 

25% при задержке до 3 часа;

• 

50% при задержке до 6 часов.

 

При задержке более чем на 6 часов  сумма гонорара остается на усмотрение менеджера.

Невыход на связь во время сдачи/промежуточной  сдачи проекта

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

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

Некачественно выполненная работа

Переводчик отвечает за качество предоставляемого им перевода. В своей работе он должен руководствоваться:

• 

указаниями менеджера проекта, присылаемыми в задании на перевод;

• 

требованиями заказчика в соответствии с принципом “Клиент всегда прав” (т.е. не зависимо от личного отношения  переводчика к этим требованиям);

• 

положениями документа «Требования  к переводу», разработанного нашим  бюро.

 

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

 

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

 

Завершение проекта может включать следующие процедуры:

• Сдача результатов проекта Заказчику;

• Заключительная оценка финансовой ситуации (постпроектный отчет);

• Заключительный отчет по проекту и проектная документация;

• Список открытых вопросов и заключительных работ;

• Разрешение всех спорных вопросов

• Роспуск команды проекта

Документирование и анализ опыта  выполнения данного проекта