Практика ведения проектов в сфере информационных технологий собственными силами в сложных условиях
Классическая теория управления проектами и большинство известных методик базируются на том, что для успеха проекта нужно создать определенные (благоприятные) условия. А если создать их нельзя, то от проекта лучше отказаться. Но что делать, когда условия для проекта неблагоприятные, а отказаться от него невозможно?
Именно для таких условий предназначены рекомендации, которые мы даем в этом цикле статей. Первая статья цикла вышла в №12/2008. Во второй части речь пойдет об организации управления проектом.
Часть 2. Организация управления проектами
Подходы к управлению проектами
Прежде всего давайте поговорим об изменении подходов к управлению проектами. На рис. 1 представлена схема типичной организации такого управления. Согласно этой схеме на стороне заказчика ключевые роли в проектном управлении играют спонсор проекта и менеджер проекта.
• Спонсором проекта может быть отдельный человек или целый комитет, в ведении которого находится бюджет проекта. Спонсор обеспечивает организационную сторону проекта и подтверждает правильность его целей.
•Менеджер проекта со стороны заказчика назначается в том случае, если ведение проекта требует ежедневного управления. В круг его обязанностей входит предоставление ресурсов, разрешение проблем и отслеживание состояния работ.
Со стороны исполнителя ключевые роли играют бизнес-менеджер и менеджер проекта.
• Бизнес-менеджер несет ответственность за успешное выполнение проекта. Кроме того, он представляет исполнителя в договорных отношениях с заказчиком.
• Менеджер проекта — это роль, на которой в конечном счете лежит ответственность за успех или неудачу. Он управляет такими аспектами, как сроки, стоимость, область применения и качество работ с целью удовлетворения ожиданий заказчика и достижения бизнес-целей исполнителя.
Такая схема предполагает активное участие в проекте внешней компании-исполнителя и разделение ею ответственности за успех/неудачу проекта. Однако в неблагоприятных условиях ответственность за внедрение вынужден брать на себя заказчик, то есть предложенная схема должна измениться. Прежде всего — заказчик и исполнитель должны поменяться местами.
У заказчика, как правило, нет достаточного количества людей, чтобы выделить для них отдельные роли. Поэтому роли в команде поддержки управления проектом сокращаются, а функции перераспределяются (на рис. 1 пунктирными линиями отображена передача функций и полномочий).
Кроме того, несколько изменяется понимание ключевых ролей в управлении проектом. В нашем понимании менеджер проекта — это не роль, а специальность (project manager — специалист по управлению проектами). В России существует приблизительный аналог — главный инженер проектов.
Гораздо шире становятся функции координатора проекта (наименование роли остается таким же): это специалист по управлению проектами. Координатор осуществляет оперативное управление ходом проекта согласно проектным документам, которые приняты управляющим советом или руководителем проекта. Функция координатора исключительно важна, но объективно конфликтна, поскольку по одну сторону от него находится высшее руководство, которое, как правило, недовольно ходом проекта, а по другую — пользователи и средний менеджмент, которых заставляют выполнять дополнительную работу (особенно на этапе опытной эксплуатации, когда необходим двойной ввод), менять привычную методологию, приемы и вообще нарушают сложившийся уклад жизни.
Менеджер проекта (со стороны исполнителя) в нашем понимании — это руководитель группы внешних консультантов. Далее мы будем рассматривать схему организации проектов силами заказчика (рис. 2) с указанным выше изменением терминов.
Организационные структуры управления проектами
Согласно PMBOK выделяются следующие виды организационных структур управления проектами:
- линейно-функциональная;
- проектная;
- матричная.
В области ИТ линейно-функциональная схема используется для мини-проектов, связанных с модернизацией автоматизированных систем и внесением в них изменений. Проектная структура применяется разработчиками ПО, к которым службу АСУ предприятия можно отнести с большой натяжкой. Матричная структура отражает закрепление в механизме проектного управления двух направлений руководства:
- вертикальное направление — управление функциональными и линейными структурными подразделениями компании;
- горизонтальное направление — управление отдельными проектами, программами, для реализации которых привлекаются человеческие и иные ресурсы различных подразделений компании.
В зависимости от типа взаимосвязей различают слабую и сильную матрицы. В слабой матрице горизонтальное направление руководства выражено слабо и реализуется секретарем проекта. Как правило, это сотрудник одного из функциональных подразделений, которому поручается координировать потоки информации между членами команды, вести протоколы совещаний.
Сильная матрица предполагает наличие координатора (менеджера) проекта, у которого есть право напрямую отдавать распоряжения и требовать отчетности от сотрудников функциональных подразделений, входящих в состав команды управления проектом. Члены команды управления проектом не выводятся из состава своих функциональных подразделений, но «откомандировываются» в команду на полную или частичную занятость. Секретаря проекта может и не быть, тогда его функции выполняет координатор.
В табл. 1 приводятся принципы выбора организационных структур проекта и соответствующие примеры из области ИТ.
Сильный и слабый руководители проекта
Для структурирования типов управления проектами в неблагоприятных условиях имеет смысл ввести понятие «сильного» и «слабого» руководителя. Надо сказать, что в PMBOK есть понятие «полномочия менеджера проекта», но оно недостаточно конкретно. По моему опыту в реальной жизни наблюдается два ярко выраженных случая, которые мы и называем «сильным» и «слабым» руководителем проекта.
Наименования «слабый» и «сильный» руководитель не относятся к личным качествам руководителя, а определяют уровень его полномочий. У сильного руководителя есть мощный административный ресурс, а у слабого его нет. Кроме того, особенностью сильного руководителя является, как правило, заинтересованность в результатах проекта (проект находится в сфере его деятельности), а также возможность влиять на его финансирование. Соответственно у слабого руководителя эти возможности отсутствуют. Типичным представителем слабого руководителя является начальник ИТ-службы или высокопоставленный, но незаинтересованный руководитель.
На рис. 3, 4, 5 изображены схемы матричных оргструктур, причем выделяются две формы управления слабой матрицей. В случае «слабого» руководителя проекта (рис. 3) управление членами проектной команды осуществляется не напрямую, а через функциональных менеджеров.
Обычно это происходит, когда в качестве руководителя проекта выступает руководитель одного из функциональных подразделений или главный специалист. «Сильный» же руководитель проекта (рис. 4) имеет право давать задания сотрудникам функциональных подразделений напрямую. Обычно это человек, имеющий высокий статус в организационной иерархии (либо первое лицо, либо его заместитель).
Понятно, что для того чтобы проект двигался при слабом руководителе, должны быть созданы дополнительные механизмы его реализации, компенсирующие отсутствие административного ресурса либо возможности (желания) активно участвовать в работе. Как подсказывает мой опыт, для этой цели правильнее всего придать дополнительные функции координатору проекта.
Редко случается, когда и руководитель, и координатор прилагают одинаковые усилия для продвижения проекта. Очень часто руководитель проекта назначается формально, и тогда крутить механизм придется координатору. Для этого он должен быть наделен соответствующими полномочиями (зафиксированными в приказе или уставе проекта). Без такого «привода» механизм управления при «слабом» руководителе не работает и проект обречен на неуспех.
Органы управления проектом
В крупных проектах предлагается создавать коллективные органы управления, например:
- комитет по управлению. Цель деятельности данного комитета — определение стратегии, рассмотрение спорных вопросов, утверждение изменений в договоре;
- комитет по контролю за изменениями. Этот комитет создается в рамках проекта с целью анализа и рассмотрения запросов на изменения. Как правило, изменения, касающиеся области определения проекта, передаются в комитет по управлению;
- комитет по анализу спорных вопросов организуется для разрешения спорных ситуаций и регулярного управления рисками.
В неблагоприятных проектных условиях сложно набрать людей во все эти органы управления, еще труднее собрать их вместе. И тогда основная нагрузка по решению вопросов переносится на методический совет, который может собираться по группам. Таким образом, в качестве коллективных органов управления проектом предполагаются:
- управляющий совет — по функциям заменяет комитет по управлению;
- методический совет — заменяет комитеты по контролю за изменениями и по анализу спорных вопросов;
- координационный комитет — это управляющий плюс методический совет.
Однако при «сильном» руководителе проекта данный механизм может быть упрощен. Например, может быть предложена схема, в которой отсутствуют такие органы управления, как управляющий совет и методический совет. Их работа заменяется техническими совещаниями при руководителе проекта или его единоличными решениями. При такой схеме проблемы решаются гораздо оперативнее, но в силу этой быстроты решения могут быть неоптимальными. Иногда эту схему модифицируют созданием координационного комитета, куда входят представители и заказчика, и исполнителя («промежуточная» схема).
Сочетания типов матричных структур управления проектами и типов руководителей сведены в табл. 2, где для каждого случая указаны рекомендуемый состав органов управления проектами. Из данной таблицы следует, что самым сложным механизм реализации проекта оказывается при сильной матрице и слабом руководителе, а самым простым — при слабой матрице и сильном руководителе.
Функции управляющего и методического советов
Поскольку управляющий и методический советы охватывают наиболее полный круг решаемых задач, рассмотрим их функции более подробно.
Управляющий совет — высший орган управления проектом. Целью его создания является разрешение противоречий и устранение административных и функциональных барьеров между подразделениями, он же несёт контрольные функции. Задачи управляющего совета:
- рассмотрение хода выполнения проекта, внесение корректировок в план работ, принятие решений о завершении или прекращении проекта;
- контроль бюджета проекта, графика финансирования, внесение корректировок в бюджет;
- введение и выведение из состава методического совета и рабочей группы новых членов;
- рассмотрение вопросов, по которым методическому совету не удалось достичь согласия;
- подготовка протокольных решений, являющихся обязательными для исполнения всеми участниками проекта.
Заседания управляющего совета созываются по окончании каждого этапа либо (внеочередные) по инициативе руководителя проекта. Возглавляет совет, как правило, высший руководитель. Управляющий совет — «продавливающий орган», поэтому крайне важно, чтобы проект возглавлял генеральный директор или его авторитетный заместитель. В состав членов совета по должности входят руководитель и координатор проекта, а также руководители функциональных направлений (как правило, заместители директора).
Методический совет является совещательным органом. Создаётся с целью корректировки действующих методологий выполнения бизнес-процессов, вызванных внедрением информационной системы; согласования интересов подразделений; подготовки решений об изменении регламентов выполнения бизнес-процессов; структурных преобразований. Решения методического совета носят рекомендательный характер и вступают в действие после утверждения руководителем проекта или председателем управляющего совета. Его задачи:
- определение состава и структуры внутреннего и внешнего документооборота, утверждение форм документов, определение статуса электронных документов;
- выработка рекомендаций по оптимизации бизнес-процессов, определение и переопределение функций персонала;
- определение методик учета, расчетов, нормирования, планирования и т. п.;
- выработка и утверждение системы классификации и кодирования, структуры справочников, определение владельцев и совладельцев информации;
- консультирование членов рабочих групп и другие вопросы.
Заседания методического совета проводятся по мере необходимости, но не реже одного раза в две недели. Возглавляет этот совет, как правило, заместитель генерального директора либо руководитель проекта. В него входят руководители и специалисты ключевых подразделений. Методичесикй совет, как правило, работает по секциям, поскольку необходимость собирать этот совет в полном составе возникает редко.
На наш взгляд важно правильно подобрать его состав. Если в методическом совете появятся некомпетентные, негативно настроенные, конфликтные люди, его работа окажется неэффективной и даже может быть заблокирована. Методический совет — это место, где люди должны договариваться, находить согласие. Это главное его назначение, поэтому в него нельзя назначать людей исключительно по должности.
В следующей, третьей части цикла мы поговорим о психологических аспектах ведения проектов в неблагоприятных условиях и мотивации участников проекта.
Источник: www.iemag.ru
psilonsk
Некоторое время назад я в очередной раз напомнил дорогой аудитории моего блога о недопустимости совмещения роли менеджера проекта с любыми исполнительскими ролями. Меня попросили высказаться более развернуто. Извольте. )
Напомню, что основной тезис такой: одна из самых больших ошибок, которую может совершить менеджер проектов, в особенности начинающий, — устроиться на работу, где он будет считаться менеджером, но выполнять будет и функции других сотрудников.
Это пагубно и для менеджера, и для его работодателя. И вот почему.
1. Время — весьма ограниченный ресурс. В сутках 24 часа, продуктивной работе можно посвятить не более 8-9, и это очень оптимистичная оценка. Представьте, что вам поручили сложный проект, и от вас зависит, пройдет он гладко и относительно спокойно или будет буксовать на каждой кочке.
От вас и только от вас зависит, будет ли клиент доволен качеством работы, ее скоростью и той суммой, в которую вы уложитесь. Вы — и только вы! — отвечаете за людей, которые под вашим руководством трудятся в проекте. Уделяя время неменеджерским задачам, вы не делаете того, что должны и чего от вас ждут.
Если вы можете управлять сложными (!) проектами, совмещая несколько ролей, дайте адресок, где вас можно найти, я с удовольствием буду у вас учиться. К сожалению, я пока таких людей не встречал, а я в этом бизнесе уже довольно давно. Профессия менеджера проектов появилась не просто так, поверьте. Если вы хороший универсал, вы просто не делали никогда сложных проектов (самое время попробовать).
В принципе, одного временного ограничения достаточно, чтобы отказаться от идеи совмещения ролей. Но есть и не менее веские аргументы.
2. Вырасти как менеджер при совмещении ролей невозможно. Каждый проект нас чему-то учит. Мы растем как менеджеры, встречая незнакомые прежде проблемы и стараясь их решить.
Профессия менеджера — это сплав психологии, здравого смысла, логики, хитрости, изворотливости, подозрительности, нацеленности на результат, обязанности следовать инструкции, способности к нестандартным ходам, желания искать общий язык и вести переговоры с людьми, твердости в отстаивании своих взглядов, умении предугадывать ходы и делать много дел одновременно. И еще миллиона вещей.
Научиться этому можно, но только если учиться. Те же, кто посвящает свое время не менее интересным, но совсем не важным для менеджера техническим вопросам, крадет у себя возможность расти как менеджер. Если вам не нравится заниматься управлением, зачем вы им занимаетесь? Растите как специалист — это не менее почетно, а иногда даже не менее денежно.
Поймите, что менеджер — это не вершина эволюции, а лишь одна из ее ветвей. Вам вовсе не обязательно становиться управленцем, чтобы достойно жить и хорошо себя чувствовать.
3. Вырасти как специалист при совмещении ролей тоже невозможно. Вместо решения интересных вам технических задач, вы будете погружаться в какие-то дрязги в коллективе, полоскать грязное белье, получать по шее от недалекого начальства за то, что сделали или не сделали другие люди, которых вы, может, и не видели никогда.
Вы погрязнете в бюрократии, вам придется делать массу бумажной работы. Оно вам надо? Ведь вы можете сосредоточиться только на красивых задачах и красиво их решать — и становиться экспертом, — да что там, гуру! — в выбранной области.
4. Управлять серьезными проектами при совмещении ролей невозможно. Это непосредственно вытекает из предыдущих пунктов. В серьезных крупных проектах все по-взрослому — там просто физически не получится влезать в исполнительские сферы из-за крупных масштабов, распределенных больших команд и т.д.
Кроме того, там так много направлений деятельности, что, даже вклиниваясь в родную и знакомую, вы не сможете повлиять таким образом на весь проект. Взяться за такую непростую работу могут только профессиональные менеджеры, которые занимаются управлением, а не бросаются грудью на низкоуровневые задачи.
Если вы известны своей любовью к совмещению, в нормальной компании серьезных проектов вам не видать — будете делать только мелочевку. Хотите серьезных проектов — забудьте про совмещение.
5. Если вы вмешиваетесь в работу других людей, зачем вы их наняли? И правда, зачем? Вы боитесь и не доверяете им? Не умеете делегировать задачи?
Не довольны качеством их работы? На каждый из этих вопросов есть ответ, но он из управленческой плоскости, не из исполнительской.
Не лезьте в работу других людей. Проекты делаются именно потому, что одни люди готовы всецело доверять профессионализму других.
6. Кто будет нести ответственность за ваши технологические решения? Предположим, вы взяли на себя часть исполнительских функций и выполнили какую-то задачу. Прошел месяц, и выяснилось, что задача решена плохо, результат никуда не годится. Причины не очень важны.
Вы готовы отвечать за это? Готовы ли вы переделать эту задачу сейчас и переделывать ее снова и снова? А другие задачи? А что вы скажете спонсору проекта? А клиенту?
А как вы с ними будете говорить об этом, возможно, очень серьезном, провале? Как менеджер или как тот, кто задачу запорол? Если как менеджер, то как вам быть с этим некомпетентным (в глазах других людей) человеком? А когда вы будете теперь решать управленческие проблемы?
Запомните: если в вашей работе найдут ошибки, а их всегда найдут при желании, то вы будете виноваты не только в них, но и во всех ошибках проекта, кто бы и когда их ни сделал.
На вас всегда покажут пальцем и скажут: «Он тоже был с нами в ту ночь». Не волнуйтесь, на вас и так покажут пальцем, но пусть это хотя бы не будет связано с техническими деталями проекта. Вот представьте, играем мы на ЧМ по футболу (который я терпеть не могу), идет ключевой матч. И вдруг выбегает на поле тренер, отталкивает вратаря и сам встает в ворота. Удар — гол.
Кто пропустил гол? Тренер, который должен был заниматься другими делами. В этот момент сразу все не важно: нет больше ни красивых схем, ни вдохновляющих речей, ни тонкой тактики, ни предыдущих достижений. Есть немолодой человек, который взялся решать задачи, которые решать не должен. И будущее его печально и предсказуемо.
Что делать с вратарем в случае ошибки — понятно. Его можно заменить, можно отправить на курсы повышения квалификации, можно застимулировать так, что мало не покажется. А что теперь делать с тренером?
7. Совмещая роли, вы навсегда перестанете восприниматься вашей командой как менеджер. Вы просто один из них. Вас можно попросить сделать задачу. Можно указать на ошибку.
Можно поржать над качеством вашей работы.
Вы больше не на острие атаки — вы в арьегарде проекта. И при этом вы все еще отвечаете за все вышеперечисленные задачи менеджера, включая работу с людьми, их стимуляцию. Во многих странах, и Россия в их числе, ролевая модель плохо укладывается в голове — нельзя вчера пить пиво с коллегой Петей, а сегодня получать люлей от менеджера Пети, это рвет мозг. Это ж Петя, вот он, это он на прошлой неделе не знал, как сделать простейшую задачку, еще ко мне подходил, спрашивал. И вдруг он меня за что-то отчитывает?
Надо уяснить важную идею: как только менеджер вмешивается в работу проектной команды, начинает ей «помогать» как специалист, он перестает быть менеджером. Если взглянуть на ситуацию отстраненно, с высоты птичьего полета, то это не хорошо и не плохо — просто человек делает одну работу и не делает другой. Но мы-то не птицы, мы всегда внизу. А внизу мы видим человека, которому поручили, — нет, доверили! — проект, поставили на его умение управлять людьми и достигать целей, а он вместо этого сидит и копается в бухгалтерских счетах, или программирует что-то, или лежит весь в машинном масле под грузовиком. Похвально, но бесполезно — всех технологических дыр все равно не заткнете.
Зато точно перестанете быть менеджером — для себя, для команды, для клиента и для начальства.
Вам и только вам решать — кем и зачем быть.
Но запомните: для менеджера совмещать управленческие и исполнительские обязанности не просто вредно — смертельно.
Источник: psilonsk.livejournal.com
Менеджер проекта со стороны Заказчика.
Менеджер проекта со стороны Заказчика ответственен за ежедневный контроль договорных обязательств Заказчика по проекту. Менеджер проекта со стороны Заказчика должен понимать цели бизнеса Заказчика, чтобы могла быть сформирована основа для разрешения проблем, конфликтов интересов и выбора оптимального решения.
Менеджер проекта со стороны Заказчика получает в свое распоряжение физические ресурсы, такие как офисное пространство, офисное оборудование, компьютеры, материалы, а также организует работу персонала Заказчика. Менеджер проекта со стороны Заказчика является связующим звеном между Исполнителем и Заказчиком. Также в его обязанности входит наблюдение за ходом выполнения проекта: контроль состояния, согласованность работ, качество работ, поиск путей разрешения возникающих проблем. Обычно Менеджер проекта со стороны Заказчика утверждает промежуточные отчеты и отчеты об окончании этапов.
Менеджер по конфигурации.
Менеджер по конфигурации несет ответственность за планирование, функционирование и контроль процесса Управление конфигурацией. В его обязанности входит:
· разработка, документирование и реализация планов и процедур процесса Управление конфигурацией;
· определение базовых положений проекта и содержания релизов;
· контроль того, чтобы не вносились неутвержденные изменения в базовые положения проекта;
· проведение в жизнь процедур процесса Управление конфигурацией в течение всего жизненного цикла проекта;
· контроль того, чтобы Репозиторий процесса Управление конфигурацией соответствующим образом сопровождался и был защищен от несанкционированных изменений.
Бизнес-менеджер Исполнителя.
Бизнес-менеджер ответственен за успешное осуществление проекта в организации Исполнителя. Он управляет практической деятельностью персонала Исполнителя и координирует деятельность ресурсов проекта относительно других проектов. Бизнес-менеджер представляет организацию Исполнителя в договорных соглашениях с Заказчиком и решает вопросы бизнеса со Спонсором проекта. Бизнес-менеджер участвует как в обзорах по проекту, так и во внутренних обзорах о состоянии проекта.
Администратор проекта.
Администратор проекта содействует Менеджеру проекта и Координатору проекта в выполнении текущих каждодневных задач руководителей проекта, занимается рассылкой протоколов совещаний, повестки дня предстоящих совещаний, информации о календарных мероприятиях. В обязанности Администратора проекта входит:
· организация Библиотеки проекта, доставка документов в Библиотеку и осуществление контроля документов;
· введение в курс новых членов команды проекта относительно среды, процедур и направления проекта;
· координация действий с администраторами организаций Заказчика и субподрядчика подготовка отчетов о состоянии проекта;
· регистрация и рассылка протоколов, решений и другой информации по итогам проводимых совещаний;
· формирование информации о текущем статусе, используя учетные записи проекта;
· ведение информации о персонале проекта (образование, квалификация, обучение, вхождение в организационную единицу, телефон /адрес, история назначений по проекту и др.).
Координатор проекта.
Координатор проекта помогает Менеджеру проекта в повседневном управлении проектом. Обычно эта роль используется в крупных проектах. Менеджер проекта может делегировать Координатору проекта какие -то специфические обязанности, но, как правило, в круг обязанностей Координатора проекта входит:
· ввод в действие и поддержка Плана качества, стандартов и процедур проекта;
· контроль того, чтобы управление на этапах проекта производилось согласованно и эффективно;
· ввод в действие и поддержка Рабочего и Финансового планов;
· обеспечение персоналом или физическими ресурсами;
· мониторинг и анализ рисков, спорных вопросов и проблем, требующих проведения корректирующих действий со стороны Менеджера проекта;
· выполнение координационных и связующих функций внутри организации Исполнителя.
Менеджер проекта.
Менеджер проекта отвечает, в конечном счете, за успех или неудачу проекта. Менеджер
проекта должен обладать пониманием целей бизнеса проекта, как со стороны Заказчика, так и стороны Исполнителя, и ясно представлять пути достижения этих целей. Менеджер проекта согласует область применения с Заказчиком и разрешает противоречия, которые могут возникнуть между различными целями сторон. Он несет ответственность за планирование проекта, обеспечение ресурсами, а также мониторинг и составление отчетности о состоянии проекта относительно принятого плана. Менеджер проекта получает в распоряжение физические ресурсы, набирает персонал, а также, в случае необходимости, увольняет персонал.
Менеджер проекта отвечает за то, чтобы работа по обеспечению качества велась в соответствии с Планом качества. Внутренние обязанности Менеджера проекта могут быть делегированы подчиненным ему руководителям команды проекта, как это представлено в организационном плане проекта.
Спонсор проекта.
В ведении Спонсора проекта находится бюджет и платежи по проекту. Эту роль обычно выполняет человек, находящийся на высшем управленческом уровне. Эта роль подразумевает наличие ясных взглядов на цели проекта, особенно в области получения прибыли.
Спонсор проекта является последней инстанцией в разрешении конфликтов по бизнес — требованиям (если они не были разрешены на более низком уровне) и по изменениям в области применения. Спонсор проекта рассчитывает, что проект будет выполнен в отведенные сроки и не выйдет за рамки бюджета. Спонсор проекта обычно является лицом, которое выдает окончательное утверждение.
Персонал проекта.
Члены команды проекта несут ответственность непосредственно перед Менеджерами проекта с обеих сторон.
Менеджер по качеству.
Менеджмент качества в рамках управления проектом — это система методов, средств и видов деятельности, направленных на выполнение требований и ожиданий клиентов проекта к качеству самого проекта и его продукции.
Таким образом, можно выделить менеджмент качества самого проекта и менеджмент качества продукции проекта. Взаимосвязь этих подфункций иллюстрируется в примере.
Пример. Взаимосвязь качества проекта и качества продукции проекта. Взаимосвязь между качеством проекта и качеством продукции может быть проиллюстрирована следующими общими примерами:
1. Стремление обеспечить выполнение работ по проекту в договорные сроки посредством перезагрузки персонала может привести к увеличению количества ошибок в технологических процессах и, кроме того, приведет к ухудшению морального климата коллектива команды проекта.
2. Стремление обеспечить выполнение работ по проекту в договорные сроки посредством ускорения проведения контрольных мероприятий и испытаний обязательно вызовет увеличение количества необнаруженных несоответствий.
Управление качеством включает в себя все функции общего руководства по разработке политики в области качества, установления целей, полномочий и ответственности, а также процессы планирования, контроля и обеспечения качества, с помощью которых в рамках системы качества происходит реализация данных функций.
Менеджер по качеству ответственен за планирование и управление всеми вопросами, которые оказывают влияние на систему качества проекта. Также он отвечает за выполнение требований по качеству, определенных в договоре и Плане качества, реализацию соответствующих стандартов и процедур, контроль проведения обзоров и аудитов качества.
Тема 5. Планирование этапа
Цели обучения:
Учебная цель темы раскрыть систему работы над планом, где помимо традиционной хронологии работ учитываются меры по управлению рисками на этапе проекта. Рассмотреть технологию работ, оценку их трудоемкости и способы оптимизации графика этапа проекта, входящая в жизненный цикл в подходе PJM. Цель планирования этапа – подготовиться к реализации задач этапа проекта.
Содержание темы:
1. Обзор основных положений.
Источник: lektsia.com
