лидирование проектов что это такое
Значение слова «лидирование»
Источник (печатная версия): Словарь русского языка: В 4-х т. / РАН, Ин-т лингвистич. исследований; Под ред. А. П. Евгеньевой. — 4-е изд., стер. — М.: Рус. яз.; Полиграфресурсы, 1999; (электронная версия): Фундаментальная электронная библиотека
лиди́рование
1. действие по значению гл. лидировать
Делаем Карту слов лучше вместе
Привет! Меня зовут Лампобот, я компьютерная программа, которая помогает делать Карту слов. Я отлично умею считать, но пока плохо понимаю, как устроен ваш мир. Помоги мне разобраться!
Спасибо! Я обязательно научусь отличать широко распространённые слова от узкоспециальных.
Насколько понятно значение слова дифференциал (существительное):
Синонимы к слову «лидирование»
Предложения со словом «лидирование»
Понятия, связанные со словом «лидирование»
Отправить комментарий
Дополнительно
Предложения со словом «лидирование»
Их основным ресурсом становилось личное лидирование.
Она базировалась на утверждении, что в основе лидирования лежат врождённые или даже наследуемые преимущества одних людей над другими.
Сейчас, будучи взрослым и состоявшимся человеком, я понимаю, что моя роль ведущего в коллективе не была неким специальным лидированием – я просто не мог проявлять себя по-другому, не мог вести себя иначе.
В связи с возросшим вниманием к понятию «лидерства» в современном деловом обществе, кто-то может выступить за замену выражения «руководитель проекта» на «лидер проекта». И неудивительно, так как в некоторых источниках роль лидер а или руководителя взаимозаменяема. Часто термины «лидер», «руководитель» и «шеф» сменяют друг друга, чтоб указать руководящие позиции. Лидерство в этом контексте используется бегло, чтобы охватить управление в целом.
Основываясь на этих определениях, кто-то может поспорить, что руководство явно отличается от лидер ства. Лидерство необходимо, чтоб начать изменения, инновации и создать новый продукт, систему или услугу. Это также включает в себя мотивирование людей для того, чтоб вводить изменения, рисковать и быть новаторами. Руководство, с другой стороны, включает в себя обеспечение эффективной работы.
Третье издание свода знаний по управлению проектами (PMBOK), составленное Институтом Управления Проектами (PMI), выделяет пять процессов: инициация, планирование, выполнение, наблюдение и управление, а также закрытие. В общем, документ описывает 44 процесса управления проектами, которые едва ли сконцентрированы на основном аспекте лидер ства.
Это не означает, что руководитель проекта не должен быть лидер ом, наоборот, чтоб стать хорошим руководителем, необходимо быть хорошим лидер ом. РМВОК не уделяет особого внимания лидер ству, а фокусируется в основном на процессах управления, однако, способность мотивации других людей для достижения их максимального потенциала является ключевым фактором для эффективного лидер ства над проектом.
Не стоит путать понятия «руководитель проекта» и «лидер проекта», так как это неправильно, неточно и часто вводит в заблуждение руководителей проекта, заставляя их думать, что их роль заключается только в руководстве процессами для их завершения. Поэтому многие руководители проектов пренебрегают обязанностями лидер а, такими как выбор направления, наставничество, мотивация и вдохновение членов команды.
Руководитель проекта может применять самые дорогие и эффективные методы управления проектами, которые когда-либо были созданы, для того, чтобы процесс проходил гладко. Но без лидер ских навыков работа с проектными инициативами и целями может обернуться тщетной попыткой. Таким образом, спросите себя, являетесь ли вы руководителем или лидер ом проекта? Почему бы не быть и тем и другим?
Процесс формирования лидер ства руководителя проекта
А.Н. Павлов (компания IT Expert), выступление на 17-м конгрессе по управлению проектами — «Проектно ориентированные бизнес и общество» — в Москве 4-6 июня 2003 г.
1. ВВЕДЕНИЕ
Успех управления проектом в значительной степени зависит от способностей руководителя проекта лидировать в коллективе проектной команды. PMI PMBOK (PM Body of knowledge) [1] описывает следующие характеристики лидер ства: направление и сплочение подчиненных, их мотивация и вдохновение. Тем не менее, процесс формирования способностей к лидер ству пока не изучен достаточно глубоко. В то же время, очевидна важность разработки знаний и способностей к лидер ству, так как такие качества необходимы для успешного управления крупными проектами и большими коллективами проектных команд. Разработка качеств лидер ства особенно критична в настоящее время, в связи с возрастающими потребностями рынка по реализации больших и комплексных проектов.
2. ПРОБЛЕМА
Как правило, каждый руководитель проекта (РП) выполняет 3 функции:
В зависимости от объема проекта, руководитель проекта уделяет различное время на выполнение каждой из трех функций. Например, руководитель небольшого проекта (команда из 2-3 человек), как правило в основном лично выполняет работы (do), в меньшей степени эагружен управлением работами подчиненных членов команды (manage), и в еще меньшей степени лидирует в коллективе команды (lead).
Руководитель среднего проекта (команда из 10-20 человек), в основном загружен работами по управлению подчиненными членами команды (manage), в меньшей степени лично выполняет работы (do), и в некоторой степени лидирует в коллективе команды (lead). Директор проекта, отвечающий за крупный проект (команда из 30-40 человек и более) обязан в основном лидировать в коллективе команды (lead), в меньшей степени осуществлять текущее руководство подчиненными (manage) и редко выполнять работы лично (do).
Успех процесса формирования лидер ства руководителя проекта зависит от организации процесса изменения приоритетов между тремя функциями руководителя проекта.
3. ИЗМЕНЕНИЕ ПРИОРИТЕТОВ В БАЛАНСЕ ВРЕМЕНИ РУКОВОДИТЕЛЯ ПРОЕКТА
В этом процессе можно отметить 3 события: (1) момент начала преимущественного управления подчиненными, (2) момент зарождения качеств лидер а, (3) момент начала преимущественного лидирования в коллективе проектной команды.
На Рисунке 1 представлен процесс изменения приоритетов в балансе времени руководителя проекта.
Зависимость баланса времени PП от объема проекта
Достижение события (1) является «моментом рождения РП». Начиная с этого момента, РП в основном управляет членами команды и в меньшей степени выполняет работы лично. Достижение события (2) является «моментом рождения потенциального лидер а». В этот момент РП обнаруживает свои потенциальные способности к лидер ству. Эти способности могут быть, а могут и не быть разработаны в дальнейшем.
Достижение события (3) является «моментом рождения лидер а». Начиная с этого момента, РП лидирует в команде проекта и в меньшей степени управляет.
Ключевым является процесс продвижения потенциального лидер а от события (2) к событию (3). Этот процесс является процессом формирования индивидуальных качеств лидер а.
Событие (3) должно произойти до определения РП на роль руководителя крупного проекта. Эта роль предназначена для директора проекта, успешно завершившего процесс формирования лидер ства и способного продемонстрировать высокоэффективные результаты по управлению командами крупных комплексных проектов.
Обе функции Управление и Лидерство возрастают на пути от события (2) к событию (3) и далее к событию (4). Однако, функция Лидерство растет быстрее, чем функция Управление. Благодаря этому факту, лидирующая функция становится эквивалентной функции управления при достижении события (3) и значительно превышает функцию управления при достижении события (4).
4. БАЛАНС ФУНКЦИЙ ЛИДЕРСТВА И УПРАВЛЕНИЯ РУКОВОДИТЕЛЯ ПРОЕКТА
На Рисунке 2 представлена иллюстрация баланса функций лидер ства и управления руководителя проекта. При достижении события (2) РП в основном управляет и в меньшей степени лидирует в команде проекта ( i.e. OE OD )..
5. РЕКОМЕНДАЦИИ ПО УСПЕШНОМУ ФОРМИРОВАНИЮ ЛИДЕРСТВА
|
Таблица 1 Изменение приоритетов между функциями управления и лидер ства РП
Процесс развития РП от потенциального к реальному лидер у проектной команды требует от РП:
Эти качества обеспечивают зарождение и необходимый рост способностей РП к лидер ству с результатом преимущественного лидирования в коллективе проектной команды при достижении события (3). В этот момент РП становится признанным лидер ом проектной команды. Согласно Гарольду Керснеру [2] на этой стадии должны быть продемонстрированы следующие компетенции лидер а: гибкость, инновационное мышление, инициатива и харизма.
Процесс дальнейшего развития качеств лидер а требует от РП:
Эти приоритеты обеспечивают последовательный рост функции лидер ства с результатом
«момента рождения зрелого лидер а» при достижении события (4). На этой стадии РП как зрелый лидер и директор проекта в большей степени делегирует, сосредотачиваясь на достижении стратегических целей крупных комплексных проектов.
6. ЛИТЕРАТУРА
1. Guide to the Project Management Body of Knowledge (PMBOK Guide) 2000 Edition, ISBN 1880410230.
2. Harold Kerzner, Progect Management. A systems Approach to Planning, Scheduling, and Consulting. 6th edition, ISBN 0-471-28835-7, p. 172
Лидирование проектных команд, управление конфликтами интересов и внутренние коммуникации в рамках кросс-функциональных проектов
Самое сложное в осуществлении любого проекта–это не поиск и консолидация ресурсов и даже не хроническая нехватка времени, а формирование атмосферы конструктивного сотрудничества всех членов проектной команды,стейкхолдеров и топ-менеджмента компании.
В этой статье несколько советов, которые помогут добиться взаимопонимания между всеми, вовлеченными в проект, сторонами не превратив, при этом, лидер а проекта в неврастеника.
Как любит поговаривать Франклин Кови – «Put first things first». Сначала должно быть слово. И это слово – не радостное объявление всем сотрудникам, что: «Сегодня мы запускаем трансформационный проект. ». Нельзя прийти в один из солнечных дней в жизни «менеджеров среднего звена», когда ничто не предвещает неприятностей, и радостно сообщить всем, что со следующего месяца ваших троих бухгалтеров заменят на одну компанию, например, которая будет предоставлять вашему бизнесу услуги по расчету заработной платы, ведению складского учета и расчету себестоимости продукции на производстве.
Во-первых – что им с этой информацией делать. Во-вторых, подружка Марь Ивановны (или Викуси) из бухгалтерии тут же ей СМС-нит и ваши благие намерения оптимизировать P&L просто сметет цунами саботажа. И все же, как запустить проект и выстроить продуктивные коммуникации с ключевыми членами вашей команды, стейкхолдерами проекта и руководством?
Инициализация проекта начинается с того, что Вы, как владелец бизнеса или функционер, принимающий решения, должны осознать потребность в запуске того самого проекта. И не суть важно какой именно это проект. Вы должны осознать внутреннюю готовность к изменениям. Осознание – это первый шаг к успешному проекту. Такое решение не приходит по наитию или спонтанно – оно основывается на вашем опыте и знаниях, управленческом чутье, если угодно, но… ВСЕГДА проверяется глубоким анализом бизнес модели и расчетом экономической целесообразности запуска, будь то строительство офиса, внедрение ERP системы или внутренние трансформационные изменения бизнеса. После осознания начинается практическая часть, т.е., по сути, запуск проекта, а его основа – это Устав проекта. Добросовестно, а не формально, подготовленный Устав значительно облегчит его воплощение.
Естественно, очень важно выполнить последовательность всех этапов подготовки и ведения проекта, но в рамках этой статьи, я бы хотел остановится на лидировании и коммуникациях со всеми, вовлеченными в проект, сторонами, особенно если эти стороны находятся в разных отделах и их функционал мало пересекается в обычной жизни.
Я сформировал для себя три принципа, которые действительно помогают проекту «взлететь». Расскажу о них на примере проекта по передаче нескольких вспомогательных бизнес функций в аутсорсинг:
Теперь Вы готовы сделать третий шаг – сформировать ключевую команду, которая станет вашей опорой и главной движущей силой проекта. Эти «адвокаты» изменений помогут Вам:
Методологии управления проектами: водопад, эджайл
В предыдущей части мы разбирались, что такое проект и зачем нужен менеджер проектов. Сегодня углубимся в тему и поговорим о инструментах, которые менеджер использует в работе.
Методологией в управлении проектами называется стандартизация проведения проектов. Под стандартизацией здесь подразумевается описание шагов работы, чеклисты к проверке – эдакая канва, в которую можно закинуть проект, и он под присмотром менеджера приплывет к завершению и готовому продукту. Так как каждый проект в той или иной степени уникален, методология не панацея, думать все-таки придется.
Методологий управления проектами великое множество – они бывают используемыми только в одной компании, бывают глобальными. Методологии бывают в виде инструментов (типа Agile), бывают в виде большой книги с набором этих инструментов (PMBoK, тоже методология).
В жизни я использовал и использую две, самые популярные методологии – Waterfall (“водопад”/“каскадная”) и Agile (и его ответвление – Scrum), о них и пойдет речь. Ради расширения кругозора читателя расскажу и о других известных мне вещах. Если читатель работает с диджитал, то “водопада” и “эджайла” хватит за глаза – можно будет использовать их в работе, жизни, рассказывать знакомым и незнакомым людям, на митапах, с умным видом попивая смузи.
Само собой, ничто ниоткуда не берется, и Петр Первый ничего не слышал про эджайл. Методологии придумываются всякими разными организациями и ассоциациями, где умные дядьки собирают свои проблемы в кучи, затем понимают, как их можно было избежать, и делятся после решениями с такими обывателями как я, например. Иногда продумывание методологий происходит на государственном уровне – там тоже решают проблемы и собирают best practices (в приличном обществе так не выражайся) в книги и руководства.
Речь сегодня пойдет в основном об этих двух зверятах. После прочтения этого раздела можешь смело идти и требовать себе самое классное место менеджера проектов в самой крупной подходящей организации города.
Водопад, каскадная методология – традиционная, самая популярная и логичная методология управления проектами. В чистом виде может сработать совсем в простых проектах. Допустим, тебе потребовалось посадить дерево. “По водопаду” выполнение проекта выглядит так:
Каждый этап в таком проекте идет следом за предыдущим и не может быть выполнен раньше предыдущего – это и есть “водопад”. Еще это пересекается с “методом критического пути”, но о нем расскажу в отдельной статье – напомни мне.
Я работаю с проектами в сфере разработки сайтов и мобильных приложений. Этапы разработки таких проектов по водопаду примерно одинаковы:
Чтобы двигаться по водопаду, нужно иметь четкое техническое задание и понимание шагов, следующих друг за другом. Из практики скажу, что работать по чистому водопаду нереально – обязательно где-то выясняется, что что-то упустили, где-то нужно откатиться на предыдущий этап и делать это параллельно с текущим этапом. Тем не менее, чем четче техническое задание, тем меньше шансов на то, что проект уйдет в сторону. Для проектов, где “уход в сторону” приемлем, есть Agile.
“Эджайл” (или “агиль”, или “а жаль” – много у него прикольных названий) относится к типу гибкой методологии. Главное его отличие от водопада – рабочий продукт на каждом этапе работы и неясный финал проекта. В примере с тем же деревом, где каждый этап последователен, этот эджайл не покатит: ну купил ты саженец, а толку? У эджайла достаточно широкая область применения, однако более всего он прижился в IT. А его виды и подтипы толстой пленкой накрыли прилегающие сферы – бизнес-планирование, продуктовый менеджмент и так далее, и тому подобное.
Для примера работы “по агилю” представим проект посложнее. Пусть это будет проект из строительства. Задача: построить дом, где можно жить.
Этапы производства (представим, что каждый этап занимает ровно спринт):
Пусть в состоянии MVP (минимальный жизнеспособный продукт), но этим домом можно будет пользоваться примерно после первого этапа – не очень комфортно, но можно. Также “по эджайлу” этапы могут не следовать друг за другом, а идти параллельно или в разном порядке. Ключевой момент: на каждом этапе реализации продукта продуктом можно пользоваться.
Чтобы фиксировать этапы, умные дядьки придумали спринты, каждый из которого содержит набор операций и сроки (чаще равные) их реализации и планируются непосредственно перед спринтом. Задачи, прилетающие в процессе спринта складываются в бэклог – корзинку с тем, что при следующем планировании спринта кто-то будет разгребать. Ну и еще одна особенность эджайла: у проекта может не быть технического задания – вот думали вы строить одноэтажный таунхаус, а в процессе решили, что для вас окей построить шестиэтажный особняк и вы вот его строите, гибко меняя планы в процессе производства.
Agile используют в IT (“диджитале”) – лучше всего он живет в стартапах, когда финальный проект не ясен, нужно проверять гипотезы и делать это быстро и гибко. Эджайл удобно использовать в проектах стороннего клиента (не из компании), когда финал проекта не ясен и у клиента тысяча тысяч идей по ходу разработки. В таком случае определяешь, сколько времени команды в неделю можешь выделить, считаешь стоимость этого времени и выставляешь счета в финале каждого спринта.
Если ты работаешь со внешними клиентами, эджайл гораздо удобнее водопада в любых проектах – ты же знаешь, сколько комментариев клиент может выдать на каждом этапе проекта и как сложно объяснить клиенту, что его комментарии превышают заложенное время на разработку, а значит и бюджет проекта. Доплачивать-то он вряд ли будет – есть же смета, и ты вроде как профессионал, должен был сразу понять, что ему вообще нужно. Эджайл работает с понимающими клиентами, остальным будет крайне сложно объяснить, почему это окей.
Еще одна особенность методологии: в ней нет как такового менеджера проекта. Есть владелец продукта, скрам-мастер (в Scrum), члены команды. То есть, менеджер здесь выступает в роли владельца продукта и делает примерно то же самое, что делает при любой другой методологии. Внутри любой проектной команды продакт-оунером выступает менеджер проекта – он заказывает продукт у команды, а не тот человек, который брифует менеджера.
В одно семейство с эджайлом (“гибкие методологии”) входят Scrum, XP и Lean – хипстерские вещи из мира стартапов – читайте интернеты.
Никакая методология не панацея. Ближайшую аналогию могу провести с чеклистами – это такая классная штука (читай статью на моем медиуме @salakhmir), которая люто помогает в работе, но, почему-то, работает не у всех. Любой инструмент – всего лишь инструмент, и сам по себе работать не будет. Представь, что лопату положили на землю и ждут, когда что-то произойдет – так и тут, чтобы что-то сделалось, нужно что-то сделать.
Преимущественно использую гибридную методологию (и водопад, и эджайл), где есть техническое задание, понятны этапы, но случаются отклонения по ходу проекта. Со стороны может казаться, что творится хаос, главное делать лицо с понтом всё идёт по плану. Часто отклонения уходят в отдельные проекта, но чаще остаются внутри текущего и тянут за собой увеличение времени (бюджета) проекта. Кажется, это плохо, но момент политики в работе с людьми (мы же работаем с людьми, а не с сайтами, помнишь?) исключать нельзя.
Эти организации, по большей мере, именно управляют развитием методологий – развивают их такие же менеджеры, каким однажды станешь ты. В мире их не так много, но все они дико важные – за деньги и время можно получить их дипломов и ходить на собеседования, поражая интервьюеров.
Project Management Institute – наш друг. Питаю к этой организации особую привязанность – у них мощная комьюнити и хорошая база. Организация базируется в США, существует с 1969 года, а их стандарты управления проектами признаются ANSI.
Основной продукт PMI – свод знаний по управлению проектами PMBoK, осенью 2017 года вышла шестая часть. Свод знаний содержит канвы выполнения проектами в мелочах – от сбора требований стейкхолдеров до закрытия проекта. Рекомендую хотя бы ознакомиться с книгой – в ней же можно почитать и про ватерфолл с эджайлом, и про метод критического пути и метод быстрого прохода – темы одной из будущих моих статей.
Дополнительно к PMBoK у PMI есть такие основные вещи: стандарты управления портфелями (проектов) и программой, стандарты управления рисками и Scrum Guide. PMBoK – не IT-книга, методики из свода применимы фактически ко всем проектам (для некоторых типов есть отдельные расширения) – маст хэв, в общем.
У PMI куча куч видов сертификаций, со ступенями и наворотами. Сертификаты PMI известны и популярны. Например, PMP – профессионал управления проектами – типа подтверждает, что ты можешь руководить проектами. Получить сертификаты организации не имея опыта нельзя, потому они больше как подтверждение, нежели как этот твой университетский диплом, который ты получил, пока учился учиться.
Международная Ассоциация Управления Проектами – такая же организация, как PMI, только европейская (Швейцария), и о ней меньше слышно. Работает с 1965 года, и изначально называлась Internet (когда интернета в помине не было).
Что они там делают – понятно мало. Ну, сертифицируют менеджеров. Выпускают свои журналы – сами и под представительствами. Зарабатывают деньги. И слава Б-гу.
“Принц” (PRojects IN Controlled Environments). Появилась методология в 1989 году, в Великобритании (и тут отделились). Ключевой особенностью методологии является польза, которую принесут процессы внутри проекта проекту. Минимизация рисков, соблюдение качества проекта. Еще у проектов PRINCE2 сложная организационная структура с комитетом проекта. В остальном, такие проекты, как проекты по другим методологиям, имеют старт, этапы и завершения – все знакомо и привычно.
«A Guidebook of Project and Program Management for Enterprise Innovation». Японская методология управления проектами – на этот раз свежее, она 1999 года. Тентаклями тут является акцент на инновации и управление ожиданиями заинтересованных лиц. Близко не сталкивался, не изучал, оценки дать не могу.
“Частная” методология управления проектами, MSF, была придумана и введена в работу в 1994 году майкрософтом. Она особенна тем, что разрабатывалась непосредственно под разработку программного обеспечения, а не адаптировалась, что можно сказать о том же PMBoK. Внешне похожа на список внутренних рекомендаций (типа как у вас в интре) для менеджеров проектов. В чистом виде не используется даже Microsoft – добавляют тот же эджайл, например. В википедии есть познавательная статья об этом фреймворке, прошу пройти туда – там больше, чем могу рассказать я.
Ничто не панацея, но понимать принципы и брать из них лучшее можно и нужно. Пока писал статью, краем глаза наткнулся на статью о Стаханове – был такой чувак при Советах, его еще в советской пропаганде продуктивности использовали. Он тоже работал по методологии (уголь добывал), но однажды понял, что если чуток переставить людей и пустить некоторые процессы параллельно, можно работать лучше. Вот и заработал себе страницу в википедии. Так и здесь – тестируй, применяй и дорабатывай (потом делись). Все, с чем ты сталкиваешься, все советы – гипотеза, которую нужно проверить. Enjoy it!
В следующей части постараюсь рассказать про планирование задач и времени, включая собственный микроменеджмент. Статья должна помочь не только начинающим менеджерам, но и тем, кто с ними работает. Если хватит запала, то статья будет прям на этой неделе. Пишите письма.