Начинаете управление проектами с автоматизации? Готовьтесь к проблемам

Поводом к написанию статьи стал звонок одного моего коллеги, для которого несколько лет назад я внедрял корпоративную систему управления проектами (КСУП). Сейчас его компания занимается девелопментом полного цикла. Собеседника интересовал вопрос: какую систему автоматизации я порекомендую для управления его проектами? Признаюсь, его вопрос застал меня врасплох. «С ходу» я предложил четыре или пять программных продуктов, которые представлены на рынке автоматизации. А затем, спохватившись, задал вопрос, который меня сильно беспокоил: «А зачем вам автоматизация?». На том конце трубки возникло явное замешательство. Я перефразировал свой вопрос: «Какие проблемы вы бы хотели решить с помощью информационной системы?». Он признался, что очень хочет получить такую же систему управления, с которой он уже когда-то работал и решил начать с развертывания информационной системы. Немного странно, неправда ли? На самом деле такая ситуация встречается сплошь и рядом.

Договоримся о понятиях. Под информационной системой управления проектами «ИСУП» я понимаю программный продукт или их совокупность, которые автоматизируют процессы управления проектами в рамках всей организации. Настольные средства руководителя проекта, например, MS Project, под это определение не попадают. Иными словами, если ваше внедрение ИСУП — это установка всем пользователям MS Project, то никаких рисков я здесь не вижу. И еще. В качестве отправной точки я выбрал постановку задачи высшим руководством компании: увеличить число успешных проектов в компании. Понятно, что если ставилась явная задача внедрить ИСУП, то проблематика теряется.

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

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

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

Проектные роли и их полномочия не определены. Если организация не договорилась кто и за что отвечает в управлении проектом, то конфликтов не миновать. Руководитель проекта может отсутствовать в принципе (конечно, есть активный «идеолог», но ответственность за его успех или неуспех он не несет). Заказчик проекта отсутствует (вместо него есть таинственный «куратор», который отвечает непонятно за что (психолог, наверное ;)).  В такой неразберихе автоматизация явно преждевременна. Роли на сервере проектов розданы по принципу «чтобы было». Ничего плохого в последнем, наверное, нет. Но согласитесь, что лучше давать руководству только ту информацию, которую оно ищет, а не все подряд. Берегите нервы и время шефа.

Информационная система не поддерживает модель принятия решений в проектах. Я люблю спрашивать менеджеров, как в ИСУП можно посмотреть проекты, которые инициированы, но еще не авторизованы в работу? Как по ним можно увидеть плановый срок разработки Устава или Плана управления проектом? Ответ чаще всего нечеткий или отсутствует. Это означает, что модель принятия решений в компании по проектам не определена или ИСУП ее не поддерживает. Поясните мне, какой смысл в инструменте автоматизации, если мы не договорились как будем принимать решения по проектам?

И в качестве вывода: руководство не доверяет информации, предоставляемой сервером проектов. У руководства сложилось ощущение, что разобраться без посторонней помощи в Сервере проектов оно не в состоянии (вспомните про бардак, который там происходит). А персонал уверен, что «проектное управление» — очередное сумасшествие менеджмента, потому что для выполнения простой работы требуется выполнить много странных действий. В такой атмосфере выращивание культуры проектного управления крайне сложно и рискованно.

Если вы все-таки решились на начать внедрение управление проектами с развертывания ИСУП, то позволю себе несколько рекомендаций:

• Ответьте сами себе: что в организации скрывается под термином «проект»? Какие проекты должны попадать на сервер? В какой момент времени? Без этой «мелочи» двигаться дальше нет смысла.
• Договоритесь о главных проектных ролях и определите их ответственность в реализации проекта. Это пригодится при настройке ролей в ИСУП.
• Используйте простые модели принятия решения. Поддерживайте у руководства ощущение простоты и легкости в работе с системой. Если появится доверие к системе, то и решения будут приниматься на основе сведений, предоставленных ИСУП.