<?xml version='1.0' encoding='UTF-8'?><rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:openSearch="http://a9.com/-/spec/opensearchrss/1.0/" xmlns:blogger="http://schemas.google.com/blogger/2008" xmlns:georss="http://www.georss.org/georss" xmlns:gd="http://schemas.google.com/g/2005" xmlns:thr="http://purl.org/syndication/thread/1.0" version="2.0"><channel><atom:id>tag:blogger.com,1999:blog-8326611694070083907</atom:id><lastBuildDate>Tue, 06 Mar 2018 02:30:02 +0000</lastBuildDate><category>управление проектами</category><category>команда проекта</category><category>управление рисками</category><category>инструменты</category><category>разное</category><category>руководитель проекта</category><category>совещания</category><category>спонсор проекта</category><title>Управление проектами</title><description>Блог об управлении проектами - науке на грани искусства</description><link>http://pr-mn.blogspot.com/</link><managingEditor>noreply@blogger.com (Dmitry)</managingEditor><generator>Blogger</generator><openSearch:totalResults>11</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>25</openSearch:itemsPerPage><item><guid isPermaLink="false">tag:blogger.com,1999:blog-8326611694070083907.post-4490156493905651093</guid><pubDate>Thu, 06 Mar 2008 12:34:00 +0000</pubDate><atom:updated>2009-04-27T04:18:03.881-07:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">совещания</category><category domain="http://www.blogger.com/atom/ns#">управление проектами</category><title>Искусство проводить совещания</title><description>&lt;a href=&quot;http://fdiver.blogspot.com/2007/12/blog-post_03.html&quot;&gt;К каждому очередному совещанию, посвященному ходу выполнения какого-либо проекта необходимо тщательно готовиться&lt;/a&gt;. Кроме обычно рекомендуемой подготовки повестки до начала совещания каждому его участнику необходимо составить так называемый OTR (Open Task Report), т.е. отчет о незавершенной работе.&lt;br /&gt;&lt;br /&gt;В OTR должны быть перечислены все задачи, которые необходимо было выполнить, но которые по разным причинам не были выполнены, а также задачи, запланированные на два следующих отчетных периода. Отчетным периодом обычно принимается промежуток времени между двумя последовательными совещаниями по данному проекту.&lt;br /&gt;&lt;br /&gt;Обычно нужно планировать задачи так, чтобы решение предыдущего совещания выполнялось в течение не более двух отчетных периодов. Т.е. при постановке задачи статус ее выполнения равен 0%. На следующем совещании – 50% или 100%. А на втором совещании задача должна быть выполнена. В противном случае она попадает в OTR члена команды, ответственного за ее выполнение.&lt;br /&gt;&lt;br /&gt;Что дает использование OTR. По моему скромному мнению главные преимущества такого инструмента состоят в следующем:&lt;br /&gt;&lt;br /&gt;1. Облегчается проведение совещания и его подготовка. В повестку дня вносятся все вопросы, решения по которым требуют принятия соответствующих мер.&lt;br /&gt;&lt;br /&gt;2. Исполнители более ответственно относятся к поставленным задачам. Регулярная отчетность вынуждает их более серьезно готовится к совещаниям и стараться не оставлять за собой открытых вопросов.&lt;br /&gt;_____&lt;br /&gt;&lt;br /&gt;&lt;a href=&quot;http://solareview.blogspot.com/2008/03/google.html&quot;&gt;&lt;span style=&quot;font-size:85%;&quot;&gt;На что готова потратится компания Google?&lt;/span&gt;&lt;/a&gt;</description><link>http://pr-mn.blogspot.com/2008/03/blog-post_06.html</link><author>noreply@blogger.com (Dmitry)</author><thr:total>5</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-8326611694070083907.post-5327567089300709803</guid><pubDate>Tue, 04 Mar 2008 09:58:00 +0000</pubDate><atom:updated>2008-03-04T02:01:08.203-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">управление проектами</category><title>Консенсус</title><description>В моем &lt;a href=&quot;http://fdiver.blogspot.com/&quot;&gt;основном блоге&lt;/a&gt; уже был опубликован пост о &lt;a href=&quot;http://fdiver.blogspot.com/2008/02/blog-post_16.html&quot;&gt;способах принимать решения&lt;/a&gt;. И на первом месте стоял так называемый метод консенсуса. Тема эта, безусловно, важная для каждого более-менее рвущегося к совершенству руководителя, да и простому смертному тоже будет неплохо знать как его «руководят» другие. Поэтом сегодня остановимся более подробно на основных рекомендациях по достижению этого самого консенсуса.&lt;br /&gt;&lt;br /&gt;Почему именно консенсус? Просто именно этот метод нередко позволяет прийти к оптимальным решениям. Ведь при выработке решения в этом случае используются знания, опыт и квалификация каждого из членов команды. Нужно только четко понимать, что консенсус – это не единодушие, когда все согласны с правильностью принятого решения. Скорее консенсус достигнут, если все согласны, что принятие решения было честным и справедливым, все точки зрения были выслушаны и поняты, а каждый член команды – может помочь практической реализации принятого решения.&lt;br /&gt;&lt;br /&gt;Для выработки консенсуса и принятия максимального эффективного решения руководителю следует придерживаться следующих 5 рекомендаций:&lt;br /&gt;&lt;br /&gt;1. Процесс принятия решения проблемы должен быть структурирован. Четкое уяснение рассматриваемой проблемы – это начало обсуждения. Дальнейшее обсуждение тоже должно придерживаться четкой структуры для сосредоточивания внимания участников на каждом этапе принятия решения.&lt;br /&gt;&lt;br /&gt;2. Регулируйте участие команды в выработке решения. Побуждайте людей использовать приемы &lt;a href=&quot;http://fdiver.blogspot.com/2008/02/blog-post_12.html&quot;&gt;активного выслушивания&lt;/a&gt;. Нельзя разрешать наиболее активным доминировать в ходе обсуждения, а скромным – оставаться в тени. На каждом этапе процесса решения проблемы должен быть услышан голос каждого из участников.&lt;br /&gt;&lt;br /&gt;3. Относитесь к конфликту как к признаку творческого мышления. Избегание конфликта путем изменения своих позиций – не лучший путь к оптимальному решению Руководителю нужно выявить и тщательно проанализировать различные мнения.&lt;br /&gt;&lt;br /&gt;4. Сформируйте консенсус. Выбирайте варианты, которые удовлетворяют целям всех участников обсуждения и объедините, если возможно, разные точки зрения.&lt;br /&gt;&lt;br /&gt;5. Подготовьте запасной аэродром. Вы должны знать как именно вы придете к окончательному решению. Заранее определите другой метод принятия решения на случай, если обсуждение зайдет в тупик.&lt;br /&gt;&lt;br /&gt;Ключ к принятию консенсусного решения – сбалансированное участие каждого и выработка решения, реализацию которого будет поддерживать каждый член команды. Для оценки возможного предлагаемого решения специалисты прелагают использовать шкалу 5L: loathe – вы категорически отвергаете решение; lament – вы будете выражать недовольство решением после совещания; live – вы смиритесь с принятым решением; like – вас устраивает это решение; love – вы в восторге от него.&lt;br /&gt;&lt;br /&gt;Консенсус не обходимо принимать, только если нет людей, которые оценили предлагаемое решение первыми двумя «L».&lt;br /&gt;&lt;br /&gt;&lt;span style=&quot;font-size:78%;color:#666666;&quot;&gt;&lt;em&gt;Спонсор поста - &lt;/em&gt;&lt;/span&gt;&lt;a href=&quot;http://solareview.blogspot.com/&quot;&gt;&lt;span style=&quot;font-size:78%;color:#666666;&quot;&gt;&lt;em&gt;Блог об альтернативных источниках энергии, новых технологиях, тенденциях и перспективах&lt;/em&gt;&lt;/span&gt;&lt;/a&gt;</description><link>http://pr-mn.blogspot.com/2008/03/blog-post.html</link><author>noreply@blogger.com (Dmitry)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-8326611694070083907.post-8065353921631823713</guid><pubDate>Fri, 22 Feb 2008 14:17:00 +0000</pubDate><atom:updated>2009-04-27T04:17:46.211-07:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">управление проектами</category><title>Принятие решений</title><description>&lt;p&gt;Любой проект немыслим без необходимости принимать сотни и тысячи различных решений. Оказывается, есть несколько способов сделать это:&lt;/p&gt;&lt;p&gt;1. Консенсус. В этом случае все члены команды принимают участие в уяснении проблемы, выработке вариантов ее решения и выборе окончательного решения. Такие решения обычно гораздо качественнее решений, принимаемых другими способами, но само принятие решения консенсусом может занимать немало времени, особенно если у членов команды отсутствуют необходимые в таком случае знания и квалификация. Кроме того, если численность группы превышает 15 человек, то принятие решения консенсусом также становиться весьма проблематичным. &lt;/p&gt;&lt;p&gt;2. Голосование. Очень демократичный метод, отличающийся высокой оперативностью принятия решений. При этом участие может принять весьма большое количество людей. Однако, чем сложнее предлагаемые варианты решения проблемы и чем больше этих вариантов, тем сложнее принимать их голосованием. Кроме того, члены команды, оказавшиеся в меньшинстве, будут проявлять мало заинтересованности в выполнении данного решения. &lt;/p&gt;&lt;p&gt;3. Делегирование полномочий. Решение принимается наиболее проинформированными и квалифицированными в данном вопросе членами команды. Принятие решения упрощается, т.к. в нем участвует меньшее количество людей, но они должны пользоваться безусловным доверием со стороны команды. &lt;/p&gt;&lt;p&gt;4. Автократический метод. Требуемое решение принимает руководитель. Решение одним человеком принимается быстрее, чем в случае коллективного обсуждения. Руководитель обычно значительно лучше проинформирован и несет высокую ответственность за свои действия, что дает ему право на самостоятельное принятие решений. В тоже время, поспешное, недостаточно обоснованное решение может повлечь за собой катастрофические последствия. Постоянное использование данного метода может резко снизить доверие команды к руководителю, и ее заинтересованность в выполнении решений снижается. Автократические решения принимаются в тех случаях, когда решение должно быть принято обязательно, но коллектив не располагает достаточной информацией для принятия решения по методу консенсуса. &lt;/p&gt;&lt;p&gt;&lt;span style=&quot;font-size:85%;&quot;&gt;_____&lt;/span&gt;&lt;/p&gt;&lt;p&gt;&lt;span style=&quot;font-size:85%;&quot;&gt;Больше информации по управлению проектами - в блоге &lt;/span&gt;&lt;a href=&quot;http://fdiver.blogspot.com/&quot;&gt;&lt;span style=&quot;font-size:85%;&quot;&gt;Наемного менеджера&lt;/span&gt;&lt;/a&gt;&lt;/p&gt;</description><link>http://pr-mn.blogspot.com/2008/02/blog-post_22.html</link><author>noreply@blogger.com (Dmitry)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-8326611694070083907.post-2853823967897700492</guid><pubDate>Mon, 18 Feb 2008 17:34:00 +0000</pubDate><atom:updated>2009-04-27T04:19:16.155-07:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">управление проектами</category><category domain="http://www.blogger.com/atom/ns#">управление рисками</category><title>Cтратегии реагирования на риск</title><description>&lt;p&gt;&lt;span style=&quot;font-size:78%;color:#666666;&quot;&gt;&lt;em&gt;По материалам блога &lt;/em&gt;&lt;/span&gt;&lt;a href=&quot;http://fdiver.blogspot.com/&quot;&gt;&lt;span style=&quot;font-size:78%;color:#666666;&quot;&gt;&lt;em&gt;Записки наемного менеджера&lt;/em&gt;&lt;/span&gt;&lt;/a&gt;&lt;/p&gt;&lt;p&gt;1. &lt;strong&gt;Принятие риска&lt;/strong&gt;. Данная стратегия возможна, когда последствия или вероятность возникновения проблемы оцениваются как минимальные. Риск известен, последствия понимаются всеми участниками проекта, но никакие меры не принимаются до момента, когда данный риск все-таки материализуется. После этого команда принимает соответствующие меры.&lt;/p&gt;&lt;p&gt;2. &lt;strong&gt;Избежание риска&lt;/strong&gt;. Возможно путем невыполнения определенной части проекта. Но сокращение масштаба проекта может изменить и возможные доходы от реализации проекта. Попытка избежать риска при выполнении проектов может привести к его низкой прибыльности: высокая прибыли требует больших рисков. &lt;/p&gt;&lt;p&gt;3. &lt;strong&gt;Отслеживание риска&lt;/strong&gt;. В ходе выполнения проекта могут быть выбраны те или иные прогнозные индикаторы для наблюдения за приближением к точке неприемлемого риска. При выборе этой стратегии необходимо учесть такие факторы как возможность обнаружения риска и наличие триггеров, т.е. индикаторов событий риска. Подробнее об индикаторах риска &lt;a href=&quot;http://fdiver.blogspot.com/2008/01/blog-post_21.html&quot;&gt;смотрите здесь&lt;/a&gt;. &lt;/p&gt;&lt;p&gt;4. &lt;strong&gt;Перекладывание риска&lt;/strong&gt;. Приобретение страхового полиса, разделение ответственности с подрядчиком, работа по договорам с фиксированной ценой и многие другие методы являются примером стратегии перехода рисков. перекладывание рисков на кого-то другого имеет определенные преимущества, но может навлечь новые риски, такие как перерасход средств, несоблюдение графика проекта и т.п. &lt;/p&gt;&lt;p&gt;5. &lt;strong&gt;Ослабление риска&lt;/strong&gt;. Представляет собой «упорную работу команды проекта по снижению риска». Ослабление охватывает практически весь круг мер, которые проектная команда может принимать для преодоления рисков.&lt;/p&gt;</description><link>http://pr-mn.blogspot.com/2008/02/c.html</link><author>noreply@blogger.com (Dmitry)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-8326611694070083907.post-3571940489669229740</guid><pubDate>Sun, 10 Feb 2008 12:04:00 +0000</pubDate><atom:updated>2008-02-10T04:05:57.133-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">команда проекта</category><category domain="http://www.blogger.com/atom/ns#">управление проектами</category><title>Этапы формирования коллектива</title><description>&lt;p&gt;&lt;a href=&quot;http://fdiver.blogspot.com/2008/02/blog-post_06.html&quot;&gt;&lt;em&gt;&lt;span style=&quot;font-size:85%;color:#666666;&quot;&gt;Источник&lt;/span&gt;&lt;/em&gt;&lt;/a&gt;&lt;/p&gt;&lt;p&gt;Каждый раз любой коллектив проходит через одни и те же этапы:&lt;/p&gt;&lt;p&gt;1. Образование команды. На этом этапе члены новой команды испытывают достаточно противоречивые чувства: от радости за то, что они оказались в числе «избранных», до опасений оказаться «лишним» и не вписаться в коллектив. Руководителю, лидеру команды необходимо четко изложить структуру и общее направление деятельности команды. Очень важно дать участникам проекта всю ту минимально необходимую информацию, которая поможет им сориентироваться, найти свое место, понять цели и правила их достижения. &lt;/p&gt;&lt;p&gt;2. Первые трения. Начало работы неизбежно приводит к высокой вероятности возникновения как конфликтов между участниками, так и внутренних конфликтов. Не видя всего объема работы, которая может оказаться новой для них, люди испытывают беспокойство и тревогу. Некоторые даже могут захотеть покинуть команду. Однако эти и другие «элементы хаоса» заставляют команду притираться и начинать принимать совместные решения. Руководитель должен направлять этот процесс в правильном направлении, активно участвуя в принятии коллективных решений, демонстрируя готовность выслушать и прислушаться к мнению каждого члена команды. &lt;/p&gt;&lt;p&gt;3. Нормализация. Члены команды начинают доверять друг другу и коллективу в целом, помогать друг другу в достижении общих целей и избегать конфликтов. Это самое время для руководителя команды доверить часть своих властных полномочий самому коллективу. &lt;/p&gt;&lt;p&gt;4. Выход на максимальную производительность. Не всем командам удается дойти до этого этапа, но те, кто вышли – показывают свою максимальную производительность, сравнительно быстро и безболезненно преодолевают любые препятствия и осуществляют необходимые изменения. На этом этапе лидер может сосредоточиться на устранении препятствий и совершенствовании коллективных процессов. Значительная часть полномочий передается появившимся в команде неформальным лидерам. &lt;/p&gt;&lt;p&gt;5. Расставание. Проект завершен, и команда должна быть расформирована. Самое время подвести итоги и проанализировать полученные результаты. Необходимо отметить успехи каждого члена команды и показать им возможности для дальнейшего совершенствования знаний и умений. &lt;/p&gt;</description><link>http://pr-mn.blogspot.com/2008/02/blog-post_10.html</link><author>noreply@blogger.com (Dmitry)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-8326611694070083907.post-126030634914709981</guid><pubDate>Tue, 05 Feb 2008 11:12:00 +0000</pubDate><atom:updated>2008-02-02T03:45:31.555-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">управление проектами</category><category domain="http://www.blogger.com/atom/ns#">управление рисками</category><title>Управление рисками</title><description>&lt;p&gt;По большому счету, управление проектами – это, по сути, управление рисками. Рассмотрим кратко его основные этапы:&lt;/p&gt;&lt;p&gt;&lt;strong&gt;Первый этап - выявление рисков&lt;/strong&gt;. Выявление потенциальных рисков требует незаурядного мастерства и, опыта и превосходного знания методов управления проектами. Существует четыре основных метода выявления рисков: опрос всех участников (сессии «мозгового штурма», интервьюирование и т.п.); составления перечня всех возможных рисков (профиля рисков); изучение опыта выполнения подобных проектов в прошлом; и, наконец, сосредоточение внимания на рисках, связанных с расписание и бюджетов проекта.&lt;/p&gt;&lt;p&gt;&lt;strong&gt;Второй этап - разработка стратегии планирования&lt;/strong&gt;. Необходимо четко понимать разницу между серьезными и малозначительными рисками. Необходимо оценить степень риска и разработать подходящую стратегию реагирования на этот риск. Такая стратегия обычно включает в себя три составляющие: определение риска и серьезности его отрицательных последствий; присвоение риску определенной вероятности наступления; разработка плана сокращения возможного ущерба, основанного на серьезности и вероятности данного риска. Существует пять классических стратегий реагирования на риск: принятие риска, избежание риска, отслеживание риска, перекладывание риска и ослабление риска.&lt;/p&gt;&lt;p&gt;&lt;strong&gt;Третий этап – фонд средств на непредвиденные расходы и резервный фонд&lt;/strong&gt;. Создание таких фондов основано на планировании бюджета на случай возникновения непредвиденных ситуаций. Необходимо предусмотреть средства на компенсацию известных рисков, а также и для неизвестных рисков.&lt;/p&gt;&lt;p&gt;&lt;strong&gt;Четвертый этап – непрерывное управление рисками&lt;/strong&gt;. Включает в себя регулярное отслеживание рисков, выявление новых рисков и корректировку планов реагирования на риск. Непрерывное управление риском, по сути, представляет собой повторение основных процессов управления рисками на протяжении всего времени выполнения проекта.&lt;/p&gt;&lt;p&gt;____&lt;/p&gt;&lt;p&gt;&lt;span style=&quot;font-size:85%;&quot;&gt;Партнер блога - &lt;/span&gt;&lt;a href=&quot;http://fdiver.blogpot.com/&quot;&gt;&lt;span style=&quot;font-size:85%;&quot;&gt;блог об успехе жизни и личном развитии&lt;/span&gt;&lt;/a&gt;&lt;/p&gt;</description><link>http://pr-mn.blogspot.com/2008/02/blog-post_5914.html</link><author>noreply@blogger.com (Dmitry)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-8326611694070083907.post-3621055289656572094</guid><pubDate>Sun, 03 Feb 2008 10:49:00 +0000</pubDate><atom:updated>2008-02-02T03:45:04.098-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">команда проекта</category><category domain="http://www.blogger.com/atom/ns#">спонсор проекта</category><category domain="http://www.blogger.com/atom/ns#">управление проектами</category><title>Спонсор проекта</title><description>&lt;p&gt;Обсудим такую весомую фигуру как спонсор проекта.&lt;/p&gt;&lt;p&gt;Отмечу сразу, этот важный человек никакого отношения к вопросу денег не имеет. И о нем не всегда можно прочесть в некоторых популярных руководствах по проектному менеджменту. Спонсорство в данном случае означает поддержку проекта формальными властными полномочиями. Т.е. спонсор – это человек, принадлежащий к кругу высших менеджеров компании, выступающий связующим звеном между проектом и обычным порядком принятия решений в компании, а также оказывающий всестороннюю помощь проектной команде, не являясь ее участником. &lt;/p&gt;&lt;p&gt;Именно спонсор в конечном итоге несет ответственность за успех проекта, но при этом он оказывает опеку не проекту, а скорее руководителю проекта и всей команде. Его задача – помочь этим людям, не всегда наделенным необходимой полнотой власти, добиться успеха в своем деле.&lt;/p&gt;&lt;p&gt;Кроме помощи в составлении основополагающих документов проекта (таких как устав, &lt;a href=&quot;http://fdiver.blogspot.com/2008/01/blog-post_13.html&quot;&gt;матрица ответственности&lt;/a&gt;, содержание работы и плана проекта), спонсор может выполнять следующие функции: давать рекомендации руководителю проекта, выступать его оппонентом в обсуждениях текущего состояния проекта, отслеживать и поддерживать приоритетность проекта, помогать преодолевать организационные препятствия. &lt;/p&gt;&lt;p&gt;Авторитетный и активный спонсор выступает защитником, поборником проекта, продвигает и отстаивает его. Наличие такого спонсора является огромной поддержкой для любого руководителя проекта и источником формальной власти.&lt;/p&gt;&lt;p&gt;Таким образом, спонсора можно рассматривать в роли наставника, старшего товарища и даже коуча, в конце концов. Наличие спонсора не является новомодной тенденцией, а необходимым фактором успеха вашего проекта.&lt;/p&gt;&lt;p&gt;Подробнее &lt;a href=&quot;http://fdiver.blogspot.com/2008/01/blog-post_11.html&quot;&gt;здесь...&lt;/a&gt;&lt;/p&gt;</description><link>http://pr-mn.blogspot.com/2008/02/blog-post_3165.html</link><author>noreply@blogger.com (Dmitry)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-8326611694070083907.post-3489108827134631316</guid><pubDate>Sat, 02 Feb 2008 11:05:00 +0000</pubDate><atom:updated>2008-02-02T03:44:18.074-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">инструменты</category><category domain="http://www.blogger.com/atom/ns#">управление проектами</category><title>Матрица ответственности</title><description>&lt;p&gt;В рамках проекта у его руководителя обычно не бывает ни времени, ни полномочий разработать формальную систему должностных обязанностей всех участников. Проект всегда имеет временное ограничение, и времени на написание положений о подразделениях и должностных инструкций нет. В этом случае одним из наиболее эффективных и оперативных решений является &lt;em&gt;матрица ответственности&lt;/em&gt;, т.е. документ, поясняющий роли и властные полномочия каждой из сторон, заинтересованных в выполнении проекта.&lt;/p&gt;&lt;p&gt;Матрица ответственности представляет собой очень компактную таблицу, помещающуюся на одной странице. В шапке этой таблицы перечисляются все непосредственные и косвенные участники проекта. Для простоты некоторые из них объединяются в группы. В левой колонке перечисляются все основные работы, задачи, направления деятельности и сферы ответственности участников данного проекта.&lt;/p&gt;&lt;p&gt;После этого остается продумать и письменно закрепить роль каждого участника или группы лиц: О – ответственный исполнитель, С – согласовывает решение, И – должен информироваться, К – должен оказывать консультационные услуги, У – право окончательного утверждения. Конечно, могут быть и другие роли, которые определяются содержанием конкретного проекта, но суть матрицы ответственности остается прежней. &lt;/p&gt;&lt;p&gt;_____&lt;/p&gt;&lt;p&gt;&lt;a href=&quot;http://fdiver.blogspot.com/2008/01/blog-post_13.html&quot;&gt;&lt;span style=&quot;font-size:85%;&quot;&gt;Подробнее про инструменты управления проектом&lt;/span&gt;&lt;/a&gt;&lt;/p&gt;</description><link>http://pr-mn.blogspot.com/2008/02/blog-post_2073.html</link><author>noreply@blogger.com (Dmitry)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-8326611694070083907.post-5947811535772618006</guid><pubDate>Sat, 02 Feb 2008 10:47:00 +0000</pubDate><atom:updated>2008-02-02T03:08:00.382-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">руководитель проекта</category><category domain="http://www.blogger.com/atom/ns#">управление проектами</category><title>Функции руководителя проекта</title><description>&lt;p&gt;Любой проект имеет свои жизненные стадии, которые включают в себя определение проекта, планирование, выполнение и завершение. Но, как и среди двух солдат, идущих в баню, один должен быть командиром, так и у проекта всегда должен быть руководитель&lt;a href=&quot;http://www.artlebedev.ru/&quot;&gt;.&lt;/a&gt; О функциях руководителя проекта мы и поговорим.&lt;/p&gt;&lt;p&gt;Рассматривая стадии проекта, специалисты обычно выделяют три основные функции управления проектами:&lt;/p&gt;&lt;p&gt;&lt;strong&gt;1. Определение проекта.&lt;/strong&gt; Эта функция руководителя предполагает определение целей и базовых механизмов управления проектом. Также определяется команда проекта и строится иерархия отношений в ней. Самым оптимальным является письменное закрепление всех договоренностей в документе, условно называемом правила проекта.&lt;/p&gt;&lt;p&gt;&lt;strong&gt;2. Планирование проекта.&lt;/strong&gt; Эта функция предполагает организацию руководителем работ по составлению календарных и финансовых планов, планов управления рисками. Именно здесь закладывается тело проекта, которое необходимо будет выполнить в будущем.&lt;/p&gt;&lt;p&gt;&lt;strong&gt;3. Управление проектом.&lt;/strong&gt; Собственно эта функция обычно и занимает большую часть времени, отведенного на проект. Руководитель оценивает прогресс – ход выполнения проекта, обеспечивает координацию действий всех участников проекта путем установления эффективных схем коммуникаций, информирует команду о ходе выполнения проекта и изменениях в нем. Также он организовывает корректирующие действия – текущие реакции на препятствия или проблемы, которые возникают в ходе выполнения любого проекта.&lt;/p&gt;&lt;p&gt;Хотя проект и имеет свои жизненные стадии, но функции руководителя проекта не ограничены только рамками конкретной стадии. Ведь любое планирование влечет за собой корректировку определения проекта, а управление требует постоянного внесения изменений в план и даже – в определение проекта.&lt;/p&gt;&lt;p&gt;_____&lt;/p&gt;&lt;p&gt;&lt;span style=&quot;font-size:85%;&quot;&gt;Больше об управлении проектами и менеджменте в целом читайте &lt;/span&gt;&lt;a href=&quot;http://fdiver.blogspot.com/&quot;&gt;&lt;span style=&quot;font-size:85%;&quot;&gt;здесь&lt;/span&gt;&lt;/a&gt;&lt;span style=&quot;font-size:85%;&quot;&gt;.&lt;/span&gt;&lt;/p&gt;</description><link>http://pr-mn.blogspot.com/2008/02/blog-post_02.html</link><author>noreply@blogger.com (Dmitry)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-8326611694070083907.post-2848994202393681327</guid><pubDate>Fri, 01 Feb 2008 10:28:00 +0000</pubDate><atom:updated>2008-02-02T03:44:48.729-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">управление проектами</category><title>Факторы успеха проекта</title><description>&lt;p&gt;Что нужно для успеха любого проекта? Специалисты выделяют 5 основных факторов:&lt;/p&gt;&lt;p&gt;&lt;strong&gt;1. Четкие цели проекта.&lt;/strong&gt; Помните, проект без четкой цели обречен на неудачу. Конечно, любой проект начинается, чтобы достичь какой-либо цели. Но при этом, зачастую, цели проекта бывают изначально размытыми, и команде очень сложно сориентироваться в направлении куда она движется. Чем четче цель, тем легче всем участникам выбрать правильное направление и тем выше вероятность успеха всего проекта в целом.&lt;/p&gt;&lt;p&gt;&lt;strong&gt;2. План проекта. &lt;/strong&gt;В нем должны быть отражены этапы реализации всего проекта, четкие обязанности всех участников проекта и критерии оценки их деятельности. Также план проекта используется для оценки хода его выполнения. Без плана трудно достичь поставленных целей. Планы могут быть различной степени детализации от мысленного плана мелкого проекта типа воскресного похода в магазин вплоть до подробного учета самых мелких задач и мероприятий сложных проектов с сотнями участников.&lt;/p&gt;&lt;p&gt;&lt;strong&gt;3. Общение между участниками проекта. &lt;/strong&gt;Эффективное взаимодействие участников определяет успешность реализации проекта. Именно люди являются движущей силой любого начинания, и именно они должны четко понимать цели проекта, знать свой сектор ответственности и достигать оптимального решения поставленных задач. Именно людям приходится принимать множество решения в случае отклонения хода проекта от запланированного. А эффективное принятие решений не возможно без эффективного общения.&lt;/p&gt;&lt;p&gt;&lt;strong&gt;4. Контроль за содержанием проекта. &lt;/strong&gt;Все участники проекта должны достичь согласия относительно содержания проекта, как в начальной стадии, так и при внесении любых изменений его содержания. Еще раз повторю, что именно люди – движущая сила проекта и именно они должны четко понимать содержание проекта, отслеживать все его изменения и обеспечивать достижение целей. Команда должна в любой момент четко понимать содержание проекта, как бы оно не изменялось с начального момента.&lt;/p&gt;&lt;p&gt;&lt;strong&gt;5. Поддержка со стороны высшего руководства. &lt;/strong&gt;Наделение исполнителей соответствующими полномочиями приблизит проект к успеху. Ведь не всегда лидер проекта и его команда получают всю полноту власти по всем вопросам, необходимым для успешного завершения проекта. Но именно они всегда могут привлечь любые ресурсы, которыми располагает высшее руководство компании в случае возникновения такой необходимости. Правильное взаимодействие с высшим руководством, непосредственно не вовлеченным в проект, всегда является весомым плюсом для любого руководителя проекта и важным моментом для успешного завершения проекта.&lt;/p&gt;&lt;p&gt;_____&lt;/p&gt;&lt;p&gt;&lt;span style=&quot;font-size:85%;&quot;&gt;Более подробно на ту же тему читайте &lt;/span&gt;&lt;a href=&quot;http://fdiver.blogspot.com/&quot;&gt;&lt;span style=&quot;font-size:85%;&quot;&gt;здесь&lt;/span&gt;&lt;/a&gt;&lt;span style=&quot;font-size:85%;&quot;&gt;.&lt;/span&gt;&lt;/p&gt;</description><link>http://pr-mn.blogspot.com/2008/02/blog-post.html</link><author>noreply@blogger.com (Dmitry)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-8326611694070083907.post-8325394862454879880</guid><pubDate>Fri, 25 Jan 2008 11:51:00 +0000</pubDate><atom:updated>2008-02-02T03:54:06.461-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">разное</category><category domain="http://www.blogger.com/atom/ns#">управление проектами</category><title>Вступительно слово</title><description>Данный блог открыт как площадка для сбора в одном месте всех моих публикаций по теме управления проектами. Здесь будут выкладываться избранные посты с других блогов, в том числе и с &lt;a href=&quot;http://fdiver.blogspot.com/&quot;&gt;этого блога&lt;/a&gt;.</description><link>http://pr-mn.blogspot.com/2008/01/blog-post.html</link><author>noreply@blogger.com (Dmitry)</author><thr:total>0</thr:total></item></channel></rss>