Преодоление периода полураспада (t 1/2): управление решением PPM после реализации

  • Статья

Эта статья является частью нашей коллекции "Из окопов". В ней описывается, как настроить платформу для настройки модели управления для решения управления портфелем проектов (PPM). Он также включает пример плана управления, который можно использовать в качестве отправной точки для настройки собственной стратегии управления.

Чтобы скачать Word версию этой статьи, см. статью Об использовании полураспада (t 1/2): Управление решением PPM, пост-реализация: технический документ.

Дополнительные статьи см. в технических документах "Из окопов".

Победить период полураспада (t 1/2): управление решением PPM, после реализации

Введение

В радиоактивной физике период полураспада (t1/2) — это время, необходимое для того, чтобы количество упало до половины его значения, измеренного в начале периода времени. (Ссылка: https://en.wikipedia.org/wiki/Half-life).

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

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

Что и почему

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

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

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

Области управления

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

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

Примечание.

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

Как правило, существует четыре ключевые области, в которых могут произойти изменения для решения PPM.

Четыре ключевые области изменений для решения PPM: информация, проектирование, инфраструктура и процесс.

Управление информацией

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

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

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

Вторая область, которая должна быть частью плана управления, — это обслуживание "проектирования" развертывания PPM. По мере того как вы продолжите использовать решение, будут возникать запросы на настройку структуры решения. Они могут возникнуть из-за того, что определенная группа хочет изменить способ использования средства или хочет воспользоваться преимуществами новых функций. Классический пример — изменение способа создания отчетов по времени. Возможно, вы выбрали метод %Work Complete, тогда как с добавленным новым отделом может потребоваться переключить его на метод "Количество отработано за период" для интеграции с другими финансовыми решениями. Таким образом, вопрос заключается в том, кто будет оценивать влияние этого изменения на ваше решение и как будут развернуты изменения.

Управление проектированием — это план управления изменениями, влияющими на общую структуру решения PPM.

Управление процессами

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

Например, возьмем сценарий, в котором ваш pmo должен отправлять отчет высшему руководству каждую среду. Возможно, вы настроили процесс, чтобы убедиться, что расписания отправляются каждую пятницу к определенному времени, и все вы руководители проектов обновляют и публикуют свои планы проектов к понедельнику утра, прежде чем произойдет отчетность. Теперь предположим, что высшее руководство просит отчеты, которые будут отправлены в понедельник, а не каждую среду. Это приводит к изменению процесса использования решения PPM, а не к изменению структуры самого решения PPM.

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

Управление инфраструктурой

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

  • Установка пакетов обновления или накопительных обновлений.

  • Установка новых надстроек или приложений.

  • Обновление инфраструктуры (добавление серверов приложений, веб-серверов и т. д.) для решения проблем с производительностью.

  • Изменения в инфраструктуре из-за изменений в других приложениях в организациях (например, виртуализация всех серверов).

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

Ключевые вопросы

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

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

  • Кто одобряет эти изменения не только с точки зрения рентабельности инвестиций(ROI), но и с точки зрения управления?

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

Команда по управлению

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

Ниже приведен один из способов настройки структуры команды.

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

Центральный комитет по управлению (CGC) Это будет команда лиц, принимающих решения, которые могут утвердить или отклонить рекомендации, сделанные владельцами системы управления. Наличие центрального комитета управления не только помогает уменьшить бюрократию, но и помогает вывести все идеи на общую платформу и оценить их, учитывая друг друга.

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

Другие ключевые компоненты

Некоторые из других ключевых компонентов для успешной стратегии управления включают, помимо прочего, следующие:

  • Решение "Запрос на работу", которое позволяет пользователям запрашивать изменения, функции и функции. Это может быть так же просто, как список SharePoint или используемое в настоящее время решение для запросов на работу.

  • Процесс обработки изменений, который включает в себя проверки из ИТ, управления, CGC и других задействованных бизнес-функций.

  • Процесс фактической реализации изменений. Это может быть простое переход от разработки к тестированию на производственные решения или полноценное Release Management в соответствии со стандартами вашей организации.

Процесс

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

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

Заключение

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

В качестве прощания рассмотрите следующие основные здравые подходы к построению стратегии управления.

  • План управления не обязательно должен быть томом с большим количеством неясной терминологии и языка, которые никто не может использовать в повседневной жизни. Он может быть простым, как лист Excel, с краткими ответами на ключевые вопросы (рассматриваются в разделе Ключевые вопросы).

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

  • План управления должен быть легко реализован и хорошо интегрироваться в существующие процессы организации. Не обязательно изобретать колесо.

  • Поймите, что управление решением PPM — это постоянно развивающийся процесс. Важно не зацикливать на параличе анализа. Начните с малого, добавьте ценность, а затем масштабируйте ее.

Об авторе

Прасанна Адави (PMP, MCTS, MCITP, MCT) — старший консультант по управлению корпоративными проектами (EPM) и тренер, специализирующийся на платформах Microsoft Project, Microsoft Project Server и Microsoft SharePoint. Его main основное внимание уделяется созданию и созданию бизнес-решений, которые помогут организациям достичь максимальной отдачи от своих инвестиций.

Он также имеет обширный опыт в руководстве комплексными проектами в широком спектре областей и вертикали, включая ИТ, ERP (SAP), производство, разработку приложений, автомобилестроение и творческие услуги. Он является постоянным докладчиком на различных мероприятиях Project Server, EPM и SharePoint по всей стране или региону, а также регулярно участник в SharePoint и сообществе EPM.

Празанна является обычным блоггером (https://www.prasannaadavi.com), а также проводит подкаст раз в две недели (https://www.msprojectpodcast.com), в основном посвященный решениям Microsoft Project и Project Server. Прасанна является старшим консультантом EPMA (https://www.epmainc.com).