Билл Дункан (Bill Duncan) — ведущий автор PMBOK 1996г.

Перевод с англ.: Ярослава Рашевского

Печатается с согласия автора

Когда я впервые осознал идею формализованного управления проектами еще в 1982 году, большинство стандартов управления проектами были организационно-ориентированы и довольно сильно ограничены сферами оборонных контрактов и инжиниринга / строительства. Сегодня существует как минимум десяток стандартов хорошо известных в мире, и они используются практически во всех областях: традиционные парные информационные системы, разработка новых продуктов, фармацевтика, телекоммуникации, и других. Итак, похоже, мы добились некоторых успехов. Что нам нужно в будущем?1. Мы должны придти к согласию о том, что такое стандарт.

Вэб-сайт ISO говорит, что стандарт это «документированные соглашения, содержащие технические спецификации или другие точные критерии, что будут использоваться последовательно в качестве правил, руководств или определений характеристик, чтобы гарантировать, что материалы, продукты, процессы и услуги соответствуют их целям”. Существует множество областей управления проектами, которые могли бы получить выгоду от “четких критериев” — приходит на ум вычисление критического пути. Но есть и другие, такие как управление заинтересованными сторонами, где “правила, руководства или определенные характеристики” будут полезны, даже без точных критериев. Мой словарь говорит, что стандарт является “признанной мерой для сравнения количественных или качественных значений”. Я думаю, что это или подобное определение, есть то, что мы должны уяснить в рамках проектного управления. Далее, я думаю, что мы должны признать 3 разных вида стандартов:

· Описательные стандарты. Это документы, рассказывающие факты, детали или подробности чего-то;

· Нормативные стандарты. Это документы, обеспечивающие руководящие принципы (нормы), которые будут использоваться в качестве основы для измерения, сравнения или принятия решений.

· Предписывающие стандарты. Это документы, которые определяют конкретный способ делать что-то.

И мы должны отнести каждый опубликованный стандарт, какому-то из типов. Попытки использовать описательные стандарты, такие как ISO 21500, в качестве предписывающих — это рецепт катастрофы.2. Нам нужен общий язык.

По словам комика Стива Мартина, “эти сумасшедшие французы; у них есть разные слова для всего!” В управлении проектами мы используем разные слова означающие одно и то же (например, отношения, зависимости, ограничения). В других случаях мы используем одно и то же слово для обозначения совершенно разных вещей (устав, фаза). Одним из основных препятствий в этой области является наша относительная замкнутость. Несмотря на общую широту дисциплины, тот факт, что большинство практиков имеют опыт только в одной ее сфере, остается фактом. Так же, как физическая изоляция порождает языковые диалекты, наша интеллектуальная изоляция породила диалекты управления проектами. Например, вы знаете, руководителей ИТ-проектов, которые знают, что такое график 3-го уровня? Знаете ли вы руководителей ЕРС-проектов, которые не знают? Трансграничные проекты создают еще одну проблему. Даже когда все участники номинально англоязычные, мы все равно должны “перевести” такие базовые понятия, такие как «тендер» и «фаза».3. Нам нужны детальные стандарты.

Большинство нынешних стандартов, по замыслу являются документами высокого уровня. Чтобы продолжить рост управления проектами как дисциплины, нам нужны дополнительные стандарты, которые касаются конкретных тем более детально. Международная Ассоциация Развития Стоимостного Инжиниринга (AACEI) имеет несколько хороших абзацев в своих Рекомендуемых практиках, и, Офис общего учёта федерального правительства США также опубликовал некоторые полезные материалы по оценке и планированию расписания, но нам нужно больше.4. Нам необходимо уделять больше внимания разнице между содержанием и работой.

Вот пример: вас попросили покрасить комнату в зеленый. Ваш заказчик решил изменить цвет на красный. Содержание подвергается влиянию как только характеристики продукта изменились. Так или иначе Работы подвержены влиянию в зависимости от момента — если краска куплена или стены уже были окрашены, работа проекта изменилась. ПРОДУКТОриентированные процессы значительно отличаются в зависимости от сферы. Изоляция ПРОЕКТНОориентированных процессов необходима для продолжения описания межотраслевых практик. Любой другой подход приведет к фрагментации отраслевой ориентированности стандартов.5. Мы должны заботиться о том, чтоб не спутать частное с общим.

Практики собирают “факты” управления проектами от многих источников: боссов, сверстников, учебных программ, профессиональных изданий. Но эти факты могут быть опасны вне контекста. Например, “операция не должна быть дольше 2-х недель” частое хорошее правило для отчетности о прогрессе проекта. Но когда неопытные руководители проектов применяют это правило к оценке или декомпозиции, оно не работает хорошо. И когда эту практику исказили до “любая операция должна быть длительностью 2 недели” дает просто глупый результат. Другой пример: многие сторонники управления проектами по критической цепи утверждают, что планирование операций по дате их раннего начала, вероятно, будет способствовать задержкам в расписании. Но это справедливо только тогда, когда сетевая логика не определена должным образом. Фактически, планирование начала операций на момент их раннего начала абсолютно правильно — именно это отстаивают сторонники критической цепи!

Лично я не вижу. что эти 5 проблем решается в ближайшее время. А вы?

Оригинал опубликован на: https://www.LinkedIn.com/pulse/whence-pm-standards-bill-duncan

© 2017, Ассоциация экспертов системного менеджмента «МихиКо». Все права защищены.