Проектные эксперты
Как я готовлю отчеты по проектам
Данная статья стала победителем конкурса докладов по теме "Как я готовлю отчеты по проектам" на конференции
Международная он-лайн конференция «Управление проектами 2009. Развитие и перспективы»
http://www.bogdanov-associates.com/conference
Автор: М.Г. Якубович
Тренер, бизнес-консультант по вопросам управления проектами, зам. директора по развитию
(г. Минск)
Умение разработать отчетность для руководителя проекта является одним из важнейших навыков: надо уметь понять требования Заказчика и спонсора проекта к структуре отчета, построить систему сбора данных и формирования отчетности о ходе проекта таким образом, чтобы ей было удобно пользоваться сотрудникам проекта и в то же время, создание сводного отчета не было слишком трудозатратным. Понятное дело, что для выполнения последнего требования нужна автоматизация.
В данный момент я управляю тремя проектами одновременно. При чем делаю это в компании, находящейся на нулевом уровне какой ни возьми модели зрелости управления проектами. Компания занимается транспортно-экспедиторскими услугами. Функциональная структура компании не способствует реализации проектов, т.к. сотрудники, назначенные высшим руководством в проект, работают в нем по остаточному принципу – в первую очередь работают над задачами отдела, а если остается время – над проектом. Стандартизированных требований к форме отчета по проектам в компании нет, потому я сам предлагаю форму Заказчикам проекта. Естественно стандартная форма подходит не всем Заказчикам и для многих проектов по ходу проекта эта форма меняется – Заказчик начинает понимать, что ему надо от отчета по проекту.
Итак, к моим текущим проектам.
Для управления всеми проектами я использовал информационную систему, построенную на базе продуктов Microsoft Project Server и SharePoint. На сервере проектов располагаются Project-файлы каждого проекта, а на SharePoint – порталы проектов.
Содержание первого проекта – разработка и внедрение информационной системы автоматизации оперативной деятельности на баз е платформы 1С 8.0. Сегодня функционал этой системы включает лишь оперативный контур, но в ближайшее время вполне может быть принято решение о расширении функционала – включении в информационную систему модуля финансового учета, модуля продаж и маркетинга, модуля управления персоналом и тд. Но это будет уже другой проект.
Сбор требований к программе я осуществляю только в письменном (электронном) виде – это первое что я изменил в проекте, в котором я стал третьим по счету руководителем проекта. Для хранения всех требований и постановки задач программисту используется функционал SharePoint, имеющийся в списке Вопросы. Одно требование – один вопрос, которому присваивается атрибут приоритетности (важный, средняя, низкая), статус (активен, проработка, закрыт), фамилия постановщика, и к вопросу приаттачивается файл с описанием постановки. Программист моментально после размещения нового вопроса на портале проекта получает сообщение в почту о новом вопросе и если у него возникает сомнение по приоритетам, звонит мне и уточняет какая задача для него приоритетнее на данный момент. В данном проекте мы ушли от заполнения стандартного тайм-шита – программист счел это не очень удобным (ему приходилось закрывать вопросы в списке Вопросы и потом заполнять тайм-шит, переходя на закладку Задачи в PWA). Поэтому для ускорения вводы данных я добавил в список Вопросы поле Фактические трудозатраты и настроил возможность суммирования значений по данному полю. По окончании работы над задачей он проставляет фактические трудозатраты (это один из атрибутов вопроса), звонит мне и сообщает, в каком релизе выйдут изменения. По выходу нового релиза программист публикует на портале в библиотеке Релизы файл со сведениями о содержании нового релиза. Решение о том, считать задачу выполненной или нет, принимаю я по результатам тестирования. Благодаря такому сбору данных о фактических трудозатратах и выпущенных релизах создание отчета по проекту не представляет для меня никакой сложности – за любой период времени я могу сделать отчет о том, какой функционал появился в ИС и сколько было потрачено времени программистом на создание этого функционала. Т.к. постановки у нас в проекте может делать любой сотрудник компании и высшее руководство не требует данных о потраченном постановщиками на проект времени, то сбор данных по постановкам не ведется. Основные источники данных о прогрессе проекта – документы с информацией о релизах список Вопросы и поле фактические трудозатраты. Форма отчета в Приложении 1.
Второй проект – разработка и внедрение системы сбалансированных показателей. Проектная команда – высшее руководство компании (заместители директоров по функциональным направлениям). Заставить их вести отчеты о фактически трудозатратах не получилось, да и как оказалось, директору компании это не надо. В этом проекте у меня есть план проекта в MS Project, опубликованный на сервере проектов и портал проекта. На портале проекта я храню все результаты проекта, веду опросы и колонку новостей. В силу того, что все продукты проекта являются, по сути, документами и в предметной области проекта я разбираюсь достаточно неплохо, приемку задач у исполнителей я выполняю лично, а потом сдаю результаты работ Заказчику проекта. Прогресс проекта я отмечаю в файле MS Project и на отчет по проекту затрачиваю не более 15 минут за любой период времени. Для этого я смотрю в проджект-план, что было сделано за данный период времени по продуктам проекта и добавляю к отчету возникшие проблемы, которые, как правило, фиксирую на портале в разделе Риски. Форма отчета совпадает с отчетом в первом проекте.
Для работы над третьим проектом, суть которого в переводе бухгалтерского и налогового учета с платформы 1С 7.7 на платформу 1С 8.1, я привлек компанию аутсорсера (1С-франчайзи). Несмотря на то, что в данной компании внедряли управление проектами, в ходе проекта возникли вопросы по сбору данных о фактически выполненном объеме работ. Дело в том, что я не являюсь специалистом в бухгалтерском учете и для проведения приемо-сдаточных работ я привлекаю главных бухгалтеров дочерних компаний, которые мы автоматизируем в проекте. Именно их экспертное мнение о том, какие работы аутсорсера можно считать выполненными является для меня определяющим. В данном проекте Заказчик контролирует ход проекта по участкам бухгалтерского учета, и его не интересует фактически потраченное время на проект, поэтому форма отчетности отличается от предыдущих проектов и представлена в Приложении 2.
Для актуализации данной формы я провожу совещания (иногда это просто беседа по телефону) с главными бухгалтерами, которые рассказывают мне, как обстоит дело по каждому участку учета, а я актуализирую отчет.
Надо сказать, что ни по одному из проектов нареканий у Заказчиков проекта и у проектной группы по системе отчетности нет.
Какие выводы по системе отчетности хочется сделать:
1. Старайтесь на старте проекта выяснить у Заказчика в какой форме он хотел бы получать отчеты. Если он не может Вам внятно изложить требования, предложите ему форму отчета сами, а по ходу проекта он Вам ее скорректирует.
2. Систему сбора данных максимально адаптируйте под исполнителей проекта, заполняющих формы отчетности для Вас (если конечно у компании нет установленных обязательных требований). Да, Вам надо потратить на это какое-то время, но исполнители в ходе проекта будут его тратить гораздо больше, если форма будет неудобная. Заботьтесь о них, даже в таких вещах, кажущихся мелочами и это окупится!
3. Система отчетности связана с системой коммуникаций, планируйте их на старте проекта, создавайте автоматизированные системы сбора данных и обучайте сотрудников использовать их, пусть они не тратят на отчеты много времени - ведь для них это непроизводительная деятельность!
4. Не «зарывайте проблемы под ковер». Излагайте их в отчете по проекту и предлагайте решения, если еще не приступили к корректирующим действиям.
5. На старте проекта утвердите у Заказчика процедуру управления изменениями и активно используйте ее, если что-то идет не по плану!
Удачи Вам в проектах!
В приложении - формы отчетов
Международная он-лайн конференция «Управление проектами 2009. Развитие и перспективы»
http://www.bogdanov-associates.com/conference
Автор: М.Г. Якубович
Тренер, бизнес-консультант по вопросам управления проектами, зам. директора по развитию
(г. Минск)
Умение разработать отчетность для руководителя проекта является одним из важнейших навыков: надо уметь понять требования Заказчика и спонсора проекта к структуре отчета, построить систему сбора данных и формирования отчетности о ходе проекта таким образом, чтобы ей было удобно пользоваться сотрудникам проекта и в то же время, создание сводного отчета не было слишком трудозатратным. Понятное дело, что для выполнения последнего требования нужна автоматизация.
В данный момент я управляю тремя проектами одновременно. При чем делаю это в компании, находящейся на нулевом уровне какой ни возьми модели зрелости управления проектами. Компания занимается транспортно-экспедиторскими услугами. Функциональная структура компании не способствует реализации проектов, т.к. сотрудники, назначенные высшим руководством в проект, работают в нем по остаточному принципу – в первую очередь работают над задачами отдела, а если остается время – над проектом. Стандартизированных требований к форме отчета по проектам в компании нет, потому я сам предлагаю форму Заказчикам проекта. Естественно стандартная форма подходит не всем Заказчикам и для многих проектов по ходу проекта эта форма меняется – Заказчик начинает понимать, что ему надо от отчета по проекту.
Итак, к моим текущим проектам.
Для управления всеми проектами я использовал информационную систему, построенную на базе продуктов Microsoft Project Server и SharePoint. На сервере проектов располагаются Project-файлы каждого проекта, а на SharePoint – порталы проектов.
Содержание первого проекта – разработка и внедрение информационной системы автоматизации оперативной деятельности на баз е платформы 1С 8.0. Сегодня функционал этой системы включает лишь оперативный контур, но в ближайшее время вполне может быть принято решение о расширении функционала – включении в информационную систему модуля финансового учета, модуля продаж и маркетинга, модуля управления персоналом и тд. Но это будет уже другой проект.
Сбор требований к программе я осуществляю только в письменном (электронном) виде – это первое что я изменил в проекте, в котором я стал третьим по счету руководителем проекта. Для хранения всех требований и постановки задач программисту используется функционал SharePoint, имеющийся в списке Вопросы. Одно требование – один вопрос, которому присваивается атрибут приоритетности (важный, средняя, низкая), статус (активен, проработка, закрыт), фамилия постановщика, и к вопросу приаттачивается файл с описанием постановки. Программист моментально после размещения нового вопроса на портале проекта получает сообщение в почту о новом вопросе и если у него возникает сомнение по приоритетам, звонит мне и уточняет какая задача для него приоритетнее на данный момент. В данном проекте мы ушли от заполнения стандартного тайм-шита – программист счел это не очень удобным (ему приходилось закрывать вопросы в списке Вопросы и потом заполнять тайм-шит, переходя на закладку Задачи в PWA). Поэтому для ускорения вводы данных я добавил в список Вопросы поле Фактические трудозатраты и настроил возможность суммирования значений по данному полю. По окончании работы над задачей он проставляет фактические трудозатраты (это один из атрибутов вопроса), звонит мне и сообщает, в каком релизе выйдут изменения. По выходу нового релиза программист публикует на портале в библиотеке Релизы файл со сведениями о содержании нового релиза. Решение о том, считать задачу выполненной или нет, принимаю я по результатам тестирования. Благодаря такому сбору данных о фактических трудозатратах и выпущенных релизах создание отчета по проекту не представляет для меня никакой сложности – за любой период времени я могу сделать отчет о том, какой функционал появился в ИС и сколько было потрачено времени программистом на создание этого функционала. Т.к. постановки у нас в проекте может делать любой сотрудник компании и высшее руководство не требует данных о потраченном постановщиками на проект времени, то сбор данных по постановкам не ведется. Основные источники данных о прогрессе проекта – документы с информацией о релизах список Вопросы и поле фактические трудозатраты. Форма отчета в Приложении 1.
Второй проект – разработка и внедрение системы сбалансированных показателей. Проектная команда – высшее руководство компании (заместители директоров по функциональным направлениям). Заставить их вести отчеты о фактически трудозатратах не получилось, да и как оказалось, директору компании это не надо. В этом проекте у меня есть план проекта в MS Project, опубликованный на сервере проектов и портал проекта. На портале проекта я храню все результаты проекта, веду опросы и колонку новостей. В силу того, что все продукты проекта являются, по сути, документами и в предметной области проекта я разбираюсь достаточно неплохо, приемку задач у исполнителей я выполняю лично, а потом сдаю результаты работ Заказчику проекта. Прогресс проекта я отмечаю в файле MS Project и на отчет по проекту затрачиваю не более 15 минут за любой период времени. Для этого я смотрю в проджект-план, что было сделано за данный период времени по продуктам проекта и добавляю к отчету возникшие проблемы, которые, как правило, фиксирую на портале в разделе Риски. Форма отчета совпадает с отчетом в первом проекте.
Для работы над третьим проектом, суть которого в переводе бухгалтерского и налогового учета с платформы 1С 7.7 на платформу 1С 8.1, я привлек компанию аутсорсера (1С-франчайзи). Несмотря на то, что в данной компании внедряли управление проектами, в ходе проекта возникли вопросы по сбору данных о фактически выполненном объеме работ. Дело в том, что я не являюсь специалистом в бухгалтерском учете и для проведения приемо-сдаточных работ я привлекаю главных бухгалтеров дочерних компаний, которые мы автоматизируем в проекте. Именно их экспертное мнение о том, какие работы аутсорсера можно считать выполненными является для меня определяющим. В данном проекте Заказчик контролирует ход проекта по участкам бухгалтерского учета, и его не интересует фактически потраченное время на проект, поэтому форма отчетности отличается от предыдущих проектов и представлена в Приложении 2.
Для актуализации данной формы я провожу совещания (иногда это просто беседа по телефону) с главными бухгалтерами, которые рассказывают мне, как обстоит дело по каждому участку учета, а я актуализирую отчет.
Надо сказать, что ни по одному из проектов нареканий у Заказчиков проекта и у проектной группы по системе отчетности нет.
Какие выводы по системе отчетности хочется сделать:
1. Старайтесь на старте проекта выяснить у Заказчика в какой форме он хотел бы получать отчеты. Если он не может Вам внятно изложить требования, предложите ему форму отчета сами, а по ходу проекта он Вам ее скорректирует.
2. Систему сбора данных максимально адаптируйте под исполнителей проекта, заполняющих формы отчетности для Вас (если конечно у компании нет установленных обязательных требований). Да, Вам надо потратить на это какое-то время, но исполнители в ходе проекта будут его тратить гораздо больше, если форма будет неудобная. Заботьтесь о них, даже в таких вещах, кажущихся мелочами и это окупится!
3. Система отчетности связана с системой коммуникаций, планируйте их на старте проекта, создавайте автоматизированные системы сбора данных и обучайте сотрудников использовать их, пусть они не тратят на отчеты много времени - ведь для них это непроизводительная деятельность!
4. Не «зарывайте проблемы под ковер». Излагайте их в отчете по проекту и предлагайте решения, если еще не приступили к корректирующим действиям.
5. На старте проекта утвердите у Заказчика процедуру управления изменениями и активно используйте ее, если что-то идет не по плану!
Удачи Вам в проектах!
В приложении - формы отчетов
- Вложения
-
-
Приложение 1.doc, 53 KB
-
© 2009 Created by Константин Тютюнов on Ning. Create a Ning Network!
