БИЗНЕС-СЕТЬ KINETICS CRM CALL-ЦЕНТРЫ ERP ECM ITSM PM АБС АБН SEC SAAS
     
ЧТО ТАКОЕ PM? НОВОСТИ АНАЛИТИКА PM СИСТЕМЫ СЕРТИФИКАЦИЯ ПОСТАВЩИКИ ФОРУМ Напишите нам!  
СТАТЬИ
МЕТОДОЛОГИЯ
ПРАКТИКА ВНЕДРЕНИЯ
ОБЗОРЫ РЫНКА
ВИДЕОМАТЕРИАЛЫ
МНЕНИЯ ЭКСПЕРТОВ
РЕЙТИНГИ
project management ПОДПИСКА

Чтобы подписаться на рассылку новостей сайта, введите свой e-mail:

 
   
ITSM и ITIL?
ITSM (сокращение от IT Service Management) - это концепция управления IТ инфраструктурой компании, сфокусированная на предоставлении услуг и ориентированная на бизнес-потребителя этих сервисов. >>>
ITIL (IT Infrastructure Library) - это обобщение лучшего международного опыта в области организации и управления IT >>>
 
CRM СИСТЕМЫ
CRM (Customer Relationship Management) - это концепция управления отношениями с клиентами. В терминах управления бизнесом - это система организации работы front-office с ориентировкой на потребности клиента, на проактивную работу с клиентом.>>>
 
   
МЕТОДОЛОГИЯ


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

Методология управления проектами представляет собой набор процедур и определяющих их внутренних нормативных документов, а также совокупность инструментов и методов управления проектами, которые обеспечивают реализацию всех проектов компании по единым правилам и стандартам. Методология определяет как процедуры управления (принятия решений по проектам) на разных фазах жизненного цикла, так и требования к проектам в разных функциональных областях: финансы, кадры, сроки, ресурсы, риски, качество, договора и поставки и др. (А.Ю.Сооляттэ)
 
Модель проектной группы MSF (MSF Team Model) описывает подход Майкрософт к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта. Данная модель определяет ролевые кластеры, их области компетенции и зоны ответственности, а также рекомендации членам проектной группы, позволяющие им успешно осуществить свою миссию по воплощению проекта в жизнь.

MSF основан на постулате о шести качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы. В то время как за успех проекта ответственна вся команда, каждый из ее ролевых кластеров, определяемых моделью, ассоциирован с одной из упомянутых шести целей и работает над ее достижением. Шесть ролевых кластеров модели проектной группы — это «Управление продуктом» (product management), «Управление программой» (program management), «Разработка» (development), «Тестирование» (test), «Удовлетворение потребителя» (user experience) и «Управление выпуском» (release management). Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Но в любом случае суть концепции остается той же — построить основу производственных отношений и связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд любого проекта. Одна роль (или один кластер) может быть представлена одним или несколькими сотрудниками, в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера.

Microsoft Solutions Framework представляет собой согласованный набор концепций, моделей и правил. В последней версии MSF 3.0 были обновлены модели проектной группы (Team Model) и процессов (Process Model), а также добавлены:
- три новые дисциплины — управление проектами, управление рисками и управление подготовкой (Readiness Management);
- новые руководства, которые доступны через интернет;
- примеры шаблонов документов для проекта MSF;
- новый очный курс 1846A MSF Essentials.

Подробнее смотрите информацию на сайте Microsoft www.microsoft.com/rus/msdn/msf
 

Методы анализа наиболее типичных проблем управления проектом

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

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

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

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

Определение альтернатив: 1) ничего не делать; 2) реструктурировать проект без новых ресурсов; 3) добавить ресурсы для решения проблемы, не обращая внимания на стоимость; 4) перераспределить ресурсы внутри команды проекта; 5) устранить ресурсы из проекта; 6) расширить масштаб и/или цель проекта; 7) сузить масштаб и/или цель проекта; 8) решить проблему за пределами проекта; 9) изменить технологию работы в проекте.

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

Объявление о решении и действиях (одновременно).

Совершение действия. Совершать действия следует одновременно: если делать это последовательно, некоторое время будет существовать «гибрид» старого и нового.

Проверка и контроль исполнения. Результаты действий и решений должны проявиться вскоре после их претворения в жизнь. Для этого следует ответить на вопросы: вылечена «болезнь» или только ее симптомы; не создают ли побочные результаты решений новые проблемы; существуют ли дополнительные области, где можно применить эти действия, и решения с небольшими дополнительными усилиями.

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

  • формулирование проблемы и возможные последствия;

  • выделение определенных проблемных областей и мониторинг потенциальных сложностей;

  • структуризация проблем и возможных способов их решения.

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

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

Первый метод

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

Проблема 1. Моральный дух команды: если моральный дух слаб, разумно укреплять его «снизу вверх», повышать уверенность сотрудников в себе, обеспечивать дополнительную поддержку. Если моральный дух силен, не обольщайте себя тем, что все идет хорошо, — у команды может быть просто завышена самооценка.

Проблема 2. Состав команды: рекомендуется решать кадровые проблемы самостоятельно и мирно. Если такие меры не помогают, имеет смысл обсудить проблему с топ-менеджментом.

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

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

Проблема 5. Управление технологией: неразумно воспринимать технологию как должное — любая технология требует управления и активной оценки ее использования.

Проблема 6. Изъятие из проекта критически важных ресурсов: следует с самого начала учитывать, что такая угроза существует; четко представлять себе потребности, настаивать на получении определенных ресурсов, учитывая при этом состояние бизнеса фирмы в целом.

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

Проблема 8. Координация работы с поставщиками и подрядчиками: еще до начала проекта следует выяснить личный интерес поставщика или подрядчика и использовать его. При выборе поставщиков или подрядчиков необходимо четко формулировать задачи проекта. Для облегчения координации работы с ними выявить зависимости между проектами; определить способы контроля качества и изменения графика и приоритетов; установить процесс координации между проектами на уровне менеджера проекта и ниже.

Второй метод

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

Проблема 1. Низкие результаты работы. Клиент считает, что группа не заинтересована в решении проблемы и ее члены не способны работать вместе.

Возможные причины:

  • члены группы не могут достичь согласия по поводу задачи группы;

  • задача группы в отношении результата и ресурсов была поставлена нечетко;

  • менеджеры не справляются с работой;

  • руководитель проектной группы не имеет соответствующих полномочий или лидерских качеств;

  • члены группы не обладают достаточными техническими и функциональными качествами.

Возможные способы коррекции ситуации:

  • более четко сформулировать задачу группы;

  • прояснить разделение функций и подотчетность в группе;

  • организовать тренинг руководителю группы по лидерству;

  • провести тренинг для членов группы по техническим и функциональным навыкам.

Проблема 2. Личностные конфликты в группе. В команде проекта существуют очень сильные противоречия. Основываясь на опыте, предположим следующие причины межличностных конфликтов в группах:

  • члены группы уверены в том, что именно они, а не менеджер, несут полную ответственность за результаты работы группы;

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

Возможные пути решения проблем:

  • дать понять членам группы, что руководитель отвечает за результат ее работы;

  • объяснить каждому сотруднику круг его обязанностей и ответственности и провести общее собрание для разрешения возникших конфликтов.

Проблема 3. Члены группы не могут работать как одна команда. Одна из наиболее распространенных проблем, как в функциональных, так и в проектных группах. Возможные причины:

  • руководители не могут прийти к согласию по поводу конкретной задачи группы и подотчетности;

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

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

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

  • выработать коллективное видение задания группы в отношении ресурсов и результатов;

  • выработать персональное видение задачи каждого в отношении ресурсов и результатов;

  • обсудить совместно значимость разделения обязанностей и распределить сферы ответственности между членами группы;

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

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

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

Резюме

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

  • неосведомленность о проблеме;

  • неверный «диагноз»;

  • решение не «продано» топ-менеджменту;

  • принятие решений без запланированных действий;

  • действия при отсутствии рамок решения;

  • неспособность действовать тогда, когда нужно;

  • действия, не соответствующие принятым решениям.


Пятенко С.В., генеральный директор "Экономико-правовой школы ФБК" (ЭПШ ФБК), д.э.н., магистр делового администрирования.



 
О проекте Конфиденциальность Реклама на портале Карта сайта  
Copyright © 2006 - 2018 PMONLINE.RU и Бизнес-сеть "Kinetics". All rights reserved.