+7(499)-938-42-58 Москва
+7(800)-333-37-98 Горячая линия

Knowledge Management: определяем содержание проекта

Содержание

The 10 Project Management Knowledge Areas (PMBOK)

Knowledge Management: определяем содержание проекта

What do you need to know to succeed at project management? Everything!

While there’s some truth to that joke, it’s not helpful to the student or the experienced professional who is looking for a way to understand the myriad responsibilities of being a project manager.

 The vast range of project management tools, terms, skills and knowledge that are within its discipline can be intimidating.

This is why PMBOK was created — to help unify and standardize the many parts of project management.

What is PMBOK in Project Management?

PMBOK stands for Project Management Body of Knowledge. It is a set of standard terminology and guidelines for project management published and updated by The Project Management Institute (PMI).

What Are the Project Management Knowledge Areas?

PMI has divided the large field of project management into 10 more digestible parts, which it calls the 10 project management knowledge areas in its A Guide to the Project Management Body of Knowledge (PMBOK).

Project management knowledge areas coincide with the process groups, which are project initiation, project planning, project execution, monitoring and controlling, and project closing. These are the chronological phases that every project goes through.

The knowledge areas take place during anyone of these process groups. You can think of the process groups as horizontal, while the knowledge areas are vertical. The knowledge areas are the core technical subject matter, which are necessary for effective project management.

Project Integration Management

What holds a project together? That would be project integration management, which includes such fundamental plans as developing a project charter that is created during the initiation phase. This is the document that sets up the project and assigns the project manager.

Another aspect of this area is the project management plan, which is developed as a project roadmap for the project to reach a successful end. Once created, the project plan is approved by stakeholders and/or sponsors, and then it’s monitored and tracked through a change log as the project progresses.

The project integration area also includes the directing and managing of the project work, which is the production of its deliverables. This process is monitored, analyzed and reported on to identify and control any changes or problems that might occur.

Also, any change control will be carried out. That might require request forms, approval from stakeholders and/or sponsors or another admin. This area is also part of the project closure at the end of the project.

Project Scope Management

Scope relates to the work of the project.  So, that includes plan scope management, which is part of the project management plan. It also is when a detailed requirement for the final product or service is collected.

You’ll also need to define scope in a scope statement. This is anything from a sentence to a bulleted list that is comprehensive to reduce major project risks. And a Work Breakdown Structure (WBS), which is a graphic breakdown of project work, is another part of this area.

Validate scope during the project, which means making sure that the deliverables are being approved regularly by the sponsor or stakeholder. This occurs during the monitoring and controlling process groups and is about accepting the deliverables, not the specs laid out during planning.

The scope statement is ly going to change over the course of the project to control the scope, such as if a project falls behind schedule.

Project Time Management

Project time management is, no surprise, time consuming. The project is divided into tasks, which are scheduled with start dates and deadlines, as well as budgets for each task. And things are constantly changing over the phases of any project, which means revising these things often.

This involves plan schedule management, which involves creating a schedule for the project and determining who is responsible for what. That means defining activities, which is not the same as making a WBS, but similar. So, you create a task list that touches on every aspect of the project.

Related: Time Management Strategies & Tools

These tasks are then put in an order that makes sense, and any dependencies between them is noted. These dependencies are then determined to be either finish-to-start (FS), finish-to-finish (FF), start-to-start (SS) or start-to-finish (SF). This is mostly for larger projects.

With the tasks now sequenced, the resources required for each must be estimated and assigned. The duration of each task is also determined at this point. All this will lead to a schedule by first figuring out the critical path and float for each task. Use a Gantt chart to place the tasks on a timeline, and then work on resource leveling to balance resource usage.

Once the schedule is made, plan to control the schedule are necessary. Earned value management is performed regularly to make sure that the actual plan is proceeding as it had been planned.

Project Cost Management

This area involves the project budget, which means having good estimating tools to make sure that the funds cover the extent of the project and are being monitored regularly to keep stakeholders or sponsors informed.

Related: Free Project Budget Template for Excel

Plan cost management will determine the method to establish the budget, which includes how and if it will change and what procedures will be used to control it. Each task will have to be estimated for cost, which means including all resources such as labor, materials, equipment and anything else needed to complete the task.

This will determine the project budget, once you take all the task costs and combine them. Then comes the need to control those cost through an earned value analysis. This is performed regularly throughout the project to make sure the estimated costs are in line with actual expenditures.

Project Quality Management

A project can come in on time and within budget, but if the quality is not up to the standard set, then the project is a failure. Plan quality management is part of the overall project management plan, though it can be a standalone document if it contains the quality specs for the product or service.

The process needs to include quality assurance, which is just a way to make sure that quality standards are being met. Therefore, to control quality, the deliverables must be inspected to make sure that those standards outlined in the quality management plan are being met.

Project Human Resource Management

The project team is your most important resource, so it’s crucial to assemble the best team and to make sure they’re happy. But also you need to track their performance to ensure that the project is progressing as planned. A human resource management plan will identify their roles and their requirements for those positions, as well as how they fit in the overall project structure.

After you’ve determined the job descriptions, it’s time to fill those positions and acquire a project team. This can be done in-house by drawing from other departments in the organization, by getting new hires or by a combination of both. The team needs development, possibly training and other things that will make them viable for the project.

Managing the project team is an ongoing responsibility of the project manager. The team is monitored to make sure they’re working productively and that there are no internal conflicts, so everyone is satisfied.

Project Communications Management

All areas of project management are important, but communications might be paramount as it informs every aspect of the project. Communications inform the team and stakeholders, therefore the need to plan communications management is a critical step in any project.

Related: Free Communication Plan Template

It is at this point that the dissemination of communications is determined, including how it’s done and with what frequency. Target who needs what and when. Also, note how communications will occur when issues arise in the project, such as changes.

Manage the communications when the project is executed to make sure it runs as planned. This will also involve controlling communications by reviewing their effectiveness regularly and adjusting as needed.

Project Risk Management

Risk management plans will identify how the risks will be itemized, categorized and prioritized. This involves identifying risks that might occur during the execution of the project by making a risk register.

Perform qualitative risk analysis after the biggest risks have been identified and classified by lihood and impact. Then prioritize them. Then perform quantitative analysis according to their impact on the project, such as its budget, schedule, etc.

Now you’ll need to plan risk responses. If those risks in fact become issues, then a response needs to have been written in advance, with an owner who can make sure the risk is properly identified and handled. Controlling risk involves regularly reviewing the risk register and crossing off those risks that are no longer going to impact the project.

Project Procurement Management

This deals with outside procurement, which is part of most projects, such as hiring subcontractors. This will obviously have an impact on the budget and schedule. Planning procurement management starts by identifying the outside needs of the project and how those contractors will be involved.

Now conduct those procurements by hiring the contractors, which includes a statement of work, terms of reference, request for proposals and choosing a vendor. You’ll want to control the procurement process by managing and monitoring, and then closing the contracts once the work has been done to everyone’s satisfaction.

Project Stakeholder Management

The stakeholders must be happy, as the project has been created for their needs. Therefore, they must be actively managed any other part of the project. To start one must identify the stakeholders. It’s not always easy, but it’s a crucial part of starting any project, so find out who they are and what concerns they have.

Now plan stakeholder management, which means listing each stakeholder and prioritizing what their concerns are and how they might impact the project. This will lead to managing stakeholders’ expectations to make sure their needs are met and that you’re in communication with them.

Throughout the project, control stakeholder engagement. Do this by determining if the stakeholders’ needs are being addressed. If not, figure out what changes need to be made to either satisfy those needs or adjust the expectations.

Project management knowledge areas bring a project to life, but that life can be chaotic and complex, which is why a project manager needs a tool to help manage all these moving parts of a project. ProjectManager.

com is a cloud-based project management software with real-time dashboards and Gantt charts to monitor the project accurately throughout its many phases.

See how it can help you manage your projects by taking this free 30-day trial.

Источник: https://www.projectmanager.com/blog/10-project-management-knowledge-areas

10 (PMBOK) Области знаний по управлению проектами 2019

Knowledge Management: определяем содержание проекта

Вам предстоит многому научиться как менеджер проекта! Руководство для Группы знаний по управлению проектами (Руководство PMBOK®) – Пятое издание раскрывает то, что руководители проектов должны знать, чтобы успешно пройти экзамен PMP®, а также быть эффективным в этой роли.

Есть 10 областей знаний по управлению проектами, охватываемых PMBOK® Guide . Они охватывают каждый из 47 процессов управления проектами. В этой статье вы найдете представление на высоком уровне каждой из этих областей относительно того, что вам нужно знать и выполнять как менеджер проекта.

Управление интеграцией проектов

Это описано в руководстве PMBOK® Guide , но это связано с объединением всего, что вы знаете, чтобы вы управляли своим проектом целостно, а не в отдельные куски процесса. Из-за этого легче изучить эту область знаний. Пропустите этот раздел книги и вернитесь к нему позже!

Управление областью проекта

«Сфера применения» – это способ определить, каким будет ваш проект. Управление областью – это все, чтобы убедиться, что все четко знают, для чего предназначен проект и что он включает. Он охватывает требования к сбору и подготовку структуры разбивки работ. (Вот как выполнить задачи разбивки.)

Управление временем проекта

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

Здесь вы также составляете график своего проекта.

Управление стоимостью проекта

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

И, конечно же, он охватывает отслеживание расходов проекта на этот бюджет и обеспечение того, чтобы вы все еще были на пути, чтобы не перерасход.

Управление качеством проекта

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

Управление человеческими ресурсами проекта

Управление человеческими ресурсами проекта связано с тем, как вы управляете своей проектной командой.

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

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

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

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

Существуют тесные связи с управлением человеческими ресурсами и управлением заинтересованными сторонами, даже если они не явны, поскольку я думаю, что они должны быть в PMBOK® Guide .

Управление рисками проектов

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

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

Управление закупками проектов

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

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

Управление заинтересованными сторонами проекта

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

Если вы сможете понять все эти области знаний, у вас будет все, что вам нужно знать, когда будет рассмотрен менеджер проектов!

Источник: https://ru.routestofinance.com/10-project-management-knowledge-areas

Управление содержанием проекта

Knowledge Management: определяем содержание проекта

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

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

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

Также стоит различать содержание проекта и содержание продукта: в первом случае, это работы, которые необходимо выполнить для получения желаемого результата (продукта, услуги), во втором случае – это функции и характеристики результата.

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

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

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

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

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

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

проекта включает в себя:

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

Описание содержания проекта

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

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

Например, если вы внедряете новую информационную систему, в содержание проекта будет входить:

  1. Сама система (тут же приводится список ее компонентов).
  2. Права в системе, настроенные в соответствии с утвержденным бизнес-процессом.
  3. Техническое обеспечение системы (сервера, подключение на машины пользователей).
  4. Комплект документации (тут перечень) для поддержки и развития решения.
  5. Обученные пользователи.
  6. Обученные специалисты службы поддержки, которые все это добро будут поддерживать.
  7. Обновленные нормативные документы компании (например, процедура по работе с дебиторами).

Критерии приемки результата проекта

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

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

Например, для элемента “Обученные пользователи” (подкатегория “Обученные бухгалтера по работе с дебиторами”) критерием приемки может быть “Бухгалтер может выполнить следующие операции: ввод акта сверки, согласование счета и т.д. самостоятельно не более чем за 1 минуту”.

Границы проекта

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

На рисунке ниже схематично изображено определение границ проекта.

Определение границ проекта

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

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

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

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

На кофе и новые материалы для читателей блога 🙂

Источник: https://upravlenie-proektami.ru/upravlenie-soderzhaniem-proekta-granitcy-i-dopushcheniia-proekta

Управление проектами по PmBok

Knowledge Management: определяем содержание проекта

Руководство PMI PMBoK® – это стандарт для управления проектами. Данный стандарт описывает процессы управления проектами, инструменты и методы, используемые для управления проектом в целях достижения успешного результата.

PMI PMBOK был разработан и поддерживается Институтом управления проектами (PMI®, Project Management Institute) — это ведущая международная некоммерческая ассоциация профессионалов в управлении проектами, объединяющая более 200 000 членов в 125 странах. Получить степень PMP можно здесь.

Разберем свод правил по этой книге с помощью методологии Ивана Селиховкина.

  1. Структура PMBOK
  2. Принципы проектного управления
  3. Области знаний

Часть 1.структура pmbok

10 областей знаний:

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

Области знаний разбиты на группы и состоят из 47 процессов управления проектом, объединенных  в 5 групп:

  • Инициация
  • Планирование
  • Исполнение
  • Мониторинг и Контроль
  • Закрытие

Процесс — это задача, к примеру, создать расписание.

Пример: область знаний «управление сроками» на этапах «ПЛАНИРОВАНИЕ» и «МОНИТОРИНГ»:

Исключение: процессы из областей знания «интеграция» и «управление HR»:

Примечание. Область знаний «Управление интеграцией» — в книге эта глава первая, но никогда не стоит начинать чтение книги с этой главы, потому что она абстрактна и не даем применимых знаний.

Часть 2.

  1. Принцип яйца
  2. Принцип удава
  3. Принцип командности и проактивности

Разберем каждый принцип подробнее.

1. Принцип яйца

 «Скорлупа яйца» — Устав проекта, который пишется в начале проекта

«Внутреннее содержимое яйца»:

  1. содержимое проекта (что собираемся сделать, требования и функционал)  > сроки, стоимость
  2. коммуникации, риски, закупки, качество, HR

Жизненный цикл проекта:

Начало проекта — «инициация» > Середина проекта — «цикл Деминга»  > Конец проекта — «закрытие»

Если представить этапы в виде удава, то получается следующая картинка (этого в книге нет, это разработал И.Селиховкин):

3. Принцип командности и проактивности

  1. Следует вовлекать команду в процесс планирования
  2. Проактивность!

Часть 3. области знаний

Области знаний:

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

1. УПРАВЛЕНИЕ ИНТЕГРАЦИЕЙ ПРОЕКТА

payback period — (период оккупаемости)

ROI-return of investment — (возврат инвестиций)

internal rate of return — (внутренняя ставка возврата)

discounted cash flow — (дисконтированный денежный поток)

net present value — (чистый дисконтированный доход)

4.1. Разработка устава проекта 

Устав фиксирует цели и ограничения проекта

Должен быть неизменным

Пример: Temp1 — ProjectCharter_2015

4.2. Разработка плана управления проектом

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

4.3. Мониторинг и контроль работ проекта

Проверка хода проекта относительно всех планов: нужно сверить «план» и «факт» (укладываем в сроки?, укладываемся в бюджет? и т.п.)

4.5. Руководство и управление работами проекта

Это координация команды, действия по планам, работа с отчета и т.п.

4.6. Закрытие фазы или проекта

Все проекты и фазы должны быть закрыты все зависимости завершился он триумфом или провалом.

Для закрытия: 

  • выдать результат (требуемый по scope baseline)
  • проверить и сделать «что нужно» для закрытия (например, высвободить команду подписать акт приемки работ, получить отзыв от клиента и т.п.)
  • зафиксировать полезную информацию по проекту («выученный урок» — что было успешно/неуспешно, какие самые большие риски и т.п.)

2. УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА

Определить, какие работы необходимы, а потом что только они выполняются.

5.2. Сбор требований

Сбор требований происходит посредством опроса заинтересонных лиц — интервью, анкеты и т.п. 

Пример матрицы требований RequirementMatrix_2015

5.3. Определение содержания

Делаем концепцию (техническое задание): детальное описание продукта и проекта

Определяем: что делаем и чего НЕ делаем в ходе проекта

Пример концепции: ProjectScope_2015

5.4. Создание иерархической структуры работ

Разделяй и властвуй!

Перед тем как представить иерархическую структуру работ желательно представить иерархическую структуру продукта

Иерархическая структура продукта (PBS — Product Breakdown Structure):

Иерархическая структура работ (WBS — Work Breakdown Structure):

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

От сложного – к простому.

5.5. Контроль содержания

Если понимаем, что не учли какой-то элемент, то вносим изменения в планы

3. УПРАВЛЕНИЕ ВРЕМЕНЕМ (СРОКАМИ) ПРОЕКТА

Вот как это выглядит на «Карте процессов»:

6.1. Управление расписанием

Как создать расписание и сопоставление содержания с расписанием

6.2. Определение операций

Декомпозиция технического задания в ДЕЙСТВИЯ!

Берем иерархическую структуру работ и переводим ее в «глаголы» — как добьем результата обозначенного в ИСР.

6.3. Определение последовательности операций

Перестраиваем ИСР в Сетевую диаграмму (PDM — Precedence Diagramming Method, Метод «операции в узлах» (метод предшествования).

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

6.4. Оценка ресурсов операций

Ресурсы делятся на:

  • Возобновляемые – люди и оборудование
  • Невозобновляемые – материалы

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

6.5. Оценка длительности операций

Способ оценки по аналогии с предыдущей похожей деятельностью.

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

 Среди аналоговых методов оценки есть один метод, который люди используют чаще всего – оценка из своего опыта. Это предполагает простой алгоритм:

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

Такой оценки имеет существенную особенность – оценки получаются заниженными, то есть оптимистичными.

Это оценка такого типа:

я не знаю, сколько понадобится времени на эту операцию, но могу сказать, что если все пойдет хорошо, то уложимся в 5 дней (оптимистичная оценка), в худшем варианте понадобится 10 дней (пессимистичная оценка), а скорее всего, потребуется 7 дней (наиболее вероятная оценка).

В результате нужно усреднить способом «оценка PERT» (PERT – Program Evaluation and Review Technique): 

Ожидаемая оценка = (Оптимистичная + 4 * Наиболее вероятная + Пессимистичная) / 6

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

Пример: Оценка по трем точкам.

Некоторая работа исполнялась 10 раз. Статистика длительностей:

  • 2 раза за 4 дня – оптимистичная
  • 7 раз за 5 дней – наиболее вероятная
  • 1 раз за 9 дней – пессимистичная

Посчитаем разные средние значения:

Средняя (арифм) = (4 * 2 + 5 * 7 + 9 * 1) / 10 = 5,2 дней

Ожидаемая (PERT) = (4 + 4 * 5 + 9) / 6 = 5,5 дней

6.6. Разработка расписания

Используйте программное обеспечение — диаграммы Ганта и т.п.

Метод критического пути для составления расписания

Метод критического пути является основным способом расчета расписания проекта.

Операции могут иметь резервы, вызванные наличием параллельных цепочек:

Резерв (Float, Total Float, Slack) – время, на которое операция может быть задержана, без увеличения длительности проекта:

Резерв = Поздний старт — Ранний старт

Свободный резерв (Free Float) – время, на которое операция может быть задержана, не влияя на раннее начало любой последующей операции

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

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

Операции без резервов являются основным фокусом внимания менеджера и команды проекта:

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

6.7. Контроль расписания

Делаем прогнозы отклонений и отслеживаем укладываемся ли в в график.

4. УПРАВЛЕНИЕ СТОИМОСТЬЮ ПРОЕКТА

Вот как это выглядит на «Карте процессов»:

7.1. Планирование управлением стоимостью

Как будем держать под контролем наш план

7.2. Оценка стоимости

Считаем себестоимость на основе временных зарат.

Стоимость проекта = стоимость всех работ проекта

Стоимость работы = стоимость израсходованных ресурсов.

Стоимость проекта = Сумма стоимостей израсходованных ресурсов.

7.3. Определение бюджета

Бюджет проекта – это распределение стоимости проекта по времени.

Базовый план стоимости (cost baseline)= себестоимость работ + резервы работ + резервы пакетов работ

Бюджет проекта (project budget) = Базовый план стоимости + управленческие резервы

Управленческие резервы — это деньги, который спонсор проекта отложил на «всякий случай»

«План по стоимости» — это бюджет проекта.

Стоимости делят на две важные группы:

  • стоимости ресурсов — состоят из стоимости людей, оборудования и материалов, требуемых для исполнения работ проекта,
  • денежные затраты — это затраты на оплату работ внешних исполнителей – поставщиков и подрядчиков. На рисунке эти затраты показаны кривой «Ожидаемый денежный поток»

«Резерв управления» – это превышение бюджета, вызванное выявленными рисками.

7.4. Контроль стоимости

Собираем все вместе  и контролируем календарный план проекта (MS Project):

Пример: The Practice Standard for Earned Value Management

Далее разберем:

  • управление качеством,
  • управление HR,
  • управление коммуникациями,
  • управление рисками,
  • управление закупками,
  • управление заинтересованными сторонами.

7. УПРАВЛЕНИЕ КОММУНИКАЦИЯМИ

  • Определение заинтересованных сторон проекта.

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

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

  • Планирование коммуникаций

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

  • Распространение информации

Это процесс предоставления необходимой информации заинтересованным сторонам проекта в соответствии с планом.

  • Управление ожиданиями заинтересованных сторон проекта

Это процесс общения и работы с заинтересованными сторонами проекта для удовлетворения их потребностей и решения возникающих проблем.

  • Подготовка отчетов об исполнении

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

Тур по книгам по управлению проектами:

  1. Описать основные принципы работы в IT-сфере успешно удалось Тому Демарко и Тиму Листеру. Пожалуй, начать книжное путешествие стоит с их книги «Человеческий фактор: успешные проекты и команды».  Из книги узнаете: «как?», «зачем?» и «почему?»
  2. Если в вашей работе много рисков, то возьмите на заметку  «Вальсируя с Медведями».

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

А вот сервис, где представлена деловая литература: //filegiver.

com/c/delovaya-literatura

Часть 3 подготовлена по материалам Селиховкина, PMlead.ru, //projectbureau.ru/book/bp_work/ и книги PMBOK

Источник: https://blog.alevi.ru/management/upravlenie-proektami-po-pmbok/

Поделиться:
Нет комментариев

    Добавить комментарий

    Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.