Коллектив авторов - Управление проектами. Фундаментальный курс

• Название: Управление проектами. Фундаментальный курс
• Автор: Коллектив авторов
• Жанр: Экономика
• Год: 2013
• ISBN: 978-5-7598-0868-8

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

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

---

• простота и понятность интерфейса;

• доступная ценовая политика на лицензии.

Однако не нужно думать, что решение Microsoft – единственно правильный выбор, так как предприятиям есть смысл рассматривать при внедрении ИСУП решения и от других производителей.

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

• Списки справочников в системе и список объектов, для которых используются данные справочники. Например, в системе будет вестись справочник подрядчиков, и он будет связан работами проекта в ИСУП, чтобы можно было указать, на какую работу назначен какой подрядчик.

• Список экранных и отчетных форм, которые будут использоваться для ввода и просмотра данных в системе.

• Профили ролей пользователей в системе, набор функций, которые доступны пользователям с данной ролью в системе, и набор объектов, к которым пользователи будут иметь доступ на чтение, редактирование.

Например, роль руководителя проекта в ИСУП характеризуется тем, что пользователи, которым присвоена данная роль в ИСУП, смогут иметь доступ на запись к тем проектам, где они указаны как руководители проектов, смогут просматривать, но не редактировать список ресурсов, смогут назначать ресурсы на работы своих проектов, но не изменять характеристики ресурсов и т. д. Комплект функций, которые могут быть доступны тем или иным профилям, зависит от платформы.

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

Настроенная ИСУП должна сопровождаться «классической» необходимой документацией (руководство пользователя и руководство технического администратора) и регламентами работы с ИСУП по ролям участников проектной деятельности.

Руководства пользователей должны быть не только по стандартной функциональности, но и по тем функциям, которые были модернизированы в ходе настройки ИСУП под методологию управления проектами предприятия.

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

• После подписания приказа о старте проекта администратор проектного офиса информирует посредством электронного сообщения руководителя проекта о присвоении шифра проекта и о создании пустого проекта в ИСУП с определенным названием.

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

• После разработки календарного расписания проекта руководитель проекта должен распечатать базовый календарный план по вехам из ИСУП, согласовать его в соответствии с методологией управления проектами, отсканировать подписанный документ, выложить в библиотеку проектных документов и уведомить проектный офис о том, что необходимо зафиксировать базовый календарный план с ИСУП на основании подписанного документа.

Как видно из примера, регламент работы в ИСУП должен обеспечивать единообразие планирования и контроля проектов всеми руководителями проектов для обеспечения получения сводной отчетности.

Для приемки ИСУП в эксплуатацию рекомендуется провести испытания настроенной ИСУП на контрольном примере. При этом, учитывая, что тестируется не разработанное с нуля под заказчика ПО, а настроенная платформа, нужно обращать особое внимание на то, насколько в ИСУП учтены функциональные требования, насколько понятна и удобна в использовании сопроводительная документация.

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

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

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

6.6. Функции проектного офиса компании при внедрении и развитии системы управления проектами

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

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

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

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