Подавляющее большинство проектов самого разного рода имеют между собой очень много общих черт — независимо от того, связаны ли они со строительством железобетонного объекта, или с разработкой программного обеспечения, или с созданием и внедрением новых банковских технологий.
Поэтому, говоря о методах управления проектом, необходимо иметь в виду, что эти методы, как правило, сохраняют свою сущность независимо от области деятельности, в которой реализуется проект. Основанием для такого утверждения является общепринятая к настоящему моменту позиция, заключающаяся в том, что управление проектом в принципе подчиняется одним и тем же закономерностям, не зависящим от предметной области.
Естественно, применительно к конкретным областям может требоваться специальная доводка («тонкая настройка»), но, в принципе, эти методы полностью сохраняют свою сущность в любых отраслях.
Организация проектной деятельности — вопрос, к настоящему времени исследованный до определенной степени глубины, что позволяет эффективно использовать заложенные в существующих подходах идеи для решения корпоративных задач проектного менеджмента.
Проблематика управления проектами
Вместе с тем, прямое использование соответствующих технологий часто встречает два объективных препятствующих фактора. Один из них связан с тем, что технологии управления проектами часто носят так называемый «рамочный» характер, и их непосредственное применение нуждается в предварительной детализации и адаптации к условиям конкретной инфраструктуры (помимо необходимости модернизации самой инфраструктуры для создания возможности управления проектами).
Другой препятствующий фактор в отечественных условиях связан с тем, что лидирующие позиции в методологии управления проектами прочно занимает западный менеджмент. Адаптация же соответствующих методик к российским условиям — образу мышления, сложившейся практике деятельности, системе взаимоотношений разных уровней — требует значительной интеллектуальной составляющей, что, по всей видимости, не может быть безупречно исполнено в условиях ограниченного времени и недостаточного финансирования этой области на федеральном уровне.
Таким образом, задача, связанная с изучением различных аспектов управления проектами в области информационных технологий, их применением и интеграцией в цельную концепцию, является нетривиальной.
Современные методологии управления проектами можно условно классифицировать в две группы — как «рамочные» и «тактические». Под этими условными наименованиями имеется в виду следующее.
При необходимости реализации проектов, выполняемых в рамках предприятий, неизбежно приходится сталкиваться с решением целого ряда вопросов, связанных с адаптацией предприятия к требованиям, диктуемым проектной работой. Элементарными примерами могут служить специфические требования при подборе персонала для проектной работы (безусловно, отличающиеся от требований к сотрудникам обычных организаций), система принятия решений (также неизбежно отличающаяся от системы принятия решений на предприятии в целом), и так далее. Особенности такого рода привели к созданию целого ряда стандартов, называемых «рамочными».
Эти стандарты носят весьма общий характер и являются в тактическом плане неконструктивными: они говорят о том, что нужно делать для того, чтобы создать в организации условия для полноценной проектной деятельности, но не говорят, как это реализовать. Примерами «рамочных» стандартов могут служить американский федеральный стандарт PMBoK (Project Management Body Of Knowledge) и британский федеральный стандарт Prince2 (PRojects IN a Controlled Environment) по управлению проектами, кратко рассмотренные в Приложении. Из их сопоставления можно сделать следующие выводы:
- формальные схемы организации деятельности в их рамках существенно различаются;
- фактически организационные диаграммы включают сходные элементы, которые могут подвергаться различной компоновке и различаться в пределах некоторых «допусков».
Типичные признаки неконструктивности таких моделей:
- недостаточная подробность стандартов, возможность самых различных их толкований в зависимости от представлений менеджера, руководителя организации или аудитора;
- неточность оценки качества и эффективности процессов, задействованных при создании и внедрении продукта/технологии;
- отсутствие в ряде стандартов механизмов, способствующих улучшению составляющих подход процессов.
Поэтому попытки непосредственного применения «рамочных» моделей при управлении реальными проектами встречают существенные трудности.
Выход из положения
Известным способом решения проблемы, связанной с преодолением сформулированных неопределенностей, естественным образом порождаемых «рамочными» стандартами, является путь, избираемый, как правило, крупными западными компаниями. Он заключается в специализации и детализации «рамочного» стандарта и разработке, таким образом, собственного фирменного стандарта.
При этом конкретное наполнение такого стандарта производится специалистами высокого уровня, работающими в самой компании. В результате такой стандарт становится неотъемлемой частью фирменного стиля и принадлежностью «брэнда» (например, у таких компаний, как SAP, NCR, PwC и пр.) Однако, к сожалению, этот подход не всегда приемлем для отечественных коммерческих учреждений, не имеющих возможности направлять значительные ресурсы на академические и прикладные исследования в области проектного менеджмента.
Другим — практическим — решением этой проблемы является подход, связанный с комбинированием и объединением различных методологий по управлению проектами. При этом одна из этих методологий является «рамочной» и имеет современную процессную структуру, в то время как сопряженная с ней носит тактический характер и имеет процедурную природу, т.е. ориентирована на решение частных задач в рамках единого проекта.
В противоположность «рамочным» моделям, модели «тактические» предоставляют инструментарий для решения конкретных проблем в ходе проекта: говорят о том, в каком порядке и как нужно их решать. Такие модели не имеют «скелета» для проектов корпоративного уровня. Они могут использоваться как для адаптации «рамочных» стандартов в конкретных организациях, так и самостоятельно, т.е. без адресации к «рамочным» стандартам. Примером такой модели может быть разработка одной из ирландских консалтинговых компаний, носящая незамысловатое название Structured Project Management (SPM).
На основе такого конгломерата, построенного на сочетании «рамочной» и «тактической» моделей, может оказаться затруднительным создание собственного фирменного стиля разработки, но сам подход обладает рядом преимуществ, а именно — позволяет:
- создать реальный инструментарий, использующийся системно при разрешении возникающих в ходе проекта проблем,
- обеспечить сопровождение разрабатываемых продуктов и технологий документацией, предусмотренной «рамочным» стандартом управления проектом, тем самым подтверждая и демонстрируя системный подход к управлению проектами.
Организация проектной деятельности в банке
Проектную работу (Не путать с проектным финансированием!) трудно назвать для банка профильной, скорее — наоборот. Однако, в последнее время в отечественных банках наблюдается устойчивый рост интереса к тому, чтобы решать возникающие вопросы организационно-технологического характера без помощи внешних консультантов и специалистов по проектному менеджменту, а собственными силами и средствами, если таковые имеются. С этой целью в банках инициируются проекты и учреждаются проектные группы, участники которых ведут соответствующую работу в качестве своих основных или дополнительных обязанностей.
Возникающая при этом специфическая проблема заключается в том, что организация и внутренний контроль деятельности подразделений в банке и деятельности рабочей группы в ходе проекта существенно различаются. По сравнению с проектом, функционирование банка — это ежедневный монотонный процесс, пронизываемый нормативами и правилами деятельности, внутренним и внешним контролем, требованиями к ликвидности и доходности, и т.д. и т.п.
Проект же — это взрыв активности, максимальное напряжение интеллектуальных, физических, моральных и прочих сил, сосредотачиваемое в течение сравнительно коротких промежутков времени. В силу этого, требования, с которыми нужно подходить к организации проектной работы в банке, существенно иные, нежели требования при создании просто еще одного подразделения.
В качестве отправной точки при проработке вопросов организации проектной деятельности можно взять следующие принципы, устоявшиеся с течением времени и не вызывающие, как правило, серьезного противодействия даже со стороны скептически настроенных оппонентов:
- Процесс разработки проекта имеет плановую основу;
- Продукты разрабатываются в ходе проекта на основе заранее определенного (возможно — типового) жизненного цикла разработки;
- Назначается единственный лидер проекта (его наименование — «руководитель», «менеджер» и т.п. — несущественно), который наделяется полномочиями и статусом, достаточными для принятия самостоятельных решений по всем аспектам внутрипроектной деятельности на основе ранее определенных ресурсов и согласованных целей проекта (этапа проекта);
- Контроль внутри этапов (микро-контроль) осуществляется единолично лидером проекта;
- Контроль проекта в целом (макро-контроль) осуществляется специально учреждаемой «дирекцией проекта» на контрольных точках (например, на границах этапов).
Задача, которую предстоит решить при постановке проектной работы, состоит в необходимости замены высокоиндивидуального процесса процессом стандартным, т.е. заведомо согласованным, прогнозируемым и управляемым. Для этого требуется создать методологический и практический инструментарий, которым воспользуются лидер и участники проекта при решении проектных задач.
На языке жизненного цикла разработки продукта, таким инструментарием могут стать методики, средства и соглашения для создания спецификации продукта/технологии, проектирования, реализации, тестирования, внедрения, а также для сквозного и скользящего планирования всей деятельности, для обеспечивающих действий, включающих управление персоналом, переговорные процессы, совещания и пр. При этом система контроля проекта в целом будет надстройкой над этим инструментарием.
В качестве наименее проблемного, «бархатного» подхода к организации проектной работы в банке рекомендуется движение внутренних стандартов банка и требований проектной работы навстречу друг к другу — вплоть до остановки в точке оптимальной на данный момент «конфигурации». Этому соответствует следующая примерная последовательность мероприятий:
- Формулировка требований к банку, позволяющих оптимизировать проектную работу с учетом общепринятых принципов ее организации;
- Взаимная адаптация банка и принципов организации проектной работы;
- Создание или адаптация методологии осуществления конструктивной работы в ходе проектов;
- Создание или адаптация инструментария при решении в ходе проектов типовых задач планово-организационной природы;
- Система мониторинга проектов.
Все это позволит обеспечить гармоничное развитие проектной работы в банке вместе с системой контроля и управления рисками, которая составляет, в соответствии с одним из определений, сущность любого банка.
Источники информации
- Duncan W.R. A Guide to the Project Management Body of Knowledge. North Carolina: PMI Publishing Division. 1996.
- Либерзон В.И. Основные понятия и процессы управления проектами. Директор информационной службы. № 3. 2000.
- Ципес Г.Л., Товб А.С. Свобода менеджера как осознанная необходимость, или стандарт управления проектами уровня предприятия. // Директор информационной службы. №7. 2001.
- O’Connell F. How to run successful projects. Wiltshire, Prentice Hall International (UK) Limited. 1994.
Приложение
Рамочный стандарт Prince2
Позиционируется как процессный подход к управлению проектами, обеспечивающий легко адаптируемое и масштабируемое средство для управления любыми типами проектов. Каждый процесс в нем определяется вместе с ключевыми входными и выходными данными, а также со специфическими целями и предпринимаемыми действиями.
В соответствии с ней, процесс «проектной навигации» начинается с самого начала проекта и продолжается вплоть до его завершения. Надзор и контроль за процессом осуществляет так называемая «дирекция проекта» — исполнительный институт, осуществляющий общую координацию и надзор за проектом.
Руководитель проекта подотчетен дирекции проекта, которая в свою очередь подотчетна руководству более широкой программой (или корпорацией), частью которой является проектная структура. Дирекция проекта утверждает назначения в рамках команды проекта, а также создает план стадии инициации проекта.
Процесс инициации проекта ставит своими целями обоснование необходимости проекта, создание стабильной управленческой основы для исполнения проекта, подготовку ресурсов для первоначальной стадии проекта, контроль планирования трудоемкости и эффективных затрат времени в ходе проекта.
Процесс управления границами стадий связан с временными контрольными точками, при наступлении которых дирекция проекта принимает очередное решение о продолжении или прекращении проекта. Целями этого процесса являются подтверждение того, что в результате исполнения текущей стадии имеются в наличии все ранее запланированные результаты, обеспечение дирекции проекта информацией, фиксирование объективных показателей, свидетельствующих о продвижении.
Процесс стадийного контроля описывает мониторинг и контроль деятельности лидера проекта, отвечающего за запланированный ход событий и своевременное реагирование при возникновении нештатных ситуаций. В течение всей стадии руководитель проекта осуществляет цикл действий, состоящий из определения подлежащих решению задач, сбора информации о ходе выполнения соответствующей работы, фиксирования изменений, обзора ситуации, предоставления отчетов и предпринятия необходимых корректирующих действий.
Процесс управления созданием продукта ставит своей целью обеспечение того, чтобы требуемые продукты в ходы проекта действительно создавались. При этом осуществляется контроль того, что выполняется вся необходимая работа по созданию этих продуктов, производятся контроль за ходом их построения и последовательная корректировка прогнозов по срокам, действует контроль качества, создаваемые продукты представляются для одобрения заказчиком.
Процесс завершения проекта ставит своей целью обеспечение контролируемости стадии завершения проекта. Большая часть работы представляет собой входные данные для принятия решения дирекцией проекта о его завершении — запланированном или вынужденном. При этом могут осуществляться контроль соответствия результатов документированным положениям при инициации проекта, подготовка финальных отчетов, обеспечение последующей поддержки и обучения и т.п.
Процесс планирования представляет собой повторяемое действие и играет важную роль в других процессах, в частности — при планировании стадии инициации проекта, планировании всего проекта, планировании стадий и подготовке планов по прогнозированию и преодолению возможных нештатных ситуаций.
Перечисленные процессы и их взаимодействие описаны в стандарте существенно подробнее, чем здесь, однако это описание дается в формате констатации требований к организации, которым она должна удовлетворить для соответствия данному стандарту.
Рамочный стандарт PMBOK
Стандарт включает в себя несколько областей знаний проектного менеджмента. В соответствии со схемой, область управления интеграцией проекта описывает процессы, требуемые для обеспечения полноценной координации разнообразных элементов проекта. Она включает разработку плана проекта, исполнение плана проекта и общий контроль изменений.
Область управления пространством проекта описывает процессы, требуемые для обеспечения того, чтобы в процессе проекта выполнялась та и только та работа, которая в действительности необходима для успешного завершения. Включает инициирование, а также определение, планирование, верификацию и контроль изменения пространства деятельности.
Область управления временем проекта описывает процессы, требуемые для обеспечения своевременного завершения проекта. Включает определение, последовательность, оценку продолжительности, разработку и контроль план-графика проектной работы.
Область управления стоимостью проекта описывает процессы, требуемые для обеспечения исполнения проекта в рамках утвержденного бюджета. Включает планирование ресурсов, а также оценку, учет и контроль расходов.
Область управления качеством проекта описывает процессы, требуемые для обеспечения соответствия результатов проекта поставленным задачам. Включает планирование, обеспечение и контроль качества.
Область управления участниками проекта описывает процессы, требуемые для повышения эффективности работы участников проекта. Включает организационное планирование, подбор персонала и создание команды.
Область управления информацией по проекту описывает процессы, требуемые для своевременного и соответствующего генерирования, подбора, распространения, хранения и предоставления информации о проекте. Включает планирование распространения информации.
Область управления рисками проекта описывает процессы, связанные с идентификацией, анализом и реагированием на проектные риски. Включает идентификацию и ограничение рисков, разработку запасных вариантов и их контроль.
Область управления внешними ресурсами проекта описывает процессы, требуемые для привлечения внешних ресурсов и услуг. Включает планирование такой деятельности, подбор источников ресурсов и управление ими.
Тактическая модель SPM
В модели определяется набор действий, которые применяются на всех вложенных уровнях проекта, по мере их применимости. При этом решение каждой задачи может представлять собой отдельный проект, т.е. суб-проект (уровни вложенности не ограничиваются).
В число действий, детально описываемых в данной модели, в частности, входят:
- спецификация цели [суб-]проекта;
- составление списка задач [суб-]проекта;
- определение лидера [суб-]проекта (ответственного лица);
- распределение задач в [суб-]проекте;
- риск-анализ [суб-]проекта;
- мониторинг и информационный менеджмент [суб-]проекта.
М.В. Вигдорович