https://dzen.ru/a/ZBSEoJHIyUYPEP1n?share_to=telegram
Границы проекта: как с ними работать?

Опишу сейчас ситуацию, в которую угодили накануне закрытия проекта. Проект по внедрению 1С:ERP закрывается по договору 3 апреля. Осталось до окончания опытной эксплуатации буквально несколько недель. В этот момент фирма 1С выпускает новый релиз конфигурации 1С:ERP. Заказчик требует выполнить в рамках бюджета проекта обновление конфигурации (доработанной). Осложняется это обстоятельство тем, что у нас в ТЗ прописано, что критерием приемки работ является сдача бухгалтерией актуальной отчетности за 1 квартал 23 г. В новом релизе 1С:ERP, естественно, появились изменения в отчетности по НДС. Теперь у РП есть несколько основных вариантов развития ситуации:
1. Настаивать на том, чтобы закрыть проект в прежнем релизе конфигурации, а обновление вынести за рамки проекта и отдельный бюджет (последствия этой позиции пока не понятны).
2. Выполнить обновление (где-то 3-4 недели работы команды из 5-6 человек) в рамках текущего проекта, снизив существенно рентабельность проекта.
3. Договориться о заказчиком частично возместить затраты на обновление.
4. Сделать обновление только в части бухгалтерской отчетности.
Может есть и другие варианты.
А что бы предложили вы в этой ситуации?

Подробное рассмотрение темы "Управление рисками проекта"

https://dzen.ru/a/ZB2160QQwX027cKk?share_to=telegram

https://dzen.ru/a/ZB9B7EQQwX02KrFz?share_to=telegram
В чем разница между допущениями и ограничениями проекта?

📎 Вчера были на встрече с клиентом - известная сеть клиник. Получил удовольствие от общения с заказчиком.

Немного об общей атмосфере встречи.

Со стороны клиента: ИТ-директор, операционный директор (бывший руководитель по закупкам)
и зам. директора по закупкам.

Первые слова прозвучали примерно так: "с такой ценой, которую вы указали в предложении, нам не о чем здесь разговаривать".

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

При этом, было заметно, что в нас заинтересованы. Почему? 1. Переговоры шли достаточно долго, хотя неоднократно нам говорили, что дальше разговаривать не о чем.
2. От нас ждут наше новое предложение и готовы его обсуждать.
3. С нами долго общалась IT-служба перед этими переговорами, которая выясняла наш опыт и подход к решению таких задач. Т.е. это не случайный "наезд", а продуманная торговая стратегия.
4. Клиента поджимают сроки и им необходимо выбрать команду для старта проекта. Требуется узкая специализация для решения задач проекта. Т.е. такие компетенции сравнительно редки.
5. С одной командой, которая проводила предпроектное обследование, они расстались, видимо, не устроила цена, которую подрядчик назвал после обследования. И еще одна ошибка в выборе подрядчика (по цене) повлечет последствия для проекта и его участников.

Другими словами, если бы не были заинтересованы, либо встреч не состоялась, либо переговоры завершились очень быстро.

Как готовиться и вести себя на таких переговорах?

1. Необходимо заранее готовиться. Мы, к сожалению, не были готовы. Пришли знакомить команду с заказчиком, а получили "наезд". Готовиться - это значит определить свою стратегию переговоров (желательно провести SWOT анализ перед встречей, который очень хорошо приводит мысли в порядок).
2. Держать себя достойно и уверенно.
3. Знать и использовать свои сильные стороны. Выяснить слабости противоположной стороны. Это позволит вам определить степени свободы для маневров.
4. Не стремиться договориться здесь и сейчас, тем более любой ценой. Не предлагать сразу скидки и доп. работы, чтобы угодить клиенту. Это всегда воспринимается, как слабость.
5. Не надо эмоционально реагировать на манипуляции, чего и добивается любой манипулятор.
6. Иметь заготовленные сценарии предложений. Сначала предлагается клиенту самый выгодный для нас сценарий, потом, при необходимости, уступаем немного. Главное, чтобы было куда отступать. Не отступать в одностороннем порядке, Уступка за уступку.
8. Держать паузу. Лучше всего сказать, что надо обдумать и все взвесить, а потом выйти с новым предложением.

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

P.S. В нашем случае, сделаем усилия, чтобы договориться. Но если клиент "невменько", тогда сделки не будет. Такое тоже бывает.

https://dzen.ru/a/ZCRto-WQ9SyHZiL6?share_to=telegram
Искусственный интеллект (ChatGPT) на службе аналитика

Рефлексия участников обучения в Школе аналитика (февраль 2023) на тему достоверности экспертных оценок.

Коллеги, в оценке портфеля был применен метод номинальной группы.

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

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

Метод номинальный группы избегает ловушек группового мышления путем изоляции экспертов и анонимности оценок. Название "номинальная группа" означает, что группа является группой только номинально (фиктивно).

Кроме номинальной группы в ГОСТ Р 58771-2019, приложение Б, раздел Б.1 «Технологии выявления мнения причастных сторон и экспертов» предлагает и другие методы выявления мнений

Б.1.2 Мозговой штурм
Б.1.3 Метод Делфи (Delphi)
Б.1.5 Структурированные или полуструктурированные интервью
Б.1.6 Опросы

Приоритеты определились - три лидирующие темы, по результатам опроса. Забыли ещё добавить тему, связанную с продажами проектов. Надеемся, что эта тема тоже будет полезна для подписчиков.

Получил от клиента сегодня такое сообщение:

"У нас катастрофическая проблема с русский языком в результирующих документах. Не однократно по рабочим группам в рамках бизнес процессов делают замечания, а дело не двигается. Попроси что в зоне вашей ответственности проверить документы еще раз. Стыдно сдавать в таком виде … дай слово что поправите.".

Проект выполняем совместно с крупной консалтинговой компанией.

Честно говоря, действительно стыдно. Работаем в hi-tech, а элементарной грамоте не обучены.

Читаем статью Александра Мирзахмедова "Слонов едят по частям" о важности декомпозиции проектных задач.
https://dzen.ru/a/ZCZ_C1UqlhHAZFIM?share_to=telegram

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

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

Читать статью
https://dzen.ru/media/techit/doljnostnaia-instrukciia-rukovoditelia-proekta-1s-64248b419b207461190e5d9e

Интересные посты на канале в марте:

✦ Развитие начинающих проектных специалистов. Основные элементы системного подхода.

✦ Путь стажера аналитика до руководителя проектной группы. Интервью с Андреем Осинцевым, руководителем проектной группы компании «Первый бит».

✦ ТОП-10 книг для бизнес-аналитика: от новичка до профессионала

✦ О мифах и рифах гибких технологий. Захватывающая статья Александра Мирзахмедова.

✦ Как повысить низкую самооценку проектных специалистов?

✦ Проблемы при продаже проектов. Сценарии развития переговоров.

✦ Искусственный интеллект (ChatGPT) на службе аналитика.

Задать свой вопрос, поделиться мнением, рассказать историю по теме проектных технологий вы можете в нашем чате Проектник 1С

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

Читайте подробности в нашей новой статье

Метод набегающей волны в планировании проекта.

Планирование проекта «методом набегающей волны» (Rolling Wave Planning) – детальное планирование только на ближайшие этап(ы) проекта, а последующие элементы плана описываются только в общем виде.

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

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

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

📝Поделитесь, какие методы планирования проекта вы считаете более эффективными?

Друзья, добрый день! Хотим поделиться с вами историей, которая произошла на проекте у нашей коллеги.

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

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

Как такое могло произойти? Честно говоря, я не знаю.

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

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

❓Какие выводы можно сделать из подобной ситуации и как избежать аналогичных случаев? Что скажете, коллеги?