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

Не знаю, какая доля из 60% неуспешных проектов не успешна именно из-за отказа в планировании, но планированием в ходе реализации проекта точно не стоит пренебрегать (гарантия 100% – обожаю эту фразу после того, как её запретили использовать в одной компании, где я работал). Поскольку Excel для планирования не походит, нужен специализированный софт. Сейчас управление задачами и работами встроено в корпоративные порталы и CRM системы, но для начала я рекомендую взять универсальный локальный инструмент, такой как MS Project или GanttProject – последний, кстати, бесплатный. Вы уже готовы вносить задачи? Замечательно, но изменение начинается не с задач, мы будем планировать сверху-вниз.

Сначала нужно сделать строку с итоговой задачей – назовите её, как своё изменение / проект, чтобы видеть общие сроки, которые будут считаться автоматически. Ну теперь можно вводить задачи? Опять нет, изменения делятся на этапы, и сначала нужно ввести их, например:

1. Инициирование – здесь вы доказываете окружающим, что изменение всем нужно.
2. Анализ или обследование текущей ситуации – здесь вы понимаете, где вы находитесь; не то, чтобы вы раньше этого совсем не знали, но погружение до деталей, которые важны для реализации именно вашего изменения порой даёт неожиданные результаты.
3. Дизайн или проектирование целевого решения – здесь вы детализируете видение до уровня процессов, которые, в свою очередь, имеют детализацию до документов, функций и ролей.
4. Разработка / настройка – подготовка к переходу в целевое состояние; если это ИТ, то нужно доработать и настроить системы (а также задокументировать их), в случае организационных изменений, как правило нужно разработать стандарты или регламенты.
5. Подготовка к старту: для ИТ здесь происходит миграция данных и тестирование, во всех случаях происходит обучение людей.
6. Опытная или опытно-промышленная эксплуатация или "обкатка" изменений на тестовых или реальных данных соответственно.
7. Закрытие проекта или подведение итогов изменения – здесь нужно поставить точку, достигли мы целей (реализовали целевое видение) или нет (и почему).

Как выглядит процесс планирования?

1. Руководитель проекта (РП) выписывает задачи, указывает последовательность, так называемая технологическая последовательность работ. Например, без утверждённого дизайна приступать к разработке не стоит. Далее руководитель проекта отправляет работы на оценку – но это также не задачи конкретных исполнителей, а более крупные части, например, "Разработать Дизайн решения", "Согласовать дизайн решения".
2. Оценщики, как правило, это руководители направлений с опытом выполнения этих работ, указывают длительность по каждой работе.
3. РП собирает оценки и умножает их на три. Почему на три? Потому что, как правило, оценщики указывают чистое время появления первой версии (также именуемой первый драфт), который ещё нужно согласовать с кучей людей, доработать / протестировать, и только потом можно нести к заказчику. В условиях давления со стороны заказчика умножать на три нелегко, поэтому вам понадобятся смелые РП. Далее РП вводит оценки в программу планирования (те самые MS Project / OpenProject) и получает даты, когда данное изменение может быть реализовано – смотрим на верхнюю строку плана.

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