Рп в ит кто это

5 составляющих счастья ИТ-проекта: Взгляд РП

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

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

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

Эффективные проектные метрики:

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

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

1. Разрастание масштаба или Scope creep

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

На что обратить внимание: Ключевой вопрос при оценке Scope creep — насколько влияют на ход проекта изменяющиеся требования? Как изменения влияют на количество новых задач? Регулярное отслеживание данного параметра поможет оставаться на плаву и не взваливать на команду больше необходимого.

В качестве примера — типичная статистика по релизу. 2 промежуточных статуса (Approved, Committed) – не актуальны в контексте Scope creep. А вот то, что входит в статус New – это и есть иллюстрация разрастания. Из этой статистики видно, что 71 из 329 – это больше 21%, в данном случае, приходится на новые задачи (то, что было заведено как новые требования).

Возьмем типичный Burndown chart проекта, в котором новые требования учитываются под осью «Время». Это позволяет получить наглядную картину роста scope creep. Если бы его не было, то дата окончания работ была бы в точке Т1, а текущий тренд говорит, что вероятная дата окончания будет значительно позже – в Т2.

2. Качество наших проектных оценок

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

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

В современных реалиях, в Agile проектах, практически нереально застраховаться от ошибки в оценке задач. И чем дальше мы находимся от этапа разработки, тем менее точной будет наша оценка (тут актуальна концепция Конуса Неопределенности). Можно попробовать улучшить качество оценки с помощью PERT (Project Evaluation Review Technique). Суть в том, чтобы дать оптимистичную (To), пессимистичную (Tp) и наиболее вероятную (Tm) оценки на задачу. И по фoрмуле (То + 4*Tm + Tp)/6 получить ожидаемую оценку по задаче.

С точки зрения контроля графика выполнения проекта, можно отойти от «Критического пути» проекта к несколько модифицированному подходу предложенному Голдраттом – метод «Критической цепи». Он дает больше гибкости за счет использования буферов при оценке задач. Что, в свою очередь, должно снизить риски разломать план-график проекта.

3. Статус здоровья команды

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

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

Статус здоровья команды — это одна из ключевых метрик успешности проекта. Понятно, что она напрямую связана как с качеством коммуникаций в команде, так и с рисками потери сотрудника, его экспертизы и опыта из-за того что он решил покинуть проект/компанию. Причины могут быть различными: от конкурентного уровня оплаты до семейных обстоятельств, но, в данном случае, говорим о вовлеченности и компетенциях. Очень эффективный фреймворк был предложен Синтией Максвелл (на тот момент Director of Engineering at Yahoo). Она предлагает отслеживать сложность задач и рост экспертизы, знаний сотрудников, по ходу проекта.

Две оси (Challenge – сложность задач, Skills – уровень знаний и экспертизы). Нужно периодически отслеживать текущий статус сотрудников в проектной команде. Задачи, которые они выполняют, должны быть достаточно амбициозными и сложными. При этом, в ходе их выполнения должны приобретаться новые знания.

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

4. Легкость масштабирования проекта

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

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

В качестве положительного примера могу привести проект «Рексофт», на котором после 4 последовательно реализованных этапов с все большим и большим масштабом заказчик просто забронировал ресурсы команды из 7 инженеров, 3 тестировщиков и двух менеджеров на год вперед — то есть, он пока еще не был уверен, что конкретно предстоит делать, но был готов к обеспечению потенциальных задач исполнителями.

5. Всеобщее счастье

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

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

На что обратить внимание: одним из следствий удовлетворенности заказчика (и успешности проекта) является то, готов ли он перейти от фиксированных затрат на проект к модели «time & material». Как правило, это говорит о высоком уровне доверия исполнителю. Члены команды могут выражать счастье в трех плоскостях: вовлеченностью в проект, ростом их компетенций и материального вознаграждения. Возможно, своевременные опросы удовлетворенности обеих сторон помогут отследить параметры счастья. Но это не точно.

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

• управление проектами
• ит-проекты
• agile

• Блог компании Reksoft
• Управление проектами
• Agile

Руководитель ИТ проекта

Руководитель ИТ-проектов – сотрудник, целью которого является сопровождение конкретного проекта от планирования до реализации. Критерием успеха здесь является соответствие результата поставленным задачам.

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

Квалификационные требования

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

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

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

Функциональные обязанности

Руководство проектом в ИТ-сфере включает в себя следующие должностные обязанности:

• Определение сроков завершения различных этапов работы;
• Разработка плана действий;
• Расчет финансовых затрат на закупку оборудования, оплату труда, иные необходимые цели;
• Ежедневное управление персоналом, участвующим в работе;
• Контроль качества;
• Определение возможных рисков и их минимизация;
• Найм субподрядчиков для исполнения отдельных функций;
• Своевременное внесение изменений в планы и сроки, если того требует ситуация;
• Обеспечение связи между всеми участниками реализации проекта, сведение их усилий к единому результату.

Профессиональные навыки

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

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

Чтобы управлять проектами, надо ориентироваться в экономических вопросах, уметь рассчитывать бюджет и контролировать его исполнение. Руководитель ИТ-проектов должен понимать – как минимизировать затраты и в каких случаях снижение затрат нежелательно из-за негативного влияния на сроки и качество работы. Хороший руководитель проектов в сфере ИТ способен исчерпывающе объяснить свою позицию заказчику.

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

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

Где пройти обучение на руководителя IT-проекта

Возможность повысить квалификацию для руководителей ИТ-проектов, подтвержденную дипломом Высшей Школы Экономики, реализована в ВШБИ НИУ ВШЭ на программе профессиональной переподготовки «Управление ИТ и ИТ-проектами» или программе МВА-CIO. ← Назад к списку

Кто такой руководитель проекта по мнению владельца бизнеса и как с этим бороться

Я хотел бы поговорить о том, что сегодня в России понимается под проектным управлением и в чем, по мнению многих, заключается роль руководителя проекта.

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

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

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

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

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

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

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

Итого, проекты часто путают с процессами, а руководителей проектов со специалистами или операционными руководителями. К чему призываю? Называть вещи своими именами, а для этого читать матчасть — взяться и прочитать, как бы он страшно не выглядел, PMBOK, PRINCE2 Manual, сходить на курсы по внедрению пары-тройки более легких феймворков типа P3Express, Канбан и при случае подсказать в непринужденной дружеской беседе знакомому владельцу бизнеса что есть что. Глядишь, через некоторое время мы с вами и увидим позитивные сдвиги в массовом сознании.

• руководитель проекта
• проектное управление

• Управление проектами
• Читальный зал

Руководитель и администратор проекта: функции и особенности взаимодействия

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

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

Руководитель проекта

Руководитель проекта (РП, менеджер проекта, project manager, РМ) – лицо, на которое возлагается персональная ответственность за оперативное управление проектной командой и проектом в разрезе областей знаний (управление рискам, коммуникациями, бюджетом, сроками и др.) для достижения целей, показателей и результатов проекта. Чтобы проект стал успешен, руководитель проектов обеспечивает:

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

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

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

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

Должностные обязанности руководителя проекта

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

Работа с ресурсами проекта:

• формирование, управление, развитие проектной команды;
• разработка и управление реализацией плана коммуникаций участников проекта;
• разработка и мониторинг достижения показателей эффективности проектной команды;
• реализация системы стимулирования и мотивирования проектной команды.

Управление реализацией проекта:

• оперативное управление проектом, контроль своевременного и качественного выполнения работ;
• управление изменениями в проекте: корректировка плана работ и согласование вносимых изменений заинтересованными сторонами проекта;
• обеспечение своевременного предоставления информации всем участникам проекта;
• организация разработки и согласования документов по проекту на всех фазах жизненного цикла Обеспечение своевременной передачи результатов проекта заказчику.

Для роли руководитель проекта очень важны такие личные качества как: нацеленность на результат, коммуникативность, гибкость клиентоцентричность, эмоциональный интеллект и прагматичность.

Чтобы полноценно выполнять обязанности, руководитель проекта должен уметь:

• Быстро переключаться между проектными событиями, расставляя приоритеты, учитывая различные стороны проекта: финансовую, экономическую, технологическую и функциональную;
• Легко переходить от локальных, очень конкретных вопросов задачного контекста на тактический и стратегический уровень функций управления, проявляя порой недюжинную эрудицию и интеллектуальную гибкость;
• Проявлять гибкость при взаимодействии с разными участниками проекта, выстраивая гармоничное взаимодействие между интересами индивидуальных исполнителей и всей команды, между стейкхолдерами разных уровней и ценностных ориентаций;
• Проявлять эмоциональный интеллект, сплачивая команду и не идти на поводу у различного рода манипуляций;
• Быть готовым предъявлять высокие требования к результатами получать в самый важный момент результат, сильно отличающийся от идеального;
• Держать общую ценность и цели в фокусе внимания команды с тем, чтобы она регулярно мобилизовалась на едва различимый изначально успех;
• Быстро восстанавливаться после стрессов и добиваться успеха.

Должностные обязанности руководителя проекта включают большой блок работ по документальному обеспечению и проведению совещаний. Высокий уровень управления процессами в организации предусматривает большое количество документации и регламентов. Руководитель проектов оказывается в непростой ситуации: совместить рутинную работу по документообороту и заниматься развитием проекта очень непросто. Очень важно вовремя осознать свой уровень погруженности в документооборот и рутинные задачи и предпринять необходимые действия по решению возникающей проблемы. В такой момент руководитель должен задуматься о введении роли Администратор проекта.

Администратор проекта

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

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

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

Ключевые роли администратора проекта:

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

Квалифицированный администратор проектов способен вести не один проект и выступать помощником у нескольких руководителей проектов.

Типовые должностные обязанности администратора предусматривают:

помощь в организации совещаний, подготовку и согласование итоговых протоколов, контроль извещений и исполнения решений совещаний

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

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

Как грамотно распределенный функционал АП может повлиять на повышение эффективности работы РП

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

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

Функции, которые нужно делегировать администратору проекта для совместного построения эффективной работы:

1. Формирование и обновление реестра контактов. Оперативное формирование реестра контактов участников проекта (с указанием их ролей и должностей, руководителей, короткого описания) — основная задача Администратора проекта. Крайне важно, чтобы все участники проекта могли в любой момент найти нужную информацию о контактах участников команды. А дополнительное ведение информации Нелишним будет указать и дни рождения сотрудников — поможет планированию мотивационных мероприятий.
2. Кодирование. Администратор проекта должен разработать систему кодирования документов, которые находятся в рабочих папках и ознакомиться команду с правилами кодировки. Очень важно, чтобы каждый участник команды в любой момент мог найти необходимый актуальный документ.
3. Создание и ведение архива. Администратор проекта поддерживает в актуальном состоянии рабочую область проекта. Структура архива должна быть максимально простой. Документы внутри архива должны быть распределены по интуитивно понятным папкам, в соответствии с заданными правилами кодирования в наименованиях. Администратор проекта должен быть единственным участником, который вносит документацию в архив.
4. Организация и протоколирование совещаний. План проведения регулярных совещаний должен быть заблаговременно подготовлен минимум на месяц вперед. Перед совещанием о нем заранее оповещаются все участники, формируется повестка, которая направляется участникам минимум за сутки до совещания. В ходе совещания составляется протокол, формулировки которого согласуются сразу. Безусловно, в случае необходимости резервируется время для формулирования особого мнения или уточнения деталей, однако принципиальные вопросы должны решаться на месте, а решения должны тут же фиксироваться в протоколе. Поручения из протоколов сразу же заносятся в Журнал — один из основных инструментов управления. Ведение этого журнала можно возложить на администратора проекта: именно он будет напоминать исполнителям о том, что подходит срок исполнения поручения, отслеживать выполнение, получение документов и тд. Руководитель проектов подключается лишь тогда, когда поручения не выполнены.
5. Сбор и обработка табелей учета рабочего времени. Однако опыт показывает, что грамотное использование данного инструмента помогает руководителю проекта понимать ситуацию с загрузкой команды, эффективностью отдельных сотрудников, а также позволяет с цифрами в руках обосновывать дополнительную потребность в человеческих ресурсах. На основании табеля учета рабочего времени администратор проекта может проанализировать ситуацию с переработками и потерями рабочего времени и поделиться своими наблюдениями с руководителем проекта.
6. Разработка отчетных форматов. Администратор проекта может предложить несколько вариантов отчетных форматов уже на основании своего опыта и наблюдений для оценки ситуации на проекте, при этом отразить в ней наиболее важную информацию. Составление отчетов вручную поможет понять источники данных и порядок их обновлений. В дальнейшем можно будет предложить более сложный дизайн. По прошествии некоторого времени можно будет понять какую часть работы можно было бы автоматизировать и поставить задачу программистам.
7. Контроль предоставления регулярной отчетности в проектную команду, интеграция отчетов Данная задача коррелирует с задачей ведения Журнала: в данном случае отчет является результатом поручения о его подготовке. Администратор проекта направляет автоматически повторяемое уведомление о подготовке и отправке отчета, вносит соответствующий пункт в Журнал, а затем контролирует предоставление информации, необходимой для формирования сводных отчетов по проекту. В случае если отчет в срок не пришел (либо пришел, но в некорректном формате), вопрос эскалируется на руководителя проекта. В случае своевременного предоставления отчета дальше начинается работа руководителя проекта по оценке статуса выполнения работ исполнителями.
8. Разработка и актуализация календарно-сетевого графика проекта. На первом этапе работы над проектом роль планировщика задач может взять на себя администратор проекта. Для этого нужны базовые знания и навыки работы в соответствующих программных продуктах.

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

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