Skip to main content
All CollectionsArdoq Use Case SolutionsStrategy to Execution Series
Strategy to Execution: Purpose, Scope, and Rationale
Strategy to Execution: Purpose, Scope, and Rationale

Realize business objectives effectively and efficiently with Ardoq's Strategy to Execution solution.

Jason Baragry avatar
Written by Jason Baragry
Updated over a week ago

Ardoq’s approach to Strategy to Execution gives you the ability to define, monitor, and adjust your strategic objectives and how they are being delivered in response to changing business conditions.

Contents

Purpose and Value

More than half of Enterprises are failing in achieving their strategic objectives according to a survey by Gartner, Inc [Gartner 2022]. Similar statistics have been reported for the last few decades. For instance: [Kaplan 2005]:

  • On average, 95% of a company's employees are unaware of, or do not understand, its strategy*

  • HR and IT managers reveal that the strategies of fully 67% of those organizations are not aligned with business unit and corporate strategies. Budgeting is similarly disconnected with some 60% of organizations not linking their financial budgets to strategic priorities.*

In addition, an IBM survey of Fortune 1000 CIOs found that, on average, CIOs believe that 40 percent of all IT spending brought no return to their organizations* [Enterprise Value 2008]

Ardoq’s approach to Strategy to Execution allows everybody to understand the prioritized enterprise objectives, how they are being delivered, who is involved, and enables reprioritization as changes occur.

The first version of Strategy to Execution provides insight across objectives, initiatives, capability changes and impacts to applications and organization units. Subsequent iterations will deepen support for prioritization and benefit realization.

The Value of focusing on Strategy to Execution

The primary stakeholders for Ardoq Strategy to Execution are the company roles who are responsible for execution:

  • COO and CIO

  • Head of Portfolio Management

  • Initiative Owners

  • Project Managers and Architects

  • Roles that are accountable for Objectives at the company and team levels.

CEOs and CFOs are also relevant stakeholders because the company as a whole is receiving the value from the Strategy to Execution outcomes. But they are usually not active in the S2E process execution.

Role

Mission

Objective

Outcome

COO / CIO

  • Deliver on company strategy efficiently and effectively

  • Ensure benefit realization of investment decisions

  • Remove waste investment

  • Improve prioritization process

  • Ensure investments are made according to strategy

  • Enable time-to-value through autonomous decision making

  • Keep strategy updated and ensure all colleagues are updated

  • Keep objectives prioritized to enable execution prioritization

  • Effective use of investment to deliver on company goals

  • Effective use of talent and capacity

  • Effective time-to-value for business objectives

  • Better ratio of Investment between running- and growing-the-business

PMO (project mgmt office) / Initiative Owners

  • Prioritize and reprioritize in response to changing business conditions and strategy adjustments

  • Define cross-portfolio objectives aligned with company objectives

  • Keep objectives prioritized to enable execution prioritization

  • Keep business stakeholders appraised of progress and changes to prognosis

  • Up-to-date understanding of which initiatives are proposed and in execution

  • Up-to-date understanding of where impacts will occur and which teams need to be involved

  • Up-to-date information needed for (re)prioritization

PMs / Arch

  • Define value stream execution objectives aligned to portfolio and company objectives

  • Ensure team/product/ value-stream execution, impact and benefits is reflected at portfolio and company level

  • Provide continuously up-to-date information about the change management process for improved decision-making and execution

Measuring the Value of Strategy to Execution

A guiding principle for Ardoq is to monitor and measure metrics to show that you are delivering value to the business. The following is a list of possible metrics that can be measured to show the benefit of Strategy to Execution. A subset of these is implemented in the Ardoq use case and is detailed later in this document. You can extend the use case with your own metrics that will measure the value of the benefit you are delivering with S2E.

These metrics are derived from industry sources on Strategy to Execution, Value Realization and Benefits Management. That research shows a significant correlation between successful companies and those that:

  • Align Objectives to each other at multiple levels of the organization.

  • Align Objectives to Execution to ensure investment is based on up-to-date strategy.

  • Regularly review objectives in light of changed conditions and reprioritize accordingly.

  • Regularly review objectives for their quality in terms of prioritization and cascading execution.

  • Have clear prioritization and quantified success criteria for objectives

  • Have clear accountability for objectives and that people are held accountable for benefit realization from those objectives

  • Can quickly show where strategy to execution is not aligned so that decision-makers can react, discuss, and take action.

Outcome

Metric of Success

Example Ardoq Deliverable

Better investment execution through aligned Objectives

  • Objective Alignment

  • Initiative - Objective Alignment

  • Increased % of initiatives completed successfully on budget.

  • Dashboard widget and Report on non-alignment of Objectives.

  • Dashboard widget and Report on non-alignment of Initiatives and Objectives

  • Trend widget showing the change in alignment over time

  • Reports and Trend Widget on Initiative success

Increased objective success

  • Measure of OKR process success criteria (completeness)

  • Key Results (or equiv metrics) on Objectives to show they are being measured

  • Report and Dashboard widget showing OKR completeness over time

  • Data quality (DQ) report on Objectives without KRs or metrics.

Objectives leading to better Objective and Initiative prioritization decisions

  • Initiative time to prioritization

  • Metric on adequate capacity

  • Metric to capture opinion from non-top-level objective owners or team leads on the quality of objectives used for prioritization and execution

  • Is there clear objective prioritization to help Initiative planning.

  • Highlight contention of people and initiatives that impact the same places

  • Metrics on the number of interventions in the S2E process

  • Measure time period for Planned to Prioritized status changes on Initiatives

  • Survey to Initiative owners on adequate capacity. The number should trend down as prio improves

  • Survey to non-top-level objective owners - Do you have objectives from above that allows prio at your level?

  • Dashboard on objectives without priority between them

  • Dashboard, broadcast trigger showing where initiatives will have impact contention - same application of same teams that are required

Improved accountability for strategic execution

  • Opinion at top levels

  • Survey and dashboard for top-level (1-2). Do aligned descending objectives and initiatives deliver on your obj? Trend should go up

Improved reaction to changed context

  • Time to last objective review

  • Number of adjusted objectives within an objective active period

  • Number of intervention events for non-adjustment

  • Dashboard and Report of the number of incidents of non-compliance of objective review

Improved ratio of investment for Change rather than Run

  • Objective and Initiative classification in terms of Run, Grow, Transform

  • Dashboards the capture investment percentage between these 3 values

The Value of doing Strategy to Execution with Ardoq

Ardoq’s strength is to provide up-to-date insights from complex, interconnected and dynamic information that is updated across the entire company.

Flexibility

  • Each enterprise has a different way of doing Strategy & Objectives and Change Portfolio Management. Use Ardoq’s approach for immediate time-to-value or adapt it to the way your company operates

Up-to-date information for decision making

  • Integrations to maintain up-to-date information from external information sources

  • Surveys and Broadcasts to get information from the people with the most up-to-date knowledge with the least effort

  • Data quality dashboards and policies to automatically trigger relevant stakeholders when information needs to be updated

Ownership and Accountability

  • All information types - objectives, initiatives, metrics, etc - have owners who are responsible for maintaining and updating information. These people are automatically notified to update information as data changes or as time triggers are met.

Scope and Rationale

This document describes the purpose, scope, and rationale for the Strategy to Execution Series. It will be updated as new versions of the Use Case are released.

The scope of the Strategy to Execution Series is defined by the following sets of questions for enterprise stakeholders. They can be summarized as: what are we doing, why are we doing it, and what benefit will it bring to the organization?

Questions to be answered using Strategy to Execution

Strategy and Objectives

  • What are the Strategy and Objectives for the Enterprise?

  • What are the Objectives for each organization unit?

  • What are the Strategy and Objectives at a particular point in time or over a timespan?

  • What are the highest priority Objectives?

  • How are company level objectives aligned with specific objectives of individual organization units?

  • Do all Objectives have effective ownership and alignment to company-level strategy?

Objective Progress

  • What is the progress of a particular set of Objectives?

  • What is the progress compared to the time period they are relevant for?

  • What is the aggregated progress for cascading or aligned Objectives?

  • When were organization unit objectives last updated?

  • What are the time dependencies between Objectives? Which need to be achieved in order to enable others?

Objectives and Execution

  • Which Initiatives are we performing to deliver on our Objectives?

  • What are the timelines of those Initiatives?

  • What is the status of those Initiatives and therefore status of Objectives?

  • Which Initiatives are proposed, prioritized, in execution and complete?

  • What are the dependencies between Initiatives and when are they planned to execute?

  • What is the budget and cost of each Initiative and, by extension, budget and cost of each Objective?

  • How much are we spending on each top-level Objective based on the aligned organization unit Objectives and subsequent Initiatives?

  • Which teams are responsible for delivering Initiatives and therefore Objectives?

  • Which teams will be impacted if prioritizations change?

  • Can we create communication channels between people and teams working on the same Objectives?

Execution, Impact and Benefits

  • What business benefits will we get from each Initiative?

  • What business capability changes are needed to deliver on Objectives?

  • What is the business roadmap for the organization?

  • When will company-level benefits be delivered?

  • Which applications and operational teams will be improved / impacted by Initiatives?

  • What are individual teams working on and what's the benefit for the business?

  • Do we have critical business capabilities that are not being improved by current Objectives?

Each of these questions is used to create a slide in an Ardoq presentation, report, dashboard and/or a Discover viewpoint that is provided together with the use case sample data.

Strategy & Objectives

Ardoq’s Strategy to Execution implementation starts with Objectives & Key Results (OKRs). This section explains the concepts and rationale. The complete details are provided in the Strategy to Execution Metamodel document.

There are many approaches to representing strategy and objectives in enterprise architecture frameworks. For example, BizBOK describes multiple approaches to modeling this area and provides a definition for the Strategy Domain of The Business Architecture Metamodel. Similarly, Archimate provides a detailed set of Motivation elements that cover this area, while BTABoK from IASA, provides its own description about how to model Strategy. And there are many more approaches in the industry.

One of Ardoq’s principles for EA modeling is to focus on usefulness over precision detail. Our analysis of the industry, and our customer base, shows that there is no common or even primary approach that enterprises use. It is one of multiple strategy definition frameworks that are available, for instance, balanced scorecards, a more informal approach such as OKRs, or their own ad-hoc approach to strategy definition. That research also shows that successful EAs use an approach that captures Strategy & Objectives as they are utilized in their company rather than specified in an EA framework. Discussions with our customers and partners showed that EAs that used formal strategy and objective metamodels from EA frameworks were less successful in getting them adopted as a common tool between Business and IT.

OKRs provide an approach that is used successfully by many organizations and is simple enough to also be adapted to ad-hoc usage. The purpose of the Strategy to Execution Use Case Guide(s) is to help organizations answer the questions posed earlier in this document. That requires a simple way to connect the strategic objectives of the enterprise to the initiatives that are ongoing, where the impact will be, and the benefits they will provide. And, from a bottom-up perspective, what is the company working on, why are they doing it, and how do they know if they’re being successful. This requires less precision in modeling the goals, visions, strategies, and motivations of the enterprise and more about the interconnections between objectives and execution.

Ardoq’s metamodel flexibility allows users to extend the initial set of concepts provided in the Use Case Guide to use a more detailed strategy and objectives model from one of the previously mentioned frameworks. The configuration needed to aggregate information from execution concepts to objectives would then need to be modified to suit.

The Objectives workspace provides concepts for Objectives and Key Results. Key Results are part of an Objective (parent-child relationship) and there can be relationships between Objectives.

Key Results are optional. Users can choose if they want to use these components for a full OKR implementation or if they only want to use Objective components in a more informal approach.

We use the Objective component type to represent both strategies and objectives. Our research shows that it's more important to deliver insight into the relationship between strategy and execution than it is to have high-fidelity differentiation of concepts about business motivation.

We recognize that a strategy is conceptually different to an objective. A strategy is a broad approach taken to achieve an organizational goal or vision, whereas an objective is a measurable step taken to achieve that strategy. However, from a structural perspective, strategy and objectives can be implemented using the same component type - the Objective component. A strategic objective may apply over a longer time span and may not have specific key results. Using one component to represent both strategy and objective allows the Use Case to more easily aggregate progress and investment information between these concepts.

Another reason to use the Objective component type for both strategies and objectives is that it makes it easier to analyze relationships from a single component type to allow information about cost, progress, and status to be aggregated from connected components, such as Capabilities and Initiatives, up to the Objectives.

Ardoq recommends having Objectives that are aligned throughout the organization. There is significant discussion in the industry about cascading versus aligned OKRs. We provide the ‘Is Supported By’ reference type to define relationships between Objectives. Users can choose whether this reference should represent aligned or cascading relationships.

The ‘Is Supported By’ reference is used by the use case to aggregate progress and cost/budget information between Objectives. The Strategy to Execution metamodel document explains the algorithm in more detail and how users can configure it to their specific context.

All active Objectives should be realized by at least one Initiative, as described in the next section. The cost, budget, and progress fields on an objective are calculated values from those connected Initiatives. Users that want to use OKRs without connected initiatives need to extend the component definition with manual fields to capture those attributes.

Objectives have an additional field for completeness. This field is manually set and captures the final percentage completeness achieved for an objective. OKR Objectives are recommended to be set so that teams achieve approximately 70% completeness. We use this manual field in addition to the progress field which is automatically calculated based on the progress of Initiatives that realize the Objective. Users can adjust how they use these fields based on how they define objective progress and their adherence to OKR techniques.

Objectives, and Initiatives which will be detailed later, contain a field for categorizing the strategic investment type. One of the goals of this use case is to improve investment in initiatives according to strategy. This field classifies objective and initiative investments so you can measure the ratio of investment that focuses on improving the business compared to simply running the business. The categories follow the Gartner recommendations for investment classification:

  • Run: This is an investment that is focused on the continuing operation of the business. Some businesses call this “business as usual,” “keep the lights on” IT spending or “sustain investments.” Run expenses do not directly increase revenue, or achieve new or enhanced goals of the enterprise by themselves.

  • Grow: This is an investment in developing and enhancing IT systems in support of business growth (typically organic growth). Discretionary investments are more likely to be included in the grow-the-business or transform-the-business cost.

  • Transform: This is an investment focused on implementing information and technology systems that enable the enterprise to enter new markets, address new customer segments, create new value propositions, and enact new business models.

Note: Grow and Transform can be grouped into a single category for Change.

Finally, if your organization is successful at using a more sophisticated approach to business motivation, such as the metamodels defined in BizBOK or Archimate Business Motivation Model, then you can easily extend the concepts in this workspace to implement those concepts or use Ardoq’s existing Archimate workspace template directly.

Key Result v Metric

The Key Result component type can be confused with the existing Metric component type. It is correct that both these types capture a quantifiable benefit and that the Metric component type could be used in place of a Key Result. However, we provide the Key Result component type for the following reasons:

  • Objectives & Key Results are a known approach to modeling goals and their progress. It is important to provide both component types that are part of this conceptual model.

  • Key Results are part of the parent-child relationship with Objectives. In the Ardoq metamodel, this represents that the child is an exclusive part of the parent. That is, it is not possible to have a Key Result that is independent of an Objective. In contrast, a Metric is a measure that can exist separately from another component type that is associated with it.

Change Initiatives

An Initiative represents work to be done to deliver on Objectives. As a rule of thumb, an Initiative is something that has its own prioritization and investment decision. Initiative descriptions can be at multiple levels of detail and Initiatives can be hierarchic - Initiatives with sub-Initiatives - so it is possible to have a detailed hierarchy of Initiatives that are maintained within Ardoq. Additionally, Initiatives can be linked to project management issues that are imported from external tools, such as JIRA.

Initiative components can have two types of relationships to other Initiatives:

  1. Parent-child relationship. Where one Initiative is part of another initiative.

  2. Is Dependency For. This represents that one Initiative must be executed before another can execute.

Aggregation of progress and cost information occurs from Initiatives to Objectives. These follow the ‘is Realized By’ reference and only happen from the Initiative component directly connected to the Objective. There is no aggregation within an Initiative hierarchy. Aggregation roll-ups do not follow dependency relationships.

Figure: model of an Initiative hierarchy with multiple child Initiatives as part of a larger Programme

An important part of Strategy to Execution in Ardoq is to connect strategy to actual execution tasks. In addition to the hierarchy of Initiative components defined in Ardoq, it is possible to import tasks from external issue- and project-tracking solutions. Ardoq is working on an improved JIRA integration that will allow import of projects, epics and tasks. Organizations that use other tools can use Ardoq’s Excel import or custom integration capabilities. The Strategy to Execution use case provides a JIRA Excel import configuration that can be used until the integration is ready. This can also be used as an example to create an excel import from other tools. Import from tools other than JIRA should create a workspace with a similar structure to JIRA Import workspaces and not as a replacement for Change Initiative components.

These two workspaces - Initiatives and tasks imported from external issue trackers - provide two options for representing execution tasks. Users can choose if execution tasks should be represented as Initiative components directly in Ardoq or as components imported from external solutions or as a combination of the two. However, it is necessary to have at least one Initiative component that connects Objectives to items imported from issue- and project-tracking solutions. That is, Objectives are only connected to Initiatives, not to imported tasks from issue tracking tools. Companies use issue-tracking tools in different ways that depend on their approach to project development. Some create separate projects with a full hierarchy of epics and tasks. Others use projects as an agile team backlog that may consist of individual tasks related to separate company Initiatives.

Companies use issue-tracking tools in different ways. Therefore it is necessary to have at least one Initiative component that acts as a connection point between these imported tasks and the Objectives and Capability Delta components. This is to allow our analysis scripts to aggregate progress, dates, and cost information from executing tasks to the relevant Objectives and Capability Deltas in Ardoq. Additionally, because companies use issue-tracking solutions in different ways we have not implemented aggregation of information, such as status, from imported tasks to the Initiative components defined in Ardoq. Contact your CSM for help on how to do this based on your context.

Users can utilize the following alternatives:

  • Full hierarchy of Initiative components with no imported task components

  • Single Initiative component and one or more imported task components in a hierarchy

  • Hierarchy of Initiative components and hierarchy of imported task components.

The choice of alternative impacts how you will aggregate and connect information. The Use Case Guide provides pre-built support to aggregate budget, cost, and progress information from the Initiative components to the Objectives that they realize. The full details are provided below. Aggregation of information from execution tasks to Objectives is limited to the reference from the first Initiative component referenced from an Objective component. That is, it does not traverse the hierarchy of Initiatives - though the algorithm can be extended to do that if it matches your context. This is explained in more detail later in this document.

Objectives have an ‘Is Realized By’ relationship to Initiatives. An Objective can be realized by multiple Initiatives and Initiatives can realize multiple Objectives. This reference is used to aggregate progress, budget, and cost information to Objectives. It is the responsibility of each user to understand how that information is aggregated when there are many-to-many relationships. This is especially important when aggregating cost information.

Figure: Visualization showing OKRs where the Objective name includes the [current progress percentage] that is aggregated from the Initiatives which realize the Objectives. Also shows color heat-map based on the objective priority.

The Folder component type in the above figure is used to group Objectives and Key Results within a workspace. Each Objective should be owned by an Organization Unit and by an individual Person (see Reference Types below), and these relationships can be used to create visualizations that group Objectives using those relationships. However, Organization Unit and Person exist in separate workspaces from Objectives, and because there is no parent-child relationship between Objectives within the workspace, this can result in many Objectives existing at the top-level of a workspace view.

Opening a workspace with a view that shows the entire workspace, for instance, Dependency Map, will result in many Objectives being visualized. The Folder component can group this large number of Objectives to help manage the visualization. Ardoq recommends using a folder structure that replicates the Organizational Unit ownership relationships. Folder components have no additional fields and are used only for cosmetic purposes.

References should be made from Initiatives to the Capability Deltas they realize. The reference between Capability Delta and Initiatives use the date range of the initiative to calculate the effective date range of the Capability Delta. If you connect from an imported task to the Capability Delta then that imported task will need the same field type so the effective date range can be calculated on the Capability Delta. More detail is provided in the metamodel description. See the section on Capability Delta for more information.

Initiative Impact and Capability Deltas

Impact

Knowing where Initiatives will impact the organization - both the Business and IT aspects - is important for answering the scope questions mentioned at the beginning of this document. The impact on the Business is captured with Impacts references between Initiatives and both Business Capabilities and the Organization Units that realize those capabilities.

Business and Technical Capabilities should already have Is Realized By references to the Applications and Organization Units as a result of performing the Business Capability Realization Use Case. It is necessary to create Impacts references in addition because there could be multiple applications and teams that realize a capability. The impacts reference identifies which ones are impacted to deliver a specific capability delta for a particular change initiative.

Scenarios are an important way to depict the impact of Initiatives. The Impacts references are a supplement to scenarios and are not meant as an alternative. Using these references in addition to scenarios provides the following advantages:

  • Impacts information can be shown on timeline and dependency map visualizations which is currently not possible with Scenarios. This makes possible it to create business roadmaps.

  • Impacts references can be connected to other components, in this case, Initiatives. Scenarios are currently not able to be connected through references. This allows impacts references to be used in analytics and other visualizations and viewpoints.

The Impacts references can also be easily archived when the Initiative has been completed. See the following section on the temporal nature of Strategy to Execution information.

Figure showing impacts of the “Implement New Enterprise Architecture Tool”

Figure showing a scenario of the “Implement New Enterprise Architecture Tool”

Capability Delta

It is important to define both where the impact of a change initiative will be and what the business benefit of those impacts will be. This is needed in Strategy to Execution to both highlight needs and benefit realization as well as to collect information needed for prioritization of proposed Initiatives. A business capability model is mostly stable over time. Capability components contain fields to define, for example, their maturity level but they don’t capture small improvement information that comes from specific change initiatives that exist for a relatively short period of time. As a result, we have created the Capability Delta component type to capture that information.

A Capability Delta represents a change to a Capability. Usually, that is a gap or improvement for an existing capability. That change may be an identified required change, i.e., a capability gap found during capability-based planning, or it could be an improvement that will be delivered as part of an Initiative. Sometimes a business objective requires the creation of whole new capabilities or the removal of capabilities as part of a business divestiture. A Capability Delta component can also represent the initial creation or removal of a capability. The concept of a Capability Delta is similar to the concept of a capability increment found in TOGAF.

Capability Deltas represent the business change needed for an objective and/or the benefit delivered from one or more Initiatives. A Capability component has ‘Is Impacted By’ references to one or more Capability Delta components. A Capability Delta is also the target of Realizes references from one or more Initiatives.

A loop of references will exist between Objective, Initiative and Capability Delta components, which may seem like duplicate information. However, this is necessary because of the processes that connect them together. Sometimes companies start with Objectives, then define Initiatives, and finally specify Capability Deltas as part of the business case development for the Initiative. Alternatively, a company may start with an Objective, then perform capability-based planning to identify Capability Deltas (gaps), which will later be realized by planning Initiatives. Users may end up with a loop of references but the process to get there will happen over a period of time and it may be necessary to create Capability Delta components from either the Objective or Initiative first.

Figure: Timeline showing projects and capability deltas as a roadmap. The visualization can be filtered to only show capability delta components for a business-only roadmap

Capability Delta components aggregate the datetime information from the Initiatives that realize them. As a consequence, they can be used to visualize the business roadmap for the organization. For instance as a timeline of business improvements to be delivered.

A Capability Delta will be created when a gap is identified to realize an Objective or when defining the business benefit of a proposed Initiative. The component will be relevant during the lifespan of the Initiative, or while the Objective remains relevant. But when the Initiative is finalized and the Objective is met then the maturity level of the Capability itself is adjusted and the Capability Delta component is archived. See the discussion below on the temporary nature of particular Strategy to Execution components. The current use case does not automatically update the maturity level when the referenced Initiatives are completed. But that could be included in a future iteration.

Navigating the Transient Nature of Strategy to Execution

All concepts defined in our Use Case Guides have an inherent lifecycle. Applications, IT Infrastructure, and Business Capabilities will continuously change and eventually be replaced. But those concepts will exist in EA models for long periods of time that are usually measured in years.

The concepts for Strategy to Execution, such as Objectives, Initiatives, impact references, and Capability Deltas, usually have much shorter life-cycles that are measured in months. Additionally, the volume and frequency of change for these concepts are much higher than Applications, Capabilities, etc. Consequently, there is a need to make Strategy to Execution concepts prominent in EA models when they are relevant for decision-making and then remove or minimize their visibility when they are no longer relevant.

Techniques for achieving this are discussed in Navigating the Transient Nature of Strategy to Execution.

The Strategy to Execution Process

The goal of Ardoq is to provide data-driven business insights and benefits by automating many aspects of your execution processes. This entails:

  • Identifying the process and process events

  • Stakeholders that needs to participate or consume information at this point in the process

  • The business information or deliverable that is needed by the stakeholder

The Strategy and Objectives Process

The Strategy and Objectives execution process is depicted as a simplified state-machine with defined states in the process and the trigger events between those states.

The following section describes the stakeholders, information requirements, and trigger events in more detail.

Each process state has the triggers (events) to enter the state, the stakeholder who is triggered and the information that stakeholder needs to provide or consume. This is then used to execute the process through Ardoq. Using this process definition allows you to identify:

  • Each of the events that should be considered as a broadcast from Ardoq

  • Each requirement for information that should be evaluated as a survey in Discover

  • Each requirement to consume information that should be evaluated as a dashboard, report, or viewpoint in Ardoq Discover, or as an Ardoq presentation slide

Process State

Trigger

Stakeholder and Information

Setting / Adjusting OKRs for a specific period

  • Start a new Objective period

  • Context change to adjust Objectives mid-period

  • Objectives are set for the defined period

  • Objective owners create or update Objective information

Executing current objective period

  • OKR assessment trigger

  • Objective owners assess preceding and succeeding objectives for quality

  • Objective owners assess changed context, such as reprioritization in the company, to determine if Objectives need adjustment

  • OKR data quality problem

  • Impacted Objective owners update objective information. Example rules are Objectives that are not aligned. Objectives without assigned priority. Objectives without Key Results or quantified metrics

  • Progress change trigger

  • Objective owners update objective and key result progress information and quantified metrics

Finalizing current objective period

  • Objective period end

  • Objective owners finalize information and set completeness scores

  • Execution owners evaluate succeeding objective performance

  • Objective process owner evaluate objective process performance

Evaluating and Adjusting S&O process

  • Objective process assessment trigger

  • Process owner updates trigger rules, viewpoints, dashboards, surveys and reports

The Initiative Execution Process

The Initiative Execution process is also described as a simple value chain. Organizations use many different initiative or project management processes. We have provided a simple process that can fit into your own organization - whether they are using a centralized PMO execution process or a fully distributed agile business approach.

Each process state has the triggers (events) to enter the state, the stakeholder who is triggered and the information that stakeholder needs to provide or consume. This can be used to execute the process through Ardoq. Using this process definition allows you to identify:

  • Each of the events that should be considered as a broadcast from Ardoq

  • Each requirement for information that should be evaluated as a survey in Discover

  • Each requirement to consume information that should be evaluated as a dashboard, report, or viewpoint in Ardoq Discover, or as an Ardoq presentation slide

Process State

Trigger

Stakeholder

Information and Ardoq Asset

Create Initiative

Start Initiative

PMO, Initiative Owners, Objective Owners

Survey available from architecture portal

Analyze Initiative

When Initiative are owned

Initiative Owners

Architects

Survey to adjust Initiative

Survey to set Business and IT impact of Initiatives

Assign People to Initiative

Update people utilization

All Initiative participants

Broadcast and Survey to update allocations

Broadcast every 2 weeks to prompt info change

Status check

Initiative owner

Team owner

Portfolio owner

Survey and Broadcast to adjust Initiative cost, progress, and status

Dashboard for status

Visualizations for status, completeness, cost

Finalize Initiative

End of Initiative

Initiative owner

Team owner

Portfolio owner

Survey to adjust Initiative

Dashboard for status, completeness, cost

Visualizations for overall completeness, data quality

References

Gartner, Tomas Nielsen. “Turning Strategy Into Reality — How to Successfully Execute on Your Strategic Goals.” Presented at the Gartner IT Symposium / Xpo, Barcelona, Spain, November 2022.

Enterprise Value: Governance of IT Investments : Getting Started with Value Management. Rolling Meadows, Ill.: IT Governance Institute, 2008.

Robert S. Kaplan and David P. Norton. “The Office of Strategy Management.” Harvard Business Review, 2005.

Change Log

Version

Date

Author

Rationale

1.0

3/16/23

Jason Baragry

Published

Did this answer your question?