Действия по укреплению команды

Действия по укреплению команды могут варьироваться от пятиминутного пункта в повестке дня совещания по оценке текущего состояния до специальных тренингов с участием профессионалов с целью улучшения межличностных отношений среди членов команды. Цель выполнения действий по укреплению команды – помочь отдельным ее членам эффективно работать друг с другом. Стратегии укрепления команды особенно ценны, когда члены команды расположены далеко друг от друга и не имеют возможности личного общения. Неформальное общение и соответствующие мероприятия могут помочь укрепить чувство доверия и установить хорошие рабочие взаимоотношения.
Одним из наиболее важных навыков при развитии среды команды является умение рассматривать проблемы команды проекта и обсуждать их как командные проблемы. Необходимо стимулировать всю команду для совместного разрешения данных проблем. Для формирования эффективных команд проектов менеджеры проектов должны заручиться поддержкой высшего руководства и приверженностью членов команд, назначать соответствующие поощрения и вознаграждения, формировать своеобразие команды, эффективно улаживать конфликты, укреплять доверие и создавать условия для открытого общения между членами команды и, кроме того, осуществлять адекватное руководство командой.
Укрепление команды, как постоянный процесс, является критически важным для успеха проекта. Хотя укрепление команды особенно принципиально в начале проекта, данный процесс никогда не заканчивается. Изменения в окружающей среде проекта неизбежны, и для эффективного управления ими должны прилагаться постоянные или периодические усилия по укреплению команды. Менеджер проекта должен постоянно контролировать действия членов команды и их производительность, чтобы определять, требуются ли какие-либо действия для предотвращения или устранения различных проблем команды.
Одна из теорий утверждает, что существует пять стадий развития, через которые могут проходить команды. Обычно эти стадии наступают по порядку. Однако нередко команда может «застрять» на определенной стадии или вернуться на более раннюю. Кроме того, в проектах, члены команд которых работали раньше вместе, определенные стадии могут быть пропущены.

• Формирование. На данной стадии команда собирается вместе и узнает о проекте и о своих формальных ролях и ответственности в нем. Члены команды на данной фазе, как правило, независимы друг от друга и не особенно открыты. Для получения подробной информации см. Tuckman ladder of team development.
• Шторм. В течение данной стадии команда начинает изучать работы по проекту, технические решения и подход к управлению проектом. Если члены команды не настроены на сотрудничество и не открыты различным идеям и перспективам, обстановка может стать деструктивной.
• Урегулирование. На стадии урегулирования члены команды начинают работать вместе и подстраивают свои рабочие привычки и модели поведения так, чтобы содействовать командной работе. Члены команды начинают доверять друг другу.
• Результативность. Команды, достигшие стадии результативности, функционируют как хорошо организованное подразделение. Они независимы и спокойно и эффективно решают проблемы.
• Завершение. На этой стадии команда завершает работу и переходит к следующему проекту.

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

6.4 Estimate Activity Durations

11/01/2020 by tvolodi

The process of estimating the number of work periods needed to complete individual activities with estimated resources.

The key benefit – it provides the amount of time each activity will take to complete.

Frequency: throughout the project.

Process name/ Enterprise Process Asset Group	Input	Process	Output	Process name/ Enterprise Process Asset Group
Project Management Plan	Schedule management plan	6.4 Estimate Activity Durations	Duration Estimates	Project Documents
	Scope baseline		Basis of estimates
Project Documents	Activity attributes		Activity attributes	Project document updates
	Activity list		Assumption log
	Assumption Log		Lesson learned register
	Lesson learned register
	Milestone list
	Project team assignments
	Resource breakdown structure
	Resource calendars
	Resource requirements
	Risk register
Enterprise environmental factors
Organizational process assets

Estimation of the amount of work effort + available resource (quantity and quality) estimation + project calendars + resource calendars -> approximate number of work periods (activity duration) .

Factors for consideration:

• Law of diminishing returns. Effect of using the next unit of resource is lesser than using the previous unit.
• Number of resources. Increasing the number of one resource not always reduce usage of others including time. Increased number of people leads to increased communications which lead to increased time to execute job.
• Advances in technology.
• Motivation of staff.
  • Student Syndrome – start to work before deadline;
  • Parkinson’s Law – work expands to fill the all available time.

6.4.1 Inputs

6.4.1.1 Project Management Plan

Used components:

• Schedule management plan. The used method and accuracy level, other criteria to estimate durations.
• Scope baseline. Used: WBS dictionary (technical details).

6.4.1.2 Project Documents

To consider:

• Activity attributes. Predecessor-successor relationships, lead and lags, logical relationships.
• Activity list. Contains all schedule activities for the project.
• Assumption log. Assumptions + constraints.
• Lesson learned register.
• Milestone list.
• Project team assignments.
• Resource breakdown structure. A hierarchical structure of the identified resources by category and type.
• Resource calendars. Availability of specific resource, resources with specific attributes.
• Resource requirements. Performance level, skill level, …
• Risk register.

6.4.1.3 Enterprise Environment Factors

Include:

• Duration estimating databases, other reference data,
• Productivity metrics,
• Published commercial information,
• Location of team member.

6.4.1.4 Organizational Process Assets

Include:

• Historical duration information,
• Project calendars,
• Estimating policies,
• Scheduling methodology,
• Lesson learned repository.

6.4.2 Tools and Techniques

6.4.2.1 Expert Judgement

By individuals or groups by topics:

• Schedule development, management and control;
• Expertise in estimating;
• Discipline or application knowledge.

6.4.2.2 Analogous Estimating

A technique for estimating the duration the duration or cost of an activity or a project using historical data from a similar activity or project. The activities / project should be analogous. For the duration it is taken actual duration. The method is frequently used when there is limited information about the project.

Less costly but less accurate.

6.4.2.3 Parametric Estimating

An algorithm is used to calculate cost or duration based on historical data and project parameters. A statistical relationship between historical data and other variables.

6.4.2.4 Three-Point Estimating

Defines an approximate range for an activity duration:

• Most likely (tM). The estimate for the most likely variant of resource number, quality, availability and so on.
• Optimistic (tO). Best-case scenario.
• Pessimistic (tP). The worst-case scenario.
• Expected (tE). tE = (tO+tM+tP)/3. Used when there is insufficient historical data or when using expert judgmental data.

6.4.2.5 Bottom-up Estimating

Estimating by aggregating the estimates of the lower-level components of the WBS.

The activity is decomposed to the needed level of detail to get a confident detail estimations.

6.4.2.6 Data Analysis

• Alternatives Analysis. Used to compare:
  • Various levels of resource capability or skills;
  • Scheduling compression techniques;
  • Different tools;
  • Decisions on make/rent/buy resources.
• Reserve analysis. Used to determine the amount of contingency and management reserves needed for the project. Duration estimates may include contingency reserve (schedule reserves) for schedule uncertainty for the identified risks that are accepted. The contingency reserve may be a percentage or a fixed number of work periods. They may be aggregated. With more precise information on the project the reserve may be used, reduced, or eliminated. The reserves should be clearly documented.
  • Management reserve is allocated for management control purposes -> unforeseen work that is within the scope of project. not included into the schedule baseline, but it is part of the overall project duration requirements. Use of the reserve may require a change to the schedule baseline.

6.4.2.7 Decision Making

Voting.

6.4.2.8 Meeting

6.4.3 Outputs

6.4.3.1 Duration Estimates

Quantitative assessment of the likely number of time periods that required to complete an activity, a phase, or a project. They do not include any lags. They may include the range of possible results.

6.4.3.2 Basis of Estimates

How the estimates were derived. May include:

• Documentation of the basis of the estimate,
• Documentation of all assumptions made,
• Documentation of any known constraints,
• Indication of the range of possible estimates to indicate that the duration is estimated between a range of values,
• Indication of the confidence level of the final estimate,
• Documentation of individual project risks influencing this estimate.

6.4.3.3 Project Documents Updates

Include:

• Activity attributes.
• Assumption log.
• Lesson learned register.

Процесс построения архитектуры

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

Обычная архитектура имеет дело с неживыми предметами. Кирпичи - они и в Африке кирпичи, а бетон, хоть и меняет агрегатные состояния, но предсказуем. Никакие чертежи, планы не могут изменить свойств кирпича.  А вот архитектура предприятия имеет дело с людьми, подразделениями, организациями. Все они имеют свои цели, устремления, поведение, хоть и на разных уровнях.  И они меняют свое поведение/характеристики по мере того, как меняется их понимание окружающей среды и их собственных целей. Если я увижу, что в новой архитектуре нет места моему подразделению (моей должности, организации, …), то очень легко предугадать, что мои характеристики как работника подразделения очень и очень изменятся. Точно так же изменятся характеристики всех участников жизни предприятия на всех уровнях. Таким образом, мы пришли к тому, что продукты разработки архитектуры предприятия носят очень и очень временный характер. Как только они разработаны, нужно их менять, так как предприятие уже изменилось даже в силу разработки этих же продуктов, не говоря уже о внешнем воздействии. И так постоянно, пока предприятие живо.

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

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

• Нет документированной архитектуры вообще. Архитектура существует только в голове управленческого персонала компании. Нельзя сказать, что это плохо. Для частных предприятий, малых, - это даже хорошо. Есть экономия на разработке архитектуры, а результат от ее использования не так уж и велик. Количество сотрудников мало и архитектура может быть проговорена и распространена без лишней бюрократии. Но для больших предприятий - это беда. Не имея четкой основы для обсуждения, разные слои менеджмента движутся с большими задержками. Наверху жалуются на “тупых” подчиненных, которым всегда туго все доходит. Снизу жалуются на начальство, которое “понапридумывает всякой чепухи”, а реальные проблемы не решаются;
• Существует документированная архитектура в виде когда-то созданных инструкций, положений, регламентов, и т.д. Когда-то создали, и больше особо не меняли. В результате документация осталась тоже где-то в прошлом, а предприятие спотыкается о нее, с одной стороны стараясь приспособиться к новой внешней среде, а с другой стороны начальство продолжает стараться заставить подчиненных работать по инструкции. Это вариант, который остался от старого прошлого, когда организации эволюционировали медленно, так как все менялось медленно, когда цикл обновления оборудования был 10 лет, а то и больше. Сейчас, когда цикл обновления сократился до 3 лет, а программном обеспечении - так и вообще такое впечатление, что непрерывно, такой подход уже применять очень и очень тяжело. Лучше сказать, что невозможно. Кстати, нужно отметить, что в эту категорию попадают и те разработки архитектуры предприятия, где руководство и архитекторы не понимают ее природу. Создав кипу документации, создатели успокаиваются и начинают заставлять предприятие жить по этим инструкциям, не замечая, что их документация медленно, но верно устаревает;
• Архитектура предприятия создается до мельчайших подробностей. В результате получается многотомный продукт. И его уже нужно менять. А ресурсов на поддержание такой детальной документации обычно нет. И ситуация переходит в предыдущий вариант;
• Правильный вариант. Документация достаточно подробна, но и не тяжеловесна. Разрабатывается на основе тесного общения всех заинтересованных лиц. Будучи однажды разработанной, постоянно поддерживается в актуальном состоянии, более того - на основе ее разработки формируются рабочие документы, которые регулируют жизнь предприятия. Архитектура является средством, а не самоцелью.

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

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

Как и обычный продукт, архитектура разрабатывается в течение следующих этапов, шагов:

• Рассмотрение первоначальной идеи;
• Конструирование;
• Реализация; 
• Изменение и замена системы. 

Материалы, посвященные управлению проектами

Вводное слово

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

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

Последствия… Вавилонская башня от Andreas Bengter

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

Бурж Халиф, самое высокое здание на текущий момент. Невозможно представить, что такое здание было построено без описания архитектуры здания в чертежах и планах, которые соединили тысячи работников в единый организм. И невозможно представить, как удается управлять компаниями без подобных детальных чертежей. Может поэтому в странах СНГ один из самых низких уровней организованности?

 

Определение понятие архитектуры по стандарту ISO/IEC/IEEE FDIS 42010:2011:

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

Как видно из определения, архитектура включает в себя как конструкцию, так и те факторы, которые влияют на ее развитие.

Архитектура создается для использования определенным кругом лиц. Такие лица называются заинтересованными, или, как один из аглоникаизмов, стейкхолдеры (те, которые держат отбивные :) ) - stakeholders. По определению стандарта IEEE заинтересованными лицами являются:

Заинтересованные лица - персоны, группы или целые организации (или классы таковых), которые интересуются системой, или кого таковая система затрагивает.

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

Планирование работ подчиненных в ИТ

Поделюсь некоторыми наработками по планированию работ проектов и не только, которые я используют в своей практике. Основные подходы:

• Использование нескольких временных горизонтов (временных перспектив, срезов);
• Привлечение подчиненных в качестве экспертов;
• Контроль и перепланирование.

  1. Временные горизонты

Считаю хорошей практикой планирование работ на несколько горизонтов:

• Горизонт проекта, в котором увязаны высокоуровневые задачи. Этот уровень планирования должен показать, когда планируется окончание проекта и его общие затраты. Это взгляд на проект с высоты птичьего полета. Если проект не на один месяц, то у участников проекта должно быть представление о месте и времени их текущей работы в общем процессе выполнения проекта.
• Горизонт следующей важной вехи. Это первая важная цель, которая должна быть на виду. Достижение этой вехи – это значительный шаг на пути выполнения всего проекта. Это повод сделать выводы об эффективности хода проекта, выпить шампанское за хороший результат или очень крепко задуматься о причинах неудачи.
• Недельные планы. Скажу честно, это мои любимые планы. И, насколько я заметил, любимые для многих другим руководителей. В первую очередь это объясняется «природным» циклом, т.е. трудовой неделей. Работаем до пятницы, а после выходных – следующий цикл. Также это достаточный горизонт планирования для того, чтобы получить заметное продвижение по работам. Психологически очень удобно, так обозримо для того, чтобы держать в памяти основные моменты задач. За этот период можно получить результат, который можно показать руководству, которое не сведуще в тонкостях технологии, но может понять, что продукт получил новые свойства.
• Планы на 2-3 дня. Обычно на недельных планах и останавливаются. Я же требую составление планов с задачами, продолжительность которых не превышает 2-3 дня. Это план, где моих знаний еще достаточно для того, чтобы понять в общих чертах, что, как и когда будет сделано. В то же время, на этом уровне планирования также могу определить, что исполнитель понимает о чем идет речь. Даже если у нас получилось недопонимание, что и как нужно сделать, потерянными окажутся максимум три дня, а не вся неделя. Психологически период в два-три дня не дает исполнителю чувства, что время еще на задачу есть, можно расслабиться, потом догоним. Задачу нужно сделать завтра, а завтра – вот оно уже, завтра! J
• Почасовые и с больше й детализацией планы. Иногда есть надобность в почасовых планах. Такие планы я использую, когда необходимо распланировать определенное мероприятие, например: показ клиенту, или когда нужно за два дня получить какой-то результат. Чтобы не было разночтений, что нужно сделать, составляется такой план. Также по нему удобно оперативно отслеживать, как идут дела, чтобы максимально быстро вмешаться, если что-то пошло не так. Но в моей практике это скорее исключение, чем правило. Такие планы требуют много усилий для планирования и для повседневной деятельности обычно избыточны. Я предпочитаю, чтобы такие планы были в голове исполнителя.

  2. Привлечение подчиненных к планированию

Индустрия информационных технологий так быстро развивается, что знать все обо всем просто не реально, только если вы не гений. Если начальник мог выдать задание подчиненному с любой степенью детализации, потому что он «собаку съел» на этом, то сейчас это обычно очень затруднительно. У меня несколько подчиненных, каждый из них специалист в своей области, и чтобы передать знания от одного к другому нужно время. Что говорить обо мне, у которого подчиненные больше знают в своей области, чем я? Мне приходится доверять им и приглашать их для участия в планировании работ в качестве экспертов. На самом деле очень мало специалистов, которые не хотят работать. Зато много специалистов, которые не хотят работать без видимого результата. Поэтому наша задача помочь получить им этот результат, собственно, это то, за что нам платят деньги уже наши руководители. Итак, в процессе планирования участвуют мои специалисты. Мои задачи:

• Обрисовать задачи, которые нужно выполнить в результате проекта, по результатам вех, по результату текущей недели;
• Согласовать видение способа выполнения задач подчиненных – тактику, с видением полученных результатов руководством – стратегия.
• Убедиться, что специалисты:
  • Понимают, что от них хотят,
  • Четко представляют, как это получить;
  • Если не понимают, то в явном виде могут описать, что может пойти не так (риски), и что можно сделать для исправления этого «не так»;
  • Понимают, какие ресурсы и время нужно для выполнения задач и согласны с ними. Более того, сроки у меня обычно назначают подчиненные. Если я чувствую, что они их завышают, я
    • Задаю уточняющие вопросы, чтобы улучшить свое понимание;
    • Задаю уточняющие вопросы, чтобы подчиненный понял, что завысил сроки;
    • Привлекаю к планированию специалиста, который понимает, о чем идет речь. Пусть меня простят, можно сказать, что я сталкиваю двух специалистов, а сам выступаю в роли судьи.
  • Если сроки занижают – это гораздо большая проблема, и встречается существенно чаще. Обычно я просто умножаю срок на коэффициент три. Одна часть – собственно работа программиста, вторая часть – подготовительно-завершающие работы (развернуть среду, задокументировать, что-то подчитать, …), третья часть – тестирование и исправление ошибок. Конечно, если специалист опытный – то коэффициент уменьшается. Но это уже индивидуально.

Задачи специалиста (напомню, он здесь в качестве эксперта):

• Уяснить, что требуется сделать;
• Оценить ресурсы и сроки;
• Оценить накладные расходы на выполнение работы.

Иногда руководство просто выдает задания подчиненным без согласования с ними. Такой подход работает там, где процесс налажен и стандартизирован. На производстве с роторными станками все элементы операций измерены с точностью до секунды. Можно посчитать теоретически производительность и она будет близкой к практике. В ИТ это не проходит. Ввиду сложности, начальник не может просчитать ВСЕ варианты событий. Если начальник спускает директиву без согласования с подчиненным – все, включается принцип: что заказали, то и получили. Любая ошибка автоматом списывается на начальника: «Я все сделал так, как Вы приказали».

3. Контроль и перепланирование

И обязательно контроль. «План – ничто, планирование все». Уверен, мы планируем для того, чтобы получить план, который просто является намерением о действиях. Мы постоянно должны интересоваться, как идет выполнение плана, почему есть отклонение от плана, и менять планы. Принцип «Я спланировал, а они не выполнили» - это не наши методы. Так могут думать только те, кто не чувствует за собой ответственности. Еще раз, план, точнее процесс планирования для того, чтобы в процессе планирования и начальник, и подчиненные поняли, что нужно сделать, как и когда. И работали как единая команда.

Системный взгляд на управление проектами. Обзор

По мотивам Harold Kerzner "Системный подход к планированию, построению графика и контроля".

16 положений др. Керзнера к зрелости в управлении проектами

Dr. Kerzner's 16 Points to Project Management Maturity

• Adopt a project management methodology and use it consistently.
• Implement a philosophy that drives the company toward project management maturity and communicate it to everyone.
• Commit to developing effective plans at the beginning of each project.
• Minimize scope changes by committing to realistic objectives.
• Recognize that cost and schedule management are inseparable.
• Select the right person as the project manager.
• Provide executives with project sponsor information, not project management information.
• Strengthen involvement and support of line management.
• Focus on deliverables rather than resources.
• Cultivate effective communication, cooperation, and trust to achieve rapid project management maturity.
• Share recognition for project success with the entire project team and line management.
• Eliminate nonproductive meetings.
• Focus on identifying and solving problems early, quickly, and cost effectively.
• Measure progress periodically.
• Use project management software as a tool—not as a substitute for effective planning or interpersonal skills.
• Institute an all-employee training program with periodic updates based upon documented lessons learned.

16 положений др. Керзнера к зрелости в управлении проектами

• Примите на вооружение методологию управления проектом и используйте ее последовательно.
• Реализуйте философию, которая ведет компанию к зрелости в управлении и говорите о ней с каждым.
• Придерживайтесь разработки эффективных планов в начале каждого проекта.
• Минимизируйте изменения в объеме проекта придерживаясь реалистичных целей.
• Осознавайте, что стоимость и график проекта являются неразделимыми.
• Выберите правильного человека в качестве руководителя проекта.
• Предоставляйте руководству информацию, которая необходима им как спонсорам проекта, а не информацию по управлению проектом.
• Усиливайте вовлеченность и поддержку линейных руководителей.
• Сосредотачивайтесь на выходных материалах проекта, а не на ресурсах.
• Культивируйте эффективные коммуникации, кооперацию и доверие для достижения быстрой зрелости в управлении проектом.
• Разделяйте признаки успеха в выполнении проекта со всей командой и линейным менеджментом.
• Уберите непродуктивные собрания.
• Фокусируйтесь на идентификации и решении проблем рано, быстро и экономично.
• Периодически измеряйте прогресс.
• Используйте программное обеспечение по управлению проектом как инструмент - но не как замену эффективного планирования и межличностные взаимоотношения.
• Введите программу для обучения всех сотрудников с периодическим обновлением программы, основанном на задокументированных выученных уроках.