Что такое инициация проекта
Инициация проекта. Перечень необходимых документов
Инициация проекта (или запуск проекта) – это стадия убеждения руководства или инвесторов в необходимости выполнения проекта.
Запуск проекта всегда сопровождается подготовкой комплекта документов, обосновывающих его актуальность, необходимость и окупаемость. Данные документы рассматриваются заказчиком, инвестором и экспертами на проектном комитете. По результатам рассмотрения принимается решение о запуске проекта. Назначается руководитель проекта, и формируется проектная команда.
Таким образом, запуск проекта (или открытие проекта) проходит в несколько этапов:
Перечень проектных документов на стадии инициации
С целью защиты проекта на проектном комитете рабочая группа формирует пакет документов, который может включать следующие:
Концепция проекта – это основной документ, описывающий структуру проекта, цели, задачи, ограничения и допущения. Также она отражает будущий результат, сроки и способы его достижения, сведения о рисках и технико-экономических показателях. Написание концепции проекта – это тоже мини-проект со своими этапами и сроками.
Технико-экономическое обоснование (ТЭО) — это документ, обосновывающий целесообразность создания продукта или услуги. ТЭО содержит анализ затрат и результатов проекта. Оно позволяет инвесторам определить, стоит ли вкладывать деньги в предлагаемый проект.
Описание жизненного цикла проекта – это документ, предназначенный для описания основных этапов проекта со сроками и критериями прохождения контрольных рубежей.
Визуализация жизненного цикла проекта с основными этапами его реализации называется Дорожной картой.
Устав проекта – это документ, кратко описывающий:
Сводный план проекта – календарно-сетевой график проекта, детализированный до уровня работ и содержащий сведения об ответственных исполнителях работ.
Бюджет проекта – документ, описывающий подробное распределение входящих и исходящих денежных потоков проекта по периодам и статьям затрат. Финансовая модель проекта – документ, содержащий информацию о прогнозируемых денежных потоках проекта и показателях его экономической эффективности.
План управления рисками проекта описывает основные факторы возникновения рисков, их качественные и количественные характеристики, планы реагирования на риски, а также необходимые для этого ресурсы.
План управления коммуникациями проекта – документ, описывающий способы передачи информация о ходе, результатах, рисках и проблемах проекта.
Вообще не существует четко определенного перечня документов, требуемых для инициации проекта. Каждая организация в рамках проектного управления формирует свой перечень необходимых документов и их шаблоны.
Ошибки на стадии инициации проекта
Значительная часть проектов задумывается с целью получения конкретных результатов, имеющих финансовую ценность для участников проекта. Но прежде чем предпринимать усилия по воплощению идеи в жизнь, нужно обязательно оценить целесообразность реализации проекта, в том числе с экономической точки зрения.
Наиболее распространенными ошибками фазы инициации, приводящими к провалу проекта, являются:
Более подробно ошибки на стадии инициации проекта рассматриваются в соответствующей статье.
Результаты запуска проекта
Основными результатами при запуске проекта являются:
Теперь главная задача руководителя проекта – грамотно собрать проектную команду и организовать ее работу в соответствии с целями и задачами проекта. На руководителя проекта возлагается вся ответственность за успешный результат. Подробнее с функциями руководителя проекта на разных стадиях жизненного цикла можно ознакомиться в соответствующей статье.
А освоить навыки управления проектами и проектной командой на всех этапах жизненного цикла можно на онлайн-курсе «Эффективный руководитель». Данный курс содержит модули по управлению проектами, а также модули по управлению собственной эффективностью, командой и коммуникациями. С программой курса «Эффективный руководитель» можно ознакомиться на соответствующей странице сайта.
Инициация проекта. В чем суть нового проекта? Часть 3
Целью инициации проекта является получение обязательства начать проект. Вы хотите, чтобы клиент или спонсор могли принять обоснованное решение о переходе на этап планирования.
Как правило, первым шагом в инициации проекта является назначение менеджера проекта. В некоторых случаях руководитель проекта может быть назначен в проект после его утверждения.
Во время инициации проекта вы определяете проблему, которую должен решить проект, и собираете всю сопутствующую информацию. Как только у вас есть первоначальное определение проекта, пришло время подготовить устав проекта, документ, который формально описывает проект и излагает полномочия менеджера проекта.
В этой главе мы рассмотрим ключевые элементы определения проекта и что входит в устав проекта на стадии его инициации.
Кто такие заинтересованные стороны проекта
Термин «заинтересованная сторона» означает конкретного человека или группу людей, которые заинтересованы в результатах проекта. Это может быть клиент, отделы, влияющие на проект, и даже люди, которые работают над задачами проекта.
Для руководителя проекта необходимо знать важность, влияние и заинтересованность заинтересованных сторон в проекте. Вам также необходимо знать их ожидания и вклад в проект. Таким образом, вы, как руководитель проекта, можете сосредоточиться на построении отношений с заинтересованными сторонами, которые оказывают наибольшее влияние на успех проекта.
Давайте рассмотрим основные виды заинтересованных сторон:
Иногда бывает сложно определить, кто является заинтересованными сторонами для вашего проекта, а также оценить, какие из них наиболее важны, и как эффективно с ними работать. Вот где пригодится документ анализа заинтересованных сторон или реестр заинтересованных сторон.
Цели, Требования и Интересы
Опыт постановки проектного управления
Опыт постановки проектного управления
Руководитель проектного офиса в ЗАО «АЭМ-Технологии». Работала в различных компаниях Санкт-Петербурга и Москвы, в том числе OpenWay, PricewaterhouseCoopers, Orange Business Services (France Telecom), НИПК «Электрон». Выполняла различные проекты, в том числе по внедрению информационных систем, разработке стратегий, организационным изменениям, реинжинирингу бизнес-процессов, разработке методологии и внедрению проектного управления в производственных компаниях.
В общем случае, проект постановки проектного управления можно разбить на пять этапов (рис. 1.):
Ниже мы обсудим их последовательно.
Рис. 1. Этапы проекта по постановке проектного управления.
Этап 1. Зарождение идеи: зачем нам проектное управление?
Для ясности дальнейшего текста введем два определения:
Внедренец — тот, кто должен поставить проектное управление (независимо от того, сотрудник ли это самой компании или внешний консультант).
Инициатор — топ-менеджер или владелец компании, которая хочет поставить это самое проектное управление.
Когда компания (точнее, кто-то из руководителей или владельцев) решает поставить проектное управление, за этим решением может стоять целое множество разных предпосылок. Соответственно, цели могут отличаться весьма значимым образом, при том что название будет одно: постановка проектного управления.
На мой взгляд, не бывает хороших и плохих целей при постановке инструментов управления, равно как и хороших или плохих условий и ограничений. Важно, чтобы картины мира участников не расходились между собой, а также с ожиданиями и возможностями самих участников. Разумеется, цели должны быть измеримыми и критерии их достижения должны быть понятны всем сторонам еще на начальном этапе.
Таким образом, на первом этапе, еще до старта проекта, внедренцу (как из самой компании, так и внешнему) необходимо ответить на вопрос: как руководители компании пришли к решению использовать проектное управление? Причем осознать ответ на этот вопрос важно не только для внедренца, но и для самого инициатора, поскольку нередко он не понимает, что же послужило реальным стимулом для такого намерения. Это только в красивых книгах по менеджменту все решения, принимаемые руководителями компании, обоснованны и разумны. Ответы на этот вопрос могут быть самыми неожиданными. Ниже в шутливой манере приведены самые частые предпосылки к постановке проектного управления.
Нередко мы имеем дело с действием одновременно нескольких предпосылок. Причем я ни разу не видела случая, когда и аудиторы посоветовали, и руководитель компании осознал необходимость постановки проектного управления, и на самом деле надо. Чаще всего встречается сочетание из двух факторов:
Короткое резюме этапа 1: По сути, в результате этого этапа стороны должны познакомиться друг с другом, присмотреться и сделать первичное исследование сложившейся ситуации и идеи использования проектного управления. А также понять, зрелое это решение (и насколько обдуманное) или эмоциональное и стоит ли вообще дальше идти в этом направлении.
Этап 2. Обсуждение идеи: что же конкретно мы хотим получить?
Понять предпосылки и исходные мотивы руководства компании недостаточно для запуска проекта. Дальше встает вопрос о конкретных целях внедрения проектного управления. Что хотим получить в результате постановки проектного управления? Как узнаем, что мы получили именно это? И чего нельзя допустить ни в коем случае?
И тут начинается сложно формализуемый очень интересный процесс. Для внедренца главная задача на этом этапе – не просто зафиксировать декларируемые задачи, но, что гораздо важнее, понять истинные цели постановки проектного управления, определить зазор между ними, оценить их выполнимость в условиях заданных ограничений.
На этом этапе важно «разговорить» инициатора внедрения, а последнему важно как можно более честно рассказать о том, что на самом деле ему нужно и что именно он ждет от проекта. По сути эта точка – первая встреча взаимных ожиданий и готовности. И первая точка возможных взаимных нестыковок.
Даже если у инициатора есть противоречия в его собственном представлении о желаемом (что случается весьма часто), нужно терпеливо выкладывать «кусочки мозаики» на стол и собирать всю картинку целиком. Справиться с известными противоречиями гораздо легче, чем с неизвестными. Не буду описывать случай, когда инициатор намеренно искажает информацию – в такой ситуации у проекта нет шансов. Думаю, нет смысла останавливаться на том, что вышеперечисленная информация (включая цели, ожидания и опасения) должна быть собрана со всех ключевых руководителей и центров влияния.
После того как цели и ожидания озвучены, задача обеих сторон – оценить готовность себя и второй стороны к реальным действиям. Здесь мне приходилось сталкиваться с заверениями:
«Мы действительно готовы к внедрению. Мы будем твердо настаивать на обязательности исполнения проектов по методологии для всех подразделений. Поддержка, полномочия – всё дадим».
На практике после первых шагов внедрения это часто выливалось в:
«Саботируют, не ведут проекты по утвержденной методологии? Нехорошо, ну поговори сама с ними еще раз».
Для успеха проекта жизненно необходимо понять реальную, а не декларируемую готовность и заинтересованность каждой из сторон. Понятно, что это непросто и инструментов для этого практически нет. Но тупиковых и не решаемых задач весьма немного. Вопрос, как правило, в цене решения. Причем для каждой из сторон.
В большинстве проектных методологий этапы 1 и 2 объединены в один – инициация проекта. Однако, на мой взгляд, этап 1 (знакомство и первичное исследование сложившейся ситуации и идеи использования проектного управления) необходимо выделять отдельно. По результатам этих этапов часто происходит формальное открытие проекта.
Короткое резюме этапа 2: В результате этого этапа стороны должны увидеть цели друг друга (причем как что нужно получить, так и чего никак нельзя не допустить), ожидания и возможности друг друга. И принять осознанное решение о том, нужны ли сторонам корректировки позиций или же пора в бой. В конце этого этапа часто очень не хватает возможности как-то явно убедиться, что все действительно одинаково друг друга поняли, видят общие цели и смогут вместе выполнить задачу. Распространенные инструменты, такие как устав проекта, соглашение о проекте или даже отчет об экспресс-обследовании организации, эту проблему не решают, а иногда и серьезно затуманивают реальное положение вещей.
Оценка реальной готовности компании к проектному управлению
На мой взгляд, одним из факторов успеха проекта постановки проектного управления будет проведение адекватной оценки уровня зрелости компании (хотя бы экспресс-оценки). Это обследование может быть проведено либо на этапе 2 (обсуждение идеи), что позволит лучше понять ситуацию as is и сформулировать адекватные цели проекта, либо на этапе 3 (детализация задачи). После этого необходимо сопоставить поставленные задачи с окном возможностей компании, а также ближайшими планами развития вовлеченных в проект ключевых отделов и сотрудников. Ибо, к сожалению, очень часто компании ставят себе правильные цели исключительно в расчете «на вырост» или ждут динамику развития проектного управления, характерную для совсем другой отрасли. Нередко компании хотят то, к чему сами будут готовы (дозреют) лет через пять – такое тоже бывает. И ведь желание правильное, цель верная, только в текущих условиях проектное управление «не заработает».
Процедуры инициации проекта
Развитие управленческой культуры, к сожалению, не всегда идет поступательно равномерно. Например, к тому, что процессам планирования проекта нужно уделять внимание на протяжении практически всей его продолжительности, многие руководители уже привыкли. Но вот инициация проекта далеко не в каждом случае воспринимается как нечто значимое. Тем не менее, практика показывает, что усилия и время, потраченные на процедуры инициации, способны значительно повлиять на качество и результативность работы над проектной задачей.
Что является основанием для начала проекта?
По существу, инициатором проекта может выступить любой сотрудник компании, если он в этом усматривает необходимость и понимает, что в штатном операционном режиме эту задачу не решить, и она требует объединения усилий целой группы участников. Однако для одной категории работников инициация является обязанностью, а для других групп она всего лишь похвальная активность. Если встать на позицию финансового управления и системы бюджетирования, то, как правило, именно руководители центров финансовой ответственности и обязаны в основной своей массе выступать инициаторами. Назовем основные причины рассмотрения идей и их проработки на предмет запуска в проектную реализацию.
В глобальном смысле все проектные решения связаны с проблемами управления. И при рассмотрении стратегического контекста проблематизации решение уникальных задач носит характер либо реализации возникающих возможностей, либо исключения затруднений (проблем) более низкого уровня. Напомню, что под проблемой в управленческом смысле мы понимаем неопределенность или противоречие в процессе познания явления деятельности. Их устранение невозможно с позиции действующей концепции управления для принятия решения.
В этом суть и базис стратегического планирования – выстроить такую последовательность уникальных задач (проектов), реализация которых выведет компанию на устойчиво новое состояние и концепции управления и уровня развития бизнеса. Процесс инициации с идейного замысла может начинаться в регламентной процедуре подготовки к сессии стратегического планирования или же тактического бюджетного процесса, а может возникнуть спонтанно, ситуационно. Последнее крайне нежелательно, но с этим поделать ничего нельзя, таковы наши современные реалии, мир порой меняется гораздо быстрее любых планов.
Цели и задачи проектной инициации
Проектная инициация – это не один процесс, а целая их группа согласно стандарту PMI. Они формируют начальную группу мероприятий для обеспечения состоятельности самой проектной идеи и запуска ее проектной реализации. При этом уже на данной фазе выявляются и даже устраняются многочисленные риски, отработать которые на стадии инициации гораздо выгоднее, чем после старта проекта. Инициация метафорична фразе из поговорки «Семь раз отмерь!», поскольку планирование и исполнение, начавшись практически одновременно, после приказа о начале проекта становятся значительно более затратными.
Среди задач-результатов процессов инициации выделяются следующие.
Планирование проекта следует сразу за его инициацией, но между процессами планирования и процедурами инициации имеется обратная связь, возникающая, например, по итогам получения закупочной документации. Ниже представлена часть процессной модели PMBOK, на которой мы и наблюдаем прямые и обратные связи между процессами.
Выбор проектных инициатив
Предположим идеальный вариант развития событий, при котором практически все инициативы выдвинуты к ежегодному мероприятию, посвященному стратегическому планированию. То есть в штатном режиме все инициативы обработаны проектным комитетом. Заслушаны предварительные презентации, по наиболее значимым мероприятиям уровня направлений деятельности и выше разработаны бизнес-планы. По существу, разработка ТЭО, бизнес-планов, иных предварительных расчетов является подготовкой к серьезной групповой работе над проблемами управления и развития компании.
Начинается сессия стратегического планирования или иное мероприятие подобного типа, на котором отрабатываются существенные затруднения для движения компании вперед по канве видения и миссии. Выявленные проблемы предваряют планирование, дерево проблем порождает построение дерева целей. Как раз в это время процесс подходит к весьма важному моменту: к рейтингу проблем и целей подводится пул проектных инициатив, которые начинают состыковываться между собой как некие «пазлы». Ведь еще в момент рождения идей они уже в большей своей части соответствовали присутствующей симптоматике и, возможно, еще не выявленным, а только ощущаемым проблемам.
Когда синхронизация проблем, целей и инициатив произведена, команда управленцев переходит к формированию рейтинга инициатив на основе трех параметров: проблемности, важности и достижимости результата. Под проблемностью мы понимаем уровень проблем, которым соответствует предлагаемое проектное решение. Оно оценивается в ходе коллективной работы присвоением инициативе балльной оценки от 0 до 10. Чем выше оценка, тем выше проблемность инициативы.
Процесс присвоения рейтинга инициативам продолжается по критерию важности. Важность может складываться от нескольких параметров, в зависимости от предпочтений управленческой команды. Один из вариантов разграничения критерия важности предусматривает оценку актуальности инициативы, ее эффективность и объем целевой группы. Далеко не каждая инициатива, хоть и проблемная, требует реализации немедленно. Часто оценка эффективности инвестиций имеет значительно большее значение, и этого нельзя не учитывать. Тут как раз бизнес-планирование, которое выполнено предварительно, ТЭО и расчеты дают хорошее основание для принятия оценочного решения.
Что мы понимаем под объемом целевой группы? Состав и значимость заинтересованных в проекте сторон также очень важен и требует хотя бы субъективной экспертной оценки. Это могут быть непосредственно участники проекта: заказчик, инвестор, куратор, PM и т.д. К целевой группе относятся также и пользователи проектных результатов, заинтересованные в его успехе косвенно: кредитные учреждения, бюджет, клиенты, поставщики и т.п.
Далее вы можете посмотреть на пример таблицы расчета рейтинговой оценки инициатив. Веса в таблице расставлены так, как сочла группа руководителей одной из производственных компаний в ходе мозгового штурма. Это не является каким-то эталоном, но для сравнения предложенные соотношения можно взять.
Наконец, третьим большим критерием оценки выступает достижимость или реализуемость инициативы. Она тоже делится на параметры:
В настоящей статье мы осуществили обзор основных процедур инициации проекта. Нами определены основные цели и задачи этой работы, акцентировано внимание на инструментальной процедуре формирования рейтинга инициатив для отбора их в портфель проектов. По своему опыту я знаю, что генеральному директору, кураторам и РМ часто не хватает такой увязки проблем, стратегических целей и проектных инициатив в единый контекст решений, чтобы возникли правильные ориентиры развития. А в динамике реальных событий расставленные таким образом приоритеты небесполезны.
Управление возможностями — инициация проектов
Внимание, уделяемое теме управления проектами, кажется обоснованным — возрастающая сложность систем и реализуемых проектов требует не только технических компетенций, но и применения методов управления, адекватных сложности и размерам создаваемых систем. Самые продвинутые технологии могут не оправдать надежд, если их внедрение происходит без четкого осознания ожидаемого результата и путей, которыми планируется его достичь. В этой статье мы опишем начальную стадию управления проектом — его инициацию.
Инициация начинается от появления идеи проекта и продолжается до принятия решения об участии или неучастии компании в этом проекте.
При написании статьи учитывалась специфика управления IT-проектами, однако, можно предположить, что основные нюансы и проблемы являются характерными и для других типов проектов — ведь во всех них участвуют люди, которые чаще всего и являются создателями (впрочем, как и решателями) большинства проблем управления проектами, в том числе и на стадии его инициации.
Перечисленные стадии могут реализовываться одновременно.
Компании часто недооценивают стадию инициации, сразу приступая к планированию (в лучшем случае), или к реализации (обычная практика). Однако, значение инициации трудно переоценить — именно на этой стадии происходит обоснование проекта и анализ достижимости его целей. Недостаточное внимание к этим шагам чаще всего приводит к распылению усилий компании на хаотичные инициативы без видимого результата. В итоге реальные проблемы компании остаются нерешенными, а возможности — упущенными.
Попытаемся проанализировать каждый из этапов инициации проекта с точки зрения их влияния на управление проектами.
Всякий проект должен начинаться с обоснования — формулировки проблемы, которую надо решить, или возможности, которую надо использовать для получения конкурентного преимущества. Важным фактором является необходимость осознания всеми заинтересованными участниками проекта наличия проблемы или возможности для роста. Согласитесь, трудно лечить человека, если он не осознает, что болен. Аналогично: трудно ожидать от участников проекта самоотверженной работы, если они не знают цели проекта.
Естественно, процесс обоснования внешних проектов, т. е. проектов, выполняемых по заказу внешних организаций, довольно сильно отличается от обоснования внутрикорпоративных проектов. Вкратце рассмотрим эти различия.
С обоснованием проектов, которые компания проводит для внешних клиентов, обычно проблем не возникает. Если планируемая операционная прибыль от проекта или перспективные доходы от будущих проектов c этим клиентом укладываются в нормативные значения, то проект считается обоснованным. Если это не так, то обоснованность проекта сомнительна. Основная трудность при инициации внешних проектов — слишком позднее получение исполнительными подразделениями информации о проекте. Нередки ситуации, когда исполнители узнают о проекте уже после подписания договора, когда ничего изменить или отложить уже нельзя. Довольно частым заблуждением менеджеров по продажам является уверенность в готовности остальных сотрудников выполнить любой объем работ в любые поставленные сроки, обеспечив при этом отличное качество. Заблаговременное информирование о потенциальных проектах позволит заранее подготовиться к их реализации, спланировав эффективное использование ресурсов.
Обоснование внутренних проектов, т. е. проектов, которые компания реализует для себя с целью улучшения своей деятельности, разработки новых продуктов, проведения маркетинговых исследований, выглядит не столь очевидным. Одним из решений в данном случае может быть «держание руки на пульсе» — постоянный анализ рынка, генерирование и обсуждение новых идей, пристальное внимание к проблемам компании, информирование сотрудников. Организация никогда не должна быть удовлетворена ни своим положением на рынке, ни построением своей работы. Первые признаки успокоения являются и первыми признаками упадка компании — ослаблением хватки немедленно воспользуются конкуренты.
Обратная сторона постоянного потока информации, идей и проблем — желание взяться за все и сразу. В результате чаще всего не получается ничего и никогда. Распыление ресурсов на хаотичную деятельность не позволяют решить главных проблем, требующих немедленного внимания. Выходом в данной ситуации может быть проверка потенциальных проектов на соответствие стратегии компании. Данная рекомендация может показаться абстрактной и трудновыполнимой в условиях быстроменяющегося рынка, когда подробная стратегия устаревает быстрее, чем на ней высыхают подписи руководства компании. Однако, если компания хотя бы определит свое позиционирование на рынке (вариантами могут быть инновационность, низкие цены, комплексное решение проблем заказчика), то она сможет производить первоначальный отбор проектов и без подробно прописанной стратегии.
Следующий этап инициации проекта – определение ожидаемых результатов проекта. Одним из самых понятных критериев успешности проекта, естественно, является финансовый критерий, например отдача на затраты или операционная прибыль. Для проектов, нацеленных на выполнение внешнего заказа, этот критерий является и основным. При подборе адекватных финансовых показателей проекта главным является исключение из этих показателей характеристик, напрямую не связанных с проектом. Например, учет в прибыльности IT-проекта общекорпоративных административных издержек компании-исполнителя способен исказить показатели прибыльности проекта, и, как следствие, привести к неадекватной оценке успешности работы менеджера проекта. Возможная система финансовых оценок IT-проекта может быть основана на использовании валовых показателей прибыльности, принимающих во внимание только прямые затраты данного проекта. Это позволяет оценить деятельность менеджера проектов в области его прямой ответственности, т. е. без учета административных расходов, амортизации, налогов — характеристик, обычно находящихся вне влияния менеджера проекта.
Если использование только финансовых показателей по каким-либо причинам затруднительно (например, если проект связан с созданием системы мотивации персонала или деятельностью в области PR), на помощь приходит методология Balanсed scorecard, которая является прекрасным руководством по формулированию и контролю измеримых целей деятельности компании. Не претендуя на исключительную новизну, данная система позволяет упорядочить, а главное, сделать измеримыми и взаимосвязанными многочисленные показатели работы компании (от финансовых до маркетинговых и мотивационных). Нет необходимости говорить, что оценка успешности любой деятельности возможна только при наличии измеримого показателя такой успешности.
Очередной этап инициации — анализ достижимости целей проекта — часто является болевой точкой большинства компаний. Причина в том, что решение о принятии проекта в работу часто принимается без расчета реальной прибыльности, полезности, и, главное, анализа наличия ресурсов для выполнения проекта. Принцип «ввяжемся, а там будет видно» может принести тройной убыток. Во-первых, в силу отсутствия ресурсов, компания может не ответить по взятым на себя обязательствам и потерпеть финансовые убытки, во-вторых — организация может не реализовать более выгодные для себя проекты из-за занятости ресурсов заведомо невыполнимым проектом, а в-третьих компания может понести имиджевые потери из-за ненадлежащего качества выполнения проекта. А, как известно, репутация приобретается долго и трудно, а теряется быстро и легко.
Интересной дилеммой при принятии решения об участии в проекте является выбор между отказом от проекта и снижением качества работ при невозможности достичь выполнимости целей проекта описанными выше методами. Чаще всего компании выбирают снижение качества, естественно, не объявляя об этом открыто. Ведь отказ от проекта влечет немедленные финансовые потери, а снижение качества может сказаться только в будущем. Перед тем, как высказать точку зрения на эту дилемму, приведем определение качества из стандарта управления проектами PMBOK 2000. Качество — это удовлетворенность спецификациям и пригодность к использованию. Таким образом, сделанный в соответствии с техническим заданием и пригодный к использованию продукт по определению является качественным. Принятое в некоторых компаниях понятие качества, как достижение некоего абстрактно идеального результата является неверным. Стремление достичь ненужного для заказчика качества, просто напрасная трата денег заказчика и ресурсов компании. А вот снижение качества за пределы приемлемого уровня, т. е. невыполнение четко определенных требований заказчика или непригодность результата к использованию, действительно, является недопустимым. И при осознании того, что именно этот результат (недопустимое снижение качества) является ожидаемым в случае принятия проекта, от этого проекта, конечно, лучше отказаться. Репутация дороже.
На основании понимания ожидаемого результата и анализа достижимости целей проекта компания принимает решение, будет ли она участвовать в этом проекте. Решение желательно оформить официально, чтобы обосновать планирование и подготовку к реализации проекта.
После принятия решения необходимо также определить приоритетность данного проекта по отношению к уже идущим и прочим потенциальным проектам. Показатель приоритетности проекта является хорошим основанием для решения потенциальных ресурсных конфликтов, которые могут возникнуть в ходе проекта. Входными данными для определения приоритетности могут являться характеристики проекта, значимые с точки зрения специфики бизнеса компании. Например, это может быть потенциальная доходность проекта, его политическая важность, новизна проекта для компании, риски проекта.
Немаловажным шагом при инициации проекта является как можно, раннее назначение менеджера проекта и четкое обозначение времени старта. С этого момента проект считается начатым, менеджер проекта получает полномочия и ответственность за успешность этого проекта.
В заключение хотел бы подчеркнуть, что четкая и ответственная инициация проектов позволит компаниям сконцентрировать свои усилия на проектах, наиболее полно соответствующих целям текущей деятельности и развития.
№ | Показатель | Комментарии |
1. | GM (Gross Margin) Валовая прибыль | Показывает разницу ($) между доходами и прямыми расходами проекта без учета корпоративных накладных расходов. Данная величина показывает прибыль проекта в зоне ответственности менеджера проекта |
2. | GMROI(Gross Margin Return on Investments) Валовая отдача на затраты | Показывает, какую валовую прибыль компания получила на каждый вложенный в проект рубль/доллар. Данная величина показывает, насколько эффективными оказались прямые (вызванные непосредственной работой по проекту) затраты на проект. |
3. | GMRODL (Gross Margin Return on Direct Labor) Валовая отдача на прямые трудовые расходы |