ЧЕКМАРЕВ АНАТОЛИЙ

ОШИБКИ ФОРМУЛИРОВАНИЯ ЦЕЛИ ИНФОРМАЦИОННО-ТЕХНОЛОГИЧЕСКИХ ПРОЕКТОВ

 

Чекмарев Анатолий Владимирович / Anatoly V.Chekmarev,

Anatolii_chekmar@mail.ru

 

Аннотация

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

Annotation

The article presents analysis of IT projects typical mistakes. The text is based on the personal experience of implementation of complex IT projects in biggest Russian state and commercial companies.

 

Ключевые слова: управление проектами, ошибка, качество, процесс, модель зрелости, ИТ.

 

Keywords: project management, mistake, quality, process, maturity model, IT, CMMI.

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

В связи с очевидными требованиями по ограничению распространения информации о недостатках организации при приведении примеров наименования конкретных компаний не приводятся.

Ошибки формулирования цели являются наиболее часто встречающимися в настоящее время. На что влияет ошибка формулировки цели проекта?

В ходе реализации любого сложного проекта многократно принимаются различные организационные и технические решения. Инженерная задача – это поиск оптимума при наличии ограничений. В роли ограничений выступают сроки, финансы, человеческие и технические ресурсы, выбранные функциональные ограничения и т.д. Из математики известно, что задачи оптимизации являются решаемыми только при наличии целевой функции. При этом не все проекты могут быть формализованы до такого уровня.

Поэтому стандарт ANSI PMI PMBOK для упрощения требует явного задания единой цели проекта, что приводит проект к состоянию, в котором проектные решения могут быть приняты – проектная группа получает четкий критерий выбора варианта решения. Если цель задана ошибочно или недостаточно точно, то на каждом этапе работ будет создаваться ошибка в принимаемых решениях. Это особенно критично для начальных этапов. Известно, что ошибки, допущенные в начале проекта, имеют максимальную стоимость устранения – больший объем работ потребует переделки.

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

В части ошибки при формулировке цели показателен пример проекта, реализованного в одном из инфраструктурных финансовых институтов:

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

Цель проекта формулировалась следующим образом – «модернизировать технологическую платформу для повышения масштабируемости, функциональности и надежности». Легко заметить, что цель не является измеримой, что обоснованно требуют все руководства по управлению проектами. Не может быть создан технический объект, для которого не заданы ограничения функциональности и надежности.

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

Отсутствием приоритета и измеримости целей ошибки формулирования целей проекта не ограничивались. После короткого обследования выяснилось, что руководство компании вошло в конфликт с поставщиком эксплуатируемой системы и настоящей целью проекта было замещение существующего ключевого звена программного комплекса на новое. Т.е. настоящая цель проекта должна была на уровне официальных документов формулироваться как «замещение в минимальный срок программного обеспечения системы без потери функциональности, производительности и масштабируемости».

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

После корректировки цели проекта пришлось переделывать всю проектно-технологическую документацию, разработанное программное обеспечение не использовалось в дальнейшем. При этом проект оказался успешно завершен после реформирования в рекордные для такого уровня сложности 1,5 года.

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

Программное обеспечение является элементом автоматизированного комплекса предприятия, выполняющего заданный набор функций. Внедрение очередного элемента в этот комплекс не может быть самодостаточной целью. Целью может служить достижение комплексом некоторых задаваемых характеристик: функциональных, надежности, масштабируемости, модернизируемости и т.д.

Если бы в рамках космического проекта формулировались цели внедрения какого-либо конкретного двигателя в космический аппарат, а не выведение в космос космического аппарата с человеком на борту или достижение поверхности Луны с забором лунного грунта, то, скорее всего, этот проект не был бы реализован до сих пор. При этом в рамках ИТ проектов почему-то «внедрение» часто признается допустимой целью.

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

Дополнительным недостатком подобной формулировки является то, что в данном случае нарушается баланс прав и ответственности руководителя проекта. Мало того, что ему была навязана некорректная цель. Он лишается возможности выбора оптимального проектно-технического решения в части ключевого элемента системы при сохранении ответственности за проект.

 

Список литературы

1. Managing capability and maturity, David Norfolk, Practice Leader - Development, Bloor Research, 20th February 2009.

2. Barki, H. Interpersonal Conflict and Its Management in Information System Development / H.Barki, J.Hartwick - MIS Quarterly, Vol.25, No.2, 2001. - с. 195-228.

3. Crosby, P. B. Quality is Free - Mentor (January 1, 1980) ISBN-10: 0451625854

4. Azarov, V.N. Quality management. Volume 1. – Moscow: MIEM, 1999.

5. Azarov, V.N. Quality management. Volume 2. – Moscow: MIEM, 2000.

6. Auzan А. Economics of everything. Haw institutions define our life — Moscow: «Mann, Ivanov and Ferber», 2013. ISBN 978-5-91657-976-5

7. Druzhinin V.V. Conflict theory essentials, Moscow: Radio and communications, 1989.

8. Verzuh E. Project management - Moscow: Dialectica, 2010.

9. Venda V.F. Hybrid intelligence systems Moscow: Machinostroenie, 1990.

10. Chekmarev A.V. IT - Maturity model. Quality. Innovations. Education – 2011. – № 3. – p. 40–49.

11. Chekmarev A.V. Use of conflict analysis for project management and process maturity evaluation according to CMMI Education and science automation. – 2011. – № 4(12). – p. 86–94.

12. www.sei.org