#УправлениеПроектами #Теория #Содержание

Всем привет!

Продолжаем серию из 10-ти дневных постов о проектных областях знаний. Перечень областей знаний есть в прошлом посте 👆🏻а сегодня собственно о Содержании - будет покороче, чем по интеграцию, чтобы вас сильно не грузить))) наверняка вы сейчас гуляете по городу, пьете глинтвейн или проводите время с семьей))))

Поехали 🚀🚀🚀

Итак, основная задача управления содержанием - определить то, что вы будете делать в проекте, задать границы проекта (это называется scope проекта) и четко соблюдать обозначенные границы.

В традиционных ИТ проектах в эту область могут входить такие активности как обследование бизнес -процессов, разработка методологических документов, подготовка технического задания для проведения тендера и далее создание прототипов.
В digital проектах могут проводиться UX/UI исследования, в agile проектах - составляться user stories и прочее

🆘Очень важный аспект в этой области : собрать верные требования, явные и скрытые. но для этого важно грамотно определить заинтересованы стороны. Очень часто встречается следующая история: ИТ систему внедрили, а она "не летит", потому что конечных пользователей никто не спросил о том, как им будет удобно работать. Или ещё из классики: начать рассказывать пользователям про новую систему перед запуском - люди первый раз об этом слышат и начинают "раздувать" границы проекта дополнительными хотелками.

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

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

Следующая история - это подготовка ИСР - иерархическая структура работ. В agile проектах обычно представляет собой набор пользовательских историй.
🌟 важно : ИСР - это все то, что вы будете делать в проекте - визуализация границ проекта. Может быть в виде канбан-доски, большого ватмана, доски со стикерами.
🗂Группировка работ может быть по этапам проекта / по функциональным характеристикам/ по ключевым заинтересованными. Основная ценность в том, что команда проекта и любые заинтересованные стороны могут подойти к доске и посмотреть, что мы делаем в объёме проекта, а чего не делаем.

И теперь давайте подведем итог в виде последовательности действий:

1️⃣ определяем, какие требования будем собирать - пишем это в плане управления проектом
2️⃣ выбираем способ сбора требований (обследование, анкетирование, интервью, опросы, дизайн -мышление, мозговой штурм, отображение данных, экспертная оценка и др) + выбираем тех, с кем их будем собирать
3️⃣ проводим сбор требований, фиксируем в виде документов + составляем визуальную ИСР, проверяем на соответствие целям и задачам проекта. Обязательно обсуждаем с командой - создаём единое информационное пространство
4️⃣ утверждаем список требований с заказчиком
5️⃣ переходим к составлению расписания, но об этом завтра))

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

Как всегда, если есть вопросы - буду рада ответить 👇

Перейти к описанию следующей области управления проектами. Управление расписанием

Пример ИСР

#УправлениеПроектами #Теория #Расписание

Всем привет!
мы с вами подошли к 3-й области знаний проектного управления - РАСПИСАНИЕ 📆
Напомню, что перечень областей знаний есть в прошлом посте 👆🏻

Поехали 🚀🚀🚀

Управление расписанием - это, пожалуй, одна из самых понятных и, как следствие, самая хорошо-управляемая область проектного управления. Что мы тут делаем?
Все просто: составляем расписание проекта, контролируем его исполнение и мониторим план-факт.

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

1️⃣ Анализ альтернатив. После того, как вы определили, что вы будете в проекте делать и даже назначили ресурсы для выполнения задач подумайте, а действительно ли это самый оптимальный способ выполнения с точки зрения длительности/ стоимости/ объема задействованных ресурсов/ соблюдения требований компании? К примеру, вы собираетесь включить в команду проекта разработчика для интеграции вашей системы с широко-распространенной системой гос. органов. Как вы думаете, у кого компетенции и опыта больше: у вашего программиста или у ИТ-агентства, которое занимается настройкой интеграций системы гос. органов?
Или вот еще: вы хотите с нуля писать систему для ведения бухгалтерского учета на Предприятии? Зачем? если есть уже написанные готовые программы, которые прошли неоднократное внедрение, настройку и апробацию и за счет эффекта масштаба, вам могут предложить адекватную стоимость за эту систему.


2️⃣ Сжатие расписания - в практике проектного управления так называются варианты оптимизации/ сокращения расписания. Представьте, что вас просят сократить длительность проекта на 2 месяца. В принципе, у вас всегда 2 варианта:
🌟либо добавить ресурсы на выполнение последовательных работ и сократить длительность каждой, но при этом вы увеличиваете стоимость проекта
🌟либо запараллелить работы, но при этом вы увеличиваете риски своего проекта
Не забывайте, пожалуйста, про эти ограничения и обязательно оценивайте каждый из этих вариантов при защите расписания у Заказчика.
Хорошее видео на этот счет

3️⃣ после того, как определены работы, назначена длительность и ресурсы, выбрана наилучшая стратегия реализации каждой работы составь итоговое расписание.
Инструмент может быть любым: Excel, Project и др - здесь останавливаться не буду, писала целый пост на этот счет в инсте

🆘но вот что важно: расписание это не всегда «диаграмма Ганта» (например, разработка Технического задания будет проводиться с 1-10 февраля 2020 года), ты вполне можешь составить список контрольных точек проекта с указанием финальной даты (к примеру, Техническое задание должно быть готово не позднее 10 февраля) - это еще называется вехами проекта. Также по набору достигнутых вех проекта можно отлеживать % выполнения Плана-графика и эта форма обычно ОЧЕНЬ нравится Руководителям - ее можно использовать для отчетных совещаний. А вот для планирования подойдет не всегда… В каких случаях ее можно использовать:
🌟у тебя немного работ
🌟большинство работ выполняет один исполнитель и их загрузка не связана между собой
🌟работы по большей части не связаны друг с другом
🌟длительность проекта примерно 3-6 месяцев
Пример диаграммы контрольных точек прикреплю скрином ниже

4️⃣ Следующий пункт навеян недавними консультациями по устройству на работу 😂😂😂. Вне зависимости от того, какую форму составления расписания ты выберешь, есть негласная прописная истина: расписание должно быть структурным, с выделением этапов проекта (группировка работ), с обозначенными ресурсами, с указанными зависимостями между работами, с указанием вех проекта, очень хорошо воспринимаются Заказчиком индикаторы о каждой работе проекта (красно-желто-зеленые), которые формируются автоматически в зависимости от даты. Поверь, визуальная часть может очень многое рассказать о квалификации РП. Именно поэтому при приеме на работу часто просят составить план-график проекта. Удели этому особое внимание. Сомневаешься - обратись к специалисту;)

ПРОДОЛЖЕНИЕ ->>>>>>>>

5️⃣Ну и last but not least. Контролируй план-факт исполнения расписания проекта ежедневно или еженедельно в зависимости от состава проекта.
Твой идеальный статус проекта (например, еженедельный) должен строиться примерно по такой структуре:
🌟обзор выполненных за неделю работ.
🌟разбор причин невыполнения работ и предложений по «наверстыванию» графика с фиксацией итогового решения
🌟план задач на следующую неделю
🌟обзор зафиксированных на прошлом статусе поручений и при необходимости фиксация добавленных задач в план график.

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

Как всегда, если есть вопросы - буду рада ответить 👇

Перейти к описанию следующей области управления проектами. Управление стоиомстью

Пример диаграммы контрольных точек

💰💰💰
#УправлениеПроектами #Теория #Стоимость

Всем привет!
Сегодня 4-я область знаний проектного управления - Управление стоимостью
Напомню, что перечень областей знаний есть в прошлом посте 👆🏻

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

И как всегда постараюсь рассказать вам не только об основных процессах управления стоимостью, но и о лайфхаках в этой области
Поехали 🚀🚀🚀

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

1️⃣Попросите показать детальный план-график выполнения работ (чем детальнее, тем лучше) с указанием объема задействованных ресурсов и их ставок. Основные моменты про расписание проекта и что там важно были в предыдущем посте 👆🏻 График работ - это основной документ, на основании которого рассчитывается смета или бюджет проекта, т.к. он дает понимания о работах проекта, ресурсах (людях, материалах, оборудовании), длительности выполнения проекта.

💡Не поленитесь и детально изучите план график, найдите 1-2 понятных для себя работы, оцените задействованные ресурсы и поговорите об этом с Подрядчиком, ну или попросите ваших экспертов провести подобную работу
🔴 к примеру, если в разработке Плана управления проектом не задействованы ключевые участники от Подрядчика и все делает один РП - явно хорошего результата вы в проекте не получите; Если в ПГ не присутствуют работы по установке ПО или оборудования, на основании чего тогда они включены в смету проекта? ну и т.д….

2️⃣ Оцените структуру проектной сметы - вариаций, конечно, много и, возможно, шаблон у вас в компании установлен, но посмотрите, какие статьи затрат выделены (например, здорово, когда отдельно выделяется стоимость привлечения команды, стоимость оборудования или ПО, командировочные расходы, особо круто выделение стоимости на управление проектом: Руководитель и администратор проекта).
💡под каждую цифру в смете у РП должна быть расшифровка, смело спрашивайте, как получена стоимость ПО, проведен ли сравнительный анализ наиболее оптимальной стоимости
✅ но имейте ввиду, что Подрядчик в праве не раскрывать рентабельность, т.е. сколько он на вас зарабатывает или другие показатели, например, нормы командировочных расходов, тут ваша задача согласовать основные метрики, к примеру, количество дней присутствия консультантов или очных совещаний.
🔴 если смета представляет собой набор несвязанных задач, не прозрачна по структуре, а подрядчик на каждый вопрос отвечает, что оценка получена экспертным путем - шлите лесом переделывать.

3️⃣Попросите Подрядчика рассказать об аналогичных проектах и их стоимости, реализованных для других Заказчиков, или проведите такой анализ самостоятельно Только так вы сможете сделать вывод о «справедливости» цены.
✅ В идеале Подрядчик приведёт хотя бы 2-3 аналогичных проекта, отметит нюансы вашего проекта, расскажет о проблемах, которые были в прошлых проектах, и подсветит особенности вашей сметы
🔴 подрядчик скажет, что ваш проект уникальный, но он все очень детально и точно рассчитал - ну- ну, опять же идет лесом…

4️⃣ Спросите, какой объём в структуре стоимости заложен на управление рисками. Риски, вернее их перекладывание на Подрядчика, зачастую является основной причиной привлечения Подрядчика))) Они всегда присутствуют в бюджете проекта, но самый большой вопрос - в каком объеме и почему именно столько…
✅ Подрядчик приведёт зафиксированные риски, расскажет о стратегии работы с рисками и скажет, что к примеру 10-15 % в стоимости предусмотрено в качестве резерва на риск.

ПРОДОЛЖЕНИЕ->>>>>>>

🔴 Подрядчик сделает удивленные глаза или назовёт цифру в 5-10% от стоимости. В этом случае можете считать, что в вашей цене сидит примерно 40-50% «надбавки» вместо реально проработанных рисков. Как делает часто-встречающийся РП: к примеру, разработчик называет срок разработки - 5 дней, РП закладывает - 10 и так по каждой задаче - это вкорне неверный подход. Стоимостные резервы НЕ должны закладываться в каждую работу. Все риски должны быть зафиксированы и оценены в денежном эквиваленте (но об этом поговорим в 8-м посте)

5️⃣ Если вы уже все согласовали и перешли к реализации проекта, важным этапом управления стоимостью является Мониторинг сметы. Заранее договоритесь с Исполнителем или Заказчиком, какая будет форма мониторинга, какая периодичность и какие показатели являются ключевыми. К примеру, это может быть методы освоенного объема (обычно применяется в строительстве и классических ИТ-проектах) - если кратко суть его в том, что мы не просто смотрим, сколько денег мы потратили, но и то, на сколько это соответствуют плану выполненных работ. Еще одним показателем может быть конверсия (в digital проектах), когда вы запускаете интернет магазины или странички в инстаграмм и смотрите, сколько реальных продаж вы сделали - иногда от этого показателя Исполнитель получает свой %.

ВЫВОД: В целом, если вы являетесь разработчиком сметы, а не согласующим - задайте себе те же самые вопросы, начиная с 1 пункта, и имейте ввиду: вы должны нести ответственность за каждую цифру в вашей смете! Если вы не можете ее обосновать - лучше не отправляйте ее своему руководителю или Заказчику

Делитесь в комментариях, что думаете и какие у вас лайфхаки по снижению стоимости сметы 👇🏻

Более подробно эту область знаний мы разбираем на практикумах по проектному управлению (доступны в записи):
Как составить бюджет/ смету проекта
Как оценить экономические эффекты проекта
Как составить экономическую модель проекта и рассчитать окупаемость

#УправлениеПроектами #Теория #Качество

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

Давайте для начала определим, что такое качество проекта или продукта - в общем случае это соответствие заранее установленным параметрам или требованиям,
🌟для ИТ систем часто применятся такие показатели, как быстродействие, время отклика, объем баз данных и т.д.
🌟Для производственных систем у вас может мониториться % бракованных изделий, соблюдение Гости т.д.
🌟Также под качеством проекта может подразумеваться и качество выстроенных процессов внутри проекта/ организации для своевременного выявления дефектов/ проблем.

Все эти параметры обусловлены либо стандартами качества (например, ГОСТ в строительстве, производстве пищевой продукции) или требованиями Заказчика. Для начала вам нужно их выяснить, зафиксировать и определить критерии приемки результата, чтобы при сдаче проекта не услышать от Заказчика: «это не тот результат, которого мы ждали, мы не можем его использовать», а дальше начинается составление планов достижения этих показателей, реализация планов, мониторинг и контроль и подведение итоговых замеров, насколько ваша система соответствует этим параметрам.

Общая схема управления качеством выглядит так:
1️⃣На этапе инициации Заказчик определяет требования к продукту, РП собирает все стандарты и политики, которым также должен соответствовать продукт
2️⃣На этапе планирования
◦ Команда уточняет эти требования и определяет, что нужно сделать в проекте
◦ РП разрабатывает план управления качеством (кто, что и когда делает, какие процедуры проверки качества будем использовать, с какой периодичностью) и синхронизирует его с остальными планами (сроки, деньги, др)
3️⃣ На этапе реализации
◦ команда проводит контроль качества разработок в соотв. с планом (например, тестирует программный код перед сдачей Заказчику на предмет соответствия требованиям) - чек-лист тестирования ИТ-системы забери тут
◦ отдел качества контролирует соблюдение плана по качеству (например, проектный офис проверяет наличие протоколов внутреннего тестирования, подписанного тестировщиками)
4️⃣ На этапе мониторинга Заказчик проверяет продукт на предмет соответствия заявленным требованиям (тестирует решение) и в случае успеха - принимает работы

🌟ТОП 5 советов:
1. В каждом проекте вы управляете качеством, когда что-то проверяете. перед тем, как что-то проверять, напиши, КАК проверять
2. Лучше предотвращать, чем устранять
3. Не надо делать лучше, если вас об этом не просили - это передайте проектной команде
4. постоянно ищите способы, как повысить эффективность процессов управления проектом/ разработки кода/ проведения совещаний
5. за качество отвечает каждый участник проекта

🆘А теперь Давайте сразу к ключевому и основному, что вам нужно запомнить и на этом мы пожалуй на сегодня закончим, чтобы не мучать и меня и вас 😂

Как вы знаете, в проекта есть треугольник ограничений - стоимость, расписание, содержание. Представьте, что это ваши вершины треугольника (рисунок будет ниже). В проектном управлении есть одна простая аксиома: при изменении любой вершины (к примеру, увеличение содержания или при снижении стоимости) обязательно изменяются и другие вершины, а какая-то из свершил невозможна к изменению (к примеру, проект нужно реализовать к 01.01.22), поэтому вы как Руководитель проекта всегда должны находить компромисс и наиболее важные параметры для проекта.
Что выберет Заказчик: реализацию дополнительного функционала и увеличение сроков проекта на 2 неделю + 500 тыс. руб. или завершит проект в срок, но не выполнит дополнительное требование?

✅ так вот - основной вывод сегодняшней темы в том, что какие бы вы параметры проекта не меняли, вы никогда не должны СНИЖАТЬ утвержденное качество вашего продукта и стараться удержать его наиболее «круглым»!

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

Следующая область управления проектами
Управление коммуникациями

Привет, 102 подписчика!))) 🎉

За сегодняшнюю ночь нас стало немного больше, чем 1️⃣0️⃣0️⃣)

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

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

🌟Проектный менеджер VS менеджер продукта?

#интересныеМероприятия #проекты #продукты

Кто все эти люди и какая в них разница? Судя по опросам примерно 20% не понимают разницы. И это нормально и вполне объяснимо - во многих компаниях эти функции перемешены, либо используются не по назначению.

🗣Я объясню просто на примере
Давайте представим, Вы - менеджер продукта, например в он-лайн школе, вам поставлена задача сделать ПРОДУКТ - сайт для взаимодействия преподавателей и учеников, да еще так, чтобы он он-лайн школе прибыль приносил и имел внешний, удобный, классный интерфейс.

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

📆 У менеджера проекта задача понятная и ограниченная определенной целью и во времени: к 1 июня запустить сайт с заявленным функционалом.

И вот 1️⃣ июня вы получаете готовый сайт , но дальше вам, как менеджеру продукта, предстоит поддержка и развитие ПРОДУКТА: внимательно следить за работой сайта, реагировать на внешние и внутренние изменения с целью обновления сайта; контролировать, чтобы заявленные эффекты действительно были достигнуты и, что самое главное, но редко используемое - вовремя принять решение о выводе вашего сайта из эксплуатации или замене его на более крутую версию.

А дальше все по спирали и этому может даже не быть ни конца ни края (ну вот такая доля у менеджера продукта). На этом нашему примеру конец, а кто слушал…т.е. Читал + 500 к карме 🙏

#управлениеПроектами #теория #коммуникации
💜Это Моя самая любимая область управления проектами и, если вы хотите стать хорошим руководителем проекта, полюбите её тоже.

Естественно, речь пойдет не только про общение, разговоры, обсуждения и совещания

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

Что бы вы подумали?
⁃ какого художника?
⁃ кто это вообще?
⁃ У меня его вообще в проекте нет
⁃ Блин, придётся тратить время и потом отвечать на вопросы по документам

Бывало у вас такое? Наверняка да! Первое, о чем вы должны подумать : почему он интересуется проектом и соответственно почему он вовремя не получил необходимую - скорее всего вы не идентифициррвали его как заинтересованных сторону, не учли его требования, как следствие, придется проводить доп работы. Оно вам надо?

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

Самый главный документ здесь - план коммуникаций, который обычно состоит из описания того
🌟какие совещания/встречи /звонки /статусы/ информационные сессии/ публикации вам нужно провести
🌟в каком формате (очно, заочно)/ какая периодичность
🌟кто ответственный
🌟с кем (кто должен быть на совещании или кто должен быть получателем информации )
🌟какая цель каждой коммуникации

А вот еще топ 5 лайфхаков для составления и исполнения классного плана коммуникаций:

1️⃣ Представьте все коммуникации как квадрат: они проходят внутри и снаружи проектной команды, а также в горизонтальном и вертикальном направлении. А теперь постарайтесь описать каждый из этих потоков.
Например, вертикаль вверх: в офис управления проектов РП будет 1 раз в неделю подавать отчет о статусе проекта в установленной форме (word). Горизонталь: команда обменивается статусом задач и открытыми вопросами на ежедневных стендапах и т.д.

2️⃣ коммуникации в проектах не всегда письменные и формальные. Постоять в курилке/ отметить ДР участника команды/ похвалить за крутую работу - это тоже коммуникация. Краткая шпаргалка о подходящих типах коммуникаций будет внизу в виде картинки

3️⃣ используйте правило 5С: любая коммуникация должна быть грамотной, емкой, с указанием цели, с логичным изложением мысли, и под контролем. Вам кажется эта рекомендация слишком очевидной? 😎А вы понаблюдайте за ближайшими своими или чужими коммуникациями и сделайте выводы - соблюдаются ли эти условия или нет.

4️⃣ Вспомним математику: если в проекте у вас 3 участника команды, то у вас 3 канала коммуникации. А если 4? Количество каналов рассчитывается по формуле n*(n-1)/2, т.е. При 4 участниках у вас Уже 6 каналов. А если 10 участников команды? - чтобы коммуникации оставались эффективными, Выделите 2 мини-руководителя групп (к примеру, ведущий программист и ведущий аналитик) и все коммуникации проводите с ними, а они в свою очередь - со своими 2-3 участниками.

5️⃣last but not least не стесняйтесь подтверждать получение информации - это касается и простых писем из серии: подтвердите, пожалуйста, получение письма. Я, к примеру, очень люблю писать письма с фразой kind remind и далее напоминание о том, что я ожидаю получить. Если речь про устную коммуникацию (особенно на удаленке) просите собеседника повторить как он понял вопрос/ поручение или попросите зафиксировать в виде мимо/ протокола

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

Все эти детали, шаблоны и примеры рабочих документов мы разбираем на семинаре «Инструменты проектного управления» (доступна запись)

#посмотреть #видео #управлениеРасписанием

Ежегодно пересматриваю это неимоверно милое видео про сетевое планирование и управление расписанием из Советского союза.

Столько прошло времени, а видео до сих пор актуально
Обязательно посмотрите, как будет время

Enjoy!
https://www.youtube.com/watch?v=xDp6xKOVJYE&t=977s

Еще больше информации про управление расписанием в проектах

#кейсыИзЖизни #проДоговоры

Включать ли Акт выполненных работ в результирующие документы по договору?

Давайте сразу на примере из жизни: у вас проходит опытно-промышленная эксплуатация системы (ОПЭ) и в договоре в качестве результата указан Акт выполненных работ. И вот Подрядчик запустил систему в ОПЭ и через 2 дня приходит к вам с актом выполненных работ на подписание? Можете ли вы его подписать? - очевидно нет, но, с другой стороны, юридически у вас нет необходимости сдавать другие документы.

И 2️⃣ вариант развития событий: в результатах этапа написано:
🌟Протокол проведения ОПЭ в течение 3-х месяцев
🌟Протокол устраненных замечаний по итогам ОПЭ

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

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

☝🏻Кстати, имейте ввиду, что достаточно часто Поставщики предлагают договоры, по условиям которых, предоставление акта выполненных работ обязывает вас в течение какого-то срока⏰ (к примеру, 5 дней) его подписать или направить официальный отказ, а если вы вдруг этого не сделали, работы считаются принятыми. Поэтому обязательно внимательно читайте договор и согласовывайте его с юристами.

Подробности разбираем на семинаре «Тендеры и договоры» (доступны записи)

🚘Арендовать или покупать в проектах и в жизни?
#кейсыИзЖизни #бюджетПроекта

Пост как всегда навеян прошедшим обучением на курсе Финансовый менеджмент))
Новым студентам - привет)))

Сегодня немного поговорим о классификации статей затрат на CAPEX и ОРЕХ, которая всегда используется в организациях и при управлении проектами. Знать и понимать эти термины нужно для того, чтобы уметь ответить себе на вопросы

• Арендовать место в облачном хранилище или купить собственные сервера?
• Нанимать работников в штат или привлекать со стороны?
• Арендовать автомобиль или приобрести в собственность?

Объясню на простом примере из жизни:

🚘 Вы хотите водить машину и думаете, ЧТО именно выбрать: каршеринг или купить новенький порш (ну а что… сразу замахнемся на него).

Если у вас сейчас нет достаточной суммы денег 💰(хотя бы для первого взноса по кредиту) вам выгоднее использовать каршеринг (недорого, быстро, можно взять любую машину и вполне вашей цели удовлетворяет) - это будут ваши текущие (ОРЕХовые) затраты. Вы начинаете ездить, ежедневно тратите деньги на каршеринг, пару раз съездили за город и уже понимаете, что денег то уходит не мало, а скоро годовая премия, да еще и скидки на машины прошлого года и вы решаете купить пусть не Порше, но хотя бы хёндай. И вот вы выезжаете из салона на новеньком авто и теперь понимаете, что у вас уже появилась своя собственность, которую вы почти в любой момент и по предсказуемой цене можете продать - это ваш актив или CAPEXовые расходы. Это серьезная покупка, которой вы будете пользоваться больше года (если все-таки не решитесь на порш). Однако у вас появляются новые расходы - текущий ремонт, заправка, покупка ковриков, масла, обывателей, вонючек и т.д. И это опять ваши текущие расходы, т.е. OPEX

☝🏻К чему я все это: с точки зрения краткосрочного планирования всегда выгоднее иметь OPEXовые затраты (дешевле взять машину в аренду на несколько часов), но с т.з. стратегического мышления - выгоднее наращивать свои «активы», т.е. CAPEXовые затраты (когда у вас есть в собственности автомобиль вы понимаете, что у вас есть определенная «денежная подушка».

Чем больше у вас OРEХовых затрат, тем больше расходов приходится нести ежемесячно, плюс возникают непредвиденные/ нерегулируемым проблемы (нет поблизости нужной машины из-за высокого спроса, в карантин каршеринг закрылся и т.д.).
Однако и СAPEXоывые затраты также имеют свои минусы: машину надо заправлять, ремонтировать, и между прочим платить налог.

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

📒Ну и немного теории с практическими применениями в проектах:
• Капитальные затраты, или CAPEX (сокращ. от англ. capital expenditure), представляют собой затраты на приобретение активов (срок эксплуатации более 1 года - машина), а также на их модификацию (достройку, дооборудование, реконструкцию - замена Хендай на порш) и модернизацию. Пример из проектов: закупка ПО, оборудования, лицензий, привлечение внешнего консалтинга.

• Операционные затраты, или OPEX (сокращ. от англ. operational expenditure), представляют собой затраты компании, которые возникают в процессе ее текущей деятельности. Примерами операционных затрат являются: зарплата персонала, аренда помещений, представительские расходы, командировочные, затраты на обучение или обследование бизнес-процессов.

А какую модель предпочитаете вы - покупка или аренда квартиры/ машины/ оборудования? Делитесь в комментах к посту)

💣#управлениеПроектами #теория #управлениеКомандой

Всем привет!
Сегодня 6-я область знаний проектного управления - Управление командой. Напомню, что перечень областей знаний есть в закрепленных сообщениях 👆🏻

Ооооох, к этой теме я долго не могла подступиться. Почему? Потому что помимо теоретической фигни (её тут кстати достаточно мало) тема управления командой - это огромный океан теорий, практик и личных навыков, но давайте все-таки попробуем начать.

Когда вообще начинается процесс управления ресурсами?
есть несколько сценариев :

Сценарий 1️⃣
при инициации проекта. Давайте для примера сегодня будем внедрять CRM систему. Итак заказчик назначает вас РП и даёт для первичной проработки проекта, к примеру, функционального специалиста- руководителя отдела продаж и аналитика и вот у вас уже появилась маленькая команда

Сценарий 2️⃣
вас назначают Руководителем проекта и поручают определить, кто вам нужен в проекте и вы садитесь планировать проект:

🗂определяете содержание - здесь вы пишите, что хотите, к примеру, интеграцию вашей CRM системы с бухгалтерской системой для автоматического выставления актов выполненных работ. Сразу же «прикидываете» требования к исполнителю: необходим программист из соседнего отдела, который обслуживает 1С:Бухгалтерию (внешнего подрядчика не рассматриваем- он не сможет получить доступ к нашей системе). Вторая задача - это настроить систему оплат, для этого нужен будет программист, который занимается CRM (у нас в компании никто эту систему не знает - будем брать подрядчика), а для оплат нужна интеграция с нашим сайтом (это тоже будет делать подрядчик, но без нашего разработчика сайта тут не обойтись). Ну и конечно нужно выбрать ключевых пользователей, которые поставят требования к CRM системе, протестируют ее и потом будут визионерами внедрения - запланируем пока 2 человека)))

⏰Определяете расписание - выделяете приоритетные работы и «прикидываете», когда и на какой объем работы вам необходимы будут заявленные выше ресурсы. К примеру, выставление актов потребуется только к концу квартала, да их можно и руками сделать - с этим можно повременить, а вот оплаты пойдут сразу и нужно сделать интеграцию с CRM как можно скорее - поэтому подрядчика начнем искать сразу и заранее договоримся о привлечении разработчика сайта. Результатом этого шага является предварительное расписание использования ресурсов - кто и в какой момент вам нужен.

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

Дальше начинается полноценный процесс управления ресурсами, который состоит из следующих действий:
1️⃣ Еще раз составляете перечень всех необходимых ресурсов с учетом графика работ и требований. У нас с вами получилось 2 программиста, ключевые пользователи и подрядчики. Пока без фамилий - только роли
2️⃣ Готовим матрицу ответственности - кто и что должен делать. Можно в виде матрицы RACI
3️⃣Опционально, но желательно - делаете устав команды - это принципы взаимодействия, к примеру, какие основные ценности, как мы будем принимать решения, форматы проведения совещаний - не стесняйтесь, пишите все, что хочется - так вы заранее закладываете фундамент вашего взаимодействия
4️⃣ Вот тут самое интересное - вам необходимо идти договариваться с владельцами ресурсов о выделении самых лучших специалистов для вашего проекта! Ваша задача получить конкретные фамилии под конкретные роли. Включайте все свое обаяние, прихватывайте с собой дар убеждения и вперед. Можете сначала составить письма с запросом о выделении требуемых вам фио с указанием функционала и времени участия, а если будут вопросы у менеджеров ресурсов - топайте ножками.

ПРОДОЛЖЕНИЕ->>>>>>>

🏷Я прихожу в магазин покупать вещи, а не скидки

Всем привет!
Думаете, Странный заголовок в чатике про управление проектами?? А вот и нет. Руководители проектов постоянно сталкиваются с необходимостью продажи себя или проекта, поэтому сегодня хотела бы поделиться с вами своими мыслями на этот счет.

☝🏻Итак, основная мысль - Заказчику не всегда нужен самый дешевый продукт или услуга, даже если он говорит обратное.

Я очень люблю приводить пример с покупкой вещей👠. Как прожжённый шопоголик я фанат походить по торговым центрам. В период распродаж и скидок - это конечно то еще занятие. Не успеваешь ты зайти в магазин, как тебе из самого дальнего угла кричат о том, что у нас скидки -50/ -30%. А я как бы не за скидками пришла, а туфли из новой коллекции купить (ну, к примеру).

Также и в проектах - прежде, чем предлагать Заказчику варианты снижения стоимости проекта, сформируйте ценностное предложение, которое будет соответствовать ожиданиям Заказчика и вашему понимаю о стоимости этой работы. А вот уже в запасе имейте несколько козырей на случай, если Заказчик попросит рассказать о вариантах оптимизации затрат. Кстати, вот парочка советов, как сократить затраты и при этом остаться «при заработке»
🌟сокращение содержания
🌟перенос рисков на сторону Заказчика

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

А что вы думаете на этот счет? С какими кейсами встречались?