Маленькие проекты: готовые и типовые. Каталог содержит планировки, планы и чертежи

Обратная связь

Управление малыми проектами

Роль руководителя проекта | Саймон Бюринг | Время чтения минут

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

Сосредоточение внимания на реализации проекта

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

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

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

Применение лучших практик

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

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

Определение целей и объема

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

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

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

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

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

Определение результатов

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

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

Планирование проекта

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

Все эти вещи должны быть записаны и эффективно доведены до членов команды проекта. Я видел, как многие люди сбивались с пути, потому что думали, что им нужно использовать какое-то программное обеспечение для планирования управления проектами, такое как Microsoft Project. Это ненужные накладные расходы. Я заметил, что люди, как правило, тратят слишком много времени на то, чтобы их диаграммы Ганта в Microsoft Project выглядели красиво, поэтому они упускают из виду причину, по которой они используют этот инструмент.

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

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

Коммуникация

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

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

Отслеживание и отчетность о прогрессе

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

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

Управление изменениями

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

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

Чего никогда не следует делать, так это просто принимать изменения. Даже если вы считаете, что изменение небольшое, вы никогда не должны принимать какие-либо изменения без полного понимания того, как это повлияет на стоимость и сроки. Это рецепт того, что мы называем «расползание масштаба», когда проект становится все больше и больше по мере того, как в проект добавляется все больше и больше изменений. Прежде чем вы это осознаете, ваш маленький проект станет намного большим, и вы неизбежно не сможете реализовать свой проект в соответствии с вашим первоначальным бюджетом и графиком.

Управление рисками

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

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

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

Резюме

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