?

Log in

Previous 10

Sep. 20th, 2010

14 принципов эффективного управления:

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


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


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


4. Единоначалие - работник получает распоряжение и отчитывается только перед одним непосредственным начальником.


5. Единство действий - все действия, имеющие одинаковую цель, должны объединяться в группы и осуществляться по единому плану.


6. Подчиненность интересов - интересы организации имеют преимущества перед интересами отдельных сотрудников.


7. Вознаграждение персонала - получение работниками справедливого вознаграждения за свой труд.


8. Централизация - естественный порядок в организации, имеющей управляющий центр. Лучшие результаты достигаются при верной пропорции между централизацией и децентрализацией. Полномочия (власть) должны делегироваться пропорционально ответственности.


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


10. Порядок - рабочее место для каждого работника и каждый работник на своем рабочем месте.


11.Справедливость - установленные правила и соглашения должны проводиться в жизнь справедливо на всех уровнях скалярной цепи.


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


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


14. Корпоративный дух - гармония интересов персонала и организации обеспечивает единство усилий (в единстве - сила).

Feb. 4th, 2009

Неделя Проектного Управления в бизнес-сообществе ЗУБРЫ.РУ

 Под девизом: Кризис - возможность для руководителей проектов!

Неделя Проектного Управления проходит с  3 февраля 2009г. и продлится до 10 февраля 2009г. Во время этой недели можно задать свои самые актуальные вопросы Экспертам, которые являются участниками сообщества и согласились участвовать в настоящем мероприятии. Эксперты ответят на ваши вопросы, если на них можно дать готовые ответы, или помогут разобраться в проблемах, если готовых решений нет, или они индивидуальны. Вопросы могут касаться как непосредственно самого проекта обсуждения – управления проектами, так и вопроса, который может интересовать руководителей проектов – консультаций по карьере. Каждый вопрос будет услышан и рассмотрен, а ответ на него появится на форуме сайта в течение 3-х часов.

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

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

 

Dec. 19th, 2008

Видео-уроки, основанные на PMBOK

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

The Art of Project Management

Dec. 8th, 2008

Внедрение КСУП

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

О журнале
Концепция журнала предусматривает публикацию научных работ преподавателей, слушателей и выпускников Школы IT-менеджмента по тематике информационных технологий. Данное направление является исключительно востребованным в современных условиях, когда происходит резкий рост применения IT-технологий в народном хозяйстве. С появлением журнала авторы получат возможность донести научные результаты в IT-области до широкой аудитории.

Sep. 7th, 2008

Проектный бизнес и модели его успеха


Применительно к проектному бизнесу существуют, по крайней мере, три успешных модели для российских условий. Существование не одной модели, а целого спектра моделей проект­ного бизнеса вызвано тем, что термин "проектный бизнес" охватывает значительно больший круг вопросов, чем известный термин "управле­ние проектами". Различие касается, прежде всего, основных целей биз­неса: прибыль, активы, капитализация, социальное положение и т.д.
Отдельные компоненты бизнеса могут быть формализованы или до­кументированы в формате корпоративных стандартов. Например: тех­нологическая карта производства, стандарт качества, схема управления компанией. Построить единую модель бизнеса невозможно.
 
Модель №1. Гарантированный рецепт успеха
 
Существует простой рецепт успешного проектного бизнеса, обла­дающий высокой степенью гарантии. Бизнес-модель, содержащая та­кой рецепт, называется "буквальное копирование западной модели проектного бизнеса". Российская компания, намеренная внедрить эту модель, должна выполнить 5 пунктов:
 
1.       в качестве менеджеров проектов принимать на работу только спе­циалистов, сертифицированных по стандартам PMI или IPMA; в среднем число сертифицированных специалистов должно равнять­ся числу проектов;
2.       провести обучение и тренинга всех других специалистов, задейс­твованных в реализации проектов; еще лучше направить работни­ков на стажировку в западные компании;
3.       разработать и внедрить комплексную систему корпоративных рег­ламентов, стандартов, инструкции; количество документов быть не менее 500; система должна охватывать все бизнес-процессы компании; в систему должны быть включены практически дословно модели PMI или IPMA;
4.       принять на работу специалистов западного происхождения, чис­ло иностранцев по отношению к управляющим или инженерным работникам-резидентам должно составлять, как минимум 1:10; в любом случае, число иностранцев должно быть не менее пяти; до­полнительно необходимо привлечение западной консалтинговой компании, в частности, из уже присутствующих на российском рынке;
5.       применять предыдущие четыре пункта минимум 3 года.
 
В России эта модель известна 300 лет. Петр I был первым, кто ее внедрил. Царь применил рецепт для проекта "Северная война". Успех превзошел все начальные ожидания. Россия выиграла войну, Санкт-Петербург был построен, Россия перешла на развитие по новой траектории.
Секрет рецепта состоит в необходимости буквального следования всем пунктам модели. Попытки копирования предпринимались и в те­чение почти ста лет перед Петром, например, создание полков немец­кого строя. Большого успеха эти начинания не принесли. Петр, благо­даря своей природной гениальности, понял необходимость полного и буквального копирования. Отсюда: первый воинский устав (корпора­тивный стандарт), прием в армию иностранцев, бритье бород, евро­пейские одежды, курение табака, питие кофе и иных напитков, танцы, учебники, реформа алфавита. Академия, выращивание картофеля и тому подобное. Даже национальный оплот, православная церковь под­верглась реформации: место митрополита занял Синод.
Петровский пример показывает наряду с гарантированностью моде­ли копирования также и главную ее проблему: для применения рецеп­та требуется сверх-мобилизация ресурсов. Петр обладал абсолютной властью в не бедной стране, поэтому для него проблемы ресурсов не было.
Может ли этот внешне простой рецепт применяться для российских компаний? Может, если компания обладает достаточными финансовы­ми ресурсами. По приблизительным расчетам цена вопроса составля­ет 10-50 миллионов долларов, в зависимости от размеров компании. В сумму ВХОДЯТ как прямые издержки, так и косвенные, в том числе, под­держка собственного персонала (в отличие от Петра, современная ком­пания не может позволить себе просто выбросить персонал за борт).
   
Модель №2. Бизнес на основе накопленного опыта
 
Можно строить успешный проектный бизнес без всякого копирова­ния западного опыта. Если в компании накоплен опыт, возникший на основе выполнения многих проектов, то следующие проекты можно выполнять, взяв за образец проекты, успешно выполненные ранее. Эту модель назовем моделью на основе накопленною опыта. Такие атрибу­ты проектов, как проектные этапы, образцы документов и контрактов, календарные трафики и типовые сметы, степень загрузки персонала могут быть скопированы с предыдущих проектов.
 
Преимуществом модели является практически полное отсутствие затрат на ее внедрение. В то же время, модель имеет два недостатка:
  • реальный срок накопления опыта выполнения проектов составляет 5-10 лет — именно за этот срок проектные методы и инструменты становятся привычными для всего персонала компании;
  • если в компании возникнет необходимость выполнения проектов, которые по своему типу или виду деятельности существенно отли­чаются от ранее выполнявшихся проектов, то накопленный опыт может даже оказать вред.
 В России наиболее ярким примером использования модели накоп­ленного опыта является московская строительная программа. В пере­строечный перелом 1989 - 1991 годов руководство города сохранило полностью старый советский опыт, постепенно дополнило его рыноч­ными механизмами и добилось феноменальных успехов. Не каждая столица в мире может похвастаться объемами освоения 5 миллионов квадратных метров в год.
 
Для компании, применяющей модель накопленного опыта, нет необходимости изучать современные методы проект­ного бизнеса. Даже если в компании и начнется переход к но­вым методам, фактически, это будет уже новая компания с новым бизнесом.
 
Модель №3. Адаптации западного опыта
 
Модель буквального копирования западного опыта обладает на­ивысшей степенью гарантии. Это примерно как, если бы российская компания разместила деньги в лучшем американском банке. Как и в финансовой сфере, степень гарантии является обратной стороной эф­фективности бизнеса.
Вернемся к Петровскому примеру. Если условно разделить успех Петра в Северном проекте на цену, которую заплатила нация (в пер­вую очередь числом потерянных жизней), то впечатление о Петровс­ком успехе будет уже неоднозначным. Именно поэтому последние 300 лет Петровские критики имеют почву для СВОИХ рассуждений: зачем было воевать, не лучше ли было направить усилия просто для разви­тия страны, живет же Швейцария отлично без всякого выхода к морю. В оправдание Петру необходимо признать то, что он был первым, кто применил метод тотальною копирования. У него не было предшест­венников, на чьих ошибках можно было бы учиться.
И все же, западный опыт проектного бизнеса доказал свою эффек­тивность. Возникает естественный вопрос: "Можно ли найти иной способ копирования западной модели, за меньшую цену и при сохра­нении эффективности?". Можно, но для этого нужно адаптировать, трансформировать западную систему к российским реалиям. Адапта­ция должна включать:
 
1.     анализ проектных бизнес-инструментов в обшей системе бизнеса:
-       некоторые инструменты просто не могут быть скопированы изолированно от инструментов в других ветвях бизнеса;
-       при трансформации, западные проектные инструменты необхо­димо дополнять специальными российскими инструментами, вытекающими из российской бизнес-культуры, традиций и пра­вовых норм;
-       часто западные инструменты отражают скорее их историческое происхождение, чем современную потребность;
2.      использование советского и российского опыта, российских норм:
-       многие, еще советские, инструменты можно вполне приспосо­бить для рыночной жизни;
3.    подбор пакета инструментов для нужд конкретной компании:
-       на Западе существуют как универсальные системы, так и кор­поративные стандарты; хотя в русскоязычной литературе су­ществуют переводы только универсальных стандартов, это не означает, что западные компании слепо подстраиваются под универсальные схемы; при адаптации под конкретную россий­скую компанию нет необходимости в полной универсальности, что, соответственно, снижает затраты на внедрение;
4.     возможность поэтапного внедрения;
5.      возможность вариативности в зависимости от вида деятельности:
-      адаптированная модель должна работать как конструктор для построения систем под конкретный вид проектов;
 
 Адаптированная модель это сплав западного, советского и российского опыта и знаний. Модель позволяет конструи­ровать полноценные системы проектного бизнеса под конк­ретную компанию.

May. 23rd, 2008

Управление интеграцией - процессы инициации.

Разработка устава проекта (Develop Project Charter)

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

  • Название проекта и его описание
  • Менеджер проекта и уровень его полномочий
  • Причина возникновения проекта
  • Обоснование проекта
  • Требования к проекту
  • Цель проекта
  • Первоначальные ресурсы
  • Бюджет проекта
  • Допущения и ограничения проекта
  • Организации - участники проекта
  • Отношения между участниками проекта
  • Расписание контрольных событий (вех)

Достаточно подробно и ясно устав проекта описан в руководстве к своду знаний по управлению проектами (PMBoK Guide).

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

Для наглядности, решил описать бизнес-процесс "Разработка устава проекта" с помощью BPwin, используя методологию IDEF0, пока без декомпозиции.



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

Содержание работ проекта (SOW) -  документ, входными данными для которого являются пожелания и требования, поступающие от заказчика.

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

1) Положение о целях - краткий ответ на вопрос: Зачем осуществляется данный проект?

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

3) Практические результаты проекта - указываются основные участники проекта, в частности состав проектной команды, что будет получено в результате реализации проекта; определяются как промежуточные, так и конечные результаты; дается описание продукта

4) Примерная стоимость и график работ - устанавливается бюджет и конечные сроки; без учета промежуточных результатов

5) ограничения

6) критерии успеха

7) руководства для команды и менеджмента

8) допущения

Зачем необходимо положение о  работе?
Положение о работе необходимо для того, чтобы определить в правильном ли направлении продвигается реализация проекта  и верны ли действия менеджеров, если вы хотите преуспеть. Положение о работе (SOW) устанавливает определенные правила реализации проекта в том случае, если основные участники согласны с его содержанием. В положении приводятся цели, задачи, ограничения, критерии успеха, руководство для менеджеров. Оно разъясняет ответственность и действия основных участников проекта 
Письменное положение о работе является эффективным инструментом воздействия на основных участников проекта и на их ожидания. Составление Положения и матрицы обязанностей дает возможность высокопрофессионально определить стоимость проекта, график работ, необходимое качество, и требуемы ресурсы.
Управление изменениями
SOW является инструментом управления ожиданиями и изменениями. В том случае, когда первоначальные договоренности или предположения претерпевают изменения в ходе реализации проекта, необходимо сообщить о них основным участникам проекта, получить их согласие, а затем внести эти изменения в Положение о работе.

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

May. 21st, 2008

Управление интеграцией проекта (Project Integration Management)

   Область знаний, в которой определены интеграционные процессы, которые входят в 5 групп процессов управления проектом: 
   Два процесса  в группе процессов инициации:
1) разработка устава проекта (на выходе получаем первый проектный документ - устав проекта);
2) разработка предварительного описания содержания проекта (первое понимание того, что от нас хочет заказчик, и что мы будем делать в нашем проекте).
   Затем процесс группы планирования:
3) Разработка плана управления проектом, на выходе обширный документ, описывающий правила управления проектом, это интеграционный процесс, на основании результатов которого мы будем формировать наш план.
   Потом процесс группы исполнения:
4) руководство и управление исполнением проекта.
   За ним следуют два процесса группы мониторинга и управления:
5) Общее управление изменениями, менеджер проекта производит анализ всех изменений проекта;
6) Мониторинг и управление работами проекта, контроль выполнения работ проекта, динамики и внесение управляющих воздействий.
   И напоследок процесс из группы завершающих процессов:
7) Закрытие проекта. 

 

May. 13th, 2008

Организационное окружение проекта

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

   Структура организаций подразделяется на 5 основных типов:

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



 
2) Проектная структура, вся деятельность компании реализуется в виде проектов, члены команд часто собраны в одном месте, большая часть ресурсов задействована в работах проектов, а менеджеры проектов в значительной степени независимы и обладают большими полномочиями. В проектных организациях отделы, подчиняются менеджеру проекта, выполняют функции обеспечения и поддержки других проектов. Слабой стороной является необходимость разработки гибкой системы мотивации, постоянный контроль персонала со стороны менеджера проекта, который должен быть опытным профессионалом, обладающим коммуникативными навыками. Часто, эффективность сотрудников, задействованных в проекте, снижается по мере приближения к завершающей фазе, это связано с тем, что люди пытаются защитить себя от неприятностей, задаются вопросами: "Срокзавершения проекта близок, чем я буду заниматься, когда проект завершится? А пригласят ли меня на другой проект?", а в это время им поступает более выгодное предложение поучаствовать в другом проекте. Очень важно для менеджера проекта не упустить этот момент, вовремя оказать управляющее воздействие, замотивировать ключевых сотрудников.

 


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

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



4) Сбалансированная матрица. В этом случае у нас появляется менеджер проекта, и четко прописываются правила взаимодействия сотрудников с менеджером проекта, который в свою очередь наделен не всеми полномочиями по управлению проектом и финансированием проекта. При такой структуре, для учета рабочего времени сотрудников используются time-sheet-ы (листы учета рабочего времени и расходов), где указываются выполненные работы.



5) Сильная матрица, используется в крупных компаниях. Обладает характеристиками проектной организации, в данном случае присутствует штатный менеджер проектов с широкими полномочиями, а так же входящий в штат управленческий персонал проектов. Так же преимуществом является то, что персонал полностью подчиняется менеджеру проекта, задействуется на время выполнения проекта, по его завершению люди возвращаются обратно к своим функциональным обязанностям. Для менеджеров проектов, проблем становится меньше, потому что они объединены в одну структуру, например проектный офис или группу координации проектов, где появляется руководитель проектного офиса или директор проектов, он же спонсор, задачей которого является решение проблем и распределение на уровне ресурсов для всех проектов на предприятии. Функциональные руководители сообщают о доступных ресурсах, которые они могут выделить проекту. В случае если появляется потребность в сотруднике с определенной специализацией и квалификацией, то группой управления проектами составляется заявка на подбор соответствующего требованиям человека. После чего инициируется поиск сотрудника по компании, затем в регионах, если найти подходящую кандидатуру внутри организации не удается, то приглашается специалист со стороны.



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

  

May. 10th, 2008

Области Знаний 9 и группы процессов Управления Проектом 5

Ромашка - 9 областей знаний, 5 групп процессов, точки - 44 процесса, пунктирные линии обозначают из какой области знаний в какую группу входят.



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

5 групп процессов:



То же самое, но только в виде таблицы. 
Процессы управления PMI® PMBOK®
GUIDE 2004

 

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

На мой взгляд  принцип управления процессами был унаследован из цикла Деминга (PDCA) Plan, Do, Check, Act
Планирование, Выполнение, Проверка, Воздействие



P - 1) определение целей и задач 
      2) определение способов достижения целей
D - 3) обучение и подготовка кадров
      4) выполнение работ
C - 5) проверка результатов выполнения работ
A - 6) осуществление соответствующих управляющих воздействий

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

В Природе, изначально гармоничной,
Процессы развиваются ритмично.
Уходит ночь и день приходит новый,
Восток светлеет — всходит солнце снова.
И каждый год меняет зиму лето.
И бесконечно повторится это.
...Чтоб бизнес рос, и ты циклично действуй:
Планируй —
Делай —
Проверяй —
Воздействуй.
П. Калита
  

Previous 10