Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Любая организация или компания, группа людей или просто индивидуум осуществляют целенаправленную деятельность. Это может быть постоянно текущая оперативная работа по увеличению стоимости какого-либо продукта или по производству, например, типовых товаров или услуг. В то же время она может включать и ограниченные во времени инициативы — проекты или их группы — программы. Примеры инициатив, намерений, которые мы можем смело отнести к проектам: строительство загородного дома, разработка нового типа пылесоса или новой технологии, изменение бизнес-процесса компании, разработка или внедрение программного продукта, проведение компании по PR или выборам Президента, и многое др. Фрагментов или целых блоков бизнес-деятельности или жизнедеятельности, которые можно облечь в форму проекта, значительно больше, чем тех, которые не могут быть представлены проектами. Последние могут включать, например, текущую деятельность жилищно-эксплуатационного участка или рутинную продажу билетов на самолет.
Оба указанных выше типа деятельности ограничены имеющимися ресурсами, проистекают во времени и в соответствии с этим планируются, исполняются и контролируются.
Ключевая разница между проектами и текущей операционной деятельностью в том, что последняя имеет рутинный, непрерывный и повторяющийся характер, в то время как проекты уникальны, ограничены во времени и определяются конкретной целью.
Проекты обладают уникальностью, но это не надо доводить до абсурда, рассматривая как таковые типовые домики, строящиеся на соседних участках (слегка другой состав почвы, чуть отличный пейзаж за окном, и иное количество гвоздей и краски). Это ближе к типовым бизнес-процессам. К уникальности скорее следует отнести новое проектное окружение и ограничения, принципиально отличный набор требуемых ресурсов, новых исполнителей и т. д. Уникальным можно назвать проект создания бизнес-центра компанией-инвестором, даже если пара аналогичных уже работает за углом. Уникальность ИТ проекта может выражаться не только в неповторимом внешнем виде web-сайта, но и в использовании уникального (специально разработанного под этот проект) программного обеспечения и технологий. Кроме того, такой проект характеризуется своей уникальной командой с уникальным составом участников.
Совокупность взаимосвязанных проектов часто формируется в программу, имеющую обычно более крупную и долгосрочную цель, но также уникальную. Например, программа превращения небольшой региональной торговой компании в крупную компанию российского масштаба включает: внутреннюю реструктуризацию, введение системы качества, локализацию центров прибыли и центров затрат, увеличение доли рынка, обучение персонала, создание постоянно действующего учебного центра и т. д. Программа внедрения системы проектного управления может содержать ряд малых проектов по разработке проектного инструментария, шаблонов новых проектных документов, новой организационной структуры и корпоративного регламента управления проектами.
В российской практике в понимании большинства менеджеров понятие «проект» связывалось и связывается доныне с деятельностью по разработке набора проектных документов, проектно-сметной документации (ПСД), используемой для дальнейшего создания какого-либо физического объекта, продукта, бизнеса (проект строительства моста, проект разработки космического корабля, проект бизнес-плана открытия магазина).
Но есть еще 2 определения согласно существующей практике:
·проект — это черновая версия, вариант чего-то, предварительные документы (проект решения, проект приказа или гимна);
·проект — это созданное и постоянно действующее подразделение компании (например, проект «Молочное направление» или «Бесплатные открытки»).
Вышеуказанные смысловые значения включают лишь часть общего процессного понимания проекта, о котором и пойдет речь далее. Для трактовки термина «проект» как «проектно-сметная документация, план или чертеж» в зарубежной литературе используется термин «дизайн» (design). Значение «черновик, набросок» определяется чаще как «draft».
Не отрицая правомерности применения упомянутых выше трактовок в некоторых случаях, в дальнейшем будем иметь в виду процессное понимание проекта. В англоязычной литературе для этого используется термин «project».
1.2.Управление проектами. Отличие от других видов управления
Под управлением проектом понимается целенаправленная деятельность по созданию «нового продукта» или достижению «нового результата» в условиях ограниченных ресурсов и за определенное время. При этом природа самого создаваемого «продукта» не имеет особого значения, это может быть строительство нового здания, диверсифицикация бизнеса, реструктуризация подразделения компании, разработка новой услуги, подготовка отчета или книги. Например, в ИТ отрасли понятие «управление проектом» прежде всего подразумевает комплекс действий по подготовке, проектированию, разработке, тестированию, внедрению, эксплуатации и развитию интернет-сайта.
Существует много различных определений управления проектами. Приведем лишь одно из них, наиболее привлекательное с точки зрения автора.
Управление проектами — это приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту (PMBoK, 2004).
Управление проектом — это своего рода искусство. В реальной практике, как это уже подчеркивалось, оно включает совокупность любых творческих идей и приемов, позволяющих достичь целей проекта, а также и формализованный подход, когда ряд факторов может быть предсказан и все альтернативы заранее проанализированы.
Управление проектами необходимо, потому что:
– отдельный индивидуум не может справиться с решением большого объема задач. Это требует объединения специалистов и разделения труда. Отсюда следует необходимость в обеспечении организационной структуры и системы управления проектом;
– достижение определенных целей требует ресурсов, которыми необходимо обеспечить проект, их скоординировать и эффективно использовать;
– действия по обеспечению достижения целей требуют, с одной стороны, разработки структуры управления, а с другой — необходимо организованно оформить протекание процессов работы, коммуникаций и принятия решений как внутри системы, так и за ее пределами.
На практике управление проектом часто сводят только к созданию самого продукта проекта, забывая о необходимости административного управления этим «созданием продукта». Автору очень знакомо то пристальное внимание, которое уделяется вопросам разработки проектно-сметной документации, самим строительным работам, проведению тендеров и т. п. Но на вопрос, кто и как формирует команду, как осуществляется управление рисками, кто несет ответственность за правильное и своевременное проведение совещаний, организаторы и исполнители проекта отвечают недоуменными взглядами: мол, это и так очевидно и само собой происходит. А ведь, по статистике, это «съедает» 5–15% всей сметы проекта. При разделении участников проекта по этому принципу можно выделить руководителя проекта и команду управления как лиц, отвечающих за администрирование проекта, и функциональных менеджеров, отвечающих за компоненты создаваемого продукта.
Выше мы говорили о различии проекта и текущей операционной деятельности. В этом смысле существует и отличие управления проектами от постоянной управленческой деятельности в компании.
Выделяют 2 аспекта этого различия:
·Управление проектами связано с подконтрольным объектом в течение только определенного временного промежутка (так называемого жизненного цикла проекта), в то же время предполагается, что компания как объект управления, будет существовать значительно более длительный период, в идеале — вечно. Хотя если мы говорим о создании компании и доведении результатов ее деятельности до конкретных показателей за ограниченное время, то эту деятельность можно рассматривать как проект.
·Наиболее часто ресурсы в проекте заняты на основе частичного (и часто недостаточного) использования, в то время как, управляя постоянной деятельностью, компания старается вовлекать ресурсы полностью. Совместное использование ресурсов в проектах и в текущей оперативной деятельности приводит к конфликтам и требует навыков ведения переговоров для того, чтобы проекты получили необходимые ресурсы и достигли результатов в течение их жизненного цикла. Особое искусство руководителя проекта состоит в способности предугадывать и разрешать эти конфликты еще на стадии их зарождения.
Кроме взаимодействия с текущей оперативной деятельностью компании проекты часто пересекаются между собой. В этом случае принято говорить о портфеле проектов компании.
Управление проектами также отличается и от функциональных видов управления, например управления персоналом, управления финансами или производством, и имеет, как это показано на рис. 1.2, кросс-функциональный характер. При таком типе управления используются все основные функциональные области, только в различной степени и в разное время, в зависимости от специфики проекта.
1.3.Системная модель управления проектами
Вставка 1.1
Системная модель управления проектом включает (на примере подходов IPMA и PMI) субъекты и объекты управления.
Субъекты управления — активные участники проекта (отдельные сотрудники и подразделения), взаимодействующие при выработке и принятии управленческих решений в процессе его осуществления. К ним относятся ключевые участники проекта (инвестор, заказчик, генподрядчик, исполнители), команда управления проектом (руководитель проекта и члены команды проекта). Кроме того, это и функциональные подразделения организации (маркетинг, финансы, производство и пр.), в разной степени взаимодействующие друг с другом.
Объекты управления — общие программы, сами проекты, контракты (как проекты), реализуемые в организациях или на предприятиях, процессы управления планированием и осуществлением проекта.
С точки зрения временного разреза управления проектом существуют следующие уровни управления:
·стратегический уровень, который охватывает весь жизненный цикл проекта и соответствует организационно-экономическому уровню проекта;
·годовой и квартальный уровни управления, рассматривающие работы проекта, выполнение которых запланировано в течение года и квартала соответственно;
·оперативный уровень управления, занимающийся работами проекта, выполнение которых запланировано в течение месяца, декады, недели, суток, смены и т. д.
Согласно PMBоK версии 2004 г., функции или области управления
в проекте включают управление:
·интеграцией проекта;
·замыслом и работами;
·временными параметрами;
·стоимостью;
·качеством;
·рисками;
·персоналом;
·коммуникациями;
·контрактами или поставками.
Редакция IPMA предлагает дополнительно рассматривать такие области, как:
·управление изменениями в проекте;
·управление конфликтами;
·управление безопасностью проекта.
Этот же стандарт определяет и стадии процесса управления, включающие:
·инициирование — организацию и запуск проекта и его частей;
·планирование работ проекта;
·организацию и контроль выполнения работ проекта;
·анализ и регулирование хода работ проекта;
·закрытие проекта и его частей.
Анализируя области управления, можно отметить, что принципиальной разницы между подходами IPMA и PMI нет. При дальнейшем изложении автор будет больше придерживаться методологии PMI как более структурированной и чаще применяемой на практике.
1.4.Основные (или критические) факторы успеха проекта
Существует 8 основных факторов, оказывающих критическое воздействие на успешную реализацию проекта, из которых первые 3 фактора жизненно необходимы и обязательны для осуществления проекта, остальные — менее критичны, но также значительно влияют на сроки и смету проекта.
Ясность целей проекта
Руководство материнской компании или инициаторы должны четко представлять цель проекта, грамотно донести ее до команды исполнителей, вовлекаемых в работу. Под целью в данной ситуации понимается цель заказчика, высказаная им в описании врдения и будущего результата проекта. Если проект инициируется компанией, цель обязана соответствовать ее миссии (или по крайней мере не противоречить ей) и вносить свой вклад в стратегический план развития. Цель должна однозначно трактоваться как заказчиком проекта, так и исполнителями. Не следует начинать проект, не формализовав его цель в ясных, конкретных и измеримых показателях (см. раздел 3.3). В качестве критерия используется подход, который называется «беседа в скоростном лифте», когда цель должна быть донесена до участников и правильно ими понята за время спуска скоростного лифта (10–20 с). Если этого не произошло, цель должна быть переработана.
Поддержка руководством исполняющей организации
Только при поддержке проекта руководством материнской и/или исполняющей компании (что далеко не всегда реализуется на практике) он будет успешен. Эта поддержка включает: постоянное внимание к проекту, участие представителей руководства в работе команды или рабочей группы управления проектом, готовность к обсуждению проблемных ситуаций и конфликтов по ходу проекта, объявление на собраниях об успехах или неудачах проекта, снижение дистанции власти между руководителем проекта и руководством, хотя бы на время проекта. Проект практически обречен на провал, если руководство потеряло к нему интерес. В одном из высокобюджетных (по российским масштабам) проектов собственник компании, силами которой осуществлялся проект, одновременно являлся и руководителем проекта, что очень эффективно влияло на его осуществление, практически предоставляя ему «зеленый свет». Усиление поддержки руководства или минимизация негативного влияния относятся к методам управления заинтересованными лицами и будут описаны в разделе 2.2.
Четкость планов, детализация работ
Поставленные цели должны подразумевать их четкое толкование, а также предполагать варианты возможных стратегий. Руководитель проекта обязан потратить достаточно времени для анализа возможных альтернатив реализации, отбора наиболее оптимальной из них, ее дальнейшей структуризации, детализации и построения четких планов, удовлетворяющих как верхний уровень руководства, так и нижний уровень исполнителей. Компании также необходимо иметь открытые и понятные принципы отбора или фильтрации проектных стратегий. Детальные планы должны контролироваться и изменяться при необходимости и быть понятными всем участникам проекта.
Учет требований заказчика, тесное взаимодействие с ним и ясность приемки результатов
Очень важным условием успеха проекта является понимание: что именно ждет заказчик от проекта и команды; в чем его интерес; будет ли этот интерес меняться и согласуются ли ваши представления о том, чем должен закончиться проект, с врдением заказчика? Основой такого понимания может стать техническое задание, контракт или устав проекта (состав последнего документа приведен в разделе 3.6), где согласуются все характеристики создаваемого и в дальнейшем предоставляемого заказчику продукта. Заказчик должен одобрить эти спецификации, после чего они включаются в документы проекта. Очень важным является единое понимание руководителем проекта и заказчиком результата, или продукта проекта и характеристик, по которым будет проведена приемка-сдача.
Среди других вопросов, которые надо четко представлять в начале проекта, присутствуют: что входит в требования заказчика к продукту проекта и самому проекту; что не входит в проект? Это может быть отдельной строкой технического задания. Особое внимание необходимо уделить параметрам качества создаваемого продукта (также в ясных и измеримых величинах), бюджетным и временным данным. Идеально, когда сам заказчик или его представитель входит в проектную команду или рабочую группу и активно помогает или взаимодействует с ней в течение всего проекта.
Однозначное понимание может достигаться следующими возможными способами:
·максимальная детализация требований к проекту и сопровождающей проектной документации;
·постоянное информирование и предоставление измененной проектной документации заказчику;
·регулярные совещания с заказчиком для детального совместного анализа проектной документации; именно на них выявляются непонимание и основные проблемы;
·применение формальных и неформальных способов «управления» заказчиком.
По ходу осуществления проекта спецификации или пожелания заказчика могут меняться. Изменения могут быть инициированы самим заказчиком («пожалуйста, измените расцветку обоев или увеличьте мощность разрабатываемого экскаватора») или внутренними/внешними обстоятельствами проекта (изменилась твердость грунта или существующая технология не позволяет достичь нужного качества). Руководитель проекта обязан сделать так, чтобы заказчик согласился с измененными спецификациями. Если существует письменный контракт, его нужно пересмотреть и снова подписать обеими сторонами (иными словами, утвердить изменения), чтобы во время окончательной проверки заказчик и проектная команда не имели разногласий относительно параметров проекта.
Взаимодействие с заказчиком заканчивается сдачей ему полученного результата или созданного продукта. Если есть уверенность, что эта процедура не может быть истолкована по-разному, значит, вы облегчили себе завершение проекта. Еще на фазе планирования будущий продукт должен быть прописан максимально подробно и этот документ — утвержден заказчиком. Поставьте себя на место заказчика и попытайтесь проиграть сценарий его возможного поведения при приемке (базируясь на других проектах, мнениях экспертов или СМИ или просто обращаясь к своей интуиции). Есть ли нюансы, благодаря которым он может потребовать от вас больший объем работы и уровень качества за те же деньги? Если да, то постарайтесь их немедленно устранить в документе, формализующем приемку-сдачу. Поведение заказчика необходимо анализировать в течение всего хода выполнения проекта, пытаясь предугадать нюансы сдачи результата на будущее.
Наличие необходимых ресурсов и технологий
Проект успешен только тогда, когда все требуемые ресурсы доступны в необходимом объеме, в нужное время и с требуемой производительностью или эффективностью (или компетенцией — в случае человеческих ресурсов). Для выявления их доступности очень важно привлекать руководителей функциональных внутренних отделов, внешних организаций, экспертов, поставщиков и иных владельцев ресурсов к планированию проекта уже в самом начале его разработки. Обязательным действием должно стать (хотя это бывает очень трудно обеспечить) письменное подтверждение владельца ресурса о возможности (или гарантии) выделения ресурса в проект. Для повышения качества и четкой работы ресурса его владелец может быть в последующем мотивирован. В ряде проектов чрезвычайно важную роль играет наличие компетентного руководителя проекта. Если таковой занят или отсутствует, проект может быть не начат.
Нужно четко понять и иметь ясные ответы на вопросы: есть ли технологии, необходимые для создания продукта и реализации проекта; не будет ли проблем с их использованием на уровне как лицензий, так и условий их применения (окружающая среда, географическое место, сопутствующая техника или сырье)? Конечно, гарантированное обеспечение ресурсом — это идеальная ситуация, однако надо хотя бы знать, где находится ресурс, как он может быть востребован и использован. Очевидно, что проект, использующий технологию вечного двигателя, обречен на неудачу.
Контроль выполнения проекта
Исполнение проекта, а именно качество исполнения, соответствие бюджету, времени и объему производимых работ, плановым показателям, необходимо контролировать. И это только часть элементов контроля, который должен быть комплексным, частым и понятным проверяемому исполнителю. Контроль не должен иметь карающих функций. В конце концов, что последует за драконовским наказанием — ожесточенность сотрудника, вероятность внешней полировки данных, приписок, сокрытие фактического положения дел. Основная задача — не найти виновного, а определить состояние дел в проекте. Контроль — это скорее средство понять, что именно и как отклоняется в проекте от плана, и предложить срочные меры для исправления этого. Именно такой подход к контролю обеспечивает эффективность проекта. Детальное рассмотрение контрольных действий приведено в гл. 5.
Обеспечение необходимой информацией
Для принятия всех управленческих действий в проекте на любом его уровне необходима соответствующая информация. И чем полнее, правильнее и своевременнее она будет, тем эффективнее и правильнее будут приняты решения. Эффективность проекта напрямую зависит от качества функционирования построенной информационной системы, документооборота и иных коммуникационных каналов. Мы еще вернемся к этому в гл. 7.
Возможность управления непредвиденными ситуациями
В жизни часто происходят непредвиденные ситуации, то же самое относится и к проекту. Поэтому очень хорошо, если можно предугадать их наступление в полной мере. И чем полнее вы это сделаете, тем меньше будет проблем у проекта. Можно резервировать часть средств на решение проблем, передать часть вопросов вашим поставщикам, проектировщикам и другим участникам, конечно при их согласии, или просто устранить рискованные ситуации. При этом нельзя забывать о постоянном мониторинге существующих и вновь возникающих рисков. Более подробно это будет рассмотрено в гл. 8.
1.5.Ограничения и предположения проекта
Начнем с некоторой иллюстрации. Представьте, что вы плывете на лодке по большому озеру. Лодка — это ваш проект. Трава, попадающаяся на пути, ограничивает ваше плавание, но может быть легко отодвинута веслом, т. е. эта помеха управляема. Конечно, эти движения будут требовать затрат определенных ресурсов, но это можно учесть. Большие стволы деревьев и коряги также препятствуют плаванию, и значительно в большей степени, однако и ими можно управлять, хотя бы частично снизив их влияние при затратах очень больших усилий. Такие помехи —частично управляемы. И наконец, каменные скалы, торчащие из воды, заставляют вас менять курс и являются жесткими неуправляемыми ограничениями, лишь поддающимися оценке.
Проект не существует сам по себе вне зависимости от окружающих или внутренних условий. Когда идет стройка, она происходит в четко указанном географическом месте; если проектный институт разрабатывает проектно-сметную документацию, он обременен используемой технологией проектирования (и иногда очень старой) и спецификой самих проектируемых объектов; когда компания выводит новый продукт на рынок, она работает в ограничениях существующих потребительских предпочтений, привлекательности сегментов и рынка в целом. Одним из типовых ограничений руководителя проекта является проводимая в компании политика, например политика документооборота, качества, работы с клиентами. Таким образом, каждый проект имеет свои ограничения или, как еще говорят, работает на «своем поле».
Одной из обязанностей руководителя проекта еще на этапе начала проекта является максимально возможная идентификация и детализация этих ограничений, оценка характера и степени их влияния и разработка действий по его учету или снижению. Как мы поняли из ранее изложенного, эти ограничения бывают управляемыми, неуправляемыми прямо, но поддающимися влиянию и абсолютно неуправляемыми, но поддающимися оценке. Кроме того, к ограничениям могут быть отнесены не только люди или организации, но и факторы, не принадлежащие к человеческой сфере, например явления природы, география и т. д. Возможная система классификации этих ограничений показана в табл. 1.1.
Пример заполнения табл. 1.1. Проект строительства мансарды в городском здании:
В таблицу вписываются данные по выявленным ограничениям, конкретные люди или организации, определенные факторы. Руководитель проекта определяет степень влияния их на проект, какими действиями их можно учесть, что надо ввести в проект, чтобы избежать влияния, или как их оценить.
ПРИМЕР 1.3
При строительстве природным ограничивающим фактором будет нетвердая почва, где возводится дом. Проект не может быть перенесен на другое место и почва не может быть заменена, поэтому этот фактор надо учитывать посредством производства, например дополнительных свайных работ.
В другом проекте основным ограничением, поддающимся лишь учету или оценке, может быть срок окончания проекта или его смета. Встречаются ситуации, когда ограничением является существующая команда и даже руководитель проекта.
Помимо ограничений важное место занимают предположения или допущения проекта, которые делаются на фазах инициирования и планирования и контролируются в течение всего жизненного цикла. В реальной жизни трудно предугадать дальнейшее развитие событий, поэтому допускают, что какие-то внутренние или внешние обстоятельства не изменятся в течение всего проекта. Для этого можно использовать опыт предыдущих проектов, мнение экспертов, собственную интуицию руководителя. Фактически предположения, как и ограничения, являются одними из источников информации о рисках проекта. Анализ и фиксация предположений играют важную роль при передаче рисков. Например, если вы введете в проектную документацию предположение о том, что кросс-курс значимых для проекта валют будет относительно стабильным, и с этим согласится заказчик, значит, часть риска вы уже передали.
Примерами иных предположений могут быть: предположение о стабильности экономики страны в ближайшие 4 года после выборов, сохранение существующих темпов строительства, слабая вероятность пересмотра строительных норм и правил (СНиП), лояльность руководителя проекта к цели проекта и заказчику и т. п. Предположения формализуются на фазе инициирования, и к ним, как и к ограничениям, необходимо возвращаться по мере реализации проекта и идентификации возможных рисков.
Из практики
Работая с одной проектной организацией, созданной еще в незапамятные годы и обремененной очень жесткой иерархией внутренних отношений и процедур, автор в одном из проектов столкнулся с проблемами информационного обмена и документооборота. Сотрудники привыкли согласовывать все документы по строго выстроенной иерархической цепочке. Если пропускалась хоть одна подпись, возникала задержка и как следствие неудовольствие следующего подписывающего. Эта привычка относится к социальной категории и, наверно, может рассматриваться как управляемый и одновременно поддающийся влиянию ограничивающий фактор. Управление проектом было организовано путем соблюдения этих строгих инструкций с помощью сотрудников секретариата проекта (которые и ходили по всем инстанциям вместо самих исполнителей). Одновременно после тщательного изучения хода документов и согласования с рядом руководителей их ответственности и функций были сделаны и внедрены предложения по сокращению этих путей и выводу части подписей из документооборота.