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

  Эта глава предполагает, что в организации уже имеется эффективный график работы, что все ключевые участники проекта знают (и согласились с этим), что от них ожидается.
Развитие проекта как замкнутой контрольной системы
Управление по принципу исключений
Процесс развития проекта можно считать своего рода частью замкнутой контрольной системы.
Необходимо проследить за тем, чтобы по каждому исходящему указанию или инструкции был получен ответ системы и подготовлен обратный результативный сигнал. В противном случае будет просто невозможно понять, когда необходимо предпринимать меры по устранению ошибок и проблем. Менеджер проекта должен проследить за тем, чтобы эти меры по устранению ошибок и проблем все-таки были предприняты и система замкнутого контроля эффективно действовала.
В любой системе контроля за обратной связью большое значение имеют совершаемые ошибки. Именно масштабность и стадия развития совершаемых ошибок являются причинами действий по их устранению. В контексте теории управления такие ошибки называют «исключения». Разумная концентрация внимания и подготовка отчетности по таким исключениям называется «управлением по принципу исключений».
15—2016

Управление по принципу «никаких неожиданностей»
Существует альтернативный подход к управлению. Он затрагивает только исходящие инструкции, не имеет обратной связи и не получает сигналов о совершенных ошибках. Это называется управление по принципу «никаких неожиданностей», поскольку менеджер вводит задачу на одном конце системы и не ожидает, что эта задача не приходит на другой конец системы!
Отслеживание процесса развития и обновление компьютерных данных
Когда проект уже находится в процессе реализации, необходимо представить двустороннюю систему связи между менеджером проекта и менеджером каждого отдела. Необходимо наладить процесс распространения инструкций по выполнению работ и регулярного получения результатов исполнения этих работ и развития проекта.
Использование списков задач как средство отчетности по прогрессу
Если менеджер проекта отсылает участникам проекта инструкции по работе в виде списков задач, почему бы не использовать ту же процедуру в обратном направлении для получения отчета о результатах выполнения работ? Единственное, чего здесь не хватает, это документ, прилагаемый к списку задач. Отсутствие такого документа можно компенсировать следующими способами: Использовать специально разработанные формы отчетности по прогрессу. Линейные менеджеры могут написать на своих копиях списка задач свои комментарии и отослать их обратно. Прямой ввод данных в компьютер через компьютерную сеть компании.
Первый способ предполагает большее количество форм и канцелярской работы, чего по возможности лучше избегать.
Для второго способа используется Open Plan - программное обеспечение, которое в своем стандартном наборе отчетов имеет форму, объединяющую список задач и отчет-анкету (рис. 12.1). Существует много других программных обеспечений, которые позволяют делать пометки и записывать комментарии на своих списках задач и работ.

OPEN PLAN


ДЭННИС ЛОКК




СТРАНИЦА: 1

ОТЧЕТ: ACTQST

ПРОЕКТ ГАРАЖА (ДЛЯ КНИГИ ДЭННИСА ЛОККА)

ДАТА ОТЧЕТА: 16 апреля 95

ПРОЕКТ: ГАРАЖ Анкетные данные хода выполнения работ


ТЕКУЩЕЕ ВРЕМЯ: 13 мая 96



органи
зация

кор-
регги-
ровка

%

По графику

Ход выполнения работ

фактически


ИНДЕКС РАБОТ

ОПИСАНИЕ

Затр.
время

Затр.
время

Келл

начало

заверше
ние

состо
яние

зна
чение

начало

заверше
ние

примеча
ние

СТАРТ

Начало реализации проекта гаража

0

0

100

13.05.1996

13.05.1996


0

А: 13.05.96

Выполнено


G0103

Изготовление и грунтовка коробки ворот

1

1

0

13.05.1996

13.05.1996






G0102

Закладка фундамента

4

4

0

13.05.1996

13.05.1996

р

0

начато



G0305

Установка коробки ворот

1

1

0

14.05.1996

14.05.1996






G0107

Изготовление дверей

3

3

0

13.05.1996

15.05.1996






G0205

Закладка бетонных столбов

2

2

0

17.05.1996

20.05.1996






G0713

Грунтовка дверей

1

1

0

16,05.1996

16.05.1996






G0508

Кирпичная кладка

10

10

0

21.05.1996

03.05.1996






G0810

Установка над дверьми перемычки стандартного профиля

1

1


04.06.1996

04.06.1996






G1016

Блок перемычки и постройка парапетов

2

2

0

05.06.1996

06.06.1996






G0509

Закладка пола

2

2

0
/>21.05.1996
22.05.1996






G0110

Деревянное покрытие крыши

1

1

0

13,05.1996

13.05.1996






G0913

Обработка пола

1

1

0

23.05.1996

23.05.1996






G1317

Установка дверей

1

1

0

04.06.1996

04.06.1996






G1012

Покрытие крыши

2

2

0

05.06.1996

06.06.1996





Рис. 12.1 Комбинированный список задач и вопросник по развитию проекта Этот пример был подготовлен с помощью программного обеспечения Open Plan.

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

Ввод в компьютер неверной информации может привести к последующим ошибкам в сетевом анализе, планировании ресурсов и составлении списков дальнейших работ. Если в компьютерную сеть компании загружена большая и сложная модель для использования на многих проектах, то сотрудник или группа сотрудников, ответственных за планирование, всегда будут осторожничать, чтобы вводимая информация не испортила файлы модели, так как на их восстановление потребуется много часов работы.
Хотя информация о ходе реализации проекта постоянно обновляется с помощью непосредственного ввода данных, списки задач и другие планы- графики, вероятнее всего, будут пересмотрены и переизданы только когда планировщик решит, что необходима повторная обработка данных. Такое решение должно быть принято планировщиком заранее. Затем, сразу же после ее согласования, необходимо объявить следующую дату начала отсчета (см. ниже).
Регулярность сбора данных о ходе выполнения работ Отчет о проделанной работе должен представляться довольно регулярно через небольшие промежутки времени. Обычно эта информация обновляется чаще, чем сам официальный список задач. Рекомендуемый интервал предоставления отчетов составляет одну неделю. Если же этот интервал представляет собой довольно длинный период времени, то существует вероятность того, что некоторые проблемы будут обнаружены слишком поздно, чтобы можно было предпринять меры по их исправлению.
Дата отсчета
Всю информацию о ходе выполнения работ по проекту необходимо предоставлять со ссылкой на следующую дату начала отсчета. Эта дата является отправной точкой для проведения анализа сроков и перепланирования после обновления плана-графика на компьютере.
Все сотрудники, предоставляющие данные о развитии проекта по компьютерной сети или на бумаге, должны быть проинформированы о следу
ющей назначенной дате отсчета как можно раньше. Обычно планировщик в качестве даты отсчета выбирает дату проведения перепланирования или на пару дней позже.
Если приходится довольно часто обновлять план-график по причине каких-либо изменений или по другим обстоятельствам, то и процедуры обработки данных должны быть организованы с той же регулярностью. Если эти интервалы одинаковы, то даты перепланировки и даты отсчета могут быть объявлены и занесены в календари заранее на несколько месяцев вперед.
Качество и надежность информации о ходе выполнения работ
В какой бы форме ни оформлялись отчеты о ходе выполнения работ, следует тщательно следить за тем, чтобы в отчетах никогда не было двусмысленности или неоправданных сложностей. Чем проще метод и форма отчетности, тем легче заставить задействованных менеджеров предоставлять эти отчеты регулярно и вовремя. Но даже в таком случае обучение ключевых участников процедурам предоставления регулярных рутинных отчетов о ходе выполнения работ является для менеджера хорошей проверкой на выдержку. Много попыток по осуществлению контроля над проектом провалилось из-за того, что не удалось наладить описанный выше механизм работы.
Суть информации для обновления плана-графика в компьютере
Каждый раз при составлении отчета о ходе выполнения работ (будь то информация анкет-отчетов или данные, напрямую вводимые в компьютер линейными менеджерами) по каждой операции начатой, законченной или выполняемой относительно предыдущего отчета или внесения данных в комьютер необходимо предоставлять следующие факты или оценки: Если работа началась после подачи предыдущего отчета, когда был фактический день начала работ? Если какие-то работы были начаты, но не были завершены, то следует иметь информацию о: предполагаемом проценте выполнения этих работ на дату отсчета или предполагаемом сроке для завершения этих работ после даты отсчета. Закончена ли работа? Если да, то когда был фактический день завершения работ?

Вопросы логики
Если отчет о ходе выполняемых работ не вводится непосредственно в компьютер, а предоставляется в виде печатного документа, то каждый проницательный менеджер проекта обязательно задаст вопрос: закончено ли выполнение заявленной в отчете операции? Чрезвычайно важный вопрос здесь: можно ли приступить к выполнению задачи, которая в соответствии с планом должна быть начата сразу по завершении выполнения данной операции? Этот вопрос (ответ на который обычно либо требуется, либо его просто невозможно дать, когда отчетные данные вводятся в компьютер) является серьезной проверкой того, завершено ли фактически выполнение задачи или нет. Если логика сетевого анализа проекта верна, то невозможно показать в отчете завершение операции, если еще нельзя приступить к выполнению зависящей от ее завершения следующей операции.
Настороженный менеджер проекта распознает появление проблемы, если в отчете о развитии проекта будет заявлено, что задание выполнено на 99 или 100 процентов, но к выполнению следующей задачи при этом приступить невозможно. Это может означать, что в действительности задача была выполнена не до конца. Подобная аномалия также возникает, когда инженер-конструктор заканчивает выполнение комплекта чертежей, но отказывается выпускать их для пользования из-за неуверенности в разработках или же он считает, что если у него будет еще время, он может их усовершенствовать, или по другим несущественным причинам личного характера.
В некоторых случаях начало нового этапа работы возможно, даже если предыдущая операция еще не завершена. Например, если операция может быть еще не завершена, но уже достаточно реализована для того, чтобы сделать заказ деталей, исполнение и доставка которых занимает много времени. Диаграмма сети не всегда указывает на такие возможности, поэтому те, кто не задает правильных и нужных вопросов достаточно регулярно, упускают эти шансы проверки и экспедирования процесса реализации проекта.
Зачастую в отчетах заявляют о начале операции еще до того, как отчитаются о завершении предыдущих операций. Такое положение вещей противоречит логике сетевой диаграммы и говорит о том, что ограничения сетевого анализа не являются абсолютными. Тем не менее если складывается подобная ситуация, данные все равно должны быть приняты и введены в компьютер: большинство программных обеспечений должны быть в состоянии принять непоследовательные данные о ходе выполнения проекта.

Управление по принципу личных встреч
рутинные методы сбора информации о ходе реализации проекта, описанные выше, могут быть эффективными лишь в идеальном мире. Они формируют картину, когда всю свою работу менеджер проекта выполняет, сидя в офисе за столом, раздавая указания и получая отчеты, в то время как проект гладко развивается и постепенно близится к своему успешному завершению.
Конечно, внедрение эффективной системы повседневной работы с информацией является одной из важнейших целей, однако требуется кое-что еще. Время от времени менеджер проекта должен покидать свой офис и идти с визитами к участникам проекта, производить проверки на местах, поощрять, когда необходимо, видеть своими глазами физическое выполнение плана работ и прогресс по проекту. Такой процесс обычно называют «управление по принципу личных встреч с участниками проекта».
Выезды на объекты или посещение производственных помещений являются особенно эффективными, когда они повторяются через короткие промежутки времени. Это дает возможность увидеть, как выполняются работы и есть или нет прогресс по проекту. Необходимо также делать фотографии строительных объектов для определения динамики реализации проекта и в качестве постоянного свидетельства в отчете по проекту в процессе его развития.
Статистические данные
Еще одним важным моментом является определение действительного количества работников, занятых в работе по реализации проекта, и их уровень квалификации. Полученные данные можно потом сравнить с тем количеством работников, которое компания изначально планировала задействовать в проекте. Можно, конечно, сравнить планируемые и реальные графики затрат денежных средств, но все же «перепись» кадров является более быстрым и эффективным способом получения статистических данных о расходах, связанных с соответствующими ресурсами. Выводы на основе этих данных могут указать на возникновение проблемы непосредственно при ее появлении или на ранних этапах.
Пример применения низкой ставки оценки выполнения работы Предположим, что на определенную дату в соответствии с планом-графиком работу выполняют 35 инженеров. Если на практике работают только 18 человек, то наиболее вероятно, что здесь что-то не в порядке. Хотя отчеты о ходе работы могут говорить о том, что все более или менее в поряд
ке и план выполняется, «перепись» работников показывает, что работа по проекту в конструкторском бюро не выполняется в соответствии с планом- графиком.
Если провести небольшое расследование, то можно выяснить, что разработка проекта задерживается из-за недостатка информации, из-за того, что инженеры переключились на решение более приоритетных задач или из-за того, что сам отдел недостаточно укомплектован рабочими кадрами. В таких случаях менеджер проекта должен выяснить причины возникновения проблемы и соответственно изменить количество персонала, работающего на проекте.
<< | >>
Источник: Локк Д.. Основы Управления Проектами. 2004

Еще по теме Управление развитием проекта:

  1. А.Ю. Егоров, А.А, Сафронова, А.В. Сельское. РЫНОК ИННОВАЦИОННЫХ ПРОЕКТОВ.Методология формирования,управления и развития, 2007
  2. Глава 6 Проекты и деньги. Бюджетирование и финансирование проектов в органах государственного управления
  3. Глава 5 Проекты и стандарты. Стандарт управления проектами строительной компании
  4. Глава 2 Проекты и стратегия. Проекты, программы и портфели проектов на предприятиях топливно-энергетического комплекса
  5. ВАЖНОСТЬ УПРАВЛЕНИЯ ПРОЕКТОМ
  6. Отчеты о развитии проекта
  7. Фазы развития инвестиционного проекта
  8. 18.3. ОРГАНИЗАЦИЯ УПРАВЛЕНИЯ ПРОЕКТОМ
  9. 20.2 УПРАВЛЕНИЕ КОММУНИКАЦИЯМИ ПРОЕКТА
  10. VI. Развитие корпоративного управления, управления рисками и внутреннего контроля в кредитных организациях
  11. 4.1. УПРАВЛЕНИЕ ПРОЕКТАМИ
- Антикризисное управление - Документоведение и делопроизводство - Инвестиционный менеджмент - Инновационный менеджмент - Информационный менеджмент - Исследование систем управления - Корпоративное управление - Лидерство - Маркетинг в отраслях - Маркетинг, реклама, PR - Маркетинговые исследования - Менеджмент организаций - Менеджмент персонала - Менеджмент-консалтинг - Моделирование бизнес-процессов - Моделирование бизнес-процессов - Организационное поведение - Основы менеджмента - Поведение потребителей - Производственный менеджмент - Риск-менеджмент - Самосовершенствование - Сбалансированная система показателей - Сравнительный менеджмент - Стратегический маркетинг - Стратегическое управление - Тайм-менеджмент - Теория организации - Теория управления - Управление качеством - Управление конкурентоспособностью - Управление продажами - Управление проектами - Управленческие решения - Финансовый менеджмент - ЭКОНОМИКА ДЛЯ МЕНЕДЖЕРОВ -