Конспект. Тема Целеполагание в проектах. Календарное планирование и организация системы контроля проекта
 Скачать 2.44 Mb.
|
|
Матрица ответственности. В отечественной практике этот инструмент часто звучит как матрица распределения ответственности. Под МО в PMI-руководстве понимается некая таблица, в которой показаны ресурсы, назначенные для каждого пакета работ. В ней отображаются связи между членами команды и этапами работ. Для заполнения МО традиционно применяется методика RAСI. Это аббревиатурное название, сформированное по первым буквам слов: «Исполнитель» (Responsible), «Ответственный» (Accountable), «Консультант» (Consult before doing), «Наблюдатель» (Inform after doing). Рис. 3.9. Пример матрицы RACI из Руководства PMBOK В зависимости от масштаба проекта PMBOK допускает использование МО на различных уровнях с разной степенью проработки ответственности членов рабочей группы. Если мы рассматриваем МО высокого уровня, то для построения матрицы привлекаются группы и подразделения команды с одной стороны и крупные компоненты ИСР – с другой. Напротив, МО низкого уровня «спускаются» до детализации распределения ответственности конкретных участников команд вплоть до уровня операций. Российскую практику проектирования часто отличает расширение вариантов ответственности вплоть до включения в МО также и полномочий. Это вносит разбалансировку в матрицу. Иллюстрацию такого подхода вы можете увидеть ниже. Рис. 3.10. Пример матрицы ответственности инвестиционного проекта на территории России Подзадачи и ответственность Предыдущий пример наглядно демонстрирует ситуацию размытия фокусов на ответственности. Как избежать подобной ситуации? Вспомним, коллеги, подраздел, посвященный задачам управления. В нем мы разобрали важную категорию управления – «ответственность». Тогда мы установили, что ответственность ресурса предполагает его право принять и обязанность выполнить задачу, не ссылаясь ни на какие препятствия. Позвольте напомнить пример красноярского охотника, который взялся за задачу доставить к сроку шкурки белок, битых в глаз, но под условием, что число их будет не более 45 вместо 100. Таково было его правило: браться только за то, что он способен сделать реально. Ответственным ресурсом уникальной проектной задачи выступает менеджер. В момент планирования проекта его руководитель обязан обеспечить декомпозицию результата на подзадачи, последовательное выполнение которых автоматически приводит к решению ключевой задачи. Такую декомпозицию целесообразно производить коллегиально, привлекая членов команды управления проектом к работе методом мозгового штурма. Результатами его должны явиться иерархическая структура работ, план по вехам. Обычно состав формулировок элементов таблицы соответствует функциональной доктрине управления: • разработка ТЗ; • развертывание прототипа системы; • опытная эксплуатация и т.п. Гораздо действеннее получается, если применять методы управления от задач. Предлагаю вашему вниманию пример такой декомпозиции. Рис. 3.11. Схема декомпозиции проектной задачи по внедрению продукта Y Данный пример показателен. Естественно, что за задачу верхнего уровня отвечает менеджер. И очевидно, что управление проектом устанавливает разделение ответственности по декомпозированным подзадачам между членами команды. Таким образом, закономерно созревает логика составления такой таблицы, как матрица ответственности. Ее построение начинается с формулирования задач. Оптимален так же лаконичный подход к применению матричной модели, потому что обязательность как синоним предмета нашего исследования – это еще и состояние человека: либо она есть, либо ее нет. И самое главное, такое состояние не может быть распределено между несколькими людьми. В целях управления оно может иметь только единственного носителя. В противном случае, ответственность в той или иной степени утрачивается. Наш пример декомпозиции диктует следующую форму матрицы. Рис. 3.12. Вариант упрощенной матрицы ответственности Ответственность и полномочия: как избежать ошибок? Построение МО проекта требует соблюдения важных правил: 1. Работать над МО всей командой, стараясь заполнить ее в единственную сессию. 2. Сначала заполнять все ячейки с ответственностью, исключить ситуацию, когда остаются строки без символа «О». 3. Придерживаться методики RACI, избегая расширения состава полномочий из разряда «Исполнитель», «Согласование», которые, по сути, не несут в содержании ответственности. 4. Исключить ситуацию пустых столбцов в МО. 5. Составить несколько вариантов МО, начиная с верхнего уровня и соблюдая принцип лаконичности. Если не учитывать специальных правил, изложенных выше, легко допустить ошибки, которые потом ухудшат возможности контроля, снизят эффективность управления проектом. Чтобы избежать такой ситуации, лучше сразу в ходе работы над МО, контролировать себя на возможность ошибиться. Построение МО может сопровождаться типичными ошибками: 1. Допустить ситуацию, когда в одной ячейке проставлено два символа. 2. Перегрузить МО символами, тем самым девальвируя ее работопригодность. 3. После утверждения МО «положить ее под сукно» и забыть, тем самым исключив смысл применения МО в качестве инструмента прямого контроля промежуточных результатов и спроса с ответственных ресурсов по задачам проекта. Вехи проекта. Веха проекта контрольная событие проекта, ключевой результат этапа проекта, например, завершение какого-либо ключевого мероприятия проекта, подписание важных документов или любые другие значительные действия, предусмотренные в проекте. Давайте рассмотрим четыре примера того, как вехи могут работать на ваш коллектив. 1. Выделяйте критически важные задачи. Эти задачи непременно должны быть выполнены к определённому сроку, иначе проект застопорится. К ним можно отнести согласование творческой концепции для маркетинговой кампании. 2. Выделяйте завершение этапа или стадии. Это может быть завершение большого объёма работ, например составление бюджетных смет для каждого подразделения компании в целях планирования проекта. 3. Сделайте центром внимания важное событие или результат. К подобным событиям или результатам можно отнести расширение офисного пространства компании и начало перемещения туда сотрудников. 4. Сконцентрируйтесь на достижении целей и ключевых результатов. К подобным целям и ключевым результатам можно отнести получение запланированного квартального объёма выручки от недавно запущенного продукта. Как бы то ни было, вам следует принимать во внимание частые ошибки, с которыми сталкиваются коллективы, когда только начинают пользоваться вехами: • Создание слишком большого количества вех. Количество нужных вам вех зависит от размера и масштабов инициативы. Избегайте ориентации на фиксированное количество вех только потому, что вам «так нравится». Вместо этого обращайте внимание на главные задачи, которые необходимо выполнить коллективу, чтобы успешно завершить проект. • Использование вех в качестве задач. Вехи должны представлять момент времени. Задачи же используются, чтобы отслеживать работу по достижению вех. Поэтому вехами следует обозначать время, когда должна быть завершена некая группа задач. • Отделение вех от остальной работы. Лучший способ соблюдать сроки и успешно сдавать проекты это управление всей своей работой из единого центра. Проверьте, позволяет ли ваше средство управления проектами работать с задачами, расставлять вехи и получать наглядное представление о проекте в одном месте. Сетевая модель. Сетевой график проекта раскрывает внутренние связи проекта, служит основой для календарного планирования работ и использования оборудования, облегчает взаимодействие менеджеров и исполнителеей. Сетевая модель отображает взаимосвязи между операциями (работами, задачами) и порядок их выполнения (отношение упорядочения или следования). Для представления операции используется стрелка (ориентированная дуга), направление которой соответствует процессу реализации проекта во времени. Отношение упорядочения между операциями задается с помощью событий. Событие определяется как момент времени, когда завершаются одни операции и начинаются другие. Начальная и конечная точки любой операции описываются парой событий, которые называют начальным событием и конечным событием. Метод критического пути. Метод критического пути (МКП) – это способ, применяемый для нахождения минимальной продолжительности мероприятия, достижения допустимой гибкости в рамках логики календарной модели. Критический путь проекта может быть рассмотрен применительно к табличной форме представления расписания, использован для анализа диаграммы Ганта (линейной диаграммы) или в отношении сетевого графика. Поскольку метод обладает свойством визуальной наглядности, наибольшее применение он находит для оптимизации сетевого графика. МКП формулирует ряд требований к календарной модели. 1. Все работы к моменту применения метода должны быть определены, их число, содержание должны быть точно установлены. 2. Известна предполагаемая длительность выполнения каждой операции. 3. Основным видом взаимосвязи между операциями является отношение предшествования, то есть начало последующей работы формируется в связи с окончанием предыдущей. Критический путь представляет собой совокупность последовательно выполняемых операций, которая характеризуется максимальной продолжительностью из всех возможных путей в расписании. На данном пути общие временные резервы отсутствуют. Любые работы, лежащие на нем, называются операциями критического пути. В условиях сетевого графика может быть рассмотрено несколько параллельно намеченных последовательностей для целей нахождения резервов оптимизации календарной модели. Расчет критического пути выполняется для целей: • минимизации общей продолжительности мероприятия в условиях ограничений по срокам работ; • ранжирования операций в любой момент реализации проекта в условиях решения общей задачи мероприятия в минимальные сроки; • информирования руководителя проекта об ограничивающем факторе критического пути, чтобы оптимизировать операции, влияющие на общую планируемую продолжительность. Иными словами, анализ на основе МКП показывает, какие задачи и соответствующие им работы влияют на срок окончания проекта. Он позволяет менеджеру принять взвешенные решения по сжатию расписания. Анализ параметров операций сетевого графика дает возможность найти резервы некритических задач и использовать их при выравнивании загрузки ресурсов, используя следующий алгоритм МКП. 1. Прямой анализ последовательностей работ, вычисление ранних начал и окончаний операций. 2. Обратный анализ последовательностей, расчет поздних окончаний и поздних начал выполнения работ. 3. Вычисление временных резервов для каждой из работ сетевого графика. 4. Формирование плана мероприятий по оптимизации расписания. Расчёт временных параметров по схеме «работа –дуга» и «работа- вершина». Разберем другие основные понятия сетевой модели проекта. 1. Работа – часть производственного или проектного процесса, имеющая начало и окончание в форме количественно описываемого результата, требующая затрат времени и других ресурсов. Работа отражается на диаграмме в форме однонаправленной стрелочной линии. Формой работ мы можем считать операции, мероприятия и действия. 2. Событие – факт завершения работ, результат которых необходим и достаточен для начала реализации следующих операций. Вид события на модели отражается в форме кружков, ромбиков (вехи) или других фигур, внутри которых помещается идентификационный номер события. 3. Веха представляет собой работу с нулевой продолжительностью и обозначает важное, значимое событие в проекте (например, утверждение или подписание документа, акт окончания или начала проектного этапа и т.п.). 4. Ожидание – это процедура, которая не потребляет никаких ресурсов, кроме затрат времени. Отображается как линия со стрелкой на конце с отметкой длительности и указанием наименования ожидания. 5. Фиктивная работа или зависимость – вид технологической и организационной связи работ, не требует никаких усилий и ресурсов, в том числе затрат времени. На сетевой диаграмме показывается как пунктирная стрелка. Варианты связей и отношение предшествования Сетевые методы планирования строятся по моделям, в которых проект представляется как целостная совокупность взаимосвязанных работ. Данные модели во многом формируются типом и видом связей между операциями реализации проекта. С позиции типа различаются жесткие, мягкие и ресурсные связи. Видовое различие взаимосвязанности операций основано на отношения предшествования. Рассмотрим основные типы связи. 1. Мягкие связи. Им соответствует особая, «дискреционная» логика, дающая «мягкую» основу для выбора операций к размещению на диаграмму, диктуемого технологией. В то время как технология длительный период развивалась на протяжении многих циклов, вырабатываются правила делового оборота, не требующие дополнительной фиксации и планирования. Это экономит время, место модели, стоимость и не требует дополнительного контроля со стороны PM. Поэтому менеджер проекта сам решает, нужна ему такая выделенная операция, или нет. 2. Жесткие связи. Данный вид связей основан на технологической логике. Они предписывают выполнение конкретных действий строго после других, что сообразно с процессуальной логикой. Например, наладку оборудования можно осуществлять только после его монтажа. Тестирование недочетов технологии допустимо проводить, если сдача ее в опытную эксплуатацию произошла и т.д. Иными словами, принятая технология (неважно, в какой сфере она реализуется) жестко навязывает последовательность мероприятий и событий проекта, что и обуславливает соответствующий тип связи. 3. Ресурсные связи. В условиях назначения на один ответственный ресурс нескольких задач возникает его перегруженность, что может привести к удорожанию проекта. За счет подведения под менее критичную задачу дополнительного ресурса этого можно избежать, и такие связи называются ресурсными. В момент формирования расписания проекта сначала применяются жесткие, а затем – мягкие связи. Далее, по необходимости, некоторые мягкие связи подлежат сокращению. Благодаря этому может быть достигнуто некоторое сокращение общей длительности проекта. В условиях перегруженности некоторых ответственных ресурсов из-за параллельных работ допустимо разрешение возникших конфликтов введением ресурсных связей. Однако следует контролировать, чтобы новые связи не привели к значительным изменениям общего плана. Сопряженные работы как некая последовательность проектной задачи связаны друг с другом. Назовем их операциями А и В. Введем понятие отношения предшествования, которое рассматривается как некое ограничение на сроки и общую продолжительность, так как операция В не может начаться до момента окончания операции А. Это означает, что В и А связаны отношением простого предшествования, при этом вовсе не обязательно, чтобы В начиналось одномоментно с окончанием А. Например, отделочные работы начинаются после возведения крыши дома, но это не означает, что выполняться они должны в тот же момент, когда наступит указанное событие. Сетевое планирование и управление (СПУ) предполагает два варианта построения сетевой диаграммы проекта: «дуга – работа» и «вершина – работа». При первом варианте отображения диаграммы реализуются метод критического пути и метод PERT. Метод имеет и иное название – «вершина – событие», что, по сути отражает другую сторону единого содержания. В англоязычной интерпретации данный вариант построения сетевой модели по аббревиатуре называют АоА (Activity on Arrow Diagramming). Доминирующее место в методе занимают события проекта. События различают трех видов: • начальное событие; • промежуточное событие; • конечное событие. Устройство проектной задачи таково, что в процессе ее реализации место есть только одному начальному и одному конечному событию. До начального события и после конечного события работы не выполняются. В момент конечного события проект считается завершенным. До наступления промежуточного события все входящие операции должны быть выполнены. Оно дает старт всем исходящим из него операциям. Фиктивные работы применяются после работ, если неизвестно, какая из них окажется последней. Рис. 3.13. Пример сетевой диаграммы метода «дуга – работа» Приведем правила построения сетевой модели. ПРАВИЛО 1. Каждая операция в сети представляется одной дугой (стрелкой). ПРАВИЛО 2. Ни одна пара операций не должна определяться одинаковыми начальным и конечным событиями. Возможность неоднозначного определения операций через события появляется в случае, когда две или большее число операций допустимо выполнять одновременно. Чтобы исключить такую ситуацию вводится фиктивная операция. Рис. 3.14. Варианты введения фиктивной операции Рис.3.14(б) иллюстрирует различные варианты введения такой фиктивной операции D. В результате операции A и B определяются теперь однозначно парой событий, отличающихся либо номером начального, либо номером конечного события. Заметим, что фиктивные операции не требуют затрат ни времени, ни ресурсов. Фиктивные операции позволяют также правильно отображать логические связи, которые без их помощи нельзя задать на сети. Предположим, что в некотором проекте операции A и B должны непосредственно предшествовать C, а операции Е непосредственно предшествует только В. На рис.3.15. (а) эти условия отражены неверно, так как, хотя упорядочения между А, В и С показаны правильно, из этого фрагмента следует, что операции Е должны непосредственно предшествовать обе операции А и В. Правильное представление указанных условий дает фрагмент (б), в котором используется фиктивная операция D. Поскольку на операцию D не затрачиваются ни время, ни ресурсы, заданные отношения упорядочения выполняются. Рис.3.15. Отображение логических взаимосвязей при помощи фиктивных операций ПРАВИЛО 3. При включении каждой операции в сетевую модель для обеспечения правильного упорядочения необходимо дать ответы на следующие вопросы. а) Какие операции необходимо завершить непосредственно перед началом рассматриваемой операции? б) Какие операции должны непосредственно следовать после завершения данной операции? в) Какие операции могут выполняться одновременно с рассматриваемой? ПРИМЕР: Постройте сетевую модель, включающую операции A, B, C ,..., L, которая отображает следующие отношения упорядочения. 1. А, В и С исходные операции проекта, которые можно начинать одновременно. 2. А и В предшествуют D. 3. B предшествует E, F и H. 4. F и C предшествуют G. 5. E и H предшествуют I и J. 6. C, D, F и J предшествуют K. 7. K предшествует L. 8. I, G и L завершающие операции проекта. Сеть, соответствующая этим отношениям упорядочения, приведена на рис.3.16. Рис.3.16 (а). Графическое отображение сетевой модели Фиктивные операции D1 и D2 введены для того, чтобы правильно отразить отношения следования. Операция D3 использована для однозначного определения операций E и H по конечным событиям. |