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

Вопрос 5: Исходя из вышеизложенного, какие изменения/добавления нужно сделать в новой технологии?

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

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

Впервые эти шесть вопросов появились в книге «Цель-3. Необходимо, но недостаточно» (Голдратт, Шрагенхайм, Птак, 2000) и включали в себя анализ модулей ERP систем, заменяющих (в действительности  — лишь расширяющих) MRP систему (изначально MRP1[i] позднее превратившейся в MRP2).

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

Существует три проблемных области принятия решения в проектном управлении, где ТОС [i] должна оказать значительное влияние:

1. Как выбрать проект?
2. Как выбрать конкретные характеристики продукта [ii] для данного проекта?
3. Как управлять графиком проекта и его реализацией?

Итак, мы, Алексей Васильев и Руслан Лазуков провели деловую игру по самым важным документам проекта в Санкт-Петербургском сообществе менеджеров ИТ проектов (SPB SPM Club). Точнее это был тренинг. Тренинг на отработку навыка написания Устава проекта и Плана управления проектом.

Никакое ИТ решение не может реально помочь, когда нет подкрепления методологией обеспечения коммуникаций в компании или команде проекта и фокусирования целях. Поэтому, BIPULSE будет наиболее эффективен если следовать принципам Agile, Теории Ограничений Систем и Бережливого производства которые мы свели в 7 простых правил.

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

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

Формулировка Задачи должна отвечать на вопрос "Что мне надо сделать чтобы завершить проект?" , в отличии от инцидента: "Что произошло? И почему пользователь несчастен?"

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