К понятиям проект и управление проектом
Известное изречение Вернера Карла фон Гейзенберга, лауреата Нобелевской премии по физике, гласит: "Мы имеем дело не с законами природы, а с нашим представлением о них". Так и понятие Project Management в мировой практике трактуется неоднозначно в зависимости от выбранной модели, подхода к структуре знаний, типа и вида проектов и других факторов. Весьма разнообразны переводы самого термина Project Management на русский язык: управление проектом (проектами), проектный менеджмент, менеджмент проекта (проектов), проджект-менеджмент. Неоднозначен и смысл, вкладываемый в понятия "менеджмент проектов" и "управление проектами".
Понятие "проект" в разных моделях и стандартах также трактуется с разных позиций. Например, в процессной модели (ISO 9000, 10006) проект рассматривается как процесс, а в рамках "менеджерской", или организационно-деятельностной, модели (ICB IPMA) - определяется через "предприятие", "усилие" и "деятельность".
Некоторые определения
1. Проект:
- это предприятие, которое характеризуется принципиальной уникальностью условий его деятельности, таких как цели (задачи), время, затраты и качественные характеристики, отличающееся от других подобных предприятий специфической проектной организацией;
- это предпринимаемое усилие, организующее человеческие, материальные и финансовые ресурсы в неизвестный путь в рамках уникального предмета работы, заданной спецификации, с ограничениями на затраты и время, с тем, чтобы следование стандартному жизненному циклу проекта приводило к осуществлению успешных изменений, определенных посредством количественных и качественных целей и задач;
- это уникальный набор скоординированных действий, с определенным началом и завершением, осуществляемых индивидуумом или организацией для решения специфических задач с определенным расписанием, затратами и параметрами выполнения.
IPMA Competence Baseline. Version 2.0.
IPMA Editorial Committee. Bremen: Eigenverlag, 1999. - p. 23.
2. Проект
- это уникальный процесс, состоящий из набора взаимоувязанных и контролируемых работ с датами начала и окончания и предпринятый, чтобы достичь цели соответствия конкретным требованиям, включая ограничения по времени, затратам и ресурсам.
ISO/TR 10006: 1997 (E).
Quality Management - Guidelines to quality in project management - p. 1.
3. Проект
- это временное предприятие (усилие), осуществляемое (предпринятое) для создания уникального продукта или услуги.
A Guide to the Project Management Body of Knowledge.
PMI Standards Committee. 2000 Edition, 2000. - p. 4.
4. Проект
- это уникальная совокупность взаимосвязанных действий (работ), с определенными датами начала и окончания, предназначенных для успешного достижения общей цели.
Australian Institute for Project Management.
National Competence Standard for Project Management - Guidelines 1996. - p. 18.
5. Проект
- это уникальная совокупность скоординированных действий (работ) с определенными точками начала и окончания, предпринятая индивидуумом или организацией для достижения определенных целей с установленными сроками, затратами и параметрами выполнения.
British Standard BS 6079-1:2000.
Project management - Part 1: Guide to Project management - p. 2.
В России сертификация проводится на основе «Российских национальных требований к компетентности специалистов»
Российская ассоциация управления проектами СОВНЕТ создана в 1990 году. Национальные требования к компетентности (НТК), разработанные группой сертифицированных специалистов СОВНЕТ существенно расширили содержание ICB (International Competence Baseline, ICB).
Все элементы международных требований к компетентности перенесены в НТК полностью или в частично измененном виде со строгим соблюдением смысловой согласованности.
НТК СОВНЕТ:
включает в себя 43 элемента,
из них 28 — основные элементы ICB
и 15 — дополнительные.
Элементы НТК сгруппированы в четыре раздела:
1. объекты управления;
2. субъекты и инструментарий управления проектами;
3. процессы управления проектами;
4. история и тенденции развития управления проектами.
Литература: Управление проектами: Основы профессиональных знаний.
Национальные требования к компетенции специалистов (под ред. В.И. Воропаева). - М.: СОВНЕТ,
«Кубс Групп», 2001. – 265 с.
| СОВНЕТ | 
| 
|
Ассоциация Управления Проектами "СОВНЕТ"
Ассоциация Управления проектами (СОВНЕТ) основана в 1990 году и представляет собой добровольный союз профессионалов, осуществляющих научные исследования и разработки, обучение и сертификацию специалистов в области Управления проектами; обоснование, подготовку, выполнение и управление проектами в различных сферах деятельности.
Цели и задачи ассоциации:
СОВНЕТ ставит перед собой цель - широкое развитие профессионального управления проектами в России и международное сотрудничество с Международной ассоциацией управления проектами, её национальными организациями, другими зарубежными ассоциациями, институтами и компаниями в области управления проектами.
Главные задачи СОВНЕТа:
|
Сокращения
IPMA - International Project Management Association
PMI - Project Management Institute (США)
AIPM - Australian Institute for Project Management (Австралия)
APM - Association for Project Managers (Великобритания)
СОВНЕТ - Ассоциация управления проектами (Россия)
ENAA - Engineering Advancement Association of Japan (Япония)
GPM - Deutsche Gesellschaft fur Projektmanagement (Германия)
ICB IPMA - International Competence Baseline IPMA
NCB - National Competence Baseline
PM BoK - Body of Knowledge on Project Management
PMBOK - Project Management Body of Knowledge PMI (США)
!!! С 1 июля 2009 года сертификация на степень PMP® будет проводиться по новому стандарту PMI PMBOK® 2008. Действующий стандарт 2004 года — PMI PMBOK® 2004. !!!
Информационные системы
Для управления проектами
Microsoft Office Project
Единое решение для управления проектами и ресурсами на предприятии
Вы являетесь соруководителем компании Project Management Partners, занимаетесь постановкой проектного управления в компаниях. Является ли PMBoK фактическим стандартом, насколько создаваемые системы проектного управления соответствуют РМВоК?
К большому сожалению, я вижу, что люди далеко не всегда хорошо понимают, что бывают разные типы стандартов. Скажем, РМВоК является нормативным стандартом. Другими словами, РМВоК говорит: «Если вы вообще ничего не знаете о проектном управлении, то вот вам база, с которой можно начать освоение этой области». Если же речь идет о внедрении конкретной системы в конкретной компании, то, естественно, практически всегда будет необходима настройка общих принципов стандарта с учетом культуры компании, кадровых ресурсов, сферы ее деятельности. ИТ-фирма, строительная компания, организация, работающая в оборонной промышленности, — все они будут иметь различные системы управления проектами.
Системы проектного управления должны быть построены таким образом, чтобы не ограничивать возможности сотрудников компании каким-то одним, конкретным типом действий. Иными словами, стандарты РМВоК и стандарты проектного управления, разработанные на корпоративном уровне, не могут быть некой «кулинарной книгой», которой надо следовать во всех обстоятельствах. Возьмем в качестве аналогии проезд в аэропорт. Мы знаем точку отправления и точку, в которую нужно попасть, но при этом существует десять разных маршрутов, которыми можно добраться до аэропорта. Сегодня один путь будет преимущественным, а завтра — другой. Если говорить о проектном управлении, то система стандартов и корпоративных, и общих должна обеспечивать определенную степень гибкости в выборе и реализации конкретных процессов конкретными людьми. Если вы ограничите своих сотрудников только одним маршрутом в аэропорт, то иногда он окажется оптимальным, но чаще они, скорее всего, будут просто пропускать свой рейс.
Насколько универсально проектное управление? Применимы ли его принципы для любых организаций или есть определенные типы коммерческих компаний, госструктур, общественных организаций, где использование управления проектами предпочтительно, в то время как в других оно вообще невозможно?
Если вы просто возьмете РМВоК и начнете применять его предписания во всех областях одинаково, тупо переводя написанное в стандарты проектного управления своей компании, то, скорее всего, попадете в беду. Но если вы найдете возможность корректировать эти предписания по ситуации, то с этой точки зрения стандарты проектного управления универсальны, применимы ко всем областям деятельности.
Каковы необходимые условия для успешной постановки проектного управления в компании — определенная отраслевая специфика, количество обученных и сертифицированных специалистов по управлению проектами, заинтересованность руководства, что-либо еще?
Если говорить о минимально необходимом требовании, то, для того чтобы начать внедрять идею проектного управления, достаточно одного человека, который будет в нее верить. Дальше она распространяется как вирус. Сотрудники видят, что существуют практики, которые дают успешный результат, и начинают их применять. Зачастую безграмотность сотрудников в области управления проектами обусловливается не глупостью, а именно незнанием методики. Но если мы говорим о внедрении культуры управления проектами на уровне компании, то без серьезной поддержки высшего руководства не обойтись.
Количество специалистов, которое должно быть обучено в организации принципам проектного управления, в большой степени зависит от направления работы этой организации. Если взять, например, автомобильную промышленность, то основной процент персонала такой компании вовлечен в операционную деятельность, и только небольшое число сотрудников будет заниматься проектами. Поэтому если речь не идет о конкретных изменениях и внедрениях новых продуктов, большое количество обученных менеджеров проектов не обязательно принесет пользу этой компании. Но если мы говорим о компаниях проектно-ориентированных, таких как, например, компании, занимающиеся ИТ-аутсорсингом или инженерным консалтингом, то в этом случае практически все сотрудники должны иметь представление о том, что такое проектное управление, поскольку большинство из них будет так или иначе задействовано в проектах.
Поясните, пожалуйста, каковы основные компоненты корпоративной культуры управления проектами?
Прежде всего, важно подчеркнуть, что я рассматриваю культуру проектного управления как часть общей культуры работы организации. Мы не собираемся менять организацию, мы хотим усилить ее, поэтому существуют три основных компонента корпоративной культуры управления проектами. Во-первых, это управление портфелями проектов: как принимается решение, какие проекты будут вестись, как происходит выбор между теми или иными проектами, как распределяются ресурсы между проектами, как определяются приоритеты и т.д. Второе — организационная среда: что необходимо внедрить в компании на операционном уровне, для того, чтобы поддержать практики проектного управления, каким образом выбирать людей для реализации проекта, как и какие отделы привлекать, каким образом к управлению проектами должен быть привлечен топ-менеджмент компании. И только третьим компонентом являются собственно методологии управления индивидуальными проектами, т. е. то, чему в основном посвящен и РМВоК, и большая часть всех книг и публикаций по проектному управлению. По сути, мы наблюдаем новую ступень в развитии профессиональной области управления проектами. Разработка системы корпоративной культуры проектного управления вызвана к жизни потребностью, назревающей среди компаний, которые используют управление проектами. (У Билла есть великолепный курс по внедрению культуры проектного менеджмента и основным компонентам этой культуры, который уже представляется в России в виде открытого тренинга. — Н.Д.) Компании начинают понимать, что мало обучить своих менеджеров методологии, нужны еще какие-то компоненты, которые помогут внедрить проектный менеджмент на уровне организации, сделать его жизнеспособным. С тем, чтобы другие процессы в компании непроизвольно не ставили палки в колеса нормальному, эффективному ведению проектов.
Последнее время много говорится о переходе от управления отдельными проектами к управлению портфелем проектов. В чем суть управления портфелями, в чем отличия от мультипроектов, управления программами, и почему управление портфелями проектов имеет такое значение для успешного проектного управления в организации?
Если говорить о значении управления портфелем проектов для организаций, то я не считаю, что сегодня это более важно, чем раньше, просто эта задача выходит на первый план. По мере того как организации начали улучшать свои подходы к управлению индивидуальными проектами, для них стало очевидно, что другой компонент проектного управления развит слабо.
Что касается таких трех подходов в управлении проектами, как мультипроект, управление программами и управление портфелем проектов, то их нельзя рассматривать как независимые дисциплины, поскольку существует очень много пересечений и естественных взаимозависимостей. Я бы объяснил различия между ними следующим образом. Когда мы говорим о программе, то это обычно группа проектов, которые взаимосвязаны друг с другом, поскольку предпринимаются с целью получения одного результата. Например, у некоммерческой организации может быть годовая программа, которая будет объединять большое количество проектов, направленных на сбор средств. Управление этими проектами на уровне программы нацелено на то, чтобы они не вступали в конфликт друг с другом. Когда мы говорим о мультипроекте, то обычно имеем в виду перераспределение ресурсов в отношении тех или иных проектов и координацию движения ресурсов между проектами. Что касается управления портфелем проектов организации, то здесь мы чаще всего фокусируемся на стратегическом развитии организации. Основное отличие управления портфелем проектов от мультипроекта и управления программой состоит в том, что мы ставим перед собой задачу определить, насколько та или иная комбинация проектов отвечает общим принципам стратегического развития компании. Но в целом еще раз хочу повторить, что три эти области взаимно пересекаются.
Во время визита Вильяма Дункана в Москву в компании PSM Сonsulting состоялась его встреча со специалистами и журналистами. В ходе встречи Дункан обрисовал свое видение основных направлений в развитии стандартов проектного менеджмента.
— В настоящее время проектный менеджмент является вполне зрелой профессиональной дисциплиной. Развитие стандартов управления проектами должно идти в четырех основных областях. Во-первых, это традиционный свод стандартов, т. е. специфическое знание о том, как организовывать определенные функции управления проектами. Скажем, если вы вводите одну и ту же сетевую диаграмму в несколько разных программных продуктов для управления проектами, эти системы могут вычислить критический путь по-разному. На мой взгляд, было бы очень полезно иметь стандарт, который определит один правильный способ вычисления критического пути, так чтобы его придерживались все производители программных пакетов. Кроме того, очень много вопросов возникает относительно того, как надо запускать проект. Думаю, должен существовать конкретный стандарт, который опишет процесс открытия проекта как с административной точки зрения, так и с точки зрения подготовки, сбора и организации работы команды.
Вторая большая область, в которой, как мне представляется, профессия нуждается в стандартах, — это область исследований. До сих пор недостаточно последовательно используется терминология в различных областях проектного менеджмента. И в результате исследователям очень сложно писать новые статьи и вести научную работу, которая будет обогащать профессию, поскольку мы называем разные вещи одними и теми же именами, и одни и те же вещи — разными. В конечном итоге все это становится похоже на вавилонское столпотворение. На мой взгляд, сегодня проектному менеджменту не хватает базовой теории, или философии управления проектами. Такая идеологическая основа должна служить руководящим принципом развития исследований, а исследования в свою очередь должны обогащать практику.
Третья область — оценка компетенции проектных менеджеров. Нужны стандарты, определяющие, каким образом оценивать эффективность работы проектного менеджера, на основании каких критериев принимать решение, что он компетентен, успешен в своей деятельности. В этой области я сотрудничаю с двумя международными группами. Первая представляет собой сообщество ведущих специалистов в области управления проектами из разных стран с координирующим центром в Австралии. Мы стараемся разработать общие принципы оценки эффективности выполнения проектным менеджером своей работы, с тем чтобы затем эти оценки последовательно использовать на уровне национальных организаций во всех странах мира. Кроме того, я работаю с американской национальной ассоциацией по управлению проектами, которая ставит перед собой задачу разработки национальной программы сертификации проектных менеджеров исходя из общих международных принципов.
И, наконец, четвертая область — выработка общих принципов на уровне организационной среды корпорации, которые позволят поддерживать эффективное управление проектами. Наша модель корпоративной культуры проектного менеджмента адресуется именно к этой проблеме. Она является неким типом модели оценки зрелости организации, позволяет оценить состояние организации с точки зрения способности поддерживать эффективное управление проектами на организационном уровне. Но при этом в нашей модели корпоративной культуры управления проектами не существует различных степеней зрелости. По моему мнению, не существует какой-то одной модели, которая будет применима ко всем без исключения организациям. Каждая организация должна выстраивать собственный подход к управлению проектами исходя из своих сильных и слабых сторон, организационных и ресурсных возможностей.
Разработка стандартов в этой последней области будет представлять самую большую сложность, поскольку многие консалтинговые компании уже предлагают свои собственные подходы к оценке организационной зрелости компаний. Будет очень непросто объединить всю профессиональную область вокруг какого-то одного стандарта. Думаю, что здесь должен быть разработан определенный принцип, простейшая модель, некая совокупность элементов, которые в обязательном порядке должны присутствовать в организации для поддержки зрелого проектного менеджмента. С этими минимальными требованиями должны согласиться все организации, работающие в области управления проектами (IPMA, PMI, национальные ассоциации, любые организации, которые занимаются вопросами стандартизации).
Наталья Дубова
Переговоры
Диаграмма Ганта (также называемая «ленточной»), которая представляет собой диаграмму интервалов на шкале времени. Наиболее типичное использование диаграммы Ганта – визуальное отражение хода выполнения какого-либо проекта.
Диагра́мма Га́нта (англ. Gantt chart, также ленточная диаграмма, график Ганта) — это популярный тип столбчатых диаграмм, который используется для иллюстрации плана, графика работ по какому-либо проекту. Является одним из методов планирования проектов.
Первый формат диаграммы был разработан Генри Л. Гантом (Henry L. Gantt, 1861‒1919) в 1910 году.
Диаграмма Ганта представляет собой отрезки (графические плашки), размещенные на горизонтальной шкале времени. Каждый отрезок соответствует отдельной задаче или подзадаче. Задачи и подзадачи, составляющие план, размещаются по вертикали. Начало, конец и длина отрезка на шкале времени соответствуют началу, концу и длительности задачи. На некоторых диаграммах Ганта также показывается зависимость между задачами. Диаграмма может использоваться для представления текущего состояния выполнения работ: часть прямоугольника, отвечающего задаче, заштриховывается, отмечая процент выполнения задачи; показывается вертикальная линия, отвечающая моменту «сегодня».
Часто диаграмма Ганта соседствует с таблицей со списком работ, строки которой соответствуют отдельно взятой задаче, отображенной на диаграмме, а столбцы содержат дополнительную информацию о задаче. Пример такой таблицы представлен ниже.
| Список работ | продолжительность работы | стоимость |
| покупка здания | 1.02.08—8.02.08 | 15 $ |
| регистрация предприятия | 2 8.02.08—18.02.08 | 3 884 лея |
Диаграмма Ганта может использоваться для наглядного представления таких данных как:
- ход выполнения проекта;
- график рабочего времени;
- графиков отпусков;
- использование оборудования;
- занятость помещений;
- и другие.
| В типичной диаграмме Ганта отдельные задачи и операции проекта перечислены с левой стороны диаграммы, шкала времени отображается сверху, а длительности каждой задачи и операции показаны горизонтальными полосками (лентами) от даты начала до даты завершения | 
|
Гибкое представление данных
Диаграмма Ганта имеет гибкую структуру данных. Как точки, так и серии представляют собой иерархические коллекции, что позволяет, например, представить проект как набор связанных, иерархических задач.
Множество серий позволяет на одной диаграмме отображать разные данные, например: отпуска, командировки и отсутствие по болезни.
Каждая серия, точка, значение (совокупность интервалов) и интервал имеет расшифровку, что позволяет производить детализацию выбранного значения.
PERT
Program Evaluation and Review Technique (сокращенно PERT) — техника оценки и анализа программ, которая используется при управлении проектами. Была разработана в 1958 году консалтинговой фирмой «Буз, Ален и Гамильтон» совместно с корпорацией «Локхид» по заказу Подразделения специальных проектов ВМС США в составе Министерства Обороны США для проекта создания ракетной системы «Поларис» (Polaris). Проект «Поларис» был ответом на кризис, наступивший после запуска Советским Союзом первого космического спутника.
PERT — это способ анализа задач, необходимых для выполнения проекта. В особенности, анализа времени, которое требуется для выполнения каждой отдельной задачи, а также определение минимального необходимого времени для выполнения всего проекта.
PERT был разработан в 50-ые годы главным образом для упрощения планирования и составления графиков больших и сложных проектов. Метод подразумевал наличие неопределённости, давая возможность разработать рабочий график проекта без точного знания деталей и необходимого времени для всех его составляющих.
Самая известная часть PERT — это «Сети PERT» — графики соединённых между собой временных линий. PERT предназначен для очень масштабных, единовременных, сложных, нерутинных проектов.
Диаграмма представляет собой множество точек-вершин вместе с соединяющими их ориентированными дугами. Каждая из них как направленный отрезок имеет начало и конец, причем модель содержит только одну из пары симметричных дуг (от вершины 1 к вершине 2 и от вершины 2 к вершине 1). Всякой дуге, рассматриваемой в качестве какой-то работы из числа нужных для осуществления проекта, приписываются определенные количественные характеристики. Это — объемы выделяемых на нее ресурсов и, соответственно, ее ожидаемая продолжительность (длина дуги). Любая вершина интерпретируется как событие завершения работ, представленных дугами, которые входят в нее, и одновременно начала работ, отображаемых дугами, исходящими оттуда. Таким образом, фиксируется что ни к одной из работ нельзя приступить прежде чем будут выполнены все предшествующие ей согласно технологии реализации проекта. Факт начала этого процесса — вершина без входящих, а окончание — без исходящих дуг. Остальные вершины должны иметь и те, и другие. Последовательность дуг, в которой конец каждой предшествующей совпадает с началом последующей, трактуется как путь от отправной вершины к завершающей, а сумма длин таких дуг — как его продолжительность. Обычно начало и конец реализации проекта связаны множеством путей, длины которых различаются. Наибольшая определяет длительность всего этого проекта, минимально возможную при зафиксированных характеристиках дуг графа. Соответствующий путь — критический и в каждый момент времени контролировать нужно состояние именно тех работ, которые «лежат» на нем.
Пример сетевой PERT диаграммы для проекта продолжительностью в семь месяцев с пятью промежуточными точками (от 10 до 50) и шестью деятельностями (от A до F).
Сетевые графики
Сетевой график основан на использовании другой математической модели - графа. Графам (устаревшие синонимы: сеть, лабиринт, карта и т.д.) математики называют "множество вершин и набор упорядоченных или неупорядоченных пар вершин". Говоря более привычным для инженера (но менее точным) языком, граф - это набор кружков (прямоугольников, треугольников и проч.), соединенных направленными или ненаправленными отрезками. В этом случае сами кружки (или другие используемые фигуры) по терминологии теории графов будут называться "вершинами", а соединяющие их ненаправленные отрезки - "ребрами", направленные (стрелки) - "дугами". Если все отрезки являются направленными, граф называется ориентированным, если ненаправленными - неориентированным.
Основными понятиями являются — работа, события, пути.
Виды работ
Дата: 2016-09-30, просмотров: 244. 
Материалы представленные на сайте исключительно с целью ознакомления пользователям Интернета и не преследуют коммерческих целей или нарушение авторских прав.
© 2018 - 2025
|