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

Используется анализ первопричин для выявления системных неудач в Офисе управления ИТ-проектами (ИТ-ОУП) работающем в неИТ-бизнесе.

Утром я прочитал отличную статью Рэйчел Бербиглия (Rachel Berbiglia) под названием “Почему ваш ОУП не должен структурно входить в ИТ подразделение” (“Why Your PMO Doesn’t Belong in IT.”) https://www.linkedin.com/pulse/why-your-pmo-doesnt-belong-rachel-berbiglia

(Примечание: ее статья не отражает ситуацию управления исключительно ИТ-проектами или когда бизнес-ОУП структурно входит в бизнес-подразделения).

Я тоже в последнее время много думал об этом. Мне повезло быть вовлеченным в великолепно функционирующие ИТ-ОУП и я хочу особенно отметить Брэди Эрб (Brady Erb) за его прекрасные ОУП. Но, за более чем 17-ти летний опыт работы Руководителем проектов (РП), я слишком часто видел ИТ-ОУП придающие технологии большее значение, чем людям и бизнес-процессам, как и г-жа Бербиглия. Как следствие, большой процент бизнес-проектов под управлением ИТ-ОУП неудачны, и это проблема, которую необходимо решать.

Г-жа Бербиглия очень эффективно выявляет, что часто если корпоративный ОУП находится внутри ИТ-подразделения, это не способствует воздействию проекта на других людей и бизнес-процессы, особенно для проектов в областях продаж, управления персоналом, финансов, или операционной деятельности. Ее решением является вывод ОУП из ИТ-подразделения. Как выразился один из комментаторов: “есть тысячи статей о высоком проценте неудач в достижении целей проектов. Мое убеждение в том, что основной первопричиной большинства этих неудач является непризнание (в ИТ) и, как следствие, несфокусированность на бизнес-процессе и людях, а так же ложное убеждение, что технологии решат проблему”.

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

Всякий раз, когда кто-то утверждает, что “первопричиной проблемы является XYZ…” я инстинктивно обращаюсь к анализу, выявившему объявленную причину. В данном случае такой анализ не приведен. Так как у меня аналитический склад ума и я люблю анализ первопричин, то думаю будет весело применить технику “5 почему” из концепции «Шесть Сигма» для анализа первопричин этой проблемы. (Правда, признаюсь: Я ЛЮБЛЮ применять инструменты «Шесть Сигма» и анализ данных для ситуаций управления проектами). Каждый ИТ-ОУП уникален, поэтому используемый здесь сценарий дан только для примера, полезного как упражнение для сотрудников ОУП. Выявив первопричину(ы), легче определить возможные решения, как вы увидите в дальнейшем.

“5 почему” — это один из самых простых инструментов для выявления первопричин(ы) проблемы без использования статистического анализа и обязательный инструмент каждого менеджера проекта, менеджера программы, менеджера продукта. Техника легка. Если у вас есть проблемы, просто спросите “почему это случилось?” снова и снова, углубляйтесь или каждый раз дробите до следующего первого уровня «почему». Пятикратность вопроса ориентировочна. Возможно придется спросить дважды, трижды, шесть раз, или даже больше. Возможно, вам придется раскошелиться на другие «почему?» или создать новые ветви так же относящиеся к исходной Группе проблем. Если вы знакомы с техникой диаграммы «рыбья кость», то можно использовать её. Как и «мозговой штурм», метод «5 почему» наиболее эффективен при выполнении группой. Цель: погрузится достаточно глубоко, чтобы подойти к симптомам проблемы и добраться до точки, где вопрос “почему?” больше не может быть задан.

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

Проблема: бизнес-проекты управляемые ИТ-ОУП негативно влияют на людей и бизнес-процессы.

Шаг Первый. Так как мы видим многочисленные неудачи во многих проектах, то из-за больших объемов данных, ошибки в проектах объединяют в Группы со сходными признаками (далее Группы). Группа — это совокупность событий/вопросов/проблем, связанных общностью.

Группа 1: РП не в полной мере понимает потребности компании и потенциальное негативное влияние проектного решения.

Первый уровень — почему это произошло?

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

     Второй уровень — почему это произошло?

РП обладает сильными навыками в ИТ-дисциплинах, таких как сети или системы, а не в бизнесе.

          Третий уровень — почему это произошло?

У ИТ-РП есть культурная склонность считать, что он может узнать и понять бизнес, легче, чем кто-то от бизнеса сможет узнать технологию.

               Четвертый уровень — почему это проблема?

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

Потенциальные решения для Группы 1:

1. Выделить представителя от бизнеса как узкого специалиста в предметной области (проекта — прим. переводчика);

2. Нанимать ИТ-РП, имеющего бизнес-опыт;

3. Обучать ИТ-РП навыкам, необходимым для нетехнических РП;

4. Обучать ИТ-РП общим принципам бизнеса, управления процессами и управления изменениями;

Лично у меня много опыта в области управления изменениями с точки зрения ИТ (ИТУИ), часто включающего в себя документацию, контроль версий, управление и минимизацию влияния на систему. Я также, как консультант, управлял организационными изменениями (ОУИ) в компаниях из списка Forbes-100, специализируясь на внедрении новых бизнес-процессов и, возникшем в их результате, влиянии на людей. Один и тот же термин – Управление изменениями (УИ) используется и в бизнесе и в ИТ, но все-таки имеет очень разные определения в зависимости от используемого контекста. Лучшие РП должны иметь знания в обеих дисциплинах.

5.Обучить ИТ РП конкретному бизнесу.

Например: он может участвовать в продажах или стать пользователем CRM, которую планируется изменить, стать «тенью» линейных работников или использовать инструменты/системы как член бизнес-команды.

Группа 2: Документация бизнес требований (ДБТ) содержала изъяны.

Первый уровень — почему это произошло?

РП/Архитектор решений не задал правильных вопросов, или не задал вопросы правильно.

     Второй уровень — почему это произошло?

РП не был эффективен на интервью.

Первый уровень — почему это произошло?

(относится к уровню проблемы) Бизнес не эффективно доводит информацию до ИТ-РП.

     Второй уровень — почему это произошло?

Бизнес охладевает. Бизнес чувствует, что для ИТ это просто не важно или у ИТ не получится.

          Третий уровень — почему это произошло?

У бизнеса мало опыта взаимодействия с ИТ-ОУП. Возможна даже неприязнь к ИТ-ОУП. Бизнес чувствует себя обойденным, лишенным доверия или не вовлеченным.

Первый уровень — почему это произошло?

(относится к уровню проблемы)

Бизнес глобален по природе и ИТ-РП не был осведомлён о нежелании, в некоторых культурах, давать негативную обратную связь о ДБТ и о Методике приемки пользователем (МПП). Например, большинство американских родителей шокированы, узнав, что японские дети очень редко употребляют слово “нет”.

Потенциальные решения для Группы 2:

1.Дополнительно обучать РП методикам проведения интервью и постановке открытых вопросов;

2.Документировать и подтверждать все предположения;

3.Использовать сценарии вариантов использования (Use Case Scenarios — прим. переводчика) для подтверждения правильности ДБТ;

4.Обеспечивать связь вариантов использования с бизнес-целями;

5.Строить организационные связи и доверительные отношения между бизнес-подразделениями;

6.Обеспечивать, чтобы РП в глобальных проектах имел международный и мульти-культурный опыт или соответствующее обучение;

Группа 3: Исполнение содержало изъяны

Первый уровень — почему это произошло?

Проблемы были выявлены, слишком поздно, чтобы решить их.

     Второй уровень — почему это произошло?

Проблемы не были распознаны до тестирования.

Первый уровень — почему это произошло?

Технологически решение работает, но бизнес-задачи решает не эффективно.

     Второй уровень — почему это произошло?

ИТ-ОУП может иметь культурную ИТ-склонность при принятии решений в условиях конкурирующих приоритетов.

Первый уровень — почему это произошло?

(относится к проблеме уровня Группы) ИТ-РП может попасть в западню своего прошлого опыта и привычек. Однажды я работал с командой разработки, которая была твердо уверена, что почтовый индекс это обязательное поле данных. Они рассуждали по схеме: «всегда так делали». Но им было невдомек, что в таких странах, как Гонконг и ОАЭ почтовые индексы редки, а порой никогда не используются.

Потенциальные решения для Группы 3:

1.Использовать итеративную методологию вместо традиционной водопадной тогда, когда высок риск фундаментальных изменений;

2.Привлекать представителей бизнеса для принятия решений;

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

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

Если ваш ИТ ОУП вредит бизнесу, попробуйте это упражнение сами. Включите всех членов вашего ОУП, а также, представителей бизнеса. Представители бизнеса – ваши заказчики.

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

Оригинал статьи доступен на: https://www.linkedin.com/pulse/why-your-pmo-may-failing-its-business-steven-selikoff?trk=pulse-det-nav_art

Перевод: Я.Рашевский.

Публикуется с согласия автора Стивена Селикофф, Бизнес-менеджера, старшего Руководителя проектов и предпринимателя

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