Рп в бизнесе это

Прежде всего мы ассоциируем РП с необходимостью руководить проектами, но само понятие «проект» довольно часто используем неправомерно. Конечно, общие признаки проекта можно найти практически в любой деятельности, но то, что проект ограничен во времени и должен давать уникальный результат, никак не является достаточными условиями для него, а только необходимыми [1] .

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

Отсюда можно сделать вывод, что чаще всего мы (РП) играем роль не руководителя проекта, а администратора, роль статиста, но при этом наши KPI часто зависят от результатов этой так называемой «проектной деятельности». Да и сам проект назвать проектом с методологической точки зрения нельзя. Скорее всего это некоторые разрозненные куски операционной деятельности.

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

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

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

Администратор проекта: по указаниям и распоряжениям РП выполняет техническую работу, связанную с управлением проектом. Является основной точкой коммуникаций в проекте. Отвечает за коммуникации и документирование проекта.

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

Должен ли РП знать предметную область

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

С моей точки зрения это неправильно и не в лучшую сторону характеризует «персональщиков», которые сами не понимают сути и не могут донести ее до соответствующих руководителей. Попробую объяснить свою точку зрения.

Начнем с того, что управление проектом — это самостоятельная область знаний, которая требует отличной подготовки, практики и сдачи весьма нетривиальных экзаменов международного уровня. Много ли у нас в организациях ролей / должностей, требующих подтверждения компетенций на уровне международного сертификата? Более того, не каждый ИТ-директор имеет за плечами такое образование, хотя я считаю, что у CIO оно должно быть в обязательном порядке.

В настоящий момент существует далеко не одна методика проектного управления. К самым популярным я отношу PMBoK (Project Management Body of Knowledge, США), AFW (AFW Wirtschaftsakademie Bad Harzburg GmbH, Германия) и PRINCE2 (Projects in Controlled Environments, Великобритания). Уверен, что читатели знают как минимум одну из них, а многие даже имеют сертификаты разных методологий. К слову сказать, ни в одной из них нет указания на предметную область, в которой данная методология работает лучше или применяется чаще. Проектная технология не завязана на предметные области, т. е. может быть применена для любых областей знаний — и для строительных, и для ИТ-проектов, и для проектов в производстве.

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

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

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

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

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

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

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

Влияет ли проект на организацию?

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

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

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

Затем мы осознаем проблему как разрыв. В текущий момент у нас нет такой возможности, но в будущем, после внедрения ERP-системы, эта возможность появится и мы сможем все посчитать. Надо сделать проект, устраняющий разрыв, т. е. внедрить ERP-систему.

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

Изменение (переход) будет включать в себя:

• изменение процессов работы сотрудников;
• изменение ИТ-инфраструктуры, ИТ-ландшафта и проч.

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

Если проект сложен, то его, возможно, придется разделить на несколько подпроектов, например:

• подготовка ИТ-инфраструктуры;
• перепроектирование процессов;
• изменение организационной структуры;
• внедрение ERP-системы;
• ипрочие подпроекты.

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

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

Нам не нужен свой РП?

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

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

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

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

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

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

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

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

Если этот список сравнить со списком основных нарушений при организации проектов, который был представлен в первом разделе, становится очевидным, что надо либо всё делать правильно, обеспечивая РП и офис управления проектами (ОУП) необходимыми полномочиями и выполняя все правила, либо не браться за эту задачу вообще.

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

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

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

Давайте подытожим

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

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

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

Что лучше, ОУП или РП в каждом подразделении? Наверное, в этом как раз и состоит та уникальность, которая присуща проектной деятельности. Решить, какова организация должна быть в будущем, обосновать, спланировать и выполнить намеченное — это и есть ваш проект, проект изменений.

Примечания

Источник: www.tadviser.ru

Правильная формула рентабельности продаж по балансу с примерами

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

Понятие рентабельности продаж (РП или ROM)

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

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

• Если РП менее нуля, то можно сделать вывод о работе предприятия себе в убыток, так как в этом случае себестоимость превышает выручку.
• Рентабельность нулевая – знак того, что организация затрачивает на производство ровно столько же, сколько приобретает после продажи.
• Положительная рентабельность продаж означает, то что проект является прибыльным. Чем больше показатель, тем лучше для предприятия.

Понятно, что показатель рентабельности очень зависит от сферы деятельности предприятия. Например, в банковской деятельности этот показатель способен достигать 100%, а в тяжелой промышленности – и 3%.

Увеличение рентабельности продаж

Увеличение РП, несомненно, положительный фактор для любой компании.

Об увеличении рентабельности можно говорить если:

• При анализе выяснилось, что темп роста дохода больше темпа роста издержек.

На это могло повлиять следующее:

• Увеличился объем продаж.
• Изменился ассортимент выпускаемой продукции.

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

• При анализе выяснилось, что темп снижения доходов гораздо меньше, чем темп снижения издержек.

К этому, как правило, может привести:

• поднятие цен на произведенную продукцию;
• внесение изменений в структуру ассортимента продаж.

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

Рост выручки и уменьшение затрат. Это достигается, если:

• внесены изменения в ассортименте продаж;
• были изменены уровни затрат;
• повышены цены.

Эта ситуация, бесспорно, является положительной для организации.

Её уменьшение

Об уменьшении РП можно говорить в следующих случаях.

Темп роста издержек больше, чем темп роста дохода

На это могут оказывать влияние следующие причины:

• уменьшение цен;
• изменение в сторону увеличения уровня затрат;
• изменения в структуре ассортимента товара.

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

Темпы снижения доходов быстрее темпов снижения издержек

Эта ситуация, как правило, возникает только по одной причине:

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

Рост затрат и уменьшение выручки

Причины, которые могли повлиять на этот факт:

• были снижены цены;
• было решено внести изменения в структуру ассортимента товара;
• увеличены нормы затрат.

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

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

Формула

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

Расчет формулы рентабельности продаж

В общем виде формула РП выглядит следующим образом:

РП = прибыль (убыток) от продаж / выручка от продаж * 100%

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

Формула 1: расчет валовой РП

РП = валовая прибыль : выручка от продаж * 100%

Данный показатель отражает долю прибыли в каждой денежной единице, заработанной предприятием.

Формула 2: расчет операционной рентабельности (рентабельности продаж по EBIT)

РП = прибыль (убыток) от налогооблажения : выручка от продаж * 100%

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

Формула 3: расчет чистой рентабельности

РП = чистая прибыль (убыток) : выручка от продаж * 100%

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

Формула по балансу

Согласно новой форме баланса выше перечисленные формулы рентабельности продаж будут выглядеть соответственно следующим образом:

Общая формула:

РП = стр.2200 : стр.2110 * 100%,

Формула 1:

РП = стр.2100 : стр.2110 * 100%,

Формула 2:

РП = стр.2300 : стр.2110 * 100%,

Формула 3:

РП = стр.2400 : стр.2110 * 100%.

Согласно старой форме баланса эти же формулы выглядят иначе:

Общая формула:

РП = стр.050 : стр.010 * 100%,

Формула 1:

РП = стр.029 : стр.010 * 100%,

Формула 2:

РП = стр.140 : стр.010 * 100%,

Формула 3:

РП = стр.190 : стр.010 * 100%,

где: РП – рентабельность продаж;

Важно! Актуальная (новая) форма отчетности утверждена Приказом Минфина РФ от 02.07.2010 г. № 66н.

Примечание: С 01.01.2013 г. отчет о прибылях и убытках именуется отчетом о финансовых результатах.

Коэффициент РП и его формула

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

Как же следует рассчитывать коэффициент рентабельности продаж:

К РП = прибыль (убыток) от продаж / выручка от продаж

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

Как же интерпретировать рассчитанные значения

К примеру, рассчитанная рентабельность РП составляет 25%. Это говорит о том, что на каждые 100 денежных единиц предприятия приходится 25 единиц прибыли. Также можно пояснить ответ следующим образом: на каждый рубль приходится 25 копеек прибыли.

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

Пример расчета

Выручка от продаж предприятия ОАО «Иволга» за 2013 год составила 10 млн. рублей, а в 2014 году она увеличилась до 12 млн. Операционная прибыль (до налогообложения) в 2013 году составляла 3 млн. рублей, а в 2014 году она возросла до 3,8 млн. Как изменилась операционная РП?

Решение:

Рассчитаем операционную рентабельность продаж в 2013 году:

РП2013 = 3млн./10млн.*100% = 30%.

Рассчитаем этот же показатель за 2014 год:

РП2014 = 3,8млн./12млн.*100% = 31,7%.

Рассчитаем изменение рентабельности продаж:

∆ РП = 31,7% – 30% = 1,7 %.

Вывод: В 2014 году рентабельность продаж по прибыли до налогообложения увеличилась на 1,7%, что, бесспорно, является положительной тенденцией для предприятия ОАО «Иволга».

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

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

Источник: intless.ru

Полномочия менеджера проекта

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

Ниже я привожу свои мысли, как я вижу ситуацию в теории, и как это чаще всего встречается в моей практике.

Терминология

Для начала следует определиться с ключевой терминологией. Предлагаю использовать терминологию из руководства PMBOK.

Спонсор — лицо (или группа лиц), предоставляющее ресурсы и поддержку для проекта и ответственное за достижение успеха. Устанавливает приоритет проекта в организации; предоставляет ресурсы; утверждает уровень приоритетности ресурсов. Хочу отметить, что, несмотря на то, что в русском языке слово спонсор ассоциируется в первую очередь с деньгами, и что финансирование очень важно для проекта, у спонсора так же есть другие не менее важные обязанности.

Заказчики — лица или организации, которые будут одобрять продукт, услугу
или результат проекта, а также управлять ими. Формируют требования к результатам проекта, принимают и одобряют конечные результаты.

Проектная команда – остальные члены команды, которые выполняют работу по проекту.

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

Теория полномочий РП (идеальный проект в идеальной компании)

Я вижу следующую картину идеальных полномочий менеджера:

Коммуникационные полномочия

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

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

Организационные полномочия

Участие РП на фазе инициации проекта
Согласование целей проекта при его инициации/старте дает возможность сформулировать, зафиксировать и согласовать цели проекта со всеми заинтересованными лицами (с Заказчиком, Спонсором и проектной командой) на старте проекта.

Project Management Institute (PMI, http://www.pmi.org) настаивает на том, и я всецело поддерживаю эту позицию, чтобы РП привлекался к проекту как можно ранее (фаза инициации). В идеале, до заключения контракта, чтобы можно было оценить реалистичность обещанного заказчику проектного треугольника (сроки, функционал, бюджет).

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

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

Полномочия, связанные с командой

Один из ключевых моментов успешного завершения проекта является формирование эффективной команды. Для этого требуется:

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

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

Возможность мотивировать людей:

Мотивация, требующая выделения финансовых ресурсов, которая, в свою очередь, делится на:

Финансовая мотивация — премии, оплата сверхурочных/выходных, бонусы…

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

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

Практика (как это происходит в реальной жизни):

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

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

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

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

Все перечисленные выше пункты можно разбить на три типа:

• Финансовые – которые требуют финансовых вложений
• Организационные – которые регламентируются правилами компании
• Личностные – которые требуют применения личных навыков РП

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

(*) — Здесь следует читать как «Более тщательным планированием» — криво, но по сути – так как РП и так должен тщательно планировать, а в данном случае еще «более тщательно».

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

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

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

Поясню последнюю мысль подробнее.

Можно заметить, что у РП есть возможность, в основном, влиять на организационные полномочия. Личностные полномочия (софт-скилы) либо есть, либо нет, и успеть их развить за время проекта — маловероятно. С другой стороны, если они есть, то их никто не может забрать или «запретить» их применять на проекте.

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

Довольно часто удается успешно решить вопрос с отсутствием какого-то полномочия посредством личных качеств РП. Например, договориться со спонсором о выделении 15 минут в неделю, даже если в компании в отношении такой коммуникации «так не принято».

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

Кто умудряется уговорить завхоза на более удобные столы/стулья, гарнитуры и телефоны…

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

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

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

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

С уважением,
Олег Пономарев, PMP

Источник: habr.com