Применение теории стейкхолдеров при продвижении проектов в интернете

An Example of an External Stakeholder

External stakeholders are a little harder to identify, seeing as they do not have a direct relationship with the company. Instead, an external stakeholder is normally a person or organization affected by the operations of the business. When a company goes over the allowable limit of carbon emissions, for example, the town in which the company is located is considered an external stakeholder because it is affected by the increased pollution.

Conversely, external stakeholders may also sometimes have a direct effect on a company but are not directly tied to it. The government, for example, is an external stakeholder. When it makes policy changes on carbon emissions, continuing from above, the decision affects the operations of any business with increased levels of carbon.

Key Differences

A shareholder can sell their stock and buy different stock; they do not have a long-term need for the company. Stakeholders, however, are bound to the company for a longer term and for reasons of greater need.

For example, if a company is performing poorly financially, the vendors in that company’s supply chain might suffer if the company no longer uses their services. Similarly, employees of the company, who are stakeholders and rely on it for income, might lose their jobs.

Stakeholders and shareholders often have competing interests depending on their relationship with the organization or company.

Составляем и анализируем матрицу стейкхолдеров

Если на предыдущем этапе все сделано правильно – то автоматически в Excel или вручную, на листочке, можно построить матрицу стейкхолдеров и посмотреть, какие шансы есть у вашего проекта.

Матрица, созданная стандартными средствами Excel:

В конце поста вы найдете ссылку на скачивание шаблона матрицы стейкхолдеров.

Анализируем:

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

C правой стороны внизу – те, кто на ход проекта существенного влияния оказать не могут, но самому проекту рады и ждут от него позитивных изменений. Их мы регулярно информируем и поддерживаем интерес, на этапе масштабного внедрения результатов проекта они будут очень значительной боевой силой.

С левой стороны вверху – опасность! Это те товарищи, которые проект крайне не одобряют и готовы сделать все, чтобы его не было. Можно попытаться донести до них все то разумное, доброе и светлое, которое несет ваш проект, но в жизни редко получается (попробуйте объяснить топу, что ему станет хорошо, когда вы внедрите новую систему, которая позволит сократите половину его департамента). Если не получилось (а скорее всего не получилось) – в идеале вывести этого человека и его задачи за скоуп проекта, а если не получится – спрятаться за спину спонсора и оставить взаимодействие с этими товарищами ему. Худший пример в моей практике – это когда тут был принудительно назначенный Заказчик, до сих пор вздрагиваю, вспоминая.

С левой стороны внизу – те, кому проект не нравится, но власти что-то поменять у них нет. Чаще всего это пользователи, не желающие менять устоявшиеся процессы работы. За этой частью нужно активно следить (чтобы не начали чуть-чуть вредить), регулярно информировать (очень кратко)

Поменять отношение в целом можно на нейтральное, если для успеха проекта это критически важно, но потребует множества усилий и времени.

Соответственно, если в матрице половина участников в левой части графика, да еще и в верхней, да еще и спонсор среди них (ну назначили его приказом) – проект можно закрывать и не тратить время, шансов у него все равно нет.

Если все в правой – у вас явно на глазах розовые очки (ну не бывает такого!) и стоит еще раз проверить свой список на предмет того, всех ли вы учли.

Если все теснятся в серединке – придется приложить усилия, но шансы есть. И так далее.

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

Тащить и пытаться подвинуть вправо имеет смысл только «сомневающихся», то есть тех, кто находится в диапазоне +/-3, тут может быть какой-то толк.

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

Нужно больше информации или инструментов для работы со стейкхолдерами? Посмотрите курс по управлению стейкхолдерами от авторов сайта Управление-проектами.РУ. 40+ страниц практики!

Executing the Project

Now you know what a stakeholder is, how to identify and manage them, but that is a process that must be carried through the entire life cycle of the project. You might have missed an important stakeholder in your initial research, and now you have a new person who is integral to the successful completion of the project. Worse, you can’t manage who you don’t know.

Related: Stakeholder vs Shareholder: How They’re Different & Why It Matters

Therefore, it’s important to stay in constant contact with your stakeholders, as we suggested, and not only to know what they want. You can find out if there are new people who are in a position to influence the project. Get to know them, too. Things are always changing, and you have to manage that change or else you threaten the success of the project.

Роль стейкхолдеров в процессах организационного обеспечения проектов[править | править код]

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

Роль стейкхолдеров в управлении портфелем проектовправить | править код

В стандарте ГОСТ Р ИСО/МЭК 12207:2010 (ISO/IEC 12207:2008) отмечено, что в механизме управления изменениями контракта необходимо отразить роли и ответственность руководства, уровень формализации заявок на предложенные изменения и дополнительных переговоров по контракту, а также связи со стейкхолдерами.

В результате успешного управления портфелем проектов:

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

Роль стейкхолдеров в управлении качествомправить | править код

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

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

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

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

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

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

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

Understanding the Role of the Shareholder

A shareholder can be an individual, company, or institution that owns at least one share of a company and therefore has a financial interest in its profitability. For example, a shareholder might be an individual investor who is hoping the stock price will increase because it is part of their retirement portfolio. Shareholders have the right to exercise a vote and to affect the management of a company. Shareholders are owners of the company, but they are not liable for the company’s debts. For private companies, sole proprietorships, and partnerships, the owners are liable for the company’s debts. A sole proprietorship is an unincorporated business with a single owner who pays personal income tax on profits earned from the business. 

Литература[править | править код]

• Kossiakoff A., Sweet W. N., Seymour S. J., Biemer S. M. Systems Engineering Principles and Practice. — 2-е изд. — Hoboken, New Jersey: A John Wiley & Sons, 2011. — 599 с. — ISBN 978-0-470-40548-2.
• Руководство к Cводу знаний по управлению проектами (Руководство PMBOK). — 5-е изд. — Pennsylvania: Project Management Institute, Inc., 2013. — 614 с. — ISBN 978-1-62825-008-4.
• ISO/IEC/IEEE 15288:2015 Systems and software engineering — System life cycle processes
• ГОСТ Р ИСО/МЭК 9126-1 Программная инженерия — Качество программного продукта — Часть 1: Модель качества (см. ISO/IEC 9126-1:2001 Software Engineering — Product quality — Part 1: Quality model)
• ГОСТ Р ИСО/МЭК 25030 Программная инженерия — Требования и оценка качества программных продуктов — Требования к качеству (см. ISO/IEC 25030:2007 Software Engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality Requirements)
• ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств (см. ISO/IEC 12207:2008)
• ISO/IEC 29148:2011 Systems and software engineering — Life cycle processes — Requirements engineering
• ISO/IEC 42010:2011 System and software engineering — Architecture description, см. также ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011 Системная и программная инженерия. Описание архитектуры

Литература

• Kossiakoff A., Sweet W. N., Seymour S. J., Biemer S. M. Systems Engineering Principles and Practice. — 2-е изд. — Hoboken, New Jersey: A John Wiley & Sons, 2011. — 599 с. — ISBN 978-0-470-40548-2.
• Руководство к Cводу знаний по управлению проектами (Руководство PMBOK). — 5-е изд. — Pennsylvania: Project Management Institute, Inc., 2013. — 614 с. — ISBN 978-1-62825-008-4.
• ГОСТ Р ИСО/МЭК 15288-2005 Информационная технология. Системная инженерия. Процессы жизненного цикла систем (см. ISO/IEC 15288:2008)
• ГОСТ Р ИСО/МЭК 9126-1 Программная инженерия — Качество программного продукта — Часть 1: Модель качества (см. ISO/IEC 9126-1:2001 Software Engineering — Product quality — Part 1: Quality model)
• ГОСТ Р ИСО/МЭК 25030 Программная инженерия — Требования и оценка качества программных продуктов — Требования к качеству (см. ISO/IEC 25030:2007 Software Engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality Requirements)
• ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств (см. ISO/IEC 12207:2008)
• ISO/IEC 29148:2011 Systems and software engineering — Life cycle processes — Requirements engineering
• ISO/IEC 42010:2011 System and software engineering — Architecture description

Основные идеи теории стейкхолдеров

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

Теория начала формироваться ещё с 60-х годов. Первое представление заключалось в том, что компания — это система, которая имеет влияние и испытывает его со стороны своего окружения: поставщиков, потребителей, персонала, акционеров и других.

В середине 1970-х, Рассел Акофф продолжил развитие этой теории и предложил расширить количество стейкхолдеров до следующего поколения.

Однако современное представление теории стейкхолдеров сложилось с середины 80-х годов благодаря Эдварду Фримену. Именно его идея заключалась в том, что внутреннее и внешнее представление фирмы — это её заинтересованные стороны, чьи интересы и требования должны быть удовлетворены.

После возникновения теории было разработано два важных стандарта:

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

На данный момент нашей дизайн-студии пока не удалось внедрить данные стандарты в процессы управления, однако мы над этим работаем. Тем не менее в рамках реализации некоторых проектов было взято несколько инструментов, благодаря которым удалось сделать анализ и расставить приоритеты. Расскажем про них поподробнее.

Типы (группы) стейкхолдеров

Исчерпывающего списка типов (групп) стейкхолдеров не существует, так как для различных целевых систем они могут значительно отличаться. Можно привести примеры наиболее распространённых типов (групп) стейкхолдеров, которые упоминаются в стандартах (ГОСТ Р ИСО/МЭК 15288:2005, ISO/IEC 29148:2011, ГОСТ Р ИСО/МЭК 12207:2010, OMG Essence), Своде знаний по системной инженерии (SEBoK) и учебниках по системной инженерии:

• Приобретающая сторона, или покупатель (англ. acquirer) — организация или физическое лицо, которое приобретает или получает (англ. procures) продукт или услугу от поставщика. Приобретающей стороной может быть: покупатель, заказчик, владелец, оптовый покупатель.
• Заказчик, или клиент (англ. customer) — организация или физическое лицо, получающее продукт или услугу.
• Разработчик (англ. developer) — организация или физическое лицо, которое выполняет задачи разработки, включая анализ требований, проектирование, тестирование в течение всего жизненного цикла.
• Поставщик (англ. supplier) — организация или физическое лицо, которое вступает в соглашение с приобретающей стороной на поставку продукта или услуги.
• Пользователь (англ. user) — лицо или группа лиц, извлекающих пользу в процессе применения системы.
• Производитель (англ.  producer) — представитель, ответственный за выполнение работы; лицо, ответственное за выравнивание расписания, бюджета и ограниченность ресурсов, чтобы удовлетворить клиентам.
• Сопровождающая сторона (англ. maintainer) — организация или физическое лицо, выполняющее поддержку системы на одном или нескольких этапах жизненного цикла; организация, которая осуществляет деятельность по сопровождению.
• Ликвидатор (англ. disposer) — организация или физическое лицо, выполняющее ликвидацию (изъятие и списание) рассматриваемой системы и связанных с нею эксплуатационных и поддерживающих служб.
• Аккредитор, или инспектор (англ. accreditor) — организация или физическое лицо, выполняющее проверку системы на соответствие требованиям в процессе сдачи системы в эксплуатацию.
• Регулирующий орган (англ. regulatory bodies) — организация или физическое лицо, проверяющее систему на соответствие требованиям в процессе эксплуатации.
• Остальные — персонал поддержки (англ. supporters), инструкторы (англ. trainers), операторы (англ. operators) и другие.

Special Considerations

The emergence of corporate social responsibility (CSR), a self-regulating business model that helps a company be socially accountable to itself, its stakeholders, and the public, has encouraged companies to take the interests of all stakeholders into consideration. During their decision-making processes, for example, companies might consider their impact on the environment instead of making choices based solely upon the interests of shareholders. The general public is an external stakeholder now considered under CSR governance.

When a company’s operations could increase environmental pollution or take away a green space within a community, for example, the public at large is affected. These decisions may increase shareholder profits, but stakeholders could be impacted negatively. Therefore, CSR encourages corporations to make choices that protect social welfare, often using methods that reach far beyond legal and regulatory requirements.

Key Takeaways

• Shareholders are always stakeholders in a corporation, but stakeholders are not always shareholders.
• Shareholders own part of a public company through shares of stock; a stakeholder wants to see the company prosper for reasons other than stock performance.
• Shareholders don’t need to have a long-term perspective on the company and can sell the stock whenever they need to; stakeholders are often in it for the long haul and have a greater need to see the company prosper.

How ProjectManager.com Helps Stakeholders

Now that you know what a stakeholder is, and you know the importance of keeping them in the loop during the project, ProjectManager.com is here to help make this the start of a beautiful friendship. ProjectManager.com is a cloud-based project management software that provides the bridge between the project and its stakeholders.

High-Level Progress Updates

Stakeholders want data, but they don’t want to get lost in the weeds of a project. Those deep dives are crucial for project managers and their teams, but stakeholders only want the broad strokes. ProjectManager.com has a real-time dashboard that collects information as it’s reported. That data is crunched and displayed in easy-to-read charts and graphs that track six project metrics to keep stakeholders informed on progress.

Roadmaps for Context

The project plan is the roadmap that charts the direction of the project. It’s a critical document and one that is changing throughout the project. Stakeholders will need the project plan to keep the project’s progress in context. Therefore, project managers want an easy-to-share project plan. ProjectManager.com can import and export project plans and share them with anyone. As the project plan changes, just send an updated one to your stakeholders and keep them in the loop.

Detailed Reports for Meetings

Stakeholder presentations run smoothly with ProjectManager.com. While the dashboard gives the big picture, stakeholders often want to get further details. ProjectManager.com has one-click reporting that can generate the reports stakeholders want to see. If they have questions, no problem. The reports can be filtered to show cost management or just the data they want.

Степень учёта и вовлечения стейкхолдеров

Согласно предложениям OMG выделяются 6 состояний, в которых может находиться проект с точки зрения учёта, вовлечения и удовлетворённости стейкхолдеров:

• Признаны (англ. Recognized) — стейкхолдеры были определены.
• Представлены (англ. Represented) — согласованы методы привлечения стейкхолдеров и назначены представители от каждой группы стейкхолдеров.
• Вовлечены (англ. Involved) — представители групп стейкхолдеров принимают активное участие в работе и выполняют свои обязанности.
• В согласии (англ. In agreement) — представители стейкхолдеров находятся в согласии.
• Удовлетворены для развёртывания (внедрения) (англ. Satisfied for deployment) — минимальные ожидания представителей стейкхолдеров были достигнуты.
• Удовлетворены использованием (англ. Satisfied in use) — система удовлетворяет или превышает минимальные ожидания стейкхолдеров.

Для оценки текущего состояния проекта с точки зрения учёта, вовлечения и удовлетворённости стейкхолдеров предлагаются следующие контрольные списки:

Определение стейкхолдеров проекта

Большинство проектных менеджеров знакомы со стейкхолдерами проекта и понимают их значимость. Для тех, кто незнаком с термином «стейкхолдер»: субъект, на который проект оказывает воздействие и который может помочь проекту или разрушить его. В этой области PMBOK Guide (руководство, признанное в качестве стандарта управления проектами – Executive.ru) предлагает следующие рекомендации.

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

В PMBOK Guide определены и описаны следующие группы стейкхолдеров, представленные в каждом проекте:

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

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

Не упускайте из виду стейкхолдеров, препятствующих проекту.

Кроме указанных выше категорий PMBOK Guide упоминает других стейкхолдеров, таких как собственники и инвесторы, продавцы и подрядчики, члены команды и их семей, СМИ и правительственные агентства, физические лица, лоббистские организации и общество в целом.

Я считаю, что такой подход быстро понизит вашу эффективность. Если вы решите включить общество в целом, очень скоро жители Земли станут вашими стейкхолдерами, и придется беспокоиться об очень большом количестве людей. Не стоит доходить до такой крайности. Тем не менее, я попытался изначально создать очень широкую сеть, чтобы убедиться, что ни один значимый стейкхолдер не был упущен из виду. Например, PMBOK Guide должен был включить следующие дополнительные категории стейкхолдеров:

• высшее руководство клиента и исполняющей организации (если таковой является иной субъект),
• отдел руководства программой клиента и исполняющей организации (если таковой является иной субъект),
• функциональное руководство или руководство по управлению ресурсами исполняющей организации,
• вендоры (в случае необходимости подразделяются на подкатегории),
• поставщики,
• конечные пользователи результатов проекта.

На рисунке 6.3 показаны главные категории стейкхолдеров и их связь с проектным менеджером.

Стейкхолдеры проекта

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

<…>

Разработка стратегии взаимодействия с заинтересованными сторонами

Первое, что нужно оформить — это схему стратегии коммуникаций.

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

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

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

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

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

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

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

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

Стоит также упомянуть про одну из главных частей взаимодействия со стейкхолдерами — мониторинг. На протяжении проекта интерес стейкхолдера и его уровень власти на проект могут изменяться неограниченное количество раз.

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

Problems With Stakeholders

A common problem that arises with having numerous stakeholders in an enterprise is their various self interests may not all be aligned. In fact, they may be in direct conflict. The primary goal of a corporation, for example, from the viewpoint of its shareholders, is to maximize profits and enhance shareholder value. Since labor costs are a critical input cost for most companies, a company may seek to keep these costs under tight control. This might have the effect of making another important group of stakeholders, its employees, unhappy. The most efficient companies successfully manage the self-interests and expectations of their stakeholders.

Выводы по внедрению в проект

По завершению проекта мы сделали для себя следующие выводы:

1. Определение стратегии взаимодействия со стейкхолдерами является очень важным элементом управления, который позволяет реализовать проект в полном объёме.
2. Конечный результат и ожидаемый эффект от проекта будут достигнуты в том случае, когда негативное отношение каких-либо стейкхолдеров будет нивелировано вообще, либо когда эта часть заинтересованных сторон останется в явном меньшинстве.
3. Управление стейкхолдерами проекта достаточно сложный процесс, требующий постоянного контроля, потому что ошибка или недостаток внимания к заинтересованным сторонам, может привести к дискредитации проекта и его закрытию.

Каждый проект подходит для того, чтобы в его рамках велась работа с заинтересованными сторонами. Однако, определять объём этой работы вы вольны самостоятельно. Допустим вряд ли есть смысл проводить такую глубокую работу с небольшим региональным проектом. Но представлять, кто его целевая аудитория и как она может повлиять на проект — обязательно. Если вы хотите, чтобы проект был успешен.

Ищите новые инструменты, пользуйтесь менеджментом, социологией и философией. Гарантируем, что там вы найдёте кучу методов для продвижения в digital ваших проектов.