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

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

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

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

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

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

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

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

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

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

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

About author View all posts Author website

Александр Кольцов

Закончил программу MBA при Российской экономической академии им. Плеханова. Дипломная работа - "Внедрение корпоративной системы проектного управления в территориально распределенном Холдинге".
Внедряю ERP для заказчиков из Европы и США.
Опыт внедрения системы управления проектами в компаниях России и Беларуси.
Читаю тренинги по управлению проектами, внедрению КСУП, автоматизированным инструментам управления проектами.