воскресенье, 19 октября 2014 г.

Начало проекта

Что надо подготовить перед началом проекта

Устав проекта
В него входит
Описание проекта: бизнес-цели, укрупненные объекты поставки, стратегические цели

Интеграция. Роли и задачи

Во время исполнения проекта:

  • Команда проекта сосредоточенная на исполнении пакетов работ
  • Спонсор на защите проекта от изменений и обеспечении ресурсами
  • Проектный менеджер собирает проект по кусочкам

вторник, 14 октября 2014 г.

lesson learned


http://www.pmbody.com/lesson-learned/
http://www.projectmanagementdocs.com/project-closing-templates/lessons-learned.html

6 Tips For Lessons Learned on Projects

http://www.projectmanager.com/6-tips-lessons-learned-projects.php

Это могут быть кейсы с проблемами

CategoryIssue NameProblem/SuccessImpactRecommendation
Procurement ManagementContract RequirementsThe PM was not fully engaged in the contract process.All requirements were not included in the initial contract award. A contract modification was required which added a week to the project.PM must be fully engaged in all contract processes. This must be communicated to both PM and contract personnel.
Human Resources ManagementAward PlanThere was no plan for providing awards and recognition to team members.Toward the end of the project morale was low among the project team. There was increased conflict and team members were asking to leave the project.The PM should institute and communicate an awards/recognition program for every project.
Scope ManagementScope CreepStakeholders continuously tried adding to the project scope throughout the project lifecycle.The PM did not have a plan for addressing scope creep and allowed some requirements to be added until the sponsor stopped it. Overall project delay of 3 weeks was the result.The PM must have an approval process for any proposed scope changes and communicate this process to all stakeholders.
Quality ManagementBuilding MaterialA process for determining acceptable building material quality was planned into the project.This allowed the project team to work with the contractors to smoothly ensure all materials were of acceptable quality and avoided any re-work and delays associated with substandard material.Always plan quality standards and allowances into the project plan. This helps avoid delays and cost overruns.
Risk ManagementZoning ApprovalA risk was identified that there may be delays in receiving approval from the county zoning board. This was a success because it was identified early and planned for.Impact was minimal because the PM included potential zoning delays into the project schedule.Always consider external impacts on the project cost and schedule. This must be continuous throughout the project lifecycle.

http://www.lessonslearned.ru/lessons-learned-art-of-project-closure

Утверждение изменений

Изменения можно проводить не только через проектного менеджера, но и через управляющий комитет

пятница, 10 октября 2014 г.

Вина и стыд

Не позволяй вине и стыду управлять поступками
Будь ответственным

Характеристики хороших отношений


Реестр заинтересованных лиц


Планы нужны для того чтобы их выполнять

Планы нужны для того чтобы их выполнять

воскресенье, 28 сентября 2014 г.

Риски

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

Можно сделать WBS, но по рискам. Называется RBS.

Коммуникации

1) Спросить у заинтересованных лиц как они хотят получать информацию
2) Спланировать как вы будете получать информацию от заинтересованных лиц
3) Отчеты об исполнении

воскресенье, 14 сентября 2014 г.

Завершение сделки (продажа) = подписание акта по своему воздействию

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

суббота, 13 сентября 2014 г.

Метод освоенного объема. Как померить?

1) Для того чтобы подготовить измерение по этому методу надо спланировать проект для возможности проводить такое измерение

воскресенье, 7 сентября 2014 г.

Контроль изначает измерение


ПУП затраты

В плане управления проектом должно указываться как вы будете управлять затратами

Дневник спортсмена

Если вы хотите что-то улучшить вы ведете дневник как спортсмен. Это же может касаться духовных вещей и управления проектами и управления персоналом

Управление это ежедневная работа

Постоянные действия создают уверенность в завтрашнем дне

Многоязычие это возможность коммуницировать
Многие навыки менеджера расширяют его возможности
Не надо отказываться от каких-то менеджерских задач

воскресенье, 24 августа 2014 г.

KPI оценка сроков

 Индекс выполнения сроков

При планировании страховой сделать все по правильному

Резервы, риски и т.п.

Ошибки при управлении стоимостью

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

В том числе в управлении стоимостью описывается каким образом будет финансироваться проект

пятница, 15 августа 2014 г.

Разница между подтверждением содержания и закрытием проекта (фазы)


Работу надо делать хорошо

Не только программировать надо качественно, но и

1) Собирать требования
2) Описывать требования

согласовывать требования

Всю работу выполненную некачественно придется переделать

Для чего можно использовать WBS

1) Сбор требований
2) Перечень объектов поставки
3) Перечень работ

Не забываем про словарь WBS

Процесс утверждения содержания занимает много времени!


Определение содержания это процесс определения что из требований входит, а что не входит в рамки проекта

кк

Не все требования которые дают заинтересованные лица надо делать

Требования могут быть разные
1) К продукту
2) К порядку выполнения
3) К качеству

И даже к проектному управлению

Порядок сбора требований
1) Определить заинтересованных сторон
2) Собрать требования с заинтересованных сторон. Вариантов сбора требование много...

вторник, 12 августа 2014 г.

В описание содержание проекта

В том числе в него включается "Критерии приемки"

Активы процессов организации

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

Матрица отслеживания требований


5.2.2 Сбор требований: инструменты и методы


5.2.2.1 Интервью
Интервью представляют собой формальный или неформальный подход, используемый для получения информации
у заинтересованных сторон путем прямого разговора с ними. Обычно в ходе интервью задают подготовленные и
непосредственно возникающие вопросы и записывают ответы. Интервью часто проводятся на индивидуальной основе между
интервьюером и интервьюируемым, но иногда в них могут участвовать несколько интервьюеров и/или интервьюируемых.
Проведение интервью с опытными участниками проекта, спонсорами и другими представителями руководства, а также
экспертами по предметной области может помочь в выявлении и определении характеристик и функций желаемых
продуктов (поставляемых результатов). Интервью также помогают в получении конфиденциальной информации.

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

5.2.2.3 Семинары с участием модератора
Семинары с участием модератора (facilitated workshops) представляют собой сфокусированные обсуждения,
объединяющие ключевые заинтересованные стороны с целью определения требований к продукту. Семинары используются
в качестве основного метода, позволяющего быстро определить межфункциональные требования и урегулировать различия
между требованиями заинтересованных сторон. В силу особенностей формата групповой работы, хорошо скоординированные
обсуждения помогают развить доверие, выстроить отношения и наладить общение между участниками, что может привести
к повышению уровня согласия между заинтересованными сторонами. Кроме этого, проблемы могут быть обнаружены и
решены быстрее, чем при индивидуальных обсуждениях.
Например, в области разработки программного обеспечения используются семинары с участием модератора под
названием «Совместная разработка/проектирование приложений» (joint application development/design, JAD). Данные
обсуждения с участием модератора сконцентрированы на том, чтобы собрать вместе бизнес-экспертов по предметной
области и команду разработчиков для улучшения процесса разработки программного продукта. В производственных
отраслях существует «Развертывание функций качества» (quality function deployment, QFD) — это еще один пример семинара
с участием модератора, который помогает определить критически важные характеристики для разработки нового продукта.
QFDначинается со сбора потребностей заказчика, что также называется «мнением заказчика» (voice of the customer, VOC).
Затем данные потребности объективно сортируются и приоритезируются, а также устанавливаются цели для их достижения.
Во время семинаров по требованиям зачастую разрабатываются пользовательские истории — краткие текстовые описания
требуемой функциональности. Пользовательские истории описывают заинтересованную сторону, которая получает пользу
от свойства продукта (роль), что заинтересованной стороне необходимо достичь (цель) и пользу для заинтересованной
стороны (мотивацию). Пользовательские истории широко используются в рамках гибких (agile) методов.

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

5.2.2.5 Методы группового принятия решения
Метод группового принятия решений — это процесс оценки различных альтернатив с ожидаемым результатом в форме
будущих действий. Данные методы могут быть использованы для создания, классификации и приоритезации требований к
продукту.
Существуют различные методы принятия группового решения, например:
•  Единогласие.Принятие решения посредством согласия каждого с единым курсом действий. Один из способов
достижения единогласия — это метод Дельфи, при котором группа выбранных экспертов отвечает на вопросы
анкет, а также высказывает мнение относительно ответов, полученных в течение каждого раунда сбора
требований. Для обеспечения анонимности доступ к ответам имеет только модератор.
•  Большинство.Решение, которое принимается при поддержке более чем 50 % участников группы. Наличие в
группе нечетного количества участников может обеспечить принятие решения и исключить ситуацию равного
количества голосов.
•  Относительное  большинство.Выбирается решение самого большого блока в группе, даже если не достигнуто
большинство голосов. Данный метод обычно используется, когда предлагается более двух вариантов для выбора.
•  Диктатура.Данный метод предполагает, что одно лицо принимает решение за всю группу

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

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

5.2.2.7 Наблюдения
Наблюдения предоставляют непосредственный способ рассмотрения отдельных лиц в окружающей их обстановке,
а также того, как они исполняют свои обязанности или задачи и выполняют процессы. Наблюдения особенно полезны
для детализированных процессов, когда люди, пользующиеся продуктом, не могут или не желают отчетливо изложить
свои требования. Наблюдение также известно как «рабочая тень» (job shadowing). Оно обычно осуществляется внешним
наблюдателем, следящим за тем, как бизнес-эксперт выполняет свою работу. Также наблюдения могут осуществляться
«наблюдателем-участником», который фактически исполняет процесс или процедуру, чтобы узнать, как они выполняются,
и выявить скрытые требования.

5.2.2.8 Прототипы
Прототипирование представляет собой метод получения предварительных отзывов относительно требований путем
предоставления рабочей модели ожидаемого продукта, прежде чем создавать продукт в действительности. Поскольку
прототипы реальны, это позволяет заинтересованным сторонам экспериментировать с моделью конечного продукта, а
не ограничиваться обсуждением абстрактных представлений своих требований. Прототипы поддерживают концепцию
последовательного уточнения в итеративных циклах создания экспериментальных моделей, проведения экспериментов
пользователем, формирования отзывов и пересмотра прототипа. После проведения достаточного числа циклов обратной
связи, требования, полученные с помощью прототипа, оказываются в достаточной мере полными для перехода к
фазе проектирования или создания. Раскадровка (storyboarding) — это метод прототипирования, использующий
последовательность или навигацию в рамках серии изображений или иллюстраций. Раскадровка используется в различных
проектах во многих отраслях, например при создании фильмов, в рекламе, педагогическом проектировании, в проектах
гибкой (agile) разработки и других проектах разработки программного обеспечения. При разработке программного
обеспечения в раскадровке используются экспериментальные модели, чтобы продемонстрировать возможности навигации
по веб-страницам, экранам или другим интерфейсам пользователей.

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

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

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

План управления содержанием

План управления содержанием разъясняет какие требования надо собирать команде проекта.

Определение содержания —процесс разработки подробного описания проекта и продукта.

Реестр заинтересованных сторон (13.1.3.1) = мы обычно берем из организационной структуры


Качественно можно не только программировать

Качественно можно фиксировать требования и писать постановку задачи!!!

Качественно можно не только программировать

Качественно можно фиксировать требования и писать постановку задачи!!!

пятница, 8 августа 2014 г.

Исполнение и измерение

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

Корректирующие действия

Нельзя выполнить корректирующие действия если вы не измеряете текущего состояния

воскресенье, 3 августа 2014 г.

Закрытие проекта

в обычной жизни не так просто определить когда проект закрывается. Кажется что он либо резко отменятся либо тянется бесконечно!!

Формальное закрытие проекта позволяет высвободить ресурсы для следующего проекта

пятница, 1 августа 2014 г.

Инициация проекта

Не забываем про формальное одобрение менеджера проекта
Составление устава проекта
Работ с заинтересованными сторонами
Планирование на верхнем уровне
Индустриальные стандарты
Предыдущие проекты

Важно
1) Понять бизнес цели проекта. Его бизнес-контекст
2) Взаимодействовать со спонсором в соответствии с этими бизнес-целями. Через их призму освещать все отчеты о состоянии.

пятница, 25 июля 2014 г.

Надо прочитать


Как создать отчет о ходе проекта на одной странице?
http://project-management.zis.by/kontrol-proekta/kak-sozdat-otchet-o-hode-proekta-na-odnoj-stranice.html

+ книжка " Управление проектом на одной странице"

вторник, 15 июля 2014 г.

Изученное дата-страницы

07/07/2014 начало (всего 630 страниц)
15/07/2014 50 страниц. Вывод такими темпами - 15 дней
25/07/2014 65 страниц. Вывод такими темпами (за 2 недели 15 страниц) - 2 года
27/072014 80 страниц 3 месяца
03/08/2014 100 страниц 5 месяцев


PMBOOK русский. 13/05/2014 - 105-141 страниц

четверг, 10 июля 2014 г.

Что такое проект. Мысли

Мысли
Проект становится проектом только когда у него появляется дата начала и конца.
У проекта всегда есть расписание и бюджет

Если вы не можете сделать расписание это не может быть проектом

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

Любые запросы и изменения должны рассматриваться с точки зрения проектного треугольника

Результаты проекта надо приспособить к операционной деятельности

Одна из целей управления портфелем проектов это увеличение стоимости портфеля проектов

У проектного менеджера есть право отклонять изменения и требования мешающие достижению целей

Операционные заинтересованные стороны

пятница, 4 июля 2014 г.

Критерии юзабилити

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

Юзабилити

Мир проектировщика
§Пользователи
Мотивы
Задачи
Контексты
Ограничения
§Сценарии
§Wireframes
§Тестирование

Мир заказчика
§Политика
§Вкусовщина (remote photoshop)
§Смена платформы
§Смена протоколов передачи до реализации интерфейса
§Люди
§Внедрение изменений
§Все тормозит!
§
§И еще 20тысяч бессознательных вещей

суббота, 28 июня 2014 г.

Схема разработки обучения в проекте

Пилотный проект

  1. Разработка общей методологии обучения пользователей и управление логистикой проекта:
  2. Диагностика существующих аудиторных практических курсов
  3. Разработка дистанционных теоретических курсов обучения (e-learning)
  4. Инструкция по курсам для персонального использования пользователем в pdf
  5. Обучение и экзамен пользователей по он-лайн курсам  
  6. Сбор обратной связи по удовлетворенности дистанционным обучением пользователей

Мотивационные состояния


Оценка ИТ проектов

http://project-management.zis.by/ocenka-proekta/prostye-metody-ocenki-ob%23emov-rabot-proekta.html

пятница, 27 июня 2014 г.

Нетехнические факторы!!!

75% неудач из-за не технических факторов

Обучение и управление организационными изменениями
Управление организационными изменениями

Обучение конечных пользователей
Результаты на разных стадиях

1) Порядок обучения
2) Создание материалов

Тестирование и обучение?? 

Что такое управление?

Управление - это синхронизация событий производственной деятельности.
Управление - это воздействие на людей для достижения целей.

Эффективность управления это отношения часов на управление к часам на производственную деятельность. Хороший показатель 8%.

Вклад сотрудника в работу

Вопрос не только в эффективности. Вопрос в том сколько часов реально тратится. Коэффициент лени. Коэффициент эффективности.

четверг, 26 июня 2014 г.

Recurring Themes


•Historical Records – need to collect and use for planning, estimating and risk
•Kickoff meetings are important
•Work Breakdown Structures
•Do not introduce benefits that are not stated in requirements
•Needs of all stakeholders should be taken into account during all projects
•Team Members must be involved in project planning
•Project Mangers must be pro-active

среда, 25 июня 2014 г.

Порядок подписания актов у Заказчика

Как правило, акты выполненных работ подписывает Спонсор со стороны Заказчика. Для подписания акта ему необходимо подтверждения что работы были действительно выполнены. Поэтому вместе с актом надо давать некий протокол о подписанный ответственными со стороны Заказчика, о том что эти работы были выполнены