Stakeholder best practices for a Splunk deployment
A stakeholder register is a record of anyone in your organization who has an investment in Splunk, from the managers who approved the purchase to the user community who uses Splunk every day.
Creating a stakeholder register is important because it helps you keep track of your Splunk constituents and understand their needs. This can be an important benchmark so you know what to do for which stakeholders, and how to measure their success with Splunk, and ultimately, measure how Splunk helps the overall success of your organization.
- Executive sponsor
- Program manager
- Project manager
For more about these roles, see Roles best practices.
To get started, make a comprehensive list of anyone who may have a stake in Splunk, either directly or indirectly, for example:
- IT and infrastructure team
- Security operations
- Your Splunk team
- Other departments
- Customer-facing organizations
Anyone with an interest in the success of your company or organization is a potential stakeholder, even investors, future employees, and users of your products and services. So although you may not have to manage regular communication with all these stakeholders, you may have occasion to spotlight insights gained through your Splunk use cases to these outside audiences. Accounting for them on your stakeholder register can also remind you of the wide-reaching effects of your work with Splunk.
A stakeholder register should be a living document that you update regularly as people and priorities shift. The register includes sensitive details, such as names, contact information, and management strategies, so keep your register in a secure location with restricted access, and exercise caution when sharing it.
Program managers are responsible for tracking stakeholder goals and making sure they are met. The program manager should create the stakeholder register during customer onboarding and update it regularly.
Guidelines for creating a stakeholder register
At a minimum, the stakeholder register should contain three types of information for each stakeholder:
- General information - name and contact information
- Assessment - needs, expectations, and dependencies on Splunk
- Classification - attributes used to identify types of stakeholders
These are described in more detail in the following sections.
Stakeholder general information
For each stakeholder, capture the following information:
- Contact information
- How they prefer to communicate (for example, email, phone, instant messaging)
- General role and responsibilities in their organization
- Whether they are internal or external to the company
- What version of Splunk they're using (if applicable)
Include a high level evaluation of each stakeholder, for example:
- What they need to know about Splunk
- How often they need communication
- What their expectations of Splunk are
- What influence they have on Splunk projects and activities
- What interest they have in Splunk and what authority they have to influence decisions
This can be in a narrative format, or organized tabularly depending on what tool you use for your stakeholder register.
You can also manage groups of stakeholders by classifying them using various criteria. This resource is flexible; you can use classifications related to Splunk, or initiatives outside of Splunk. Here are some examples:
- Classify stakeholders based on their authority, responsibility, or interest in Splunk, for example, high, medium or low.
- Assign other attributes to stakeholders, such as internal, external, positive, supporter, detractor, neutral, champion, executive sponsor, contract signer, and so on.
Stakeholder management strategy
As an option, you can include stakeholder management strategy information in your stakeholder registry. Management strategy information includes ideas such as how to get users more involved, increase their training knowledge, garner support for expanding Splunk operations and infrastructure, and so on.
Stakeholder register template
Below is a template you can use. The classification segment shown here is just an example. Use whatever classification criteria apply to the stakeholders in your Splunk community.
|Name||Title||Role||Department||Internal/external||Communication preference||Interest in Splunk||Splunk use: High||Med||Low|
Unix profile best practices for a Splunk deployment
This documentation applies to the following versions of Splunk® Success Framework: ssf