Project scope statement, according to PMI, describes, in detail, the project deliverables and the work required to create those deliverables (PMBOK 4th, p. 115).
В общем-то, понятное и разумное определение понятия Project Scope - описание того, что должно получиться в результате проекта, и того, что будет сделано для достижения этого результата. Однако, далее в расшифровке содержимого этого документа PMI указывает один интересный и важный пункт - Project exclusions, и рекомендует включать его в Project Scope.
Project exclustions generally identifies what is excluded from the project. Explicity stating what is out of scope for the project helps to manage stakeholdes' expectations (PMBOK 4th, p. 115).
Ситуация. Заказчик просит оценить и разработать аналог определенного продукта. Продукт тщательно изучается, составляется многостраничный Project scope, в котором - случайно или намеренно (для уменьшения времени и сложности разработки) отсутствует какой-то пункт, присутствующий в аналоге, на котором заказчик во время встреч не акцентировал внимания. Заказчик подписывает договор, небрежно просматривая приложение в виде технического задания (Project scope).
При сдаче проекта (или ближе к окончанию разработки), чаще всего, задается вопрос - а где же в продукте этот замечательный пункт, который есть в аналоге? Менеджер, имея документированное доказательство того, что продукт выполнен в полном соответствии со спецификацией, начинает переговоры. Которые никогда не закончатся так же хорошо, как если бы изначально заказчик знал, чего ожидать от разработанного продукта.
Вариант 1. Заказчик спорит, что он заказывал аналог, а ему подсунули что-то недоделанное; спецификация неполная, и это ошибка менеджера; отказывается оплачивать незавершенный с его точки зрения продукт. Менеджер уповает на подпись на договоре, тратит время на переговоры и консультации. Хорошо, если вопрос решается без юридического вмешательства.
Вариант 2. Заказчик недовольно соглашается, понимая, что его "подставили". Предлагает доработать продукт, расширив бюджет. Менеджер инициирует новый проект, запрашивает ресурсы для его выполнения, которые, конечно же, уже распланированы на другие проекты. Тратится время, проект затягивается.
Вариант N. Предложите свой.
В любом случае, ни разу в моей практике не случалось, чтобы подобные ситуации заканчивались удовлетворением клиента от работы с подрядчиком, что, с точки зрения PMI, говорит о том, что ни один проект не был завершен успешно.
Я считаю, что в Project scope явно нужно вносить такой пункт, как Project exclusions, и обращать на него внимание клиента, приводя аргументы в защиту своей позиции. По результатам переговоров, возможно, предложенный Scope будет модифицирован и потребует повторной оценки, но клиент будет четко представлять результат работы.
Чем прозрачнее спецификация и описание конечного результата, тем быстрее и проще произойдет сдача проекта. Тем счастливее будет заказчик. А это - не забываем - один из критериев успешного проекта.
P.S. При Agile-подобном процессе разработки Project exlustions можно воспринимать в разрезе спринта.
В общем-то, понятное и разумное определение понятия Project Scope - описание того, что должно получиться в результате проекта, и того, что будет сделано для достижения этого результата. Однако, далее в расшифровке содержимого этого документа PMI указывает один интересный и важный пункт - Project exclusions, и рекомендует включать его в Project Scope.
Project exclustions generally identifies what is excluded from the project. Explicity stating what is out of scope for the project helps to manage stakeholdes' expectations (PMBOK 4th, p. 115).
Ситуация. Заказчик просит оценить и разработать аналог определенного продукта. Продукт тщательно изучается, составляется многостраничный Project scope, в котором - случайно или намеренно (для уменьшения времени и сложности разработки) отсутствует какой-то пункт, присутствующий в аналоге, на котором заказчик во время встреч не акцентировал внимания. Заказчик подписывает договор, небрежно просматривая приложение в виде технического задания (Project scope).
При сдаче проекта (или ближе к окончанию разработки), чаще всего, задается вопрос - а где же в продукте этот замечательный пункт, который есть в аналоге? Менеджер, имея документированное доказательство того, что продукт выполнен в полном соответствии со спецификацией, начинает переговоры. Которые никогда не закончатся так же хорошо, как если бы изначально заказчик знал, чего ожидать от разработанного продукта.
Вариант 1. Заказчик спорит, что он заказывал аналог, а ему подсунули что-то недоделанное; спецификация неполная, и это ошибка менеджера; отказывается оплачивать незавершенный с его точки зрения продукт. Менеджер уповает на подпись на договоре, тратит время на переговоры и консультации. Хорошо, если вопрос решается без юридического вмешательства.
Вариант 2. Заказчик недовольно соглашается, понимая, что его "подставили". Предлагает доработать продукт, расширив бюджет. Менеджер инициирует новый проект, запрашивает ресурсы для его выполнения, которые, конечно же, уже распланированы на другие проекты. Тратится время, проект затягивается.
Вариант N. Предложите свой.
В любом случае, ни разу в моей практике не случалось, чтобы подобные ситуации заканчивались удовлетворением клиента от работы с подрядчиком, что, с точки зрения PMI, говорит о том, что ни один проект не был завершен успешно.
Я считаю, что в Project scope явно нужно вносить такой пункт, как Project exclusions, и обращать на него внимание клиента, приводя аргументы в защиту своей позиции. По результатам переговоров, возможно, предложенный Scope будет модифицирован и потребует повторной оценки, но клиент будет четко представлять результат работы.
Чем прозрачнее спецификация и описание конечного результата, тем быстрее и проще произойдет сдача проекта. Тем счастливее будет заказчик. А это - не забываем - один из критериев успешного проекта.
P.S. При Agile-подобном процессе разработки Project exlustions можно воспринимать в разрезе спринта.
No comments:
Post a Comment