Методика

Сценарии внедрения систем управления проектами

0

Презентация c запуска PMO

1

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


NASA Guidance for writing Work Statement

0

http://www.hq.nasa.gov/office/procurement/newreq1.htm

Симпатичное сравнение с автогонками

0

Процессы PMBOK – это как правила дорожного движения.

Конкретная внедренная методика управления проектами – это как стратегия команды автогонщиков на трассе Париж-Даккар.

НЕ методология!

0

Часто при внедрении проектного управления приходится слышать что мы внедряем методологию проектного управления … PMBOK.

Стоп! Внимание!

PMBOK не является проектного методологией
PMBOK is NOT a project management methodology
PMBOK不是项目管理方法学

PS По этому поводу написаны статьи (и еще тут …), есть заметки в книгах. Запомните это, пожалуйста.

PS А где методология? А это уже другие инструменты, например:

6 углов проектного менеджера – уже не так железно

0

Развитие концепции железного треугольника управления проектами- стоимость, время и содержание проекта – шестиугольник проектного управления.

В состав шестиугольника входят следующие дополнительные компоненты:

  • Удовлетворенность клиента (Customer Satisfaction)
  • Риск (Risk)
  • Качество (Quality)

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

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

Аналогично риск. Сама природа риска такова что мы скорее не может полностью покрыть перечень рисков которым подвержен проект. В свою очередь точность измерения рисков также условна. Таким образом трудно утверждать насколько реально повлияло изменение одной из компонент на риск.

Сколько реально нужно базовых планов?

0

В Microsoft Project есть возможность сохранить десяток базовых планов. А сколько нужно на практике?

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

Главное – не забывайте сохранять базовый план. И делайте это методично – после того как были согласованы все необходимые изменения.

Интересный вариант определения Управление проектами

0

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

Microsoft Dynamics Sure Step – внедряем решения!

1

В нескольких компаниях Украины (не ИТ!) уже практикуется использование Sure Step в проектах внедрения IT систем. Использование пока ограничено формирование требований к поставщикам решений, проведением аудита документов поставщиков на соответствие Sure Step.

Методика в первую очередь направлена на партнеров Microsoft – но содержит также немало интересного методического материала для менеджеров проекта на предприятии – содержит рекомендации по проектным дисциплинам, шаблоны и примеры проектных документов. Если у вас партнер внедряет продукты Microsoft – спрашивайте с него внедрение по Sure Step!

Золотой партнер Microsoft в Украине по внедрению ERP систем – SMART business – уже несколько лет успешно внедряет ERP, CRM и SharePoint проекты на основе методики Microsoft Sure Step. Обращайтесь!

PS Неплохая обзорная статья на сайте издателя книги по Sure Step - http://www.packtpub.com/article/overview-microsoft-sure-step

Пример EVA анализа

0

Давайте на примере абстрактного проекта проведем EVA анализ.

Исходные данные проекта: 4 месяца длительность, бюджет 100`000 грн. Менеджер проекта отчитывается на конец 3-го месяца проекта. Потрачено 85`000 грн., сделано 50% объема работ. Для упрощения считаем что объем работ был запланирован равномерно – на конец третьего месяца должно было быть выполнено 75% объема работ.

PV (Planned Value, сколько мы планировали выполнить объема работ) = Запланированный процент выполнения x Бюджет проекта = 75% х 100`000 = 75`000 грн.

EV (Earned Value, что фактически сделали, по исходному плану проекта) = Актуальный процент выполнения x Бюджет проекта = 50% х 100`000 = 50`000 грн.

AC (Actual Cost, сколько фактически потратили) = 85`000 грн.

CV (Cost Variance, отклонение по стоимости) = EV- AC = 50`000 – 85`000 = -35`000 грн.

SV (Shedule Variance, отклонение по графику) = EV – PV = 50`000 – 75`000 = -25`000 грн.

После того как мыс посчитали абсолютные отклонения рассчитаем индексы для стоимости (CPI) и графика (SPI) соответственно.

CPI (Cost Performance Index) = EV/AC = 50`000 / 85`000 = 0,59

SPI (Schedule Performance Index) = EV/PV = 50`000 / 75`000 = 0,66

А теперь давайте оценим что нам “светит” в конце проекта

EAC (Estimate at Completion) =  BAC (Budget at Completion, исходный бюджет проект) / CPI = 100`000 / 0,59 = 169,5

А вот и весь EVA анализ в простом виде!

Go to Top