УСТАВ НЕБОЛЬШОГО ПРОЕКТА Наименование и описание проекта (что мы под проектом имеем ввиду?). Проект по восстановлению удовлетворения клиентов. За последние месяцы, Департамент качества выявил, что разместить заказ на оборудование для клиента на нашем портале занимает вчетверо больше времени, чем у конкурентов. Цель проекта - разобраться в причинах проблемы, предложить решение. Разработка и имплементация решения будет рассматриваться как отдельный проект. Также, у Департамента качества наготове документация по их изысканиям, она будет использована для анализа текущего проекта. Менеджер проекта и уровень полномочий (кто назначен рулить проектом, и может ли он определять, управлять, утверждать изменения в бюджет, расписание, и команду?). Василий П. будет менеджером этого проекта, и он будет вправе подбирать участников команды, определять финальный бюджет и расписание. Бизнес-кейс (зачем проект затеян? какими финансовыми или иными профитами он обусловлен? излагаем цель и обоснование проекта). Компания теряет потенциальную выручку, потому что клиенты долго оформляют заказ и иногда бросают оформление на полпути. Также, компания выявила снижение удовлетворенности клиентов, в конкретных цифрах, как результат проблем с системой заказов. Мы ожидаем, что повышение удовлетворенности клиентов приведет к росту выручки за первый год по крайней мере на $200.000, из-за сокращения звонков в поддержку и недооформленных заказов. Бонусом, проект может сгенерить идеи по повышению удовлетворения клиентов через определение того, куда адресовать проблемы с системой заказов. Предварительно назначенные ресурсы (сколько и каких ресурсов будет выделено). Два ИТ аналитика, в связи с их опытом в системах такого рода. Остальные ресурсы определит РМ в ходе планирования. Стейкхолдеры (кто влияет на проект, или на кого повлияет проект). Это John D. из Департамента качества, и Мария Ивановна из Департамента сервиса. Они будут доступны, если на проекте возникнет потребность в них. Известные требования стейкхолдеров (требования, относящиеся как к самому проекту, так и к его содержанию). К данному Уставу прилагаются детальные спецификации на существующую систему, вместе с требованиями, которым она должна соответствовать. Предполагаем, что проект не изменит существующей системы, но даст рекомендации к ее улучшению. Проект будет использовать данные от Департамента качества. Описание продукта, комплект поставки (что мы хотим получить, что будет результатом проекта). Промежуточные результаты будут включать: 1. Детальный бизнес-процесс размещения заказа 2. Анализ времени, нужного для завершения каждого шага заказа 3. Рекомендованные изменения 4. Оценочное время и цена предложенных изменений 5. ИСР 6. Список рисков Финальным результатом будет отчет, что мы можем изменить, сколько это будет стоить, на сколько мы уменьшим оформление заказа, и какую работу надо провести для имплементации решения. Высокоуровневые предположения (в справедливости чего мы уверены в текущей ситуации?). 1. существующие требования к системе заказов (кроме требований именно к скорости) позволяют разработать систему заказов вчетверо быстрее нашей 2. в софт можно вносить доработки 3. не понадобится нового hardware 4. у имеющихся экспертов предметной области и разработчиков есть опыт, чтобы они могли оценить проблему и рекомендовать решение Высокоуровневые ограничения (что ограничивает наши возможности в поставке продукта? внутри каких границ или параметров будет работать проект?). 1. ИСР надо сделать за две недели 2. Реестр рисков за три недели 3. Содержание проекта ограничено выявлением решения, которое позволит размещать заказы быстрее Измеримые цели проекта (как проект сочетается со стратегическими целями компании? какие цели проекта поддержат их? цели должны быть измеримы; они могут влиять на определенные ограничения проекта). Цель проекта - разработать решение, которое поднимет удовлетворенность клиентов до 95%, и сократит время размещения заказа до 25% от текущего. Содержание и удовлетворение клиента - это важнейшие задачи проекта, следом за ними идет "влезть в бюджет и расписание". 1. финальная дата не позднее 01/06/2019 2. предварительно согласован бюджет $50k Требования к утверждению проекта (что нужно зааппрувить для проекта, у кого на это право?). На проекте будут утверждаться: 1. спонсоры утверждают ИСР до начала планирования 2. спонсоры утверждают список рисков до начала планирования 3. спонсоры дают финальное Ок на проект Обзор рисков проекта (угрозы и возможности проекта). 1. возможно выявление новых каналов повышения удовлетворенности клиентов 2. поскольку решение анализируется внутренними специалистами, они могут быть не в курсе всех потенциальных решений 3. результирующее изменений системы заказов может повлиять на бизнес-функцию Критерии выхода из проекта (чего проект должен достичь, чтобы РМ был вправе его закрыть?). Финальный отчет включает описание решения, стоимость доработки, оценку сокращения времени на размещение заказа. Результаты должны быть согласованы Департаментом качества и Клиентским сервисом, в дополнение к команде проекта.
