Планирование не от текущих людей, а от того что требуется для выполнения работы
четверг, 30 июля 2015 г.
среда, 29 июля 2015 г.
Для чего мы повесили в офисе телевизор?
Недавно у нас в смоленском офисе, на самом видно месте, появился большой телевизор. Зачем?
Дело в том, что мы занимаемся разработкой сайтов и хотим выпускать проекты в обещанный в договоре срок. А кто этого не хочет? Хотят все – и студии и заказчики, да вот только получается, что не получается… Заказчик не может своевременно согласовать работу или прислать материалы, у студии в нужный момент перегружены ресурсы и т.д. В результате – невыполнение договора. И самое обидное, что сколько времени не выделяй, все равно не успеешь. Но это не нормально, так не должно быть.
Мы уже давно занимаемся этим вопросом, экспериментируя с разными подходами. И вот он один из них – телевизор. Как он помогает нам выполнять сроки – об этом небольшая история.
Почему важно сдавать проекты в срок?
Основная задача менеджера проектов – уложиться в срок и выделенный бюджет. В сегменте эксклюзивной разработки, где параллельных проектов не много, – эта задача стоит не так остро и решается простым учетом затраченного времени и контролем проекта на всех этапах.
http://habrahabr.ru/company/twins/blog/176805/
четверг, 19 февраля 2015 г.
Люди, которые помогали в Монголии
- Белов
- Дворяк
- Кузнецова Тома
- Слепкова Катя
- Стрыгин Константин
- Буйлин Евгений
- Макаревич
- Масленникова Ксюша
- Фомина Евгения
- Денисова Валентина
- Шакенова Юлия
- Лещенко
- Ванюшкин
- Плюснин
- Патрин
- Колесников
- Поздеев
- Шнелле
- Шестакова Маша
- Дядькина Ирина
- Амосова Марина
- Домашенко Елена
- Шилякин
- Луцкая
- Головко
- Кигинько Дмитрий
- Сазонов Даниил
- Горчинский Николай
- Елезова Ольга
- СИТ!!!
Основные
- Володин
- Гончаров
- Лямин
- Медынский
- Шевцова ИЛ
Conflict
Know the top four sources of conflict:
- schedules,
- project priorities,
- resources,
- and technical opinions.
среда, 18 февраля 2015 г.
воскресенье, 15 февраля 2015 г.
Seven Basic Quality tools
The seven basic quality tools, also known in the industry as 7QC Tools, are used within the context of the PDCA
Cycle to solve quality-related problems. As conceptually illustrated in Figure 8-7, the seven basic quality tools are:
• Cause-and-effect diagrams, which are also known as fishbone diagrams or as Ishikawa diagrams. The
problem statement placed at the head of the fishbone is used as a starting point to trace the problem’s
source back to its actionable root cause. The problem statement typically describes the problem as a gap
Cycle to solve quality-related problems. As conceptually illustrated in Figure 8-7, the seven basic quality tools are:
• Cause-and-effect diagrams, which are also known as fishbone diagrams or as Ishikawa diagrams. The
problem statement placed at the head of the fishbone is used as a starting point to trace the problem’s
source back to its actionable root cause. The problem statement typically describes the problem as a gap
пятница, 13 февраля 2015 г.
How to Attend a Job Interview - Project Management
1) Отношение - покажите ваше отношение, что вам действительно нравится и хочется
2) Приводите примеры из вашей прошлой работы. Инструменты, портфолио, шаблоны того что вы делали, публикации, отзывы клиентов
3) Одежда. Одевайтесь для успеха
4) Проявляйте интерес во время интервью. Подготовьте вопросы заранее
5) Будьте настоящим. Покажите свою силу, покажите свои желания
2) Приводите примеры из вашей прошлой работы. Инструменты, портфолио, шаблоны того что вы делали, публикации, отзывы клиентов
3) Одежда. Одевайтесь для успеха
4) Проявляйте интерес во время интервью. Подготовьте вопросы заранее
5) Будьте настоящим. Покажите свою силу, покажите свои желания
понедельник, 9 февраля 2015 г.
6.6.2.4 resource optimization techniques
resource leveling. Выравнивание ресурсов.
resource Smoothing Сглаживание ресурсов
resource Smoothing Сглаживание ресурсов
воскресенье, 8 февраля 2015 г.
6.3.2.2 dependency determination
- Mandatory dependencies. Обязательные зависимости
- discretionary dependencies/ Дискреционные зависимости «предпочтительной логикой», «предпочитаемой логикой» или «мягкой логикой»
- External dependencies Внешние зависимости
- Internal dependencies Внутренние зависимости
суббота, 7 февраля 2015 г.
5.2.2 collect requirements: tools and techniques
5.2.2.1 Interviews
5.2.2.2 Focus Groups
5.2.2.3 Facilitated Workshops
5.2.2.4 Group creativity techniques
5.2.2.5 Group decision-Making techniques
5.2.2.6 Questionnaires and Surveys
5.2.2.7 observations
5.2.2.8 Prototypes
5.2.2.9 Benchmarking
5.2.2.10 context diagrams
5.2.2.11 document Analysis
5.2.2.2 Focus Groups
5.2.2.3 Facilitated Workshops
5.2.2.4 Group creativity techniques
5.2.2.5 Group decision-Making techniques
5.2.2.6 Questionnaires and Surveys
5.2.2.7 observations
5.2.2.8 Prototypes
5.2.2.9 Benchmarking
5.2.2.10 context diagrams
5.2.2.11 document Analysis
Group decision-Making techniques
• unanimity. A decision that is reached whereby everyone agrees on a single course of action. One way to reach unanimity is the Delphi technique, in which a selected group of experts answers questionnaires and provides feedback regarding the responses from each round of requirements gathering. The responses are only available to the facilitator to maintain anonymity.
• Majority.A decision that is reached with support obtained from more than 50 % of the members of the group. Having a group size with an uneven number of participants can ensure that a decision will be reached, rather than resulting in a tie.
• Plurality. A decision that is reached whereby the largest block in a group decides, even if a majority is not achieved. This method is generally used when the number of options nominated is more than two.
• dictatorship. In this method, one individual makes the decision for the group
• Majority.A decision that is reached with support obtained from more than 50 % of the members of the group. Having a group size with an uneven number of participants can ensure that a decision will be reached, rather than resulting in a tie.
• Plurality. A decision that is reached whereby the largest block in a group decides, even if a majority is not achieved. This method is generally used when the number of options nominated is more than two.
• dictatorship. In this method, one individual makes the decision for the group
Group creativity techniques
• Brainstorming. A technique used to generate and collect multiple ideas related to project and product requirements. Although brainstorming by itself does not include voting or prioritization, it is often used with other group creativity techniques that do.
• nominal group technique.A technique that enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization.
• Idea/mind mapping. A technique in which ideas created through individual brainstorming sessions are consolidated into a single map to reflect commonality and differences in understanding, and generate new ideas.
• Affinity diagram.A technique that allows large numbers of ideas to be classified into groups for review and analysis.
• Multicriteria decision analysis.A technique that utilizes a decision matrix to provide a systematic analytical approach for establishing criteria, such as risk levels, uncertainty, and valuation, to evaluate and rank many ideas.
• nominal group technique.A technique that enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization.
• Idea/mind mapping. A technique in which ideas created through individual brainstorming sessions are consolidated into a single map to reflect commonality and differences in understanding, and generate new ideas.
• Affinity diagram.A technique that allows large numbers of ideas to be classified into groups for review and analysis.
• Multicriteria decision analysis.A technique that utilizes a decision matrix to provide a systematic analytical approach for establishing criteria, such as risk levels, uncertainty, and valuation, to evaluate and rank many ideas.
понедельник, 2 февраля 2015 г.
В чем отличие валидации от верификации?
Валидация - внешний процесс
Верификация - внутренний процесс
http://www.wikiquality.ru/chto-takoe-validaciya-i-verifikaciya-v-chem-otlichie-validacii-ot-verifikacii/
Верификация - внутренний процесс
http://www.wikiquality.ru/chto-takoe-validaciya-i-verifikaciya-v-chem-otlichie-validacii-ot-verifikacii/
How Are Work Performance Information, Data and Reports Related?
http://www.pmexamsmartnotes.com/work-performance-data-information-reports-related/
Hello! If you are looking for the fastest and most effective way to pass your PMP exam, I'm glad you have found this blog! You may want to sign up for PMP Study Blueprint (from the sidebar) and get started the right way.
I invite you to join Facebook community (Like the page), get loads of free sample PMP questions and get notified whenever I post useful lessons, articles, tip or techniques for acing the PMP exam.
Thank you for visiting and hope you find what you are looking for, if you don't, drop me a mail at shiv-at-pmexamsmartnotes-dot-com!
Cheers, Shiv
I invite you to join Facebook community (Like the page), get loads of free sample PMP questions and get notified whenever I post useful lessons, articles, tip or techniques for acing the PMP exam.
Thank you for visiting and hope you find what you are looking for, if you don't, drop me a mail at shiv-at-pmexamsmartnotes-dot-com!
Cheers, Shiv
This is a common point of confusion while preparing for PMP. Here’s a summary of how these stack up.
The flow is as below -
Which means to say that Work Performance Data that goes into a process as input comes out as Work Performance Information. And Work Performance Information that goes into a process comes out as Work Performance Reports.
Work Performance Data is the raw project data, which, when analyzed under a particular project context becomes Work Performance Information. And then Work Performance Information when presented in a suitable manner (tabular, graphical and so on) becomes Work Performance Reports.
Work Performance Data typically contain hard numbers – number of defects, start date of an activity, actual cost and so on.
Since most of the project management processes are executed in a parallel and/or overlapping manner (based on the intricacies of the project) and rarely in a linear fashion. In PMBOK guide 47 processes are described in a linear manner just for the ease of understanding.
When you use Work Performance Data as an input versus Work Performance Information as an input depends on the process being used. Work Performance Data typically is an output of Direct and Manage Project Work – which is nothing but the actual project work. And so this process belongs to Executing process group. Sounds logical, right?
Examples of Work Performance Information are forecasts, status of work packages and so on.
Now, with the same logic, this output should go as input into Monitoring and Controlling processes such as Control Scope, Control Schedule and so on. One can understand this from the Data flow diagram on page 80 of PMBOK-5.
Work Performance Reports are just that – Reports. Weekly status reports, Defect fixing reports, Agile dashboards and so on.
From some of these processes Work Performance Information comes as output and becomes input for Monitor and Control Project Work. And as per above flow diagram it turns into Work Performance Report as output.
And that’s the relationship between Work Performance Data, Work Performance Information and Work Performance Reports.
Scope
Требования являются частью содержания проекта и относятся к группе процессов "Планирование" область знаний "Содержание проекта"
Управление конфигурацией
Это фактически управление документами проекта
Управление документами по продукту и по проекту
Управление документами по продукту и по проекту
Устав проекта
Рита стр 124
Для покупателя устав: сделать какой-то продукт в соответствии с ограничениями
Для продавца: прибыль, возможность получить следующий контракт!!
Проектный менеджер работает со спонсором для формирования Устава проекта
Фактически мы не пишем устав проекта для себя. Т.е. мы не знаем чего мы хотим достичь. А когда мы пишем устав проекта для клиента. Мы достигаем целей клиента. Устав проекта для клиента может писать аналитик. Но не проектный менеджер
Если наш устав направлен на получение прибыли то как должен выглядеть план проекта?
Для покупателя устав: сделать какой-то продукт в соответствии с ограничениями
Для продавца: прибыль, возможность получить следующий контракт!!
Проектный менеджер работает со спонсором для формирования Устава проекта
Фактически мы не пишем устав проекта для себя. Т.е. мы не знаем чего мы хотим достичь. А когда мы пишем устав проекта для клиента. Мы достигаем целей клиента. Устав проекта для клиента может писать аналитик. Но не проектный менеджер
Если наш устав направлен на получение прибыли то как должен выглядеть план проекта?
воскресенье, 1 февраля 2015 г.
Ошибки в определении процессов
Инициация
1) Сбор процессов, исторической информации
2) Создание измеримых целей
Планирование
1) Окончательно подготовить закупочные документы
2) Окончательно подготовить "Как выполнять и контролировать" все части в всех планах
3) Провести стартовую встречу
Исполнение
1) Выполнять аудит качества
2) Оценивать команду и индивидуальное исполнение
3) Награждать команду
4) Использовать лог проблем
Контроль и мониторинг
1) Изменять исполнение в соответствии с метриками в проектном плане
2) Анализировать и оценивать исполнение
3) Управлять конфигурацией
4) Получать одобрение промежуточных результатов от клиента
5) Управлять резервами
Закрытие
1) Подтвердить что работа выполнила все требования
1) Сбор процессов, исторической информации
2) Создание измеримых целей
Планирование
1) Окончательно подготовить закупочные документы
2) Окончательно подготовить "Как выполнять и контролировать" все части в всех планах
3) Провести стартовую встречу
Исполнение
1) Выполнять аудит качества
2) Оценивать команду и индивидуальное исполнение
3) Награждать команду
4) Использовать лог проблем
Контроль и мониторинг
1) Изменять исполнение в соответствии с метриками в проектном плане
2) Анализировать и оценивать исполнение
3) Управлять конфигурацией
4) Получать одобрение промежуточных результатов от клиента
5) Управлять резервами
Закрытие
1) Подтвердить что работа выполнила все требования
суббота, 31 января 2015 г.
Группы процессов
1) Инициация - этап на котором происходит формальное одобрение начала проекта. Для этого предварительно выполняется оценка возможности достижения целей проекта в заданных ограничениях
2) Планирование - формирование BASELINE
3) Исполнение - Работы для выполнения проекта + работы по одобренным запросам на изменение. Фокус этой группы процессов в управлении людьми и выполнении работы в соответствии с планом.
4) Мониторинг и контроль - оценка отклонений от BASELINE и в случае если запросы на изменения изменяют BASELINE то изменение BASELINE и потом передача изменений на этап Исполнение. Одобрение изменений для достижения стратегических целей.
5) Закрытие - формальное закрытие проекта
2) Планирование - формирование BASELINE
3) Исполнение - Работы для выполнения проекта + работы по одобренным запросам на изменение. Фокус этой группы процессов в управлении людьми и выполнении работы в соответствии с планом.
4) Мониторинг и контроль - оценка отклонений от BASELINE и в случае если запросы на изменения изменяют BASELINE то изменение BASELINE и потом передача изменений на этап Исполнение. Одобрение изменений для достижения стратегических целей.
5) Закрытие - формальное закрытие проекта
пятница, 30 января 2015 г.
Презы по областям знаний
Project Management and Framework
https://www.youtube.com/watch?v=1_op0pqwI3QПроекты у клиента
Обычно мы рассматриваем проекты у клиента как проект установки программы. Но часто это можно рассматривать не просто как проект, а как портфель проектов. В данном случае я имею ввиду что помимо установки программы и обучения у клиента часто вместе с проектом идут организационные изменения. Однако этот портфель проектов не управляется как портфель.
Эти проекты (установка программы и орг изменения) обычно не скоординированы.
Эти проекты (установка программы и орг изменения) обычно не скоординированы.
понедельник, 26 января 2015 г.
суббота, 24 января 2015 г.
Управление закупками
Типы контрактов
- Cost reimbursable contract
- Fix price
- Tme&material
https://www.youtube.com/watch?v=u09-s-DGUvc
Ссылки
Словарь по управлению проектами
http://www.pm-glossary.com/pmbok/165--cost-reimbursable-contract-
http://www.pm-glossary.com/pmbok/165--cost-reimbursable-contract-
Подписаться на:
Сообщения (Atom)