This is not 'how to identify stakeholders'. This is 'how to identify key users and change agents', which is an entirely different question. Stakeholders literally includes everyone who has the...
This is not 'how to identify stakeholders'. This is 'how to identify key users and change agents', which is an entirely different question.
Stakeholders literally includes everyone who has the slightest possibility of being impacted by the project or who has the slightest possibility of impacting the project - to the point of incorporating your competitors and even the wider public community. That doesn't mean you go off and talk to all of them, but it does mean you identify, list, and consider the impacts of and on them.
The article does mention the importance of a well-considered RACI matrix. I'll offer an example, not unlike the message board in the article, of where things go wrong. In the past year, my...
The article does mention the importance of a well-considered RACI matrix.
I'll offer an example, not unlike the message board in the article, of where things go wrong.
In the past year, my (now-former, yay!) employer rolled out ServiceNow for its end-user and internal services support.
A very ambitious manager decided it was going to be all Agile all the way, with a strictly limited budget for consulting on installation only, all configuration to be done in-house, 'cause he's an ITIL expert.
He only defined two groups of key users for Phase I "minimum viable product" UAT - the Level 1 Service Desk and corporate office end users.
So when Phase I rolled out, it lacked crucial features for remote office end users, field support, trainers, infrastructure and network services, DBAs, enterprise applications ...
Moreover, the UI and other design choices in Phase I made subsequent sprints more and more ineffective.
By the time I left, there were:
At least three different 50+ item single-level drop-down menus required to create a basic service ticket;
multiple hidden right-click menus to access crucial functions;
no usable search functions;
no reliable knowledgebase, either internal or external;
two developers still tied up full-time trying to keep up with bugs and requests;
no reliable means to collect meaningful metrics other than first-level service desk ticket closure;
no guardrails on ticket closure or smart logic to guide tickets to the right team;
no way to spawn multiple sub-tasks for complex requests;
still no integration with existing patch/monitor/CMDB tools (all tickets still need manual data entry and deployments);
no updates to the system training created for the Phase I rollout...
And they're about to implement one-click purchasing in Phase II.
Yes, there was a critical need for a new ticketing/purchasing system, the old one was circa 2006.
But generating a reasonable RACI matrix at the outset to identify genuine stakeholders, gathering information (including a systematic evaluation of the works/doesn't work features and evolved UI design from the old system), getting stakeholder buy-in on what the minimum viable feature set should look like... All that would have saved a great deal of time and money.
The crucial error was making the manager responsible for delivering the product share the role of product owner. He got to define the acceptability of his own performance, including the performance metrics, and claimed a win when the product was "delivered on time and under budget". He's now a director, despite having improved no one's satisfaction.
JOIN ME IN BITTERNESS. God I was so incredibly pissed off about that blogging software. It turned me off Drupal for years, even though it wasn't Drupal's fault.
JOIN ME IN BITTERNESS.
God I was so incredibly pissed off about that blogging software. It turned me off Drupal for years, even though it wasn't Drupal's fault.
My point is more that there are stakeholders for whom a RACI matrix is utterly blank. You have people you MUST consider, who are not responsible, accountable, consulted or even informed about...
My point is more that there are stakeholders for whom a RACI matrix is utterly blank. You have people you MUST consider, who are not responsible, accountable, consulted or even informed about anything - yet can still impact or be impacted by a project, and can be a significant source of risk (both positive and negative).
a reasonable RACI matrix at the outset to identify genuine stakeholders
Again you are mixing up the search for key users and change agents with stakeholders - people fuck this up in industry all. the. goddamn. time., where if someone doesn't appear on the list of people who get the project spruiking emails or the weekly status reports they don't exist.
The ones that most often get missed in my experience are potential but not contracted (i.e. no existing relationship) vendors and customers, competitors, and various levels of government. Quite...
The ones that most often get missed in my experience are potential but not contracted (i.e. no existing relationship) vendors and customers, competitors, and various levels of government. Quite often the general population and community are missed as well, but they should be listed as Informed in a RACI.
With thanks to @Algernon_Asimov for excellent wisdom shared.
<squeals immaturely> I'm in print!
<resumes mature facade> You're welcome.
You're also wonderful.
<blushes>
This is not 'how to identify stakeholders'. This is 'how to identify key users and change agents', which is an entirely different question.
Stakeholders literally includes everyone who has the slightest possibility of being impacted by the project or who has the slightest possibility of impacting the project - to the point of incorporating your competitors and even the wider public community. That doesn't mean you go off and talk to all of them, but it does mean you identify, list, and consider the impacts of and on them.
The article does mention the importance of a well-considered RACI matrix.
I'll offer an example, not unlike the message board in the article, of where things go wrong.
In the past year, my (now-former, yay!) employer rolled out ServiceNow for its end-user and internal services support.
A very ambitious manager decided it was going to be all Agile all the way, with a strictly limited budget for consulting on installation only, all configuration to be done in-house, 'cause he's an ITIL expert.
He only defined two groups of key users for Phase I "minimum viable product" UAT - the Level 1 Service Desk and corporate office end users.
So when Phase I rolled out, it lacked crucial features for remote office end users, field support, trainers, infrastructure and network services, DBAs, enterprise applications ...
Moreover, the UI and other design choices in Phase I made subsequent sprints more and more ineffective.
By the time I left, there were:
And they're about to implement one-click purchasing in Phase II.
Yes, there was a critical need for a new ticketing/purchasing system, the old one was circa 2006.
But generating a reasonable RACI matrix at the outset to identify genuine stakeholders, gathering information (including a systematic evaluation of the works/doesn't work features and evolved UI design from the old system), getting stakeholder buy-in on what the minimum viable feature set should look like... All that would have saved a great deal of time and money.
The crucial error was making the manager responsible for delivering the product share the role of product owner. He got to define the acceptability of his own performance, including the performance metrics, and claimed a win when the product was "delivered on time and under budget". He's now a director, despite having improved no one's satisfaction.
Do I sound a little bitter?
JOIN ME IN BITTERNESS.
God I was so incredibly pissed off about that blogging software. It turned me off Drupal for years, even though it wasn't Drupal's fault.
My point is more that there are stakeholders for whom a RACI matrix is utterly blank. You have people you MUST consider, who are not responsible, accountable, consulted or even informed about anything - yet can still impact or be impacted by a project, and can be a significant source of risk (both positive and negative).
Again you are mixing up the search for key users and change agents with stakeholders - people fuck this up in industry all. the. goddamn. time., where if someone doesn't appear on the list of people who get the project spruiking emails or the weekly status reports they don't exist.
Can you describe the people you're mentioning, who don't show up on the RACI matrices you're familiar with?
The ones that most often get missed in my experience are potential but not contracted (i.e. no existing relationship) vendors and customers, competitors, and various levels of government. Quite often the general population and community are missed as well, but they should be listed as Informed in a RACI.