Define a Release Management Process for Your Applications to Deliver Lasting Value

Use your releases to drive business value and enhance the benefits delivered by your move to Agile.

Analyst Perspective

Improving your release management strategy and practices is a key step to fully unlock the value of your portfolio.

As firms invest in modern delivery practices based around product ownership, Agile, and DevOps, organizations assume that’s all that is necessary to consistently deliver value. As organizations continue to release, they continue to see challenges delivering applications of sufficient and consistent quality.

Delivering value doesn’t only require good vision, requirements, and technology. It requires a consistent and reliable approach to releasing and delivering products and services to your customer. Reaching this goal requires the definition of standards and criteria to govern release readiness, testing, and deployment.

This will ensure that when you deploy a release it meets the high standards expected by your clients and delivers the value you have intended.

Dr. Suneel Ghei

Principal Research Director, Application Development

Info-Tech Research Group

Executive Summary

Your Challenge

• Your software platforms are a key enabler of your brand. When there are issues releasing, the brand suffers. Client confidence and satisfaction erode.
• Your organization has invested significant capital in creating a culture of product ownership, Agile, and DevOps. Yet the benefits from these investments are not yet fully realized.
• Customers have more choices than ever when it comes to products and services. They require features and capabilities delivered quickly, consistently, and of sufficient quality, otherwise they will look elsewhere.

Common Obstacles

• Development teams are moving faster but then face delays waiting for testing and deployment due to a lack of defined release cycle and process.
• Individual stages in your software development life cycle (SDLC), such as code collaboration, testing, and deployment, have become leaner, but the overall complexity has increased since many products and services are composed of many applications, platforms, and processes.
• The specifics of releasing products is (wrongly) classified as a technical concern and not a business concern, hindering the ability to prioritize improved release practices.

Info-Tech's Approach

• Develop a release management framework that efficiently and effectively orchestrates the different functions supporting a software’s release.
• Use the release management framework and turn release-related activities into non-events.
• Use principles of continuous delivery for converting your release processes from an overarching concern to a feature of a high-performing software practice.

Executive Summary

Info-Tech Insights

Turn release-related activities into non-events.

Eliminate the need for dedicating time for off-hour or weekend release activities. Use a release management framework for optimizing release-related tasks, making them predictable and of high quality.

Release management is NOT a part of the software delivery life cycle.

The release cycle runs parallel to the software delivery life cycle but is not tightly coupled with it. The act of releasing begins at the point requirements are confirmed and ends when user satisfaction is measurable. In contrast, the software delivery life cycle is focused on activities such as building, architecting, and testing.

All releases are NOT created equal.

Barring standard guiding principles, each release may have specific nuances that need to be considered as part of release planning.

Your release management journey

1. Optimize Applications Release Management - Set a baseline release management process and organization.
2. Modernize Your SDLC - Move your organization to Agile and increase throughput to feed releases.
3. Deliver on Your Digital Product Vision - Understand the practices that go into delivering products, including articulating your release plans.
4. Automate Testing to Get More Done - Create the ability to do more testing quickly and ensure test coverage.
5. Implement DevOps Practices That Work - Build in tools and techniques necessary for release deployment automation.
6. Define a Release Management Process to Deliver Lasting Value (We Are Here)

Define a Release Management Process for Your Applications to Deliver Lasting Value

Use your releases to drive business value and enhance the benefits delivered by your move to Agile.

Executive Brief

Your software delivery teams are expected to deliver value to stakeholders in a timely manner and with high quality

Software delivery teams must enable the organization to react to market needs and competitive changes to improve the business’ bottom line. Otherwise, the business will question the team’s competencies.

The business is constantly looking for innovative ways to do their jobs better and they need support from your technical teams.

The increased stress from the business is widening the inefficiencies that already exist in application release management, risking poor product quality and delayed releases.

Being detached from the release process, business stakeholders do not fully understand the complexities and challenges of completing a release, which complicates the team’s communication with them when issues occur.

IT Stakeholders Are Also Not Satisfied With Their Own Throughput

• Only 29% of IT employees find application development throughput highly effective.
• Only 9% of organizations were classified as having highly effective application development throughput.
• Application development throughput ranked 37th out of 45 core IT processes in terms of effectiveness.

(Info-Tech’s Management and Governance Diagnostic, N=3,930)

Your teams, however, struggle with core release issues, resulting in delayed delivery (and disappointed stakeholders)

Implementing tools on top of an inefficient pipeline can significantly magnify the existing release issues. This can lead to missed deadlines, poor product quality, and business distrust with software delivery teams.

COMMON RELEASE ISSUES

1. Local Thinking: Release decisions and changes are made and approved without consideration of the holistic system, process, and organization.
2. No Release Cadence: Lack of process governance and oversight generates unpredictable bottlenecks and load and ill-prepared downstream teams.
3. Mismanagement of Releases: Program management does not accommodate the various integrated releases completed by multiple delivery teams.
4. Poor Scope Management: Teams are struggling to effectively accommodate changes during the project.

The bottom line: The business’ ability to operate is dictated by the software delivery team’s ability to successfully complete releases. If the team performs poorly, then the business will do poorly as well. Application release management is critical to ensure business expectations are within the team’s constraints.

“As software becomes more embedded in the business, firms are discovering that the velocity of business change is now limited by how quickly they can deploy.” – Five Ways To Streamline Release Management, J.S. Hammond

Historically, managing releases has been difficult and complicated…

Typically, application release management has been hard to coordinate because…

• Software has multiple dependencies and coordinating their inclusion into a deployable whole was not planned.
• Teams many be spending too much time on features that are not needed any longer.
• Software development functions (such as application architecture, test-first or test-driven design, source code integration, and functional testing) are not optimized.
• There are no agreed upon service-level contracts (e.g. expected details in requirements, adequate testing, source control strategy) between development functions.
• The different development functions are not integrated in a holistic style.
• The different deployment environments have variability in their configuration, reducing the reliability of testing done in different environments.
• Minimum thresholds for acceptable quality of development functions are either too low (leading to adverse outcomes down stream) or too high (leading to unnecessary delays).

…but research shows being effective at application release management increases your throughput

Research conducted on Info-Tech's members shows overwhelming evidence that application throughput is strongly tied to an effective application release management approach.

(Info-Tech Management & Governance Diagnostic, since 2019; N=684 organizations)

An application release management framework is critical for effective and timely delivery of software

A well-developed application release management framework is transformative and changes...

Info-Tech Insight: Your application release management framework should turn a system release into a non-event. This is only possible through the development of a holistic, low-risk and standardized approach to releasing software, irrespective of their size or complexity.

Robust continuous “anything” requires proficiency in five core practices

A continuous anything evaluation should not be a “one-and-done” event. As part of ongoing improvements, keep evolving it to make it a fundamental component of a strong operational strategy.

Continuous Anything

• Automate where appropriate
  • Automation is not a silver bullet. All processes are not created equal; and therefore, some are not worthy of being automated.
• Control system variables
  • Deploying and testing in environments that are apple to apple in comparison reduces the risk of unintended outcomes from production release.
• Measure process outcomes
  • A process not open to being measured is a process bound to fail. If it can be measured, it should be, and insights found should be used for improving the system.
• Select smaller features batches
  • Smaller release packages reduce the chances of cognitive load associated with finding root causes for defects and issues that may result as post-production incidents.
• Reduction of cycle time
  • Identification of waste in each stage of the continuous anything process helps in lowering cost of operations and results in quicker generation of value for stakeholders.

Invest time in developing an application release management framework for your development team(s) with a continuous anything mindset

An application release management framework converts a set of features and make them ready for releasability in a low-risk, standardized, and high-quality process.

A continuous anything (integration, delivery, and deployment) mindset is based on a growth and improvement philosophy, where every event is considered a valid data point for investigation of process efficiency.

Diagram adapted from Continuous Delivery in the Wild, Pete Hodgson, Published by O'Reilly Media, Inc., 2020

Related Info-Tech Research

Streamline Application Maintenance

• Justify the necessity of streamlined maintenance. Gain a grounded understanding of stakeholder objectives and concerns and validate their achievability against the current state of the people, process, and technologies involved in application maintenance.
• Strengthen triaging and prioritization practices. Obtain a holistic picture of the business and technical impacts, risks, and urgencies of each accepted maintenance request to justify its prioritization and relevance within your backlog. Identify opportunities to bundle requests together or integrate them within project commitments to ensure completion.
• Establish and govern a repeatable process. Develop a maintenance process with well-defined stage gates, quality controls, and roles and responsibilities, and instill development best practices to improve the success of delivery.

“Releasability” (or release criteria) of a system depends upon the inclusion of necessary building blocks and proof that they were worked on

There is no standard definition of a system’s releasability. However, there are common themes around completions or assessments that should be investigated as part of a release:

• The range of performance, technical, or compliance standards that need to be assessed.
• The full range of test types required for business approval: unit tests, acceptance tests, security test, data migration tests, etc.
• The volume-criticality mix of defects the organization is willing to accept as a risk.
• The best source and version control strategy for the development team. This is mostly a function of the team's skill with using release branches and coordinating their work artifacts.
• The addition of monitoring points and measures required for evaluations and impact analysis.
• The documentation required for audit and compliance.
• External and internal dependencies and integrations.
• Validations, approvals, and sign-offs required as part of the business’ operating procedure.
• Processes that are currently carried out outside and should be moved into the pipeline.
• Manual processes that may be automated.
• Any waste activities that do not directly contribute to releasability that can be eliminated from the development process.
• Knowledge the team has regarding challenges and successes with similar software releases in the past.

Releasability of a system is different than governing principles for application release management

Governing principles are fundamental ways of doing something, which in this case is application release management, while releasability will generally have governing principles in addition to specific needs for a successful release.

Example of Governing Principles

• Approval from Senior Director is necessary before releasing to production
• Production deployments can only be done in off-hours
• We will try to automate processes whenever it is possible for us to do so
• We will use a collaborative set of metrics to measure our processes

Examples of Releasability Criteria

• For the upcoming release, add performance testing for Finance and Budget Teams’ APIs
• Audit and compliance documentation is required for this release
• Automation of manual deployment
• Use trunk-based source code management instead of feature-based

Regulated industries are not more stable despite being less nimble

A pervasive myth in industry revolves around the misperception that continuous anything and nimble and non-event application release management is not possible in large bureaucratic and regulated organizations because they are risk-averse.

"We found that external approvals were negatively correlated with lead-time, deployment frequency and restore time, and had no correlation with change failure rate. In short, approval by an external body (such as a manager or Change Approval Board) simply doesn’t work to increase the stability of production systems…However, it certainly slows things down. It is in fact worse than having no change approval process at all." – Accelerate by Gene Kim, Jez Humble, and Nicole Forsgren

Many organizations reduce risk in their product release by adopting a paternalistic stance by:

• Requiring manual sign-offs from senior personnel who are external to the organization.
• Increasing the number and level of authorization gates.
• Staying away from change and preferring to stick with what has worked in the past.

Despite the prevalence of these types of responses to risk, the evidence is that they do not work and are in fact counter-productive because they:

• Create blocks to frequent releases.
• Introduce procedural complexity to each release and in effect make them “bigger.”
• Prefer process over people (and trusting them). Increase non-value-add scrutiny and reporting.

There is a persistent misunderstanding about continuous anything being only an IT engineering practice

01

At the enterprise level, continuous anything focuses on:

• Visibility of final value being provided in a high-quality and expedited manner
• Ensuring efficiency in the organization’s delivery framework
• Ensuring adherence to established governance and risk mitigation strategy

02

Focus of this blueprint

At the product level, continuous anything focuses on:

• Reliability of the product delivery system
• Use of scientific evidence for continuous improvement of the product’s delivery system
• Orchestration of different artifacts into a single whole

03

At the functional level, continuous anything focuses on*:

• Local functional optimization (functions = software engineering, testing, application design)
• Automation of local functions
• Use of patterns for standardizing inputs and functional areas

*Where necessary, practices at this level have been mentioned.

Related Info-Tech Research

Implement DevOps Practices That Work

• Be DevOps, rather than do DevOps. DevOps is a philosophy, not an industry framework. Your organization’s culture must shift toward system-wide thinking, cross-function collaboration, and empathy.
• Culture, learning, automation, integrated teams, and metrics and governance (CLAIM) are all critical components of effective DevOps.

Automate Testing to Get More Done

• Optimize and automate SDLC stages to recover team capacity. Recognize that automation without optimization is a recipe for long-term pain. Do it right the first time.
• Optimization and automation are not one-hit wonders. Technical debt is a part of software systems and never goes away. The only remedy is constant vigilance and enhancements to the processes.

The seeds of a good release are sown even before work on it begins

Pre-release practices such as requirements intake and product backlog management are important because:

• A standard process for documentation of features and requirements helps reduce “cognitive dissonance” between business and technology teams. Clearly articulated and well-understood business needs are fundamental ingredients of a high-quality product.
• Product backlog management done right ensures the prioritized delivery of value to stakeholders. Features can become stale or get a bump in importance, depending upon evolving circumstances. Prioritizing the backlog is, therefore, critical for ensuring time, effort, and budget are spent on things that matter.

Harness Configuration Management Superpowers

Create a configuration management practice that will provide ongoing value to the organization.

EXECUTIVE BRIEF

Analyst Perspective

A robust configuration management database (CMDB) can provide value to the business and superpowers to IT. It's time to invest smartly to reap the rewards.

IT environments are becoming more and more complex, and balancing demands for stability and demands for faster change requires visibility to make the right decisions. IT needs to know their environment intimately. They need to understand dependencies and integrations and feel confident they are making decisions with the most current and accurate view.

Solutions for managing operations rely on the CMDB to bring visibility to issues, calculate impact, and use predictive analytics to fix performance issues before they become major incidents. AIOps solutions need accurate data, but they can also help identify configuration drift and flag changes or anomalies that need investigation.

The days of relying entirely on manual entry and updates are all but gone, as the functionality of a robust configuration management system requires daily updates to provide value. We used to rely on that one hero to make sure information was up to date, but with the volume of changes we see in most environments today, it's time to improve the process and provide superpowers to the entire IT department.

Sandi Conrad, ITIL Managing Professional
Principal Research Director, IT Infrastructure & Operations, Info-Tech Research Group

Executive Summary

Your Challenge

• Build a configuration management database (CMDB): You need to implement a CMDB, populate it with records and relationships, and integrate it with discovery and management tools.
• Identify the benefits of a CMDB: Too many CMDB projects fail because IT tries to collect everything. Base your data model on the desired use cases.
• Define roles and responsibilities: Keeping data accurate and updated is difficult. Identify who will be responsible for helping

Common Obstacles

• Significant process maturity is required: Service configuration management (SCM) requires high maturity in change management, IT asset management, and service catalog practices.
• Large investment: Building a CMDB takes a large amount of effort, process, and expertise.
• Tough business case: Configuration management doesn't directly provide value to the business, but it requires a lot of investment from IT.

Info-Tech's Approach

• Define your scope and objectives: Identify the use cases for SCM and prioritize those objectives into phases.
• Design the CMDB data model: Align with your existing configuration management system's data model.
• Operationalize configuration record updates: Integrate your SCM practice with existing practices and lifecycles.

Start small

Scope creep is a serial killer of configuration management databases and service configuration management practices.

Insight summary

Many vendors are taking a CMDB-first approach to enable IT operations or sometimes asset management. It's important to ensure processes are in place immediately to ensure the data doesn't go stale as additional modules and features are activated.

Define processes early to ensure success

The right mindset is just as important as the right tools. By involving everyone early, you can ensure the right data is captured and validated and you can make maintenance part of the culture. This is critical to reaching early and continual value with a CMDB.

Identify use cases

The initial use case will be the driving force behind the first assessment of return on investment (ROI). If ROI can be realized early, momentum will increase, and the team can build on the initial successes.

If you don't see value in the first year, momentum diminishes and it's possible the project will never see value.

Keep the initial scope small and focused

Discovery can collect a lot of data quickly, and it's possible to be completely overwhelmed early in the process.

Build expertise and troubleshoot issues with a smaller scope, then build out the process.

Minimize customizations

Most CMDBs have classes and attributes defined as defaults. Use of the defaults will enable easier implementation and faster time to value, especially where automations and integrations depend on standard terms for field mapping.

Automate as much as possible

In large, complex environments, the data can quickly become unmanageable. Use automation as much as possible for discovery, dependency mapping, validation, and alerts. Minimize the amount of manual work but ensure everyone is aware of where and how these manual updates need to happen to see continual value.

Configuration management will improve functionality of all surrounding processes

A well-functioning CMDB empowers almost all other IT management and governance practices.

Service configuration management is about:

• Building a system of record about IT services and the components that support those services.
• Continuously reconciling and validating information to ensure data accuracy.
• Ensuring the data lifecycle is defined and well understood and can pass data and process audits.
• Accessing information in a variety of ways to effectively serve IT and the business.

Configuration management most closely impacts these practices

Info-Tech Research Group sees a clear relationship.

When an IT department reports they are highly effective at configuration management, they are much more likely to report they are highly effective at these management and governance processes:

The data is clear

Service configuration management is about more than just doing change management more effectively.

Source: Info-Tech Research Group, IT Management and Governance Diagnostic; N=684 organizations, 2019 to July 2022.

Make the case to use configuration management to improve IT operations

Consider the impact of access to data for informing innovations, optimization efforts, and risk assessments.

75% of Uptime's 2021 survey respondents who had an outage in the past three years said the outage would have been prevented if they'd had better management or processes.(1)

It doesn't have to be that way!

Enterprise-grade IT service management (ITSM) tools require a CMDB for the different modules to work together and to enable IT operations management (ITOM), providing greater visibility.

Decisions about changes can be made with accurate data, not guesses.

The CMDB can give the service desk fast access to helpful information about the impacted components, including a history of similar incidents and resolutions and the relationship between the impacted components and other systems and components.

Turn your team into IT superheroes.

CMDB data makes it easier for IT Ops groups to:

• Avoid change collisions.
• Eliminate poor changes due to lack of visibility into complex systems.
• Identify problematic equipment.
• Troubleshoot incidents.
• Expand the services provided by tier 1 and through automation.

Benefits of configuration management

For IT

• Configuration management will supercharge processes that have relied on inherent knowledge of the IT environment to make decisions.
• IT will more quickly analyze and understand issues and will be positioned to improve and automate issue identification and resolution.
• Increase confidence and reduce risks for decisions involving release and change management with access to accurate data, regardless of the complexity of the environment.
• Reduce or eliminate unplanned work related to poor outcomes due to decisions made with incorrect or incomplete data.

For the Business

• Improve strategic planning for business initiatives involving IT solutions, which may include integrations, development, or security concerns.
• More quickly deploy new solutions or updates due to visibility into complex environments.
• Enable business outcomes with reliable and stable IT systems.
• Reduce disruptions caused by planning without accurate data and improve resolution times for service interruptions.
• Improve access to reporting for budgeting, showbacks, and chargebacks as well as performance metrics.

Measure the value of this blueprint

Fast-track your planning and increase the success of a configuration management program with this blueprint

"The workshop was well run, with good facilitation, and gained participation from even the most difficult parts of the audience. The best part of the experience was that if I were to find myself in the same position in the future, I would repeat the workshop."

– University of Exeter

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

“Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful.”

Guided Implementation

“Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track.”

Workshop

“We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place.”

Consulting

“Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project.”

Diagnostics and consistent frameworks used throughout all four options

Guided Implementation

What does a typical GI on this topic look like?

A Guided Implementation (GI) is a series of calls with an Info-Tech analyst to help implement our best practices in your organization.

A typical GI is between 8 to 12 calls over the course of 4 to 9 months.

Workshop Overview

Contact your account representative for more information.
workshops@infotech.com 1-888-670-8889

Blueprint deliverables

Each step of this blueprint is accompanied by supporting deliverables to help you accomplish your goals:

Configuration Management Project Charter

Detail your approach to building an SCM practice and a CMDB.

Use Cases and Data Worksheet

Capture the action items related to your SCM implementation project.

Configuration Manager Job Description

Use our template for a job posting or internal job description.

Configuration Management Diagram Template Library

Use these diagrams to simplify building your SOP.

Configuration Management Policy

Set expectations for configuration control.

Configuration Management Audit and Validation Checklist

Use this framework to validate controls.

Configuration Control Board Charter

Define the board's responsibilities and meeting protocols.

Key deliverable:

Configuration Management Standard Operating Procedures Template

Outlines SCM roles and responsibilities, the CMDB data model, when records are expected to change, and configuration baselines.

Phase 1

Configuration Management Strategy

This phase will walk you through the following aspects of a configuration management system:

• Scope
• Use Cases
• Reports and Analytics

This phase involves the following participants:

• IT and business service owners
• Business/customer relationship managers
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• SCM project manager
• SCM project sponsor

Harness Service Configuration Management Superpowers

Establish clear definitions

Ensure everyone is using the same terms.

What is a configuration management database (CMDB)?

The CMDB is a system of record of your services and includes a record for everything you need to track to effectively manage your IT services.

Anything that is tracked in your CMDB is called a configuration item (CI). Examples of CIs include:

• User-Facing Services
• IT-Facing Services
• Business Capabilities
• Relationships
• IT Infrastructure Components
• Enterprise Software
• End-User Devices
• Documents

Other systems of record can refer to CIs, such as:

• Ticket database: Tickets can refer to which CI is impacted by an incident or provided as part of a service request.
• Asset management database (AMDB): An IT asset is often also a CI. By associating asset records with CI records, you can leverage your IT asset data in your reporting.
• Financial systems: If done well, the CMDB can supercharge your IT financial cost model.

CMDBs can allow you to:

• Query multiple databases simultaneously (so long as you have the CI name field in each database).
• Build automated workflows and chatbots that interact with data across multiple databases.
• More effectively identify the potential impact of changes and releases.

Do not confuse asset with configuration

Asset and configuration management look at the same world through different lenses

• IT asset management (ITAM) tends to focus on each IT asset in its own right: assignment or ownership, lifecycle, and related financial obligations and entitlements.
• Configuration management is focused on configuration items (CIs) that must be managed to deliver a service and the relationships and integrations with other CIs.
• ITAM and configuration management teams and practices should work closely together. Though asset and configuration management focus on different outcomes, they may use overlapping tools and data sets. Each practice, when working effectively, can strengthen the other.
• Many objects will exist in both the CMDB and AMDB, and the data on those shared objects will need to be kept in sync.

*Discovery, dependency mapping, and data normalization are often features or modules of configuration management, asset management, or IT service management tools.

Start with ITIL 4 guiding principles to make your configuration management project valuable and realistic

Focus on where CMDB data will provide value and ensure the cost of bringing that data in will be reasonable for its purpose. Your end goal should be not just to build a CMDB but to use a CMDB to manage workload and workflows and manage services appropriately.

ITIL 4 guiding principles as described by AXELOS

Step 1.1

Identify use cases and desired benefits for service configuration management

Activities

1.1.1 Brainstorm data collection challenges

1.1.2 Define goals and how you plan to meet them

1.1.3 Brainstorm and prioritize use cases

1.1.4 Identify the data needed to reach your goals

1.1.5 Record required data sources

This step will walk you through the following aspects of a configuration management system:

• Scope
• Use cases

This phase involves the following participants:

• IT and business service owners
• Business/customer relationship managers
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• Project sponsor
• Project manager

Identify potential obstacles in your organization to building and maintaining a CMDB

Often, we see multiple unsuccessful attempts to build out a CMDB, with teams eventually losing faith and going back to spreadsheets. These are common obstacles:

• Significant manual data collection, which is rarely current and fully accurate.
• Multiple discovery solutions creating duplicate records, with no clear path to deduplicate records.
• Manual dependency mapping that isn't accurate because it's not regularly assessed and updated.
• Hybrid cloud and on-premises environment with discovery solutions only partially collecting as the right discovery and dependency mapping solutions aren't in place.
• Dynamic environments (virtual, cloud, or containers) that may exist for a very short time, but no one knows how they should be managed.
• Lack of expertise to maintain and update the CMDB or lack of an assigned owner for the CMDB. If no one owns the process and is assigned as a steward of data, it will not be maintained.
• Database that was designed with other purposes in mind and is heavily customized, making it difficult to use and maintain.

Understanding the challenges to accessing and maintaining quality data will help define the risks created through lack of quality data.

This knowledge can drive buy-in to create a configuration management practice that benefits the organization.

1.1.1 Brainstorm data collection challenges

Involve stakeholders.
Allot 45 minutes for this discussion.

1. As a group, brainstorm the challenges you have with data:
2. Accuracy and trustworthiness: What challenges do you have with getting accurate data on IT services and systems?
   1. Access: Where do you have challenges with getting data to people when they need it?
   2. Manually created data: Where are you relying on data that could be automatically collected?
   3. Data integration: Where do you have issues with integrating data from multiple sources?
   4. Impact: What is the result of these challenges?
3. Group together these challenges into similar issues and identify what goals would help overcome them.
4. Record these challenges in the Configuration Management Project Charter, section 1.2: Project Purpose.

Download the Configuration Management Project Charter

Info-Tech Maturity Ladder

Identify your current and target state

INNOVATOR

• Characteristics of business partner
• Integration with orchestration tools

BUSINESS PARTNER

Data collection and validation is fully automated

Integrated with several IT processes

Meets the needs of IT and business use cases

TRUSTED OPERATOR

• Data collection and validation is partially or fully automated
• Trust in data accuracy is high, meets the needs of several IT use cases

FIREFIGHTER

• Data collection is partially or fully automated, validation is ad hoc
• Trust in data accuracy is variable, used for decision making

UNSTABLE

• Ad hoc or manual data collection and verification process
• Trust in data accuracy is low, and data is not easily or commonly used
• A more detailed assessment can be completed using Info-Tech's Configuration Management Audit and Validation Checklist.

INNOVATOR Characteristics of business partner Integration with orchestration tools BUSINESS PARTNER Data collection and validation is fully automated Integrated with several IT processes Meets the needs of IT and business use cases TRUSTED OPERATOR Data collection and validation is partially or fully automated Trust in data accuracy is high, meets the needs of several IT use cases FIREFIGHTER Data collection is partially or fully automated, validation is ad hoc Trust in data accuracy is variable, used for decision making UNSTABLE Ad hoc or manual data collection and verification process Trust in data accuracy is low, and data is not easily or commonly used A more detailed assessment can be completed using Info-Tech's Configuration Management Audit and Validation Checklist.

Define goals for your CMDB to ensure alignment with all stakeholders

• How are business or IT goals being hindered by not having the right data available?
• If the business isn't currently asking for service-based reporting and accountability, start with IT goals. This will help to develop goals that will be most closely aligned to the IT teams' needs and may help incentivize the right behavior in data maintenance.
• Configuration management succeeds by enabling its stakeholders to achieve their outcomes. Set goals for configuration management based on the most important outcomes expected from this project. Ask your stakeholders:
  1. What are the business' or IT's planned transformational initiatives?
  2. What are your highest priority goals?
  3. What should the priorities of the configuration management practice be?
• The answers to these questions will shape your approach to configuration management. Direct input from your leadership and executives, or their delegates, will help ensure you're setting a solid foundation for your practice.
• Identify which obstacles will need to be overcome to meet these goals.

"[T]he CMDB System should be viewed as a 'system of relevance,' rather than a 'single source of truth.' The burdens of relevance are at once less onerous and far more meaningful in terms of action, analysis, and automation. While 'truth' implies something everlasting or at least stable, relevance suggests a far more dynamic universe."

– CMDB Systems, Making Change Work in the Age of Cloud and Agile, Drogseth et al

Identify stakeholders to discuss what they need from a CMDB; business and IT needs will likely differ

Define your audience to determine who the CMDB will serve and invite them to these conversations. The CMDB can aid the business and IT and can be structured to provide dashboards and reports for both.

Nondiscoverable configuration items will need to be created for both audiences to organize CIs in a way that makes sense for all uses.

Integrations with other systems may be required to meet the needs of your audience. Note integrations for future planning.

1.1.2 Define goals and how you plan to meet them

Involve stakeholders.

Allot 45 minutes for this discussion.

As a group, identify current goals for building and using a CMDB.

Why are we doing this?

• How do you hope to use the data within the CMDB?
• What processes will be improved through use of this data and what are the expected outcomes?

How will we improve the process?

• What processes will be put in place to ensure data integrity?
• What tools will be put in place to improve the methods used to collect and maintain data?

Record these goals in the Configuration Management Project Charter, section 1.3: Project Objectives.

It's easy to think that if you build it, they will come, but CMDBs rarely succeed without solid use cases

Set expectations for your organization that defined and fulfilled use cases will factor into prioritization exercises, functional plans, and project milestones to achieve ROI for your efforts.

A good use case:

• Justifies resource allocation
• Gains funding for the right tools
• Builds stakeholder support
• Drives interest and excitement
• Gains support from anyone in a position to help build out and validate the data
• Helps to define success

In the book CMDB Systems, Making Change Work in the Age of Cloud and Agile, authors Drogseth, Sturm, and Twing describe the secrets of success:

A documented evaluation of CMDB System vendors showed that while most "best case" ROI fell between 6 and 9 months for CMDB deployments, one instance delivered ROI for a significant CMDB investment in as little as 2 weeks!

If there's a simple formula for quick time to value for a CMDB System, it's the following:

Mature levels of process awareness
+ Strong executive level support
+ A ready and willing team with strongly supportive stakeholders
+ Clearly defined and ready phase one use case
+ Carefully selected, appropriate technologies

All this = Powerful early-phase CMDB System results

Define and prioritize use cases for how the CMDB will be used to drive value

The CMDB can support several use cases and may require integration with various modules within the ITSM solution and integration with other systems.

Document the use cases that will drive your CMDB to relevance, including the expected benefits for each use case.

Identify the dependencies that will need to be implemented to be successful.

Define "done" so that once data is entered, verified, and mapped, these use cases can be realized.

"Our consulting experience suggests that more than 75% of all strategic initiatives (CMDB or not) fail to meet at least initial expectations across IT organizations. This is often due more to inflated expectations than categorical failure."

– CMDB Systems, Making Change Work in the Age of Cloud and Agile, Drogseth et al.

After identifying use cases, determine the scope of configuration items required to feed the use cases

On-premises software and equipment will be critical to many use cases as the IT team and partners work on network and data-center equipment, enterprise software, and integrations through various means, including APIs and middleware. Real-time and near real-time data collection and validation will ensure IT can act with confidence.

Cloud use can include software as a service (SaaS) solutions as well as infrastructure and platform as a service (IaaS and PaaS), and this may be more challenging for data collection. Tools must be capable of connecting to cloud environments and feeding the information back into the CMDB. Where on-premises and cloud applications show dependencies, you might need to validate data if multiple discovery and dependency mapping solutions are used to get a complete picture. Tagging will be crucial to making sense of the data as it comes into the CMDB.

In-house developed software would be beneficial to have in the CMDB but may require more manual work to identify and classify once discovered. A combination of discovery and tagging may be beneficial to input and classification.

Highly dynamic environments may require data collection through integration with a variety of solutions to manage and record continuous deployment models and verifications, or they may rely on tags and activity logs to record historical activity. Work with a partner who specializes in CI/CD to help architect this use case.

Containers will require an assessment of the level of detail required. Determine if the container is a CI and if the content will be described as attributes. If there is value to your use case to map the contents of each container as separate CIs within the container CI, then you can map to that level of detail, but don't map to that depth unless the use case calls for it.

Internet of Things (IoT) devices and applications will need to match a use case as well. IoT device asset data will be useful to track within an asset database but may have limited value to add to a CMDB. If there are connections between IoT applications and data warehouses, the dependencies should likely be mapped to ensure continued dataflow.

Out of scope

A single source of data is highly beneficial, but don't make it a catchall for items that are not easily stored in a CMDB.

Source code should be stored in a definitive media library (DML). Code can be linked to the CMDB but is generally too big to store in a CMDB and will reduce performance for data retrieval.

Knowledge articles and maintenance checklists are better suited to a knowledge base. They can also be linked to the CDMB if needed but this can get messy where many-to-many relationships between articles and CIs exist.

Fleet (transportation) assets and fixed assets should be in fleet management systems and accounting systems, respectively. Storing these types of data in the CMDB doesn't provide value to the support process.

1.1.3 Brainstorm and prioritize use cases

Which IT practices will you supercharge?

Focus on improving both operations and strategy.

1. Brainstorm the list of relevant use cases. What do you want to do with the data from the CMDB? Consider:
   1. ITSM management and governance practices
   2. IT operations, vendor orchestration, and service integration and management (SIAM) to improve vendor interactions
   3. IT finance and business service reporting needs
2. Identify which use cases are part of your two- to three-year plan, including the purpose for adding configuration data into that process. Prioritize one or two of these use cases to accomplish in your first year.
3. Identify dependencies to manage as part of the solution and define a realistic timeline for implementing integrations, modules, or data sources.
4. Document this table in the Configuration Management Project Charter, section 2.2: Use Cases.

Determine what additional data will be needed to achieve your use cases

Regardless of which use cases you are planning to fulfill with the CMDB, it is critical to not add data and complexity with the plan of resolving every possible inquiry. Ensure the cost and effort of bringing in the data and maintaining it is justified. The complexity of the environment will impact the complexity of data sources and integrations for discovery and dependency mapping.

Before bringing in new data, consider:

• Is this information available in other maintained databases now?
• Will this data be critical for decision making? If it is nice to have or optional, can it be automatically moved into the database and maintained using existing integrations?
• Is there a cost to bringing the data into the CMDB and maintaining it? Is that cost reasonable for its purpose?
• How frequently will this information be accessed, and can it be updated in an adequate cadence to meet these needs?
• When does this information need to be available?

Info-Tech Insight

If data will be used only occasionally upon request, determine if it will be more efficient to maintain it or to retrieve it from the CMDB or another data source as needed.

Remember, within the data sets, service configuration models can be used for:

• Impact analysis
• Cause and effect analysis
• Risk analysis
• Cost allocation
• Availability analysis and planning

1.1.4 Expand your use cases by identifying the data needed to reach your goals

Involve stakeholders.

Allot 60 minutes for this discussion.

Review use cases and their goals.

Identify what data will be required to meet those goals and determine whether it will be mandatory or optional/nice-to-have information.

Identify sources of data for each type of data. Color code or sort.

Italicize data points that can be automatically discovered.

Gain consensus on what information will be manually entered.

Record the data in the Use Cases and Data Worksheet.

Download the Use Cases and Data Worksheet

Use discovery and dependency mapping tools to automatically update the CMDB

Avoid manual data entry whenever possible.

Consider these features when looking at tools:

• Application dependency mapping: Establishing and tracking the relationships and dependencies between system components, applications, and IT services. The ideal tool will be able to generate maps automatically.
• Agentless and agent discovery: Scanning systems with both agent and agentless approaches. Agent-based scanning provides comprehensive information on applications used in individual endpoints, which is helpful in minimizing its IT footprint. However, agents require endpoint access. Agentless-based scanning provides a broader and holistic view of deployed applications without the need to install an agent on end devices, which can be good enough for inventory awareness.
• Data export capability: Easy exporting of application inventory information to be used in reports and other tools.
• Dashboards and chart visualization: Detailed list of the application inventory, including version number, number of users, licenses, deployment location, and other application details. These details will inform decision makers of each application's health and its candidacy for further rationalization activities.
• Customizable scanning scripts: Tailor your application discovery approach by modifying the scripts used to scan your systems.
• Integration with third-party tools: Easy integration with other systems with out-of-the-box plugins or customizable APIs.

Determine which data collection methods will be used to populate the CMDB

The effort-to-value ratio is an important factor in populating a CMDB. Manual efforts require a higher process focus, more intensive data validation, and a constant need to remind team members to act on every change.

• Determine what amount of effort is appropriate for each data grouping and use case. As decisions are made to expand data within the CMDB, the effort-to-value ratio should always factor in. To be usable, data must be accurate, and every piece of data that needs to be manually entered runs the risk of becoming obsolete.
• Identify which data sources will bring in each type of data. Where there is a possibility of duplicate records being created, one of the data sources will need to be identified as the primary.
• If the decision is to manually enter configuration items early in the process, be aware that automation may create duplicates of the CIs that will need to be deduplicated at some point in the process to make the information more usable.
• Typically, items are discovered, validated, then mapped, but there will be variations depending on the source.
• Active Directory or LDAP may be used to bring users and technicians into the CMDB. Data may be imported from spreadsheets. Identify efforts where data cleanup may have to happen before transferring into the CMDB.
• Identify how often manual imports will need to be conducted to make sure data is usable.

Identify other nondiscoverable data that will need to be added to or accessed by the CMDB

Foundational data, such as technicians, end users and approvers, roles, location, company, agency, department, building, or cost center, may be added to tables that are within or accessed by the CMDB. Work with your vendor to understand structure and where this information resides.

• These records can be imported from CSV files manually, but this will require manual removal or edits as information changes.
• Integration with the HRIS, Active Directory, or LDAP will enable automatic updates through synchronization or scheduled imports.
• If synchronization is fully enabled, new data can be added and removed from the CMDB automatically.
• Identify which nondiscoverable attributes will be needed, such as system criticality, support groups, groups it is managed by, location.
• If partially automating the process, identify where manual updates will need to occur.
• If fully automating the process, notifications will need to be set up when business owner or product or technical owner fields become empty to prompt defining a replacement within the CMDB.
• Determine who will manage these updates.
• Work with your CMDB implementation vendor to determine the best option for bringing this information in.

1.1.5 Record required data sources

Allot 15 minutes for this discussion.

1. Where do you track the work involved in providing services? Typically, your ticket database tracks service requests and incidents. Additional data sources can include:
   • Enterprise resource planning tools for tracking purchase orders
   • Project management information system for tracking tasks
2. What trusted data sources exist for the technology that supports these services? Examples include:
   • Management tools (e.g. Microsoft Endpoint Configuration Manager)
   • Architectural diagrams and network topology diagrams
   • IT asset management database
   • Spreadsheets
   • Other systems of record
3. What other data sources can help you gather the data you identified in activity 1.1.4?
4. Record the relevant data sources for each use case in the Configuration Management Standard Operating Procedures, section 6: Data Collection and Updates.

Info-Tech Insight

Improve the trustworthiness of your CMDB as a system of record by relying on data that is already trusted.

Step 1.2

Define roles and responsibilities

Activities

1.2.1 Record the project team and stakeholders

1.2.2 Complete a RACI chart to define who will be accountable and responsible for configuration tasks

This step will walk you through the following aspects of a configuration management system:

• Roles and responsibilities

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• Project manager

Identify the roles you need in your SCM project

Determine which roles will need to be involved in the initial project and how to source these roles.

Leadership Roles
Oversee the SCM implementation

1. Configuration Manager – The practice owner for SCM. This is a long-term role.
2. Configuration Control Board (CCB) Chair – An optional role that oversees proposed alterations to configuration plans. If a CCB is implemented, this is a long-term role.
3. Project Sponsor or Program Sponsor – Provides the necessary resources for building the CMDB and SCM practices.
4. Architecture Roles
   Plan the program to build strong foundation
   1. Configuration Management Architect – Technical leader who defines the overall CM solution, plans the scope, selects a tool, and leads the technical team that will implement the solution.
   2. Requirements Analyst – Gathers and manages the requirements for CM.
   3. Process Engineer – Defines, documents, and implements the entire process.

Architecture Roles
Plan the program to build strong foundation

1. Configuration Management Architect – Technical leader who defines the overall CM solution, plans the scope, selects a tool, and leads the technical team that will implement the solution.
2. Requirements Analyst – Gathers and manages the requirements for CM.
3. Process Engineer – Defines, documents, and implements the entire process.

Engineer Roles
Implement the system

1. Logical Database Analyst (DBA) – Designs the structure to hold the configuration management data and oversees implementation.
2. Communications and Trainer – Communicates the goals and functions of CM and teaches impacted users the how and why of the process and tools.

Administrative Roles
Permanent roles involving long-term ownership

1. Technical Owner – The system administrator responsible for their system's uptime. These roles usually own the data quality for their system.
2. Configuration Management Integrator – Oversees regular transfer of data into the CMDB.
3. Configuration Management Tool Support – Selects, installs, and maintains the CM tool.
4. Impact Manager – Analyzes configuration data to ensure relationships between CIs are accurate; conducts impact analysis.

1.2.1 Record the project team and stakeholders

Allocate 25 minutes to this discussion.

1. Record the project team.

1. Identify the project manager who will lead this project.
2. Identify key personnel that will need to be involved in design of the configuration management system and processes.
3. Identify where vendors/outsourcers may be required to assist with technical aspects.
4. Document the project team in the Configuration Management Project Charter, section 1.1: Project Team.

2. Record a list of stakeholders.

1. Identify stakeholders internal and external to IT.
2. Build the stakeholder profile. For each stakeholder, identify their role, interest in the project, and influence on project success. You can score these criteria high/medium/low or score them out of ten.
3. If managed service providers will need to be part of the equation, determine who will be the liaison and how they will provide or access data.

Even with full automation, this cannot be a "set it and forget it" project if it is to be successful long-term

Create a team to manage the process and data updates and to ensure data is always usable.

• Services may be added and removed.
• Technology will change as technical debt is reduced.
• Vendors may change as contract needs develop.
• Additional use cases may be introduced by IT and the business as approaches to management evolve.
• AIOps can reduce the level of effort and improve visibility as configuration items change from the baseline and notifications are automated.
• Changes can be checked against requests for changes through automated reconciliations, but changes will still need to be investigated where they do not meet expectations.
• Manual data changes will need to be made regularly and verified.

"We found that everyone wanted information from the CMDB, but no one wanted to pay to maintain it. People pointed to the configuration management team and said, 'It's their responsibility.'

Configuration managers, however, cannot own the data because they have no way of knowing if the data is accurate. They can own the processes related to checking accuracy, but not the data itself."
– Tim Mason, founding director at TRM Associates
(Excerpt from Viewpoint: Focus on CMDB Leadership)

Include these roles in your CMDB practice to ensure continued success and continual improvement

These roles can make up the configuration control board (CCB) to make decisions on major changes to services, data models, processes, or policies. A CCB will be necessary in complex environments.

Configuration Manager

This role is focused on ensuring everyone works together to build the CMDB and keep it up to date. The configuration manager is responsible to:

• Plan and manage the standards, processes, and procedures and communicate all updates to appropriate staff. Focused on continual improvement.
• Plan and manage population of the CMDB and ensure data included meets criteria for cost effectiveness and reasonable effort for the value it brings.
• Validate scope of services and CIs to be included and controlled within the CMDB and manage exceptions.
• Audit data quality to ensure it is valid, is current, and meets defined standards.
• Evaluate and recommend tools to support processes, data collection, and integrations.
• Ensure configuration management processes interface with all other service and business management functions to meet use cases.
• Report on configuration management performance and take appropriate action on process adherence and quality issues.

Configuration Librarian

This role is most important where manual data entry is prevalent and where many nonstandard configurations are in place. The librarian role is often held by the tool administrator. The librarian focuses specifically on data within the CMDB, including:

• Manual updates to configuration data.
• CMDB data verification on a regular schedule.
• Processing ad hoc requests for data.

Product/Service/Technical Owners

The product or technical owner will validate information is correctly updating and reflects the existing data requirements as new systems are provisioned or as existing systems change.

Interfacing Practice Owners

All practice owners, such as change manager, incident manager, or problem manager, must work with the configuration team to ensure data is usable for each of the use cases they are responsible for.

Download the Configuration Manager job description

Assign configuration management responsibilities and accountabilities

Align authority and accountability.

• A RACI exercise will help you discuss and document accountability and responsibility for critical configuration management activities.
• When responsibility and accountability are not well documented, it's often useful to invite a representative of the roles identified to participate in this alignment exercise. The discussion can uncover contrasting views on responsibility and governance, which can help you build a stronger management and governance model.
• The RACI chart can help you identify who should be involved when making changes to a given activity. Clarify the variety of responsibilities assigned to each key role.
• In the future, you may need to define roles in more detail as you change your configuration management procedures.

Responsible: The person who actually gets the job done.
Different roles may be responsible for different aspects of the activity relevant to their role.

Accountable: The one role accountable for the activity (in terms of completion, quality, cost, etc.)
Must have sufficient authority to be held accountable; responsible roles are often accountable to this role.

Consulted: Those who need the opportunity to provide meaningful input at certain points in the activity; typically, subject matter experts or stakeholders. The more people you must consult, the more overhead and time you'll add to a process.

Informed: Those who receive information regarding the task but do not need to provide feedback.
Information might relate to process execution, changes, or quality.

Complete a RACI chart to define who will be accountable and responsible for configuration tasks

Determine what roles will be in place in your organization and who will fulfill them, and create your RACI chart to reflect what makes sense for your organization. Additional roles may be involved where there is complexity.

1.2.2 Complete a RACI chart to define who will be accountable and responsible for configuration tasks

Allot 60 minutes for this discussion.

1. Open the Configuration Management Standard Operating Procedures, section 4.1: Responsibility Matrix. In the RACI chart, review the top row of roles. Smaller organizations may not need a configuration control board, in which case the configuration manager may have more authority.
2. Modify or expand the process tasks in the left column as needed.
3. For each role, identify what that person is responsible for, accountable for, consulted on, or informed of. Fill out each column.
4. Document in the SOP. Schedule a time to share the results with organization leads.
5. Distribute the chart among all teams in your organization.
6. Describe additional roles as needed in the documentation.
7. Add accountabilities and responsibilities for the CCB into the Configuration Control Board Charter.
8. If appropriate, add auxiliary roles to the Configuration Management Standard Operating Procedures, section 4.2: Configuration Management Auxiliary Role Definitions.

Notes:

1. Assign one Accountable for each task.
2. Have one or more Responsible for each task.
3. Avoid generic responsibilities such as "team meetings."
4. Keep your RACI definitions in your documents for quick reference.

Refer back to the RACI chart when building out the communications plan to ensure accountable and responsible team members are on board and consulted and informed people are aware of all changes.

Phase 2

Configuration Management Data Model

This phase will walk you through the following aspects of a configuration management system:

• Data Model
• Customer-Facing and Supporting Services
• Business Capabilities
• Relationships
• IT Infrastructure Components
• Enterprise Software
• End-User Devices
• Documents

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• CM practice manager
• CM project manager

Step 2.1

Build a framework for CIs and relationships

Activities

Document services:

2.1.1 Define and prioritize your services

2.1.2 Test configuration items against existing categories

2.1.3 Create a configuration control board charter to define the board's responsibilities and protocols

This step will walk you through the following aspects of a configuration management system:

• Data model
• Configuration items
• Relationships

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• CM practice manager
• Project manager

Making sense of data daily will be key to maintaining it, starting with services

As CIs are discovered and mapped, they will automatically map to each other based on integrations, APIs, queries, and transactions. However, CIs also need to be mapped to a conceptional model or service to present the service and its many layers in an easily consumable way.

These services will need to be manually created or imported into the CMDB and manually connected to the application services. Services can be mapped to technical or business services or both.

If business services reporting has been requested, talk to the business to develop a list of services that will be required. Use terms the business will be expecting and identify which applications and instances will be mapped to those services.

If IT is using the CMDB to support service usage and reporting, develop the list of IT services and identify which applications and instances will be mapped to those services.

Work with your stakeholders to ensure catalog items make sense to them

There isn't a definitive right or wrong way to define catalog items. For example, the business and IT could both reference application servers, but only IT may need to see technical services broken down by specific locations or device types.

Refer back to your goals and use cases to think through how best to meet those objectives and determine how to categorize your services.

Define the services that will be the top-level, nondiscoverable services, which will group together the CIs that make up the complete service. Identify which application(s) will connect into the technical service.

When you are ready to start discovery, this list of services will be connected to the discovered data to organize it in a way that makes sense for how your stakeholders need to see the data.

While working toward meeting the goals of the first few use cases, you will want to keep the structure simple. Once processes are in place and data is regularly validated, complexities of different service types and names can be integrated into the data.

Define the service types to manage within the CMDB to logically group CIs

Determine which method of service groupings will best serve your audience for your prioritized use cases. This will help to name your service categories. Service types can be added as the CMDB evolves and as the audience changes.

2.1.1 Define and prioritize your services

Prioritize your starting point. If multiple audiences need to be accommodated, work with one group at a time.

Timing: will vary depending on number of services, and starting point

1. Create your list of services, referencing an existing service catalog, business continuity or disaster recovery plan, list of applications, or brainstorming sessions. Use the terminology that makes the most sense for the audience and their reporting requirements.
2. If this list is already in place, assess for relevance and reduce the list to only those services that will be managed through the CMDB.
3. Determine what data will be relevant for each service based on the exercises done in 1.1.4 and 1.1.5. For example, if priority was a required attribute for use case data, ensure each service lists the priority of that service.
4. For each of these, identify the supporting services. These items can come from your technical service catalog or list of systems and software.
5. Document this table in the Use Cases and Data Worksheet, tab 3: Service Catalog.

Service Record Example

Service: Email
Supporting Services: M365, Authentication Services

Service Attributes

Availability: 24/7 (99.999%)
Priority: Critical
Users: All
Used for: Collaboration
Billable: Departmental
Support: Unified Support Model, Account # 123456789

The CMDB will be organized by services and will enable data analysis through multiple categorization schemes

To extract maximum service management benefit from a CMDB, the highest level of CI type should be a service, as demonstrated below. While it is easier to start at the system or single-asset level, taking the service mapping approach will provide you with a useful and dynamic view of your IT environment as it relates to the services you offer, instead of a static inventory of components.

Level 1: Services

• Business Service Offering: A business service is an IT service that supports a business process, or a service that is delivered to business customers. Business service offerings typically are bound by service-level agreements.
• IT Service Offering: An IT service supports the customer's business processes and is made up of people, processes, and technology. IT service offerings typically are bound by service-level agreements.

Level 2: Infrastructure CIs

• IT Component Set: An IT service offering consists of one of more sets of IT components. An IT component set allows you to group or bundle IT components with other components or groupings.
• IT Component: An IT system is composed of one or more supporting components. Many components are shared between multiple IT systems.

Level 3: Supporting CIs

• IT Subcomponent: Any IT asset that is uniquely identifiable and a component of an IT system.
• IT components can have subcomponents, and those components can have subcomponents, etc.

Assess your CMDB's standard category offerings against your environment, with a plan to minimize customization

Standard categorization schemes will allow for easier integration with multiple tools and reporting and improve results if using machine learning to automate categorization. If the CMDB chosen includes structured categories, use that as your starting point and focus only on gaps that are not addressed for CIs unique to your environment.

There is an important distinction between a class and a type. This concept is foundational for your configuration data model, so it is important that you understand it.

• Types are general groupings, and the things within a type will have similarities. For attributes that you want to collect on a type, all children classes and CIs will have those attribute fields.
• Classes are a more specific grouping within a type. All objects within a class will have specific similarities. You can also use subclasses to further differentiate between CIs.
• Individual CIs are individual instances of a class or subclass. All objects in a class will have the same attribute fields and behave the same, although the values of their attributes will likely differ.
• Attributes may be discovered or nondiscoverable and manually added to CIs. The attributes are properties of the CI such as serial number, version, memory, processor speed, or asset tag.

Use inheritance structures to simplify your configuration data model.

Assess the list of classes of configuration items against your requirements

Types are general groupings, and the things within a type will have similarities. Each type will have its own table within the CMDB. Classes within a type are a more specific grouping of configuration items and may include subclasses.

Review your vendor's CMDB documentation. Find the list of CI types or classes. Most CMDBs will have a default set of classes, like this standard list. If you need to build your own, use the table below as a starting point. Define anything required for unique classes. Create a list and consult with your installation partner.

Sample list of classes organized by type

Review relationships to determine which ones will be most appropriate to map your dependencies

Your CMDB should include multiple relationship types. Determine which ones will be most effective for your environment and ensure everyone is trained on how to use them. As CIs are mapped, verify they are correct and only manually map what is incorrect or not mapping through automation.

Manually mapping CMDB relationships may be time consuming and prone to error, but where manual mapping needs to take place, ensure the team has a common view of the dependency types available and what is important to map.

Use automated mapping whenever possible to improve accuracy, provide functional visualizations, and enable dynamic updates as the environment changes.

Where a dependency maps to external providers, determine where it makes sense to discover and map externally provided CIs.

• Only connect where there is value in mapping to vendor-owned systems.
• Only connect where data and connections can be trusted and verified.

Most common dependency mapping types

2.1.2 Test configuration items against existing categories

Time to complete: 1-2 hours

1. Select a service to test.
2. Identify the various components that make up the service, focusing on configuration items, not attributes
3. Categorize configuration items against types and classes in the default settings of the CMDB.
4. Using the default relationships within the CMDB, identify the relationships between the configuration items.
5. Identify types, classes, and relationships that do not fit within the default settings. Determine if there are common terms for these items or determine most appropriate name.
6. Validate these exceptions with the publisher.
7. Document exceptions in the Configuration Management Standard Operating Procedures, Appendix 2: Types and Classes of Configuration Items

2.1.3 Create a configuration control board charter to define the board's responsibilities and protocols

A charter will set the tone for meetings, ensure purpose is defined and meeting cadence is set for regular reviews.

1. Open the Configuration Control Board Charter. Review the document and modify as appropriate for your CCB. This will include:
   • Purpose and mandate of the committee – Reference objectives from the project charter.
   • Team composition – Determine the right mix of team members. A team of six to ten people can provide a good balance between having a variety of opinions and getting work done.
   • Voting option – Determine the right quorum to approve changes.
   • Responsibilities – List responsibilities, starting with RACI chart items.
   • Authority – Define the control board's span of control.
   • Governing laws and regulations – List any regulatory requirements that will need to be met to satisfy your auditors.
   • Meeting preparation – Set expectations to ensure meetings are productive.
2. Distribute the charter to CCB members.

Assess the default list of statuses for each state

Align this list with your CMDB

Minimize the number of customizations that will make it difficult to update the platform.

1. Review the default status list within the tool.
2. Identify which statuses will be most used. Write a definition for each status.
3. Update this list as you update process documentation in Step 3.1. After initial implementation, this list should only be modified through change enablement.
4. Record this list of statuses in the Configuration Management Standard Operating Procedures, Appendix 4: Statuses

Step 2.2

Document statuses, attributes, and data sources

Activities

2.2.1 Follow the packet and map out the in-scope services and data centers

2.2.2 Build data model diagrams

2.2.3 Determine access rights for your data

This step will walk you through the following aspects of a configuration management system:

• Statuses
• Attributes for each class of CI

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• Project manager

Outcomes of this step

• Framework for approaching CI statuses
• Attributes for each class of CI
• Data sources for those attributes

Service mapping approaches

As you start thinking about dependency mapping, it's important to understand the different methods and how they work, as well as your CMDB's capabilities. These approaches may be all in the same tool, or the tool may only have the top-down options.

Model hierarchy

Automated data mapping will be helpful, but it won't be foolproof. It's critical to understand the data model to validate and map nondiscoverable CIs correctly.

The framework consists of the business, enterprise, application, and implementation layers.

The business layer encodes real-world business concepts via the conceptual model.

The enterprise layer defines all enterprise data assets' details and their relationships.

The application layer defines the data structures as used by a specific application.

The implementation layer defines the data models and artifacts for use by software tools.

Learn how to create data models with Info-Tech's blueprint Create and Manage Enterprise Data Models

2.2.1 Follow the packet and map out the in-scope services and data centers

Reference your network topology and architecture diagrams.

Allot 1 hour for this activity.

1. Start with a single service that is well understood and documented.
2. Identify the technical components (hardware and applications) that make up the service.
3. Determine if there is a need to further break down services into logical service groupings. For example, the email service to the right is broken down into authentication and mail flow.
4. If you don't have a network diagram to follow, create a simple one to identify workflows within the service and components the service uses.
5. Record the apps and underlying components in the Configuration Management Standard Operating Procedures, Appendix 1: Configuration Data Model Structure.

This information will be used for CM project planning and validating the contents of the CMDB.

Download the Configuration Management Diagram Template Library to see an example.

Build your configuration data model

Rely on out-of-the-box functionality where possible and keep a narrow focus in the early implementation stages.

1. If you have an enterprise architecture, then your configuration management data model should align with it.
2. Keep a narrow focus in the early implementation stages. Don't fill up your CMDB until you are ready to validate and fix the data.
3. Rely on out-of-the-box (OOTB) functionality where possible. If your configuration management database (CMDB) and platform do not have a data model OOTB, then rely on a publicly available data model.
4. Map your business or IT service offering to the first few layers.

Once this is built out in the system, you can let the automated dependency mapping take over, but you will still need to validate the accuracy of the automated mapping and investigate anything that is incorrect.

Sample Configuration Data Model

Every box represents a CI, and every line represents a relationship

Example: Data model and CMDB visualization

Once the data model is entered into the CMDB, it will provide a more dynamic and complex view, including CIs shared with other services.

CMDB View

2.2.2 Build data model diagrams

Visualize the expected CI classes and relationships.

Allot 45 minutes.

1. Identify the different data model views you need. Use multiple diagrams to keep the information simple to read and understand. Common diagrams include:

1. Network level: Outline expected CI classes and relationships at the network level.
2. Application level: Outline the expected components and relationships that make up an application.
3. Services level: Outline how business capability CIs and service CIs relate to each other and to other types of CIs.

2. Use boxes to represent CI classes.
3. Use lines to represent relationships. Include details such as:

1. Relationship name: Write this name on the arrow.
2. Direction: Have an arrow point to each child.

Review samples in Configuration Management Diagram Template Library.
Record these diagrams in the Configuration Management Standard Operating Procedures, Appendix 1: Configuration Data Model Structure.

Download the Configuration Management Diagram Template Library to see examples.

Determine governance for data security, access, and validation

Align CMDB access to the organization's access control policy to maintain authorized and secure access for legitimate staff performing their role.

2.2.3 Determine access rights for your data

Allot 30 minutes for this discussion.

1. Open the Configuration Management Standard Operating Procedures, section 5: Access Rights.
2. Review the various roles from an access perspective.

1. Who needs read-only access?
2. Who needs read/write access?
3. Should there be restrictions on who can delete data?

3. Fill in the chart and communicate this to your CMDB installation vendor or your CMDB administrator.

Phase 3

Configuration Record Updates

This phase will walk you through the following aspects of a configuration management system:

• ITSM Practices and Workflows
• Discovery and Dependency Mapping Tools
• Auditing and Data Validation Practices

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• SCM project manager
• IT audit

Harness Service Configuration Management Superpowers

Step 3.1

Keep CIs and relationships up to date through lifecycle process integrations

Activities

3.1.1 Define processes to bring new services into the CMDB

3.1.2 Determine when each type of CI will be created in the CMDB

3.1.3 Identify when each type of CI will be retired in the CMDB

3.1.4 Record when and how attributes will change

3.1.5 Institute configuration control and configuration baselines

This step will walk you through the following aspects of a configuration management system:

1. ITSM Practices and Workflows
2. Discovery and Dependency Mapping Tools

This phase involves the following participants:

1. IT service owners
2. Enterprise architects
3. Practice owners and managers
4. SCM practice manager
5. Project manager

Outcomes of this step

• List of action items for updating interfacing practices and processes
• Identification of where configuration records will be manually updated

Incorporate CMDB updates into IT operations

Determine which processes will prompt changes to the CMDB data

	Change enablement	Identify which process are involved in each stage of data input, maintenance, and removal to build out a process for each scenario.
	Project management
	Change enablement	Asset management	Security controls
	Project management	Incident management	Deployment management
	Change enablement	Asset management	Security controls
	Project management	Incident management	Service management

Formalize the process for adding new services to the CMDB

As new services and products are introduced into the environment, you can improve your ability to correctly cost the service, design integrations, and ensure all operational capabilities are in place, such as data backup and business continuity plans.
In addition, attributes such as service-level agreements (SLAs), availability requirements, and product, technical, and business owners should be documented as soon as those new systems are made live.

• Introduce the technical team and CCB to the product early to ensure the service record is created before deployment and to quickly map the services once they are moved into the production environment.
• Engage with project managers or business analysts to define the process to include security and technical reviews early.
• Engage with the security and technical reviewers to start documenting the service as soon as it is approved.
• Determine which practices will be involved in the creation and approval of new services and formalize the process to streamline entry of the new service, onboarding corresponding CIs and mapping dependencies.

3.1.1 Define processes to bring new services into the CMDB

Start with the most frequent intake methods, and if needed, use this opportunity to streamline the process.

1. Discuss the methods for new services to be introduced to the IT environment.
2. Critique existing methods to assess consistency and identify issues that could prevent the creation of services in the CMDB in a timely manner.
3. Create a workflow for the existing processes, with an eye to improvement. Identify any changes that will need to be introduced and managed appropriately.
4. Identify where additional groups may need to be engaged to ensure success. For example, if project managers are not interfacing early with IT, discuss process changes with them.
5. Discuss the validation process and determine where control points are. Document these on the workflows.
6. Complete the Configuration Management Standard Operating Procedures, section 8.1: Introduce New Service and Data Model.

Possible intake opportunities:

• Business-driven project intake process
• IT-driven project intake process
• Change enablement reviews
• Vendor-driven product changes

Identify scenarios where CIs are added and removed in the configuration management database

New CIs may be introduced with new services or may be introduced and removed as part of asset refreshes or through service restoration in incident management. Updates may be done by your own services team or a managed services provider.
Determine the various ways the CIs may be changed and test with various CI types.
Review attributes such as SLAs, availability requirements, and product, technical, and business owners to determine if changes are required.

• Identify what will be updated automatically or manually. Automation could include discovery and dependency mapping or synchronization with AMDB or AIOps tools.
• Engage with relevant program managers to define and validate processes.
• Identify control points and review audit requirements.

Info-Tech Insight

Data deemed no longer current may be archived or deleted. Retained data may be used for tracing lifecycle changes when troubleshooting or meeting audit obligations. Determine what types of CIs and use cases require archived data to meet data retention policies. If none do, deletion of old data may be appropriate.

3.1.2 Identify when each type of CI will be created in the CMDB

Allot 45 minutes for discussion.

1. Discuss the various methods for new CIs to be introduced to the IT environment.
2. Critique existing methods to assess consistency and identify issues that could prevent the creation of CIs in the CMDB in a timely manner.
3. Create a workflow for the existing processes, with an eye to improvement. Identify any changes that will need to be introduced and managed appropriately.
4. Identify where additional groups may need to be engaged to ensure success. For example, if project managers are not interfacing early with IT, discuss process changes with them.
5. Discuss the validation process and determine where control points are. Document these on the workflows.
6. Complete Configuration Management Standard Operating Procedures, section 8.2: Introduce New Configuration Items to the CMDB

Possible intake opportunities:

• Business-driven project intake process
• IT-driven project intake process
• Change enablement reviews
• Vendor-driven product changes
• Incident management
• Asset management, lifecycle refresh

3.1.3 Identify when each type of CI will be retired in the CMDB

Allot 45 minutes for discussion.

1. Discuss the various methods for CIs to be removed from the IT environment.
2. Critique existing methods to assess consistency and identify issues that could prevent the retirement of CIs in the CMDB in a timely manner.
3. Create a workflow for the existing processes, with an eye to improvement. Identify any changes that will need to be introduced and managed appropriately.
4. Identify where additional groups may need to be engaged to ensure success. For example, if project managers are not interfacing early with IT, discuss process changes with them.
5. Discuss the validation process and determine where control points are. Document these on the workflows.
6. Discuss data retention. How long will retired information need to be archived? What are the potential scenarios where legacy information may be needed for analysis?
7. Complete the Configuration Management Standard Operating Procedures, section 8.4: Retire and Archive Configuration Records.

Possible retirement scenarios:

• Change enablement reviews
• Vendor-driven product changes
• Incident management
• Asset management, lifecycle refresh

Determine appropriate actions for detecting new or changed CIs through discovery

Automated detection will provide the most efficient way of recording planned changes to CIs as well as detected unplanned changes. Check with the tool to determine what reports or notifications are available for the configuration management process and define what actions will be appropriate.

As new CIs are detected, identify the process by which they should have been introduced into configuration management and compare against those records. If your CMDB can automatically check for documentation, this may be easier. Weekly reporting will allow you to catch changes quickly, and alerts on critical CIs could enable faster remediation, if the tool allows for alerting. AIOps could identify, notify of, and process many changes in a highly dynamic environment.

The configuration manager may not have authority to act but can inform the process owners of unauthorized changes for further action. Once the notifications are forwarded to the appropriate process owner, the configuration manager will note the escalation and follow up on data corrections as deemed appropriate by the associated process owner.

3.1.4 Record when and how attributes will change

These lists will help with configuration control plans and your implementation roadmap.

1. List each attribute that will change in that CI type's life.
2. Write all the times that each attribute will change. Identify:

1. The name of the workflow, service request, process, or practice that modifies the attribute.
2. Whether the update is made automatically or manually.
3. The role or tool that updates the CMDB.

3. Update the relevant process or procedure documentation. Explicitly identify when the configuration records are updated.

Document these tables in Configuration Management Standard Operation Procedures, Section 8.7: Practices That Modify CIs.

Institute configuration control and configuration baselines where appropriate

A baseline enables an assessment of one or more systems against the desired state and is useful for troubleshooting incidents or problems and validating changes and security settings.

Baselines may be used by enterprise architects and system engineers for planning purposes, by developers to test their solution against production copies, by technicians to assess configuration drift that may be causing performance issues, and by change managers to assess and verify the configuration meets the target design.

Configuration baselines are a snapshot of configuration records, displaying attributes and first-level relationships of the CIs. Standard configurations may be integral to the success of automated workflows, deployments, upgrades, and integrations, as well as prevention of security events. Comparing current CIs against their baselines will identify configuration drift, which could cause a variety of incidents. Configuration baselines are updated through change management processes.
Configuration baselines can be used for a variety of use cases:

• Version control – Management of software and hardware versions, https://dj5l3kginpy6f.cloudfront.net/blueprints/harness-configuration-management-superpowers-phases-1-4/builds, and releases.
• Access control – Management of access to facilities, storage areas, and the CMS.
• Deployment control – Take a baseline of CIs before performing a release so you can use this to check against actual deployment.
• Identify accidental changes – Everyone makes mistakes. If someone installs software on the wrong server or accidentally drops a table in a database, the CMS can alert IT of the unauthorized change (if the CI is included in configuration control).

Info-Tech Insight

Determine the appropriate method for evaluating and approving changes to baselines. Delegating this to the CCB every time may reduce agility, depending on volume. Discuss in CCB meetings.

3.1.5 Institute configuration control and configuration baselines where appropriate

Only baseline CIs and relationships that you want to control through change enablement.

1. Determine criteria for capturing configuration baselines, including CI type, event, or processes.
2. Identify who will use baselines and how they will use the data. Identify their needs.
3. Identify CIs that will be out of scope and not have baselines created.
4. Document requirements in the SOP.
5. Ensure appropriate team members have training on how to create and capture baselines in the CMDB.
6. Document in the Configuration Management Standard Operating Procedures, section 8.5: Establish and Maintain Configuration Baselines.

Step 3.2

Validate data within the CMDB

Activities

3.2.1 Build an audit plan and checklist

This step will walk you through the following aspects of a configuration management system:

• Data validation and audit

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• Project manager
• IT audit

Outcomes of this step

• Updates to processes for data validation
• Plan for auditing and validating the data in the CMDB

Audit and validate the CMDB

Review the performance of the supporting technologies and processes to validate the accuracy of the CMDB.

CM Audit Plan

• CM policies
• CM processes and procedures
• Interfacing processes
• Content within the CMDB

"If the data in your CMDB isn't accurate, then it's worthless. If it's wrong or inaccurate, it's going to drive the wrong decisions. It's going to make IT worse, not better."
– Valence Howden, Research Director, Info-Tech Research Group

Ensure the supporting technology is working properly

Does the information in the database accurately reflect reality?

Perform functional tests during audits and as part of release management practices.

Audit results need to have a clear status of "compliant," "noncompliant," or "compliant with conditions," and conditions need to be noted. The conditions will generally offer a quick win to improve a process, but don't use these audit results to quickly check off something as "done." Ensure the fix is useful and meaningful to the process.
The audit should cover three areas:

• Process: Are process requirements for the program well documented? Are the processes being followed? If there were updates to the process, were those updates to the process documented and communicated? Has behavior changed to suit those modified processes?
• Physical: Physical configuration audits (PCAs) are audits conducted to verify that a configuration item, as built, conforms to the technical documentation that defines and describes it.
• Functional: Functional configuration audits (FCAs) are audits conducted to verify that the development of a configuration item has been completed satisfactorily, the item has achieved the functional attributes specified in the functional or allocated baseline, and its technical documentation is complete and satisfactory.

Build auditing and validation of processes whenever possible

When technicians and analysts are working on a system, they should check to make sure the data about that system is correct. When they're working in the CMDB, they should check that the data they're working with is correct.

More frequent audits, especially in the early days, may help move toward process adoption and resolving data quality issues. If audits are happening more frequently, the audits can include a smaller scope, though it's important to vary each one to ensure many different areas have been audited through the year.

• Watch for data duplication from multiple discovery tools.
• Review mapping to ensure all relevant CIs are attached to a product or service.
• Ensure report data is logical.

Ensure the supporting technology is working properly

Does the information in the database accurately reflect reality?

Perform functional tests during audits and as part of release management practices.

Audit results need to have a clear status of "compliant," "noncompliant," or "compliant with conditions," and conditions need to be noted. The conditions will generally offer a quick win to improve a process, but don't use these audit results to quickly check off something as "done." Ensure the fix is useful and meaningful to the process.
The audit should cover three areas:

• Process: Are process requirements for the program well documented? Are the processes being followed? If there were updates to the process, were those updates to the process documented and communicated? Has behavior changed to suit those modified processes?
• Physical: Physical configuration audits (PCAs) are audits conducted to verify that a configuration item, as built, conforms to the technical documentation that defines and describes it.
• Functional: Functional configuration audits (FCAs) are audits conducted to verify that the development of a configuration item has been completed satisfactorily, the item has achieved the functional attributes specified in the functional or allocated baseline, and its technical documentation is complete and satisfactory.

More frequent audits, especially in the early days, may help move toward process adoption and resolving data quality issues. If audits are happening more frequently, the audits can include a smaller scope, though it's important to vary each one to ensure many different areas have been audited through the year.

• Watch for data duplication from multiple discovery tools.
• Review mapping to ensure all relevant CIs are attached to a product or service.
• Ensure report data is logical.

Identify where processes break down and data is incorrect

Once process stops working, data becomes less accurate and people find workarounds to solve their own data needs.

Data within the CMDB often becomes incorrect or incomplete where human work breaks down

• Investigate processes that are performed manually, including data entry.
• Investigate if the process executors are performing these processes uniformly.
• Determine if there are opportunities to automate or provide additional training.
• Select a sample of the corresponding data in the CMS. Verify if the data is correct.

Non-CCB personnel may not be completing processes fully or consistently

• Identify where data in the CMS needs to be updated.
• Identify whether the process practitioners are uniformly updating the CMS.
• Discuss options for improving the process and driving consistency for data that will benefit the whole organization.

Ensure that the data entered in the CMDB is correct

• Confirm that there is no data duplication. Data duplication is very common when there are multiple discovery tools in your environment. Confirm that you have set up your tools properly to avoid duplication.
• Build a process to respond to baseline divergence when people make changes without following change processes and when updates alter settings.
• Audit the system for accuracy and completeness.

3.2.1 Build an audit plan and checklist

Use the audit to identify areas where processes are breaking down.

Audits present you with the ability to address these pain points before they have greater negative impact.

1. Identify which regulatory requirements and/or auditing bodies will be relevant to audit processes or findings.
2. Determine frequency of practice audits and how they relate to internal audits or external audits.
3. Determine audit scope, including requirements for data spot checks.
4. Determine who will be responsible for conducting audits and validate this is consistent with the RACI chart.
5. Record audit procedures in the Configuration Management Standard Operating Procedures section 8.6: Verify and Review the Quality of Information Through Auditing.
6. Review the Configuration Management Audit and Validation Checklist and modify to suit your needs.

Download the Configuration Management Audit and Validation Checklist

Phase 4

Service Configuration Roadmap

This phase will walk you through the following aspect of a configuration management system:
Roadmap
This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• SCM project manager

Harness Service Configuration Management Superpowers

Step 4.1

Define measures of success

Activities

4.1.1 Identify key metrics to define configuration management success
4.1.2 Brainstorm and record desired reports, dashboards, and analytics
4.1.3 Build a configuration management policy

This phase will walk you through the following aspects of a configuration management system:

• Metrics
• Policy

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• SCM project manager

The value of metrics can be found in IT efficiency increases

When determining metrics for configuration management, be sure to separate metrics needed to gauge configuration management success and those that will use data from the CMDB to provide metrics on the success of other practices.

• Metrics provide accurate indicators for IT and business decisions.
• Metrics help you identify IT efficiencies and problems and solve issues before they become more serious.
• Active metrics tracking makes root cause analysis of issues much easier.
• Proper application of metrics helps IT services identification and prioritization.
• Operational risks can be prevented by identifying and implementing metrics.
• Metrics analysis increases the confidence of the executive team and ensures that IT is working well.

4.1.1 Identify key metrics to define configuration management success

Determine what metrics are specifically related to the practice and how and when metrics will be accessed.

Document metrics in the Configuration Management Standard Operating Procedures, section 7: Success Metrics

Use performance metrics to identify areas to improve service management processes using CMDB data

Metrics can indicate a problem with service management processes but cannot provide a clear path to a solution on their own.

• The biggest challenge is defining and measuring the process and people side of the equation.
• Expected performance may also need to be compared to actual performance in planning, budgeting, and improvements.
• The analysis will need to include critical success factors (CSFs), data collection procedures, office routines, engineering practices, and flow diagrams including workflows and key relationships.
• External benchmarking may also prove useful in identifying how similar organizations are managing aspects of their infrastructure, processing transactions/requests, or staffing. If using external benchmarking for actual process comparisons, clearly defining your internal processes first will make the data collection process smoother and more informative.

Info-Tech Insight

Using a service framework such as ITIL, COBIT, or ISO 20000 may make this job easier, and subscribing to benchmarking partners will provide some of the external data needed for comparison.

4.1.2 Brainstorm and record desired reports, dashboards, and analytics with related practices

The project team will use this list as a starting point

Allot 45 minutes for this discussion.

1. Create a table for each service or business capability.
   1. Have one column for each way of consuming data: reports, dashboards, and ad hoc analytics.
   2. Have one row for each stakeholder group that will consume the information.
2. Use the challenges and use cases to brainstorm reports, dashboards, and ad hoc analytic capabilities that each stakeholder group will find useful.
3. Record these results in your Configuration Management Standard Operating Procedures, section 7: Aligned Processes' Desired Analytical Capabilities.

Download the blueprint Take Control of Infrastructure and Operations Metrics to create a complete metrics program.

Create a configuration management policy and communicate it

Policies are important documents to provide definitive guidelines and clarity around data collection and use, process adherence, and controls.

• A configuration management policy will apply to IT as the audience, and participants in the program will largely be technical.
• Business users will benefit from a great configuration management program but will not participate directly.
• The policy will include objectives and scope, use of data, security and integrity of data, data models and criteria, and baseline configurations.
• Several governing regulations and practices may intersect with configuration management, such as ITIL, COBIT, and NIST frameworks, as well as change enablement, quality management, asset management, and more.
• As the policy is written, review processes to ensure policies and processes are aligned. The policy should enable processes, and it may require modifications if it hinders the collection, security, or use of data required to meet proposed use cases.
• Once the policy is written and approved, ensure all stakeholders understand the importance, context, and repercussions of the policy.

The approvals process is about appropriate oversight of the drafted policies. For example:

• Do the policies satisfy compliance and regulatory requirements?
• Do the policies work with the corporate culture?
• Do the policies address the underlying need?

If the draft is approved:

• Set the effective date and a review date.
• Begin communication, training, and implementation.

Employees must know that there are new policies and understand the steps they must take to comply with the policies in their work.

Employees must be able to interpret, understand, and know how to act upon the information they find in the policies.

Employees must be informed on where to get help or ask questions and who to request policy exceptions from.

If the draft is rejected:

• Acquire feedback and make revisions.
• Resubmit for approval.

4.1.3 Build a configuration management policy

This policy provides the foundation for configuration control.

Use this template as a starting point.

The Configuration Management Policy provides the foundation for a configuration control board and the use of configuration baselines.
Instructions:

1. Review and modify the policy statements. Ensure that the policy statements reflect your organization and the expectations you wish to set.
2. If you don't have a CCB: The specified responsibilities can usually be assigned to either the configuration manager or the governing body for change enablement.
3. Determine if you should apply this policy beyond SCM. As written, this policy may provide a good starting point for practices such as:
   • Secure baseline configuration management
   • Software configuration management

Download the Configuration Management Policy template

Step 4.2

Build communications and a roadmap

Activities

4.2.1 Build a communications plan
4.2.2 Identify milestones

This phase will walk you through the following aspects of a configuration management system:

• Communications plan
• Roadmap

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• SCM project manager

Outcomes of this step

• Documented expectations around configuration control
• Roadmap and action items for the SCM project

Do not discount the benefits of a great communications plan as part of change management

Many configuration management projects have failed due to lack of organizational commitment and inadequate communications.

• Start at the top to ensure stakeholder buy-in by verifying alignment and use cases. Without a committed project sponsor who believes in the value of configuration management, it will be difficult to draw the IT team into the vision.
• Clearly articulate the vision, strategy, and goals to all stakeholders. Ensure the team understands why these changes are happening, why they are happening now, and what outcomes you hope to achieve.
• Gain support from technical teams by clearly expressing organizational and departmental benefits – they need to know "what's in it for me."
• Clearly communicate new responsibilities and obligations and put a feedback process in place to hear concerns, mitigate risk, and act on opportunities for improvement. Be prepared to answer questions as this practice is rolled out.
• Be consistent in your messaging. Mixed messages can easily derail progress.
• Communicate to the business how these efforts will benefit the organization.
• Share documents built in this blueprint or workshop with your technical teams to ensure they have a clear picture of the entire configuration management practice.
• Share your measures and view of success and communicate wins throughout building the practice.

For a more detailed program, see Drive Technology Adoption

Formulate a communications plan to ensure all stakeholders and impacted staff will be aware of the plan

Communication is key to success in process adoption and in identifying potential risks and issues with integration with other processes. Engage as often as needed to get the information you need for the project and for adoption.

Identify Messages

Distinct information that needs to be sent at various times. Think about:

• Who will be impacted and how.
• What the goals are for the project/new process.
• What the audience needs to know about the new process and how they will interface with each business unit.
• How people can request configuration data.

Identify Audiences

Any person or group who will be the target of the communication. This may include:

• Project sponsors and stakeholders.
• IT staff who will be involved in the project.
• IT staff who will be impacted by the project (i.e. who will benefit from it or have obligations to fulfill because of it).
• Business sponsors and product owners.

Document and Track

Document messaging, medium, and responsibility, working with the communications team to refine messages before executing.

• Identify where people can send questions and feedback to ensure they have the information they need to make or accept the changes.
• Document Q&A and share in a central location.

Determine Timing

Successful communications plans consider timing of various messages:

• Advanced high-level notice of improvements for those who need to see action.
• Advanced detailed notice for those who will be impacted by workload.
• Advanced notice for who will be impacted (i.e. who will benefit from it or have obligations to fulfill because of it) once the project is ready to be transitioned to daily life.

Determine Delivery

Work with your communications team, if you have one, to determine the best medium, such as:

• Meeting announcement for stakeholders and IT.
• Newsletter for those less impacted.
• Intranet announcements: "coming soon!"
• Demonstrations with vendors or project team.

4.2.1 Build a communications plan

The communications team will use this list as a starting point.

Allot 45 minutes for this discussion.

Identify stakeholders.

1. Identify everyone who will be affected by the project and by configuration management.

Craft key messages tailored to each stakeholder group.

1. Identify the key messages that must be communicated to each group.

Finalize the communication plan.

1. Determine the most appropriate timing for communications with each group to maximize receptivity.
2. Identify any communication challenges you anticipate and incorporate steps to address them into your communication plan.
3. Identify multiple methods for getting the messages out (e.g. newsletters, emails, meetings).

3. Identify how feedback will be collected (i.e. through interviews or surveys) to measure whether the changes were communicated well.

Build a realistic, high-level roadmap including milestones

Break the work into manageable pieces

1. Plan to have multiple phases with short-, medium-, and long-term goals/timeframes. Building a CMDB is not easy and should be broken into manageable sections.
2. Set reasonable milestones. For each phase, document goals to define "done" and ensure they're reasonable for the resources you have available. If working with a vendor, include them in your discussions of what's realistic.
3. Treat the first phase as a pilot. Focus on items you understand well:
   1. Well-understood user-facing and IT services
   2. High-maturity management and governance practices
   3. Trusted data sources
4. Capture high-value, high-criticality services early. Depending on the complexity of your systems, you may need to split this phase into multiple phases.

Document this table in the Configuration Management Project Charter, section 3.0: Milestones

4.2.2 Identify milestones

Build out a high-level view to inform the project plan

Open the Configuration Management Project Charter, section 3: Milestones.
Instructions:

1. Identify high-level milestones for the implementation of the configuration management program. This may include tool evaluation and implementation, assignment of roles, etc.
2. Add details to fill out the milestone, keeping to a reasonable level of detail. This may inform vendor discussion or further development of the project plan.
3. Add target dates to the milestones. Validate they are realistic with the team.
4. Add notes to the assumptions and constraints section.
5. Identify risks to the plan.

Download the Configuration Management Project Charter

Workshop Participants

R = Recommended
O = Optional

Related Info-Tech Research

• Develop an IT Asset Management Strategy
• Implement Hardware Asset Management
• Implement Software Asset Management
• Optimize IT Change Management
• Drive Technology Adoption
• Improve Incident and Problem Management

Research Contributors and Experts

Thank you to everyone who contributed to this publication

Brett Johnson, Senior Consultant, VMware

Yev Khovrenkov, Senior Consultant, Solvera Solutions

Larry Marks, Reviewer, ISACA New Jersey

Darin Ohde, Director of Service Delivery, GreatAmerica Financial Services

Jim Slick, President/CEO, Slick Cyber Systems

Emily Walker, Sr. Digital Solution Consultant, ServiceNow

Valence Howden, Principal Research Director, Info-Tech Research Group

Allison Kinnaird, Practice Lead, IT Operations, Info-Tech Research Group

Robert Dang, Principal Research Advisor, Security, Info-Tech Research Group

Monica Braun, Research Director, IT Finance, Info-Tech Research Group

Jennifer Perrier, Principal Research Director, IT Finance, Info-Tech Research Group

Plus 13 anonymous contributors

Bibliography

An Introduction to Change Management, Prosci, Nov. 2019.
BAI10 Manage Configuration Audit Program. ISACA, 2014.
Bizo, Daniel, et al, "Uptime Institute Global Data Center Survey 2021." Uptime Institute, 1 Sept. 2021.
Brown, Deborah. "Change Management: Some Statistics." D&B Consulting Inc. May 15, 2014. Accessed June 14, 2016.
Cabinet Office. ITIL Service Transition. The Stationery Office, 2011.
"COBIT 2019: Management and Governance Objectives. ISACA, 2018.
"Configuration Management Assessment." CMStat, n.d. Accessed 5 Oct. 2022.
"Configuration Management Database Foundation." DMTF, 2018. Accessed 1 Feb. 2021.
Configuration Management Using COBIT 5. ISACA, 2013.
"Configuring Service Manager." Product Documentation, Ivanti, 2021. Accessed 9 Feb. 2021.
"Challenges of Implementing configuration management." CMStat, n.d. Accessed 5 Oct. 2022.
"Determining if configuration management and change control are under management control, part 1." CMStat, n.d. Accessed 5 Oct. 2022.
"Determining if configuration management and change control are under management control, part 2." CMStat, n.d. Accessed 5 Oct. 2022.
"Determining if configuration management and change control are under management control, part 3." CMStat, n.d. Accessed 5 Oct. 2022.
"CSDM: The Recipe for Success." Data Content Manager, Qualdatrix Ltd. 2022. Web.
Drogseth, Dennis, et al., 2015, CMDB Systems: Making Change Work in the Age of Cloud and Agile. Morgan Kaufman.
Ewenstein, B, et al. "Changing Change Management." McKinsey & Company, 1 July 2015. Web.
Farrell, Karen. "VIEWPOINT: Focus on CMDB Leadership." BMC Software, 1 May 2006. Web.
"How to Eliminate the No. 1 Cause of Network Downtime." SolarWinds, 4 April 2014. Accessed 9 Feb. 2021.
"ISO 10007:2017: Quality Management -- Guidelines for Configuration Management." International Organization for Standardization, 2019.
"IT Operations Management." Product Documentation, ServiceNow, version Quebec, 2021. Accessed 9 Feb. 2021.
Johnson, Elsbeth. "How to Communicate Clearly During Organizational Change." Harvard Business Review, 13 June 2017. Web.
Kloeckner, K. et al. Transforming the IT Services Lifecycle with AI Technologies. Springer, 2018.
Klosterboer, L. Implementing ITIL Configuration Management. IBM Press, 2008.
Norfolk, D., and S. Lacy. Configuration Management: Expert Guidance for IT Service Managers and Practitioners. BCS Learning & Development Limited, revised ed., Jan. 2014.
Painarkar, Mandaar. "Overview of the Common Data Model." BMC Documentation, 2015. Accessed 1 Feb. 2021.
Powers, Larry, and Ketil Been. "The Value of Organizational Change Management." Boxley Group, 2014. Accessed June 14, 2016.
"Pulse of the Profession: Enabling Organizational Change Throughout Strategic Initiatives." PMI, March 2014. Accessed June 14, 2016.
"Service Configuration Management, ITIL 4 Practice Guide." AXELOS Global Best Practice, 2020
"The Guide to Managing Configuration Drift." UpGuard, 2017.

Build a Robust and Comprehensive Data Strategy

Key to building and fostering a data-driven culture.

ANALYST PERSPECTIVE

Data Strategy: Key to helping drive organizational innovation and transformation

"In the dynamic environment in which we operate today, where we are constantly juggling disruptive forces, a well-formulated data strategy will prove to be a key asset in supporting business growth and sustainability, innovation, and transformation.

Your data strategy must align with the organization’s business strategy, and it is foundational to building and fostering an enterprise-wide data-driven culture."

Crystal Singh,

Director – Research and Advisory

Info-Tech Research Group

Our understanding of the problem

This Research is Designed For:

• Chief data officers (CDOs), chief architects, VPs, and digital transformation directors and CIOs who are accountable for ensuring data can be leveraged as a strategic asset of the organization.

This Research Will Help You:

• Put a strategy in place to ensure data is available, accessible, well integrated, secured, of acceptable quality, and suitably visualized to fuel decision making by the organizations’ executives.
• Align data management plans and investments with business requirements and the organization’s strategic plans.
• Define the relevant roles for operationalizing your data strategy.

This Research Will Also Assist:

• Data architects and enterprise architects who have been tasked with supporting the formulation or optimization of the organization’s data strategy.
• Business leaders creating plans for leveraging data in their strategic planning and business processes.
• IT professionals looking to improve the environment that manages and delivers data.

This Research Will Help Them:

• Get a handle on the current situation of data within the organization.
• Understand how the data strategy and its resulting initiatives will affect the operations, integration, and provisioning of data within the enterprise.

Executive Summary

Situation

• The volume and variety of data that organizations have been collecting and producing have been growing exponentially and show no sign of slowing down. At the same time, business landscapes and models are evolving, and users and stakeholders are becoming more and more data centric, with maturing and demanding expectations.

Complication

• As organizations pivot in response to industry disruptions and changing landscapes, a reactive and piecemeal approach leads to data architectures and designs that fail to deliver real and measurable value to the business.
• Despite the growing focus on data, many organizations struggle to develop a cohesive business-driven strategy for effectively managing and leveraging their data assets.

Resolution

Formulate a data strategy that stitches all of the pieces together to better position you to unlock the value in your data:

• Establish the business context and value: Identify key business drivers for executing on an optimized data strategy, build compelling and relevant use cases, understand your organization’s culture and appetite for data, and ensure you have well-articulated vision, principles, and goals for your data strategy.
• Ensure you have a solid data foundation: Understand your current data environment, data management enablers, people, skill sets, roles, and structure. Know your strengths and weakness so you can optimize appropriately.
• Formulate a sustainable data strategy: Round off your strategy with effective change management and communication for building and fostering a data-driven culture.

Info-Tech Insight

1. As the CDO or equivalent data leader in your organization, a robust and comprehensive data strategy is the number one tool in your toolkit for delivering on your mandate of creating measurable business value from data.
2. A data strategy should never be formulated disjointed from the business. Ensure the data strategy aligns with the business strategy and supports the business architecture.
3. Building and fostering a data-driven culture will accelerate and sustain adoption of, appetite for, and appreciation for data and hence drive the ROI on your various data investments.

Why do you need a data strategy?

Your data strategy is the vehicle for ensuring data is poised to support your organization’s strategic objectives.

The dynamic marketplace of today requires organizations to be responsive in order to gain or maintain their competitive edge and place in their industry.

Organizations need to have that 360-degree view of what’s going on and what’s likely to happen.

Disruptive forces often lead to changes in business models and require organizations to have a level of adaptability to remain relevant.

To respond, organizations need to make decisions and should be able to turn to their data to gain insights for informing their decisions.

A well-formulated and robust data strategy will ensure that your data investments bring you the returns by meeting your organization’s strategic objectives.

Organizations need to be in a position where they know what’s going on with their stakeholders and anticipate what their stakeholders’ needs are going to be.

Data cannot be fully leveraged without a cohesive strategy

Most organizations today will likely have some form of data management in place, supported by some of the common roles such as DBAs and data analysts.

Most will likely have a data architecture that supports some form of reporting.

Some may even have a chief data officer (CDO), a senior executive who has a seat at the C-suite table.

These are all great assets as a starting point BUT without a cohesive data strategy that stitches the pieces together and:

• Effectively leverages these existing assets
• Augments them with additional and relevant key roles and skills sets
• Optimizes and fills in the gaps around your current data management enablers and capabilities for the growing volume and variety of data you’re collecting
• Fully caters to real, high-value strategic organizational business needs

you’re missing the mark – you are not fully leveraging the incredible value of your data.

Cross-industry studies show that on average, less than half of an organization’s structured data is actively used in making decisions

Organizational drivers for a data strategy

Your data strategy needs to align with your organizational strategy.

Main Organizational Strategic Drivers:

1. Stakeholder Engagement/Service Excellence
2. Product and Service Innovations
3. Operational Excellence
4. Privacy, Risk, and Compliance Management

“The companies who will survive and thrive in the future are the ones who will outlearn and out-innovate everyone else. It is no longer ‘survival of the fittest’ but ‘survival of the smartest.’ Data is the element that both inspires and enables this new form of rapid innovation.” – Joel Semeniuk, 2016

A sound data strategy is the key to unlocking the value in your organization’s data.

Data should be at the foundation of your organization’s evolution.

The transformational insights that executives are constantly seeking to leverage can be unlocked with a data strategy that makes high-quality, well-integrated, trustworthy, relevant data readily available to the business users who need it.

Whether hoping to gain a better understanding of your business, trying to become an innovator in your industry, or having a compliance and regulatory mandate that needs to be met, any organization can get value from its data through a well-formulated, robust, and cohesive data strategy.

According to a leading North American bank, “More than one petabyte of new data, equivalent to about 1 million gigabytes” is entering the bank’s systems every month. – The Wall Street Journal, 2019

“Although businesses are at many different stages in unlocking the power of data, they share a common conviction that it can make or break an enterprise.”– Jim Love, ITWC CIO and Chief Digital Officer, IT World Canada, 2018

Data is a strategic organizational asset and should be treated as such

The expression “Data is an asset” or any other similar sentiment has long been heard.

With such hype, you would have expected data to have gotten more attention in the boardrooms. You would have expected to see its value reflected on financial statements as a result of its impact in driving things like acquisition, retention, product and service development and innovation, market growth, stakeholder satisfaction, relationships with partners, and overall strategic success of the organization.

The time has surely come for data to be treated as the asset it is.

“Paradoxically, “data” appear everywhere but on the balance sheet and income statement.”– HBR, 2018

“… data has traditionally been perceived as just one aspect of a technology project; it has not been treated as a corporate asset.”– “5 Essential Components of a Data Strategy,” SAS

According to Anil Chakravarthy, who is the CEO of Informatica and has a strong vantage point on how companies across industries leverage data for better business decisions, “what distinguishes the most successful businesses … is that they have developed the ability to manage data as an asset across the whole enterprise.”– McKinsey & Company, 2019

How data is perceived in today’s marketplace

Data is being touted as the oil of the digital era…

But just like oil, if left unrefined, it cannot really be used.

"Data is the new oil." – Clive Humby, Chief Data Scientist

Source: Joel Semeniuk, 2016

Enter your data strategy.

Data is being perceived as that key strategic asset in your organization for fueling innovation and transformation.

Your data strategy is what allows you to effectively mine, refine, and use this resource.

“The world’s most valuable resource is no longer oil, but data.”– The Economist, 2017

“Modern innovation is now dependent upon this data.”– Joel Semeniuk, 2016

“The better the data, the better the resulting innovation and impact.”– Joel Semeniuk, 2016

What is it in it for you? What opportunities can data help you leverage?

GOVERNMENT

Leveraging data as a strategic asset for the benefit of citizens.

• The strategic use of data can enable governments to provide higher-quality services.
• Direct resources appropriately and harness opportunities to improve impact.
• Make better evidence-informed decisions and better understand the impact of programs so that funds can be directed to where they are most likely to deliver the best results.
• Maintain legitimacy and credibility in an increasingly complex society.
• Help workers adapt and be competitive in a changing labor market.
• A data strategy would help protect citizens from the misuse of their data.

Source: Privy Council Office, Government of Canada, 2018

What is it in it for you? What opportunities can data help you leverage?

FINANCIAL

Leveraging data to boost traditional profit and loss levers, find new sources of growth, and deliver the digital bank.

• One bank used credit card transactional data (from its own terminals and those of other banks) to develop offers that gave customers incentives to make regular purchases from one of the bank’s merchants. This boosted the bank’s commissions, added revenue for its merchants, and provided more value to the customer (McKinsey & Company, 2017).
• In terms of enhancing productivity, a bank used “new algorithms to predict the cash required at each of its ATMs across the country and then combined this with route-optimization techniques to save money” (McKinsey & Company, 2017).

A European bank “turned to machine-learning algorithms that predict which currently active customers are likely to reduce their business with the bank.” The resulting understanding “gave rise to a targeted campaign that reduced churn by 15 percent” (McKinsey & Company, 2017).

A leading Canadian bank has built a marketplace around their data – they have launched a data marketplace where they have productized the bank’s data. They are providing data – as a product – to other units within the bank. These other business units essentially represent internal customers who are leveraging the product, which is data.

Through the use of data and advanced analytics, “a top bank in Asia discovered unsuspected similarities that allowed it to define 15,000 microsegments in its customer base. It then built a next-product-to-buy model that increased the likelihood to buy three times over.” Several sets of big data were explored, including “customer demographics and key characteristics, products held, credit-card statements, transaction and point-of-sale data, online and mobile transfers and payments, and credit-bureau data” (McKinsey & Company, 2017).

What is it in it for you? What opportunities can data help you leverage?

HEALTHCARE

Leveraging data and analytics to prevent deadly infections

The fifth-largest health system in the US and the largest hospital provider in California uses a big data and advanced analytics platform to predict potential sepsis cases at the earliest stages, when intervention is most helpful.

Using the Sepsis Bio-Surveillance Program, this hospital provider monitors 120,000 lives per month in 34 hospitals and manages 7,500 patients with potential sepsis per month.

Collecting data from the electronic medical records of all patients in its facilities, the solution uses natural language processing (NLP) and a rules engine to continually monitor factors that could indicate a sepsis infection. In high-probability cases, the system sends an alarm to the primary nurse or physician.

Since implementing the big data and predictive analytics system, this hospital provider has seen a significant improvement in the mortality and the length of stay in ICU for sepsis patients.

At 28 of the hospitals which have been on the program, sepsis mortality rates have dropped an average of 5%.

With patients spending less time in the ICU, cost savings were also realized. This is significant, as sepsis is the costliest condition billed to Medicare, the second costliest billed to Medicaid and the uninsured, and the fourth costliest billed to private insurance.

Source: SAS, 2019

What is it in it for you? What opportunities can data help you leverage?

RETAIL

Leveraging data to better understand customer preferences, predict purchasing, drive customer experience, and optimize supply and demand planning.

Netflix is an example of a big brand that uses big data analytics for targeted advertising. With over 100 million subscribers, the company collects large amounts of data. If you are a subscriber, you are likely familiar with their suggestions messages of the next series or movie you should catch up on. These suggestions are based on your past search data and watch data. This data provides Netflix with insights into your interests and preferences for viewing (Mentionlytics, 2018).

“For the retail industry, big data means a greater understanding of consumer shopping habits and how to attract new customers.”– Ron Barasch, Envestnet | Yodlee, 2019

The business case for data – moving from platitudes to practicality

When building your business case, consider the following:

• What is the most effective way to communicate the business case to executives?
• How can CDOs and other data leaders use data to advance their organizations’ corporate strategy?
• What does your data estate look like? Are you looking to leverage and drive value from your semi-structured and unstructured data assets?
• Does your current organizational culture support a data-driven one? Does the organization have a history of managing change effectively?
• How do changing privacy and security expectations alter the way businesses harvest, save, use, and exchange data?

“We’re the converted … We see the value in data. The battle is getting executive teams to see it our way.”– Ted Maulucci, President of SmartONE Solutions Inc. IT World Canada, 2018

Where do you stack up? What is your current data management maturity?

Info-Tech’s IT Maturity Ladder denotes the different levels of maturity for an IT department and its different functions. What is the current state of your data management capability?

Info-Tech Insight

You are best positioned to successfully execute on a data strategy if you are currently at or above the Trusted Operator level. If you find yourself still at the Unstable or Firefighter stage, your efforts are best spent on ensuring you can fulfill your day-to-day data and data management demands. Improving this capability will help build a strong data management foundation.

Guiding principles of a data strategy

Value of Clearly Defined Data Principles

• Guiding principles help define the culture and characteristics of your practice by describing your beliefs and philosophy.
• Guiding principles act as the heart of your data strategy, helping to shape initiative plans and day-to-day behaviors related to the use and treatment of the organization’s data assets.

“Organizational culture can accelerate the application of analytics, amplify its power, and steer companies away from risky outcomes.”– McKinsey, 2018

Build a Robust and Comprehensive Data Strategy

Follow Info-Tech’s methodology for effectively leveraging the value out of your data

Some say it’s the new oil. Or the currency of the new business landscape. Others describe it as the fuel of the digital economy. But we don’t need platitudes — we need real ways to extract the value from our data. – Jim Love, CIO and Chief Digital Officer, IT World Canada, 2018

Our practical step-by-step approach helps you to formulate a data strategy that delivers business value.

1. Establish Business Context and Value: In this phase, you will determine and substantiate the business drivers for optimizing the data strategy. You will identify the business drivers that necessitate the data strategy optimization and examine your current organizational data culture. This will be key to ensuring the fruits of your optimization efforts are being used. You will also define the vision, mission, and guiding principles and build high-value use cases for the data strategy.
2. Ensure You Have a Solid Data and Resources Foundation: This phase will help you ensure you have a solid data and resources foundation for operationalizing your data strategy. You will gain an understanding of your current environment in terms of data management enablers and the required resources portfolio of key people, roles, and skill sets.
3. Formulate a Sustainable Data Strategy: In this phase, you will bring the pieces together for formulating an effective data strategy. You will evaluate and prioritize the use cases built in Phase 1, which summarize the alignment of organizational goals with data needs. You will also create your strategic plan, considering change management and communication.

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

“Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful.”

Guided Implementation

“Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track.”

Workshop

“We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place.”

Consulting

“Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project.”

Diagnostics and consistent frameworks are used throughout all four options.

Drive Ongoing Adoption With an M365 Center of Excellence

Accelerate business processes change and get more value from your subscription by building and sharing thanks to an effective Centre of Excellence.

CLIENT ADVISORY DECK

Drive Ongoing Adoption With an M365 Centre of Excellence

Accelerate business processes change and get more value from your subscription by building and sharing thanks to an effective Centre of Excellence

Research Team:
John Donovan
John Annand
Principal Research Directors I&O Practice

41 builds released in 2021!
IT can no longer be expected to provide training to all users on all features

• Traditional classroom training (online and self-paced) is time consuming and overly generic
• Users tend to hold onto old familiar tools even as new ones roll out
• Citizen Programming comes with a lot of promise but also the spectre of reliving the era of Access ‘97 databases
• Seemingly small decisions around configuration have outsized impacts
• Every enterprises’ journey through adoption is unique

▲20% $ spent in 2021

148% more meetings
66% more users collaborating on documents
40.6B more emails

2021 vs. 2022 Source: Microsoft The Work Trend Index

• Who needs to be in a CoE? What daily tasks do they undertake?
• How do you turn artifacts like best practice documents into actual behavioral change?
• How does CoE differ from governance? And why is it going to be any more successful?
• How does the CoE evolve over time as enterprises become more mature?

CoE Competencies, Membership and Roles
Communication, Standards Templates
Adoption, and Business Success Metrics

Using these deliverables, Info-Tech will help you drive consistency in your enterprise collaboration, increase end-user satisfaction in the tools they are provided, optimize your license spending, fill the gaps between implementation of a technology and realization of business value, and empower end-users to innovate in ways that senior leadership had not imagined.

Executive Summary

Insight

User adoption is the primary focus of the efforts in the CoE

User adoption and setting up guardrails in governance are the focuses of the CoE in its early stages. Purging obsolete data from legacy share servers, and exchange, and rationalize legacy applications that are comparable to Microsoft offerings. The primary goal is M365 excellence, but that needs to be primed with a Roadmap, and laying down clear milestones to show progress, along with setting up quick wins to get buy in from the organization.

Breakdown your CoE into distinct areas for improvement

Due to the size and complexity of Microsoft 365, breaking it into clearly defined divisions makes sense. The parts that need to be fragmented into are, Collaboration, Power Apps, Office tools, Learning, Professional Training and Certifications, Governance and Support. Subject Matter experts needs to keep pace with the ever-changing M365 environment with enhancements continuously being rolled out. (There were 41 build releases in 2021 alone! )

Set up your M365 CoE in a decentralized design

Define how your CoE will be set up. It will either be centralized, distributed, or a combination of both. They all have their strengths and weaknesses; however a distributed CoE can ensure there is buy-in from the various departments across the CoE, as they participate in the decision making and therefore the direction the CoE goes. Additionally, it ensures that each segment of the CoE is accountable for the success of the M365 adoption, its usage, and delivering value to the organization.

Summary

Your Challenge

You have purchased Microsoft 365 for your business, and you have determined that you are not realizing the full value and potential of the product, neither adoption nor usage – for example, you have legacy applications that the user base is reluctant to move away from, whether it be Skype, Jabber, or other collaboration tools available to them. You have released Teams to the organization but may have not shown how useful it is and you have not communicated to the business that it is your new collaboration tool, along with SharePoint Online and OneDrive. How do you fix this problem?

Common Obstacles

There are roadblocks common to all CoEs: lack of in-house expertise, lack of resources (time, budget, etc.) and employee perception of just another burdensome administrative layer. These are exacerbated when building an M365 CoE.

• Constant vendor-initiated change in M365 means expertise always needs updating
• The self-service architecture of M365 is at odds with centralized limits and controls
• M365 is a multitude of services, adopted across a huge swath of the organization compared to the specific capabilities and limited audience of traditional CoEs

Info-Tech’s Approach

Having a clear vision of what business outcomes you want your Microsoft 365 CoE to accomplish is key. This vision helps select the core competencies and deliverables of the CoE.

1. Ongoing measurement and reporting of business value generated from M365 adoption
2. Servant leadership allows the CoE to work closely and deeply with end-users, which builds them up to share knowledge with others
3. Focus and clear lines of accountability ensure that everyone involved feels part of the compromise when decisions are to be made

Info-Tech Insight

The M365 CoE should be somewhat decentralized to avoid an “us versus them” mentality. Having clear KPIs at the center of the program makes it easier to demonstrate improvements and competencies. COMMUNICATE these early successes! They are vital in gaining widespread credibility and momentum.

Charter Mandate Authority to Operate

Mission : To accelerate the value that M365 brings to the organization by using the M365 CoE to increase adoption, build competency through training and best practices, and deliver on end user innovation throughout the business.

Vision Statement: To transform the organization’s efficiencies and performance through an optimized world-class M365 CoE by meeting all KPIs set out in the Charter.

Info-Tech Insights

A mission and vision for your M365 CoE are a necessary step to kick the program off. Not aving clear goals and a roadmap to get there will hinder your progress. It may even stall the whole objective if you cannot agree or measure what you are trying to accomplish

• The scope of the M365 CoE is to build the adoption rate that can meet milestone goals to advance user competency, as well as the maturation of the SMEs in each segment of the CoE leadership and contributors.
• Maturity will be measured through 100% adoption, specifically around collaboration tools and Office apps across the organization that use M365. Strategic value will be measured by core competencies within the CoE.
• SMEs are developed and educated with certifications and other training throughout the course of the CoE development to bring “bench strength” to the vision of optimizing a world-class M365 CoE.
• SMEs will all be certified Microsoft professionals. They will set the standard to be met within the CoE. The SMEs can either be internal candidates or external hires, depending on the current IT department competency.
• Additional resources required will be tech savvy department leads that understand and can help in the training of staff, who also are willing to spend a certain amount of their work time in coaching colleagues.
• They will be assisted by the training through the SMEs providing relevant material and various M365 courses both in class and self-paced online learning using M365 VIVA tools.

Charter Metrics

Areas in Scope:

• Ensure Mission is aligned to the business objectives.
• Form core team for M365 CoE, including steering committee.
• Create document for signoff from business sponsors.
• Build training plans for users, engineers, and admins.
• Document best practices and build standard templates for organizational uniformity.
• Build governance charter and priorities, setting up guardrails early to ensure compliance and security.
• Transition away and retire all legacy on-Prem apps to M365 Cloud apps.
• Build a RACI model for roles and responsibility.

Info-Tech Insights

If meaningful metrics are set up correctly, the CoE can produce results early in the one- or two-year process, demonstrating business value and increasing production amongst staff and demonstrating SME development.

CoE

What are the reason to build an M365 CoE, and what is it expected to deliver?

What It IS NOT

It does not design or build applications, migrate applications, or create migration plans. It does not deploy applications nor does it operate and monitor applications. While a steering committee is a key part of the M365 CoE, its real function is to set the standards to be achieved though metrics that can measure a successful, efficient, and best-in-class M365 operation. It does not set business goals but does align M365 goals to the business drivers. SMEs in the CoE give guidance on M365 best practices and assist in its adoption and users’ competency.

What It IS

M365 CoE means investing in and developing usage growth and adoption while maintaining governance and control. A CoE is designed to drive innovation and improvement, and as a business-wide functional unit, it can break down geographical and organizational silos that utilize their own tools and collaboration platforms. It builds a training and artifacts database of relevant and up-to-date materials.

Why Build It

Benefits that can be realized are:

• Building efficiencies, delivering quality training and knowledge transfer, and reducing risk from an organized and effective governance.
• Consistency in document and information management.
• Reusable templates and blueprints that standardize the business processes.
• Standardized and communicated business policies around security and best practices.
• Overcoming the challenges that comes with the titan of a platform that is M365.

Expected Goals and Benefits With Risk

Demonstrated impact for sustainability
Ensuring value is delivered
Ability to escalate to executive branch

The What?

What does the M365 CoE solve?

• M365 Adoption
• M365 tools templates
• SME in tools deployment and delivery
• Training and education – create artifacts and organize training sessions and certifications
• Empower users into super users
• Build analytics around usage, adoption, and ROI from license optimization

And the How?

How does the M365 CoE do it?

• By defining clear adoption goals and best practices
• By building a dedicated team with the confidence to improve the user experience
• By creating a collection of reusable artifacts.
• By establishing a stable, tested environment ensures users are not hindered in execution of the tools
• By continuously improving M365 processes

What are the Risks?

• All goals must be achievable
• Timeline phases are based on core SME competency of the IT department and the training quality of end users
• Current state of SMEs in house or hired to execute the mandate of the M365 CoE
• Business success – if business is struggling to make profits and grow, its usually the CoE that will get chopped – mainly due to layoffs
• Inability to find SMEs or train SMEs
• Turnover in CoE due to job function changes or attrition
• Overload of day-to-day responsibilities preventing SMEs from executing work for the CoE – Need to align SMEs and CoE steering chair to establish and enable shared responsibilities.

Who needs to be in a CoE for M365

Design the CoE – What model to be used?

What are their daily tasks? Is the CoE centralized, decentralized, or a combination?

Info-Tech Insights

Due to the size and complexity of Microsoft 365, a decentralized model works best. Each segment of the group could in themselves be a CoE, as in governance, training, or collaboration CoE. Maintaining SME in each group will drive the success of the M365 CoE.

Key Competencies for CoE

• Build a team of experts in M365 with sub teams in Products.
• Manage the business processes around M365.
• Train and optimize technical teams.
• Share best practices and create a knowledge base.
• Build processes that are repeatable and self-provisioned.

CoE for M365

What is the Structure? Is it centralized, decentralized, or combination? What are the pros and cons?

Thought Model

How does the CoE differ from governance?

Why is it going to be any more successful?

“These problems already exist and haven't been successfully addressed by governance – how is the CoE going to be any different?”

• Leadership
• Empower end users
• Automation of processes
• Retention policies
• Governance priorities
• Risk management
• Standard procedures
• Set metrics
• Self service
• Training
• SMEs
• Automation
• Innovation

CoE

While M365 governance is an integral part of the M365 CoE, the CoE is a more strategic program aimed at providing guidance, experienced leadership, and training.

The CoE is designed to drive innovation and improvements throughout the organization’s M365 deployment. It will build best practices, create artifacts, and mentor members to become SMEs.

Governance

CoE is a form of collaborative governance. Those responsible for making the rules are the same ones who are working through how the rules are implemented in practice.

The word most associated with CoE is "nurture." The word most associated with governance is "prevent."

The CoE is experimental and innovative and constantly revising its guidance compared to governance, which is opaque and static.

RACI chart for CoE define activities and ownership

The Work

Build artifacts

Templates

Scripts

Reference architecture

Policies definition

Blueprints

Version control

Measure usage and ROI

Quality assurance

Baseline creation and integrity

Steering Committee

Roles and Responsibilities

• Set the goals and metrics for the CoE charter
• Ensure the CoE is aligned to the business objectives
• Clear any roadblocks that may hinder progress for the team leads
• Provide guidance on best practices
• Set expectations for training and certifications
• Build SME strength through mentoring
• Promote and facilitate research into M365 developments and releases
• Ensure knowledge transfer is documented
• Create roadmap to ensure phase KPIs are met and drive toward excellence

Info-Tech Insight

Executive sponsorship is an element of the CoE that cannot be overlooked. If this occurs, the funding and longevity of the CoE will be limited. Additionally, ensure you determine if the CoE will have an end of life and what that looks like.

M365 Governance CoE Team

Governance and Management

After you’ve developed and implemented your data classification framework, ongoing governance and maintenance will be critical to your success. In addition to tracking how sensitivity labels are used in practice, you’ll need to update your control requirements based on changes in regulations, cybersecurity leading practices, and the nature of the content you manage. Governance and maintenance efforts can include:

• Establishing a governance body dedicated to data classification or adding a data classification responsibility to the charter of an existing information security body.
• Defining roles and responsibilities for those overseeing Data Classification
• Establishing KPIs to monitor and measure progress
• Tracking cybersecurity leading practices and regulatory changes
• Developing Standard Operating Procedures that support and enforce a data classification framework

Governance CoE

Tools Used in the Governance CoE Identity – MFA, SSO, Identity Manager, Conditional Access, AD , Microsoft Defender, Compliance Assessments Templates

Security and Compliance - Azure Purview, Microsoft Defender Threat Analytics, Rules-Based Classification (AIP Client & Scanner), Endpoint DLP, Insider Risk Management

Information Management – Audit Log Retention, Information Protection and Governance, Trainable Classifiers

Licenses – Entitlement Management, Risk-Based Conditional Access.

M365 Tools CoE Team

• Collaboration tools are at the center of the product portfolio for M365.
• Need to get users empowered to manage and operate Teams, OneDrive, and SharePoint Online and promote uniform communications and collaborate with document building, sharing, and storing.

Collaboration SME – Teams admin, Exchange admin, SharePoint, One Drive admin, Viva Learning (Premium), and Viva Insights (Premium)

Application SME – Covers all updates and new features related to Office programs

Power BI SME – Covers Power Automate for Office 365, Power Apps for Office 365, and Power BI Pro

Voice and Video – Tools-Calling Plan, Audio Conference (Full), Teams Phone, Mobility

PMO – Manages all M365 products online and in production. Also coordinates enhancements, writes up documentation for updates, and releases them to the training CoE for publication.

Microsoft 365 tools used to support business

• Appointments – Booking
• Blog – Sway
• Browser – Edge
• Cloud Storage – OneDrive
• Collaboration – Teams
• Email and Calendar – Outlook
• Notebook – OneNote
• Planner – Planner
• Presentation – PowerPoint
• Spreadsheet - Excel
• Surveys/Quizzes/Polls - Forms
• Whiteboard - Whiteboard
• Word Processor – Word
• Voice – Teams Phone

M365 Training CoE Team

Training and certifications for both end users and technical staff managing the M365 platform. Ensure that you set goals and objectives with your training schedule.

Training for SMEs can be broken into two categories:

First line training is internal training for users, in the collaboration space. Teams, One Drive, SharePoint Online, Exchange, and specialty training on Office tools – Word, PowerPoint, Excel, and Microsoft Forms.

Second line training is professional development for the SMEs including certifications in M365 admin, Global admin, Teams admin, and SharePoint administrator.

Additional training and certification can be obtained in governance, information management, and in the admin center for licencing optimization and compliance.

Tools used

• Viva topics – Integrated knowledge and expert discovery
• Viva Insight
• Viva Learning
• Viva Connections
• Dynamics 365
• Voice of the customer surveys

Support M365 CoE Team

Support CoE:

In charge of creating a knowledge base for M365. Manages incidents with access, usage, and administering apps to desktop. Manages change issues related to updates in patching.

Help Desk Admin:

Resets passwords when self service fails, force sign out, manages service requests.

Works with learning CoE to populate knowledge base with articles and templates.

Manages end user issues with changes and enhancements for M365.

Supporting Metrics

• Number of calls for M365 support
• Recurring M365 incidents
• Number of unresolved Platform issues
• First call resolution
• Knowledge sharing of M365
• Customer satisfaction
• Turnaround time of tickets created

Roadmap

How does the CoE evolve over time as enterprises become more mature?

• Depending on the complexity and regulatory requirements of the business, baseline governance and rules around external partners sharing internal documents will need to be set up.
• Identifying your SMEs in the organization is a perquisite at the beginning stages of setting up the M365 working group.

• Build a roadmap to get to maturity and competency that brings strategic business value.
• Meet milestone goals through a two-year, three-phase process. Begin with setting up governance guardrails.
• Set up foundational baselines against which metrics will be measured.
• Set up the M365 CoE, at first with target easy wins through group training and policy communications throughout the organization.

How do you turn artifacts like best practice documents into actual behavior change?

Info-Tech Insights

Building Blocks
The building blocks for a change in end user behavior are based on four criteria which must be clearly communicated. Knowledge transfer from SMEs to the training team is key. That in turn leads to effective knowledge transfer, allowing end users to develop skills quickly that can be shared with their teams. Sharing practices leads to best practices and maintaining these in a repository that can be quickly accessed will build on the efficiencies and effectiveness of the employees.

How Do You Empower End Users to Innovate?

Info-Tech Insights

Understand the Vision

Empowering End users starts with understanding the business vision that is embedded into the M365 CoE charter.

Ensure that the business innovation goals are aligned to the organizational strategies.

The innovative strategies need to be clearly communicated to the employees and the tools to achieve this needs to be mapped out and trained. Clearly lay out the goals, outcomes, and expectations.

End users need to understand how the M365 CoE will assist them in their day-to-day operations, whether in the collaboration space with their colleagues, or with power BI that assists them in their decision making though analytics.

The Right Resources

Arm your team with the resources they need to be successful. Building use cases as part of the training program will give the employees insight into how the M365 tools can be used in their daily work environment. It will also address the pervasive use of nonstandard tools as is seen throughout organizations that are operated in a vacuum.

Empowering your user base though the knowledge transfer borne through the building of artifacts that deal with real life examples that join the dots for employees.

By painting a picture of how the innovative use of the M365 platform can be achieved, users will feel empowered and use those use cases to build out their own innovative ideas.

Hybrid Work

Digital fabric

Collaboration – Communication – Creation

Cloud Services – Innovative Apps – Security

Productivity anywhere any place

Shared working documents in secure cloud

Mesh for Microsoft Teams/Viva

Power apps and dataverse for Teams

Self Service M365

My Apps

My Sign-Ins

My Groups

My Staff

My Access

My Account

Password reset

Sample Best Practices
Tools and Standards Templates

Then communicate them

Collaboration Best Practices

Sharing documents

Real time co-authoring

Comment

Meet

Mobile

Version History

Security Best Practices

Default Security Settings

Microsoft Security Score

Enable Alert Policies

Assign RBAC for Admins

Enable Continuous Access Evaluation

Admin Roles Best Practices in M365

• Two or three global admins in tenant/limit usage of secondary admin roles
• See Admin Portal
• •Screen shots: Best Practices Securing M365

Business Success Metrics for M365 CoE

What does success look like?

• Are you aligning the M365 metrics to business goals?
• Are your decisions data driven?
• Are you able to determine opportunities to improve with your metrics – continuous process improvement?
• Are you seeing productivity gains, and are they being measured?

Activity Output

Start building your M365 CoE and considering the steps for the Phase 1 checklist

BUILD A FOUNDATIONAL BASELINE

Step 1

1. Select Resources to create a CoE working group
2. Define your goals and objectives
3. Identify SMEs within the business and do a gap analysis
4. Build the M365 charter, mission, and vision
5. Build consensus and sponsorship from C suite
6. Create an organizational M365 framework that provides best coverage for all touch points to the platform, from support to training to controls.
7. Determine the type of CoE you want to create that fits your business (centralized, distributed, or a combination).

Step 2

1. Build training plans for SMEs and M365 teams
2. Populate company intranet with artifacts, knowledge articles, and user training portal with all things M365
3. Build out best practice workbooks, tools, and templates that encompass all departments
4. Create roles and responsibilities matrix
5. Identify “super users” in departments to assist with promoting learning and knowledge sharing.
6. Develop Metrics scorecards on success criteria ensuring they align to business goals

Step 3

1. Rational M365 licensing
2. Create communication plan promoting CoE and M365 advantages
3. Align your governance posture and building guardrails
4. Identify legacy apps that can be retired and replaced
5. Train support team and analysts with metrics supporting M365 CoE goals
6. Create baseline metrics with clear alignment to business KPIs

Related Blueprints

Modernize Your Microsoft Licensing for the Cloud Era

• Take control of your Microsoft licensing and optimize spend

Govern Office 365

• Office 365 is as difficult to wrangle as it is valuable. Leverage best practices to produce governance outcomes aligned with your goals

Migrate to Office 365 Now

• One small step to cloud, one big leap to Office 365. The key is to look before you leap

Build a Data Classification MVP for M365

• Kickstart your governance with data classification users will actually use!

Bibliography

“Five Guiding Principles of a successful Center of Excellence” Perficient, n.d. Web.

“Self Service in Microsoft 365.” Janbakker.tech, n.d. Web.

“My Apps portal overview.” Microsoft, June 2, 2022. Web.

“Collaboration Best Practices Microsoft365.” Microsoft, n.d. Web.

“Security Best Practices Microsoft 365” Microsoft, July 1, 2022. Web.

SoftwareReviews — A Division of INFO~TECH RESEARCH GROUP

Optimize Software Pricing in a Volatile Competitive Market

Leading SaaS product managers align pricing strategy to company financial goals and refresh the customer price/value equation to avoid leaving revenues uncaptured.

Table of Contents

Optimize Software Pricing in a Volatile Competitive Market

Leading SaaS product managers align pricing strategy to company financial goals and refresh the customer price/value equation to avoid leaving revenues uncaptured.

EXECUTIVE BRIEF

Analyst Perspective

Optimized Pricing Strategy

Product managers without well-documented and repeatable pricing management processes often experience pressure from “Agile” management to make gut-feel pricing decisions, resulting in poor product revenue results. When combined with a lack of customer, competitor, and internal cost understanding, these process and timing limitations drive most product managers into suboptimal software pricing decisions. And, adding insult to injury, the poor financial results from bad pricing decisions aren’t fully measured for months, which further compounds the negative effects of poor decision making.

A successful product pricing strategy aligns finance, marketing, product management, and sales to optimize pricing using a solid understanding of the customer perception of price/value, competitive pricing, and software production costs.

Success for many SaaS product managers requires a reorganization and modernization of pricing tools, techniques, and data. Leaders will develop the science of tailored price changes versus across-the-board price actions and account for inflation exposure and the customers’ willingness to pay.

This blueprint will build your skills on how to price new products or adjust pricing for existing products. The discipline you build using our pricing strategy methodology will strengthen your team’s ability to develop repeatable pricing and will build credibility with senior management and colleagues in marketing and sales.

Joanne Morin Correia Principal Research Director SoftwareReviews

Executive Summary

SoftwareReviews Insight

Product leaders will price products based on a deep understanding of the buyer price/value equation and alignment with financial and competitive pricing strategies, and they will make ongoing adjustments based on an ability to monitor buyers, competitors, and product cost changes.

What is an optimized price strategy?

SoftwareReviews Insight

An optimized pricing strategy establishes the “best” price for a product or service that maximizes profits and shareholder value while considering customer business value vs. the cost to purchase and implement – the total cost of ownership (TCO).

Challenging environment

Pricing skills are declining

Key considerations for more effective pricing decisions

New product price approach

Is Your Pricing Strategy Optimized? With the right pricing strategy, you can invest more money into your product, service, or growth. A 1% price increase will improv revenues by: Price monetization will almost double the revenue increases over customer acquisition and retention. (Pricing Strategies, Growth Ramp, March 2022)	DIAGNOSE PRICE CHALLENGES Prices of today's cloud-based services/products are often misaligned against competition and customers' perceived value, leaving more revenues on the table. Do you struggle to price new products with confidence? Do you really know your SaaS product's costs? Have you lost pricing power to stronger competitors? Has cost focus eclipsed customer value focus? If so, you are likely skipping steps and missing key outputs in your pricing strategy.
OPTIMIZE THESE STEPS ALIGNMENT Assign Team Responsibilities Set Timing for Project Deliverables Clarify Financial Expectations Collect Customer Contacts Determine Competitors BEFORE RESEARCH, HAVE YOU Documented your executive's financial expectations? If "No," return. RESEARCH & VALIDATE Research Competitors Interview Customers Test Pricing vs. Financials Create Pricing Presentation BEFORE PRESENTING, HAVE YOU: Clarified your customer and competitive positioning to validate pricing? If "No," return. BUY-IN Executive Pricing Presentation Post-Mortem of Presentation Document New Processes Monitor the Pricing Changes BEFORE RESEARCH, HAVE YOU: Documented your executive's financial expectations? If "No," return.
DELIVER KEY OUTPUTS Sponsoring executive(s) signs-offs require a well-articulated pricing plan and business case for investment that includes: Competitive features and pricing financial templates Customer validation of price value Optimized price presentation Repeatable pricing processes to monitor changes REAP THE REWARDS Product pricing is better aligned to achieve financial goals Improved pricing skills or professional development Stronger team reputation for reliable price management

Key Insights

1. Gain a competitive edge by using market and customer information to optimize product financials, refine pricing, and speed up decisions.
2. Product leaders will best set software product price based on a deep understanding of buyer/price value equation, alignment with financial strategy, and an ongoing ability to monitor buyer, competitor, and product costs.

SoftwareReviews’ methodology for optimizing your pricing strategy

Insight summary

Modernize your price planning

Blueprint deliverables

Guided Implementation

A Guided Implementation (GI) is a series of calls with a SoftwareReviews analyst to help implement our best practices in your organization.

A typical GI is 4 to 8 calls over the course of 2 to 4 months.

What does a typical GI on optimizing software pricing look like?

SoftwareReviews Offers Various Levels of Support to Meet Your Needs

Desire a Guided Implementation?

• A GI is where your SoftwareReviews engagement manager and executive advisor/counselor will work with SoftwareReviews research team members to craft with you a Custom Key Initiative Plan (CKIP).
• A CKIP guides your team through each of the major steps, outlines responsibilities between members of your team and SoftwareReviews, describes expected outcomes, and captures actual value delivered.
• A CKIP also provides you and your team with analyst/advisor/counselor feedback on project outputs, helps you communicate key principles and concepts to your team, and helps you stay on project timelines.
• If Guided Implementation assistance is desired, contact your engagement manager.

1.0 Assign team responsibilities

Input: Steering committee roles and responsibilities, Steering committee interest and role

Output: List of new pricing strategy steering committee and workstream members, roles, and timelines, Updated Software Pricing Strategy presentation

Materials: Optimize Software Pricing in a Volatile Competitive Market Presentation Template

Participants: CFO, sponsoring executive, Functional leads – development, product marketing, product management, marketing, sales, customer success/support

1. The product manager/member running this pricing/repricing program should review the entire Optimize Software Pricing in a Volatile Competitive Market blueprint and each blueprint attachment.
2. The product manager should also refer to slide 19 of the Optimize Software Pricing in a Volatile Competitive Market blueprint and decide if help via a Guided Implementation (GI) is of value. If desired, alert your SoftwareReviews engagement manager.

3. The product manager should meet with the chief product officer/CPO and functional leaders, and set the meeting agenda to:
   1. Nominate steering committee members.
   2. Nominate work-stream leads.
   3. Establish key pricing project milestones.
   4. Schedule both the steering committee (suggest monthly) and workstream lead meetings (suggest weekly) through the duration of the project.
   5. Ask the CPO to craft, outside this meeting, his/her version of the "Message from the chief product officer.”
   6. If a Guided Implementation is selected, inform the meeting attendees that a SoftwareReviews analyst will join the next meeting to share his/her Executive Brief on Pricing Strategy.
4. Record all above findings in the Optimize Software Pricing in a Volatile Competitive Market Presentation Template.

Download the Optimize Software Pricing in a Volatile Competitive Market Presentation Template

SoftwareReviews Advisory Insight:

Pricing steering committees are needed to steer overall product, pricing, and packaging decisions. Some companies include the CEO and CFO on this committee and designate it as a permanent body that meets monthly to give go/no-go decisions to “all things product and pricing related” across all products and business units.

2.0 Educate the team

Input: Typically, a joint recognition that pricing strategies need upgrading and have not been fully documented, Steering committee and working team members

Output: Communication of team members involved and the makeup of the steering committee and working team, Alignment of team members on a shared vision of “why a new price strategy is critical” and what key attributes define both the need and impact on business

Materials: Optimize Your Software Strategy Executive Brief PowerPoint presentation

Participants: Initiative manager – individual leading the new pricing strategy, CFO/sponsoring executive, Working team – typically representatives in product marketing, product management, and sales, SoftwareReviews marketing analyst (optional)

1. Walk the team through the Optimize Software Pricing in a Volatile Competitive Market Executive Brief PowerPoint presentation.
2. Optional – Have the SoftwareReviews Advisory (SRA) analyst walk the team through the Optimize Software Pricing in a Volatile Competitive Market Executive Brief PowerPoint presentation as part of your session. Contact your engagement manager to schedule.
3. Walk the team through the current version of the Optimize Software Pricing in a Volatile Competitive Market Presentation Template outlining project goals, steering committee and workstream make-up and responsibilities, project timeline and key milestones, and approach to arriving at new product pricing.
4. Set expectations among team members of their specific roles and responsibilities for this project, review the frequency of steering committee and workstream meetings to set expectations of key milestones and deliverable due dates.

Download the Optimize Software Pricing in a Volatile Competitive Market Executive Brief

3.0 Document portfolio and target products for pricing update

Input: List of entire product portfolio

Output: Prioritized list of product candidates that should be repriced

Materials: Optimize Software Pricing in a Volatile Competitive Market Executive Brief presentation, Optimize Software Pricing in a Volatile Competitive Market Workbook

Participants: Initiative manager – individual leading the new pricing strategy, CFO/sponsoring executive, Working team – typically representatives in product marketing, product management, and sales

1. Walk the team through the current version of Optimize Software Pricing in a Volatile Competitive Market workbook, tab 2: “Product Portfolio Organizer.” Modify sample attributes to match your product line where necessary.
2. As a group, record the product attributes for your entire portfolio.
3. Prioritize the product price optimization candidates for repricing with the understanding that it might change after meeting with finance.

Download the Optimize Software Pricing in a Volatile Competitive Market Workbook

4.0 Clarify product target margins

2-3 sessions of 1 Hour each

Input: Finance partner/CFO knowledge of target product current and future margins, Finance partner/CFO who has information on underlying costs with details that illustrate supplier contributions

Output: Product finance markup target percentage margins and revenues

Materials: Finance data on the product family, Optimize Software Pricing in a Volatile Competitive Market Workbook, Optimize Software Pricing in a Volatile Competitive Market Presentation Template

Participants: Initiative manager, Finance partner/CFO

1. Schedule a meeting with your finance partner/CFO to validate expectations for product margins. The goal is to understand the detail of underlying costs/margins and if the impacts of supplier costs affect the product family. The information will be placed into the Optimize Software Pricing in a Volatile Competitive Market Workbook on tab 2, Product Portfolio Organizer under the “Unit Margins” heading.
2. Arrive at a final “Cost-Plus New Price” based on underlying costs and target margins for each of the products. Record results in the Optimize Software Pricing in a Volatile Competitive Market Workbook, tab 2, under the “Cost-Plus New Price” heading.
3. Record product target finance markup price under “Cost-Plus” in Optimize Software Pricing in a Volatile Competitive Market Presentation Template, slide 9, and details in Appendix, “Cost-Plus Analysis,” slide 11.
4. Repeat this process for any other products to be repriced.

Download the Optimize Software Pricing in a Volatile Competitive Market Workbook

Download the Optimize Software Pricing in a Volatile Competitive Market Presentation Template

5.0 Establish customer price to value

1-4 weeks

Input: Identify segments within which you require price-to-value information, Understand your persona insight gaps, Review Sample Interview Guide using the Optimize Software Pricing in a Volatile, Competitive Market Workbook, Tab 4. Interview Guide.

Output: List of interviewees, Updated Interview Guide

Materials: Optimize Software Pricing in a Volatile Competitive Market Workbook, Optimize Software Pricing in a Volatile Competitive Market Presentation Template

Participants: Initiative manager, Customer success to help identify interviewees, Customers, prospects

1. Identify a list of customers and prospects that best represent your target persona when interviewed. Choose interviewees who will inform key differences among key segments (geographies, company size, a mix of customers and prospects, etc.) and who are decision makers and can best inform insights on price/value and competitors.
2. Recruit interviewees and schedule 30-minute interviews.
3. Keep track of interviewees using the Optimize Software Pricing in a Volatile Competitive Market Workbook, tab 3: “Interviewee Tracking.”
4. Review the Optimize Software Pricing in a Volatile Competitive Market Workbook, tab 4: “Interview Guide,” and modify/update it where appropriate.
5. Record interviewee perspectives on the “price they are willing to pay for the value received” (price/value equation) using the Optimize Software Pricing in a Volatile Competitive Market Workbook, tab 4: “Interview Guide.”
6. Summarize findings to result in an average “customer’s value price.” Record product target ”customer’s value price” in Optimize Software Pricing in a Volatile Competitive Market Presentation Template, slide 9 and supporting details in Appendix, “Customer Pricing Analysis,” slide 12.

Download the Optimize Software Pricing in a Volatile Competitive Market Workbook

Download the Optimize Software Pricing in a Volatile Competitive Market Presentation Template

6.0 Identify competitive pricing

1-2 weeks

Input: Identify price candidate competitors, Your product pricing, contract type, and product attribute information to compare against, Knowledge of existing competitor information, websites, and technology research sites to guide questions

Output: Competitive product average pricing

Materials: Optimize Software Pricing in a Volatile Competitive Market Workbook, Optimize Software Pricing in a Volatile Competitive Market Presentation Template

Participants: Initiative manager, Customers, prospects

1. Identify the top 3-5 competitors’ products that you most frequently compete against with your selected product.
2. Perform competitive intelligence research on deals won or lost that contain competitive pricing insights by speaking with your sales force.
3. Use the interviews with key customers to also inform competitive pricing insights. Include companies which you may have lost to a competitor in your customer interviewee list.
4. Modify and add key competitive pricing, contract, or product attributes in the Optimize Software Pricing in a Volatile Competitive Market Workbook, tab 5: “Competitive Information.”
5. Place your product’s information into the Optimize Software Pricing in a Volatile Competitive Market Workbook, tab 5: “Competitive Information.”
6. Research your competitors’ summarized pricing and product attribute insights into the workbook.
7. Record research in the Summarize research on competitors to arrive at an average “Competitors Avg. Price”. Record in ”Customer’s Value Price” in Optimize Software Pricing in a Volatile Competitive Market Presentation Template, slide 9, and details in Appendix, “Competitor Pricing Analysis,” slide 13.

Download the Optimize Software Pricing in a Volatile Competitive Market Workbook

Download the Optimize Software Pricing in a Volatile Competitive Market Presentation Template

7.0 Establish new price and gain buy-in

2-3 hours

Input: Findings from competitive, cost-plus, and customer price/value analysis

Output: Approvals for price change

Materials: Optimize Software Pricing in a Volatile Competitive Market Presentation Template

Participants: Initiative manager, Steering committee, Working team – typically representatives in product marketing, product management, sales

1. Using prior recorded findings of Customer’s Value Price, Competitors’ Avg. Price, and Finance Markup Price, arrive at a recommended “New Price” and record in Optimize Software Pricing in a Volatile Competitive Market Presentation Template, slide 9 and the Appendix for Project Analysis Details.
2. Present findings to steering committee. Be prepared to show customer interviews and competitive analysis results to support your recommendation.
3. Plan internal and external communications and discuss the timing of when to “go live” with new pricing. Discuss issues related to migration to a new price, how to handle currently low-priced customers, and how to migrate them over time to the new pricing.
4. Identify if it makes sense to target a date to launch the new pricing in the future, so customers can be alerted in advance and therefore take advantage of “current pricing” to drive added revenues.
5. Confer with IT to assess times required to implement within CPQ systems and with product marketing for time to change sales proposals, slide decks, and any other affected assets and systems.

Download the Optimize Software Pricing in a Volatile Competitive Market Presentation Template

Bibliography

“Chapter 4 Reasons for Project Failure.” Kissflow's Guide to Project Management. Kissflow, n.d. Web.

Edie, Naomi. “Microsoft Is Raising SaaS Prices, and Other Vendors Will, Too.” CIO Dive, 8 December 2021. Web.

Gruman, Galen, Alan S. Morrison, and Terril A. Retter. “Software Pricing Trends.” PricewaterhouseCoopers, 2018. Web.

Hargrave, Marshall. “Example of Economic Exposure.” Investopedia, 12 April 2022. Web.

Heaslip, Emily. “7 Smart Pricing Strategies to Attract Customers.” CO—, 17 November 2021. Web.

Higgins, Sean. “How to Price a Product That Your Sales Team Can Sell.” HubSpot, 4 April 2022. Web.

“Pricing Strategies.” Growth Ramp, March 2022. Web.

“Product Management Skills Benchmark Report 2021.” 280 Group, 9 November 2021. Web.

Quey, Jason. “Price Increase: How to Do a SaaS Pricing Change in 8 Steps.” Growth Ramp, 22 March 2021. Web.

Steenburg, Thomas, and Jill Avery. “Marketing Analysis Toolkit: Pricing and Profitability Analysis.” Harvard Business School, 16 July 2010. Web.

“2021 State of Competitive Intelligence.” Crayon and SCIO, n.d. Web.

Valchev, Konstantin. “Cost of Goods Sold (COGS) for Software-as-a-Service (SaaS) Business.” OpenView Venture Partners, OV Blog, 20 April 2020. Web.

“What Is Price Elasticity?” Market Business News, n.d. Web.

Related SoftwareReviews Research