Если сразу фиксировать исходные установки, у всех будет однозначное понимание того, на чем основан ваш план. Процессы планирования и контроля, описанные в РМВОК, не предусматривают использования деревьев принятия решений из теории ограничений в плане проекта. Тем не менее, если нам удается просто изложить исходные предположения на бумаге, мы тем самым снижаем фактор неопределенности в достаточной степени, чтобы можно было разработать строго определенное проектное задание — описать содержание, оценить затраты и составить график.
2.1.3. УПРАВЛЕНИЕ СРОКАМИ ПРОЕКТА
Управление сроками (project time management) предусматривает определение задач, или операций (activity), необходимых для выполнения заявленного содержания, их последовательности, оценку длительности операций, разработку расписания (schedule), то есть графика выполнения проекта и отслеживание выполнения графика. Для подготовки графика — на входе — нужны иерархическая структура работ, WBS и описание содержания проекта. В процессе разработки графика определяются требования к ресурсам по каждой операции и другие потенциальные ограничения. В РМВОК отмечается, что при оценке длительности работ должна указываться степень неопределенности, и делается отсылка на раздел по управлению рисками проекта, где говорится, как работать с неопределенностью. Также обсуждается необходимость выравнивания ресурсов (resource leveling) в плане проекта. Разграничение вариабельности, вызванной общими или специальными причинами, не производится (см. 2.5.2).
Управление стоимостью в РМВОК рассматривается отдельно от управления графиком выполнения проекта, однако процессы, определяющие их, одинаковы. Процесс управления затратами и графиком включает обновление графика проекта и оценок бюджета, планирование и выполнение корректирующих воздействий, систематизацию накопленных знаний (lessons learned) по завершении проекта.
2.1.4. УПРАВЛЕНИЕ РИСКАМИ ПРОЕКТА
К управлению рисками относится идентификация, количественный анализ рисков, а также планирование и отслеживание реакции системы управления проектом на возникновение опасных для успеха проекта ситуаций. Риски — это возможные события, наступление которых негативно скажется на проекте. В РМВОК не проводится разграничение между вариабельностью, вызванной общими или особыми причинами (см. 2.5.2), эти понятия оказываются смешанными при описании управления рисками. Кстати, я также ни разу не слышал, чтобы и Голдратт их различал. По моим наблюдениям, и он, и его последователи объединяют эти типы в одном понятии «вариабельность», или «законы Мерфи». На мой взгляд, по причинам, на которых остановимся позже, такое пренебрежение по отношению к неопределенности является ошибкой.
2.1.5. ДРУГИЕ ОБЛАСТИ ЗНАНИЙ РМВОК
Остальные области знаний, выделенные в РМВОК, такие как качество, человеческие ресурсы, коммуникации, поставки, также в разной степени важны для реализации проектов. Они существенны для любого типа бизнеса. Однако, поскольку мы сосредоточены на иных вопросах, в данной книге рассматривать эти аспекты не будем.
2.1.6. ОРМ3
Методика оценки степени зрелости проектного управления в организации, или ОРМ3 (Organizational Project Maturity Model) [2], была опубликована PMI в 2003 году. Ее цель — «описать стандарт управления проектами и зрелости управления проектами». На мой взгляд, она разработана в соответствии с положениями модели CMM Института инжиниринга программного обеспечения SEI (Software Engineering Institute’s Capability Maturity
Model) [3]. До того, как приступить к созданию ОРМ3, команда PMI рассмотрела 27 различных моделей и назначила специальные группы по 3 человека в каждой, чтобы детальнее изучить 17 из них. ОРМ3 содержит исчерпывающие вопросники для оценки организаций на соответствие характеристикам, присущим высокоэффективным проекто-ориентирован-ным компаниям.
ОРМ3 — это значительный шаг вперед по сравнению с РМВОК, поскольку она охватывает организационную систему целиком, а не только некоторые элементы, необходимые для управления отдельным проектом. Сфера использования пяти групп процессов, выделенных в РМВОК, расширена здесь до управления программами и портфелями проектов. В каждой группе выделяются основные и вспомогательные процессы. Выделенные в методике ОРМ3 процессы в явном виде не структурированы по ТОС или ССРМ. Пока еще слишком рано делать выводы о полезности ОРМ3. Личный опыт использования модели SEI CMMTM при организации офиса управления проектами (project management office) в ИТ-компании заставляет меня думать, что модели приносят практическую пользу, только если применяются по отношению к факторам, способным повлиять на действующее в данный момент ограничение системы. Нужно быть очень осторожным, чтобы не потеряться в обилии деталей, появление которых может быть обусловлено подобным подходом. Скорее всего, ОРМ3 следует использовать именно таким образом (то есть в совокупности с направляющими шагами ТОС).
