For any organization, it is essential that strategy and strategic objectives are correctly aligned with ongoing and planned projects. This will ensure that you have the insight into alignment, conflicts, and complexity that your organization must navigate if you are to deliver on your strategy.
Further by connecting your Strategic Planning and Execution to your architecture, you can bridge the business and IT organization at the management level.
A robust Strategy to Execution process is therefore required by your organization and a detailed explanation of its purpose, scope, and rationale can be found in the document Strategy to Execution: Purpose, Scope, and Rationale.
The following article covers the Ardoq Strategy to Execution metamodel and how we suggest structuring your information to realize value and succeed.
Ardoq’s Approach to Strategy to Execution
The complete Strategy to Execution Metamodel covers the different workspaces & components; Objectives, Initiatives, Capabilities, Technology, People, and Organization.
Understanding the Strategy to Execution Metamodel
This section will walk through the different component types, fields, and reference types that make up the metamodel for Strategy to Execution.
We look at the Strategy to Execution metamodel as being broken into three key and interconnected areas:
Objectives
Capability Deltas
Initiatives
Objective Component
The Objective component type is used to capture company or department-level strategies and objectives, making it easier to analyze relationships from a single component type and to allow for aggregation of cost, progress, and status to the Objectives.
For more information about Objectives see Strategy to Execution: Purpose, Scope, and Rationale.
Objective Fields
Field | Type | Description | Definition |
Name | Text | Name of the Objective | Not Applicable |
Description | Text | Brief description of the Objective | Not Applicable |
Comments | Text | Section for additional comments to provide context to the Objective | Not Applicable |
Active Period | Date Range | The period when the Objective is expected to start and end. | Not Applicable |
Priority | List | How important this Objective is to the organization |
|
Calculated Progress | Calculated Number | Progress of the Objective based on the progress of the initiatives that they are connected to through the “Is Realized By Reference” | See below for Gremlin query |
Completeness (%) | Number | A value to represent what percent the Objective came to meeting its target outcome at the end of its active period. | Not Applicable |
Strategic Investment
Category | List | Field used to capture how the organization is investing and whether those investments are tactical or strategic |
|
Objective Financial Fields
Field | Type | Description | Definition |
Total Attributed Budget | Calculated Number | The cost aggregation of budget from all referenced initiatives | Aggregated Total Budgeted Cost of the initiatives that they are connected to through the “Is Realized By Reference” |
Total Attributed Cost | Calculated Number | The cost aggregation of actual cost from all referenced initiatives | Aggregated Total Cost of the initiatives that they are connected to through the “Is Realized By Reference” |
Key Result Component
A Key Result component is a measure of the success criteria used to track the achievement of an Objective. Several Key Result components can be defined for any one Objective.
Key Results, which are optional, have a parent-child relationship with Objectives.
The Key Result component should not be confused with the existing Metric component type as both types capture a quantifiable benefit. Note that the Metric component type could be used in place of a Key Result.
Key Result Fields
Field | Type | Description | Definition |
Name | Text | Name of the Key Result | Not Applicable |
Description | Text | Brief description of the Key Result | Not Applicable |
Comments | Text | Section for additional comments to provide context to the Key Result | Not Applicable |
Key Result Progress (%) | Number | Progress of the Key Result | Not Applicable |
Folder Component
The Folder component type is used to group Components within a workspace, specifically to help manage visualization.
Folder components have no additional fields and are used only for cosmetic purposes.
Objectives References
As seen above there are a series of references that connect objectives to other component types within Ardoq:
Reference | Description | Source | Target |
Is Supported By | This reference is used to show connecting objectives. An example of this is aligned objectives, Company Objectives that flow down to department and team-level objectives | Objective | Objective |
Owns | This reference is used to show ownership/responsibility of the objective. This should be to a Person. It can also be to an Org Unit, Team, Department as needed | Org Unit / Person | Objective |
Depends On | This reference is used to show when one component is dependent on another component in order for it to be realized | Objective | Capability Delta |
Is Realized By | This reference is used to show the connection between objectives and the work taking place that is delivering those objectives | Objective | Initiative |
Objectives Gremlin Code
This section contains the Gremlin code used to implement the Calculated Fields of the Objectives components.
Calculated Progress
This contains the Gremlin code that calculates the progress on the objective component by aggregating and averaging the progress from referenced Initiatives via the “Is Supported By” reference:
getValues = union(
emit().repeat(
out('Is Supported By')).
out('Is Realized By').values('percent_progress'),
out('Is Realized By').values('percent_progress'))
getTree = getValues.clone()
round = {Math.round(it.get()*100)/100}
g.V(ids).
filter(getTree).
project('id', 'name', 'value').
by(id).
by('name').
by(getValues.
mean().map{ it.get().round(0) }) |
Total Attributed Budget
This contains the Gremlin code that calculates the total attributed budget on the Objective Component. The values are aggregated sum total from the initiative’s Total Budgeted Cost field via the “Is Realized By” reference:
def toRoundedDecimalNumber = {
return Math.round(it.get() * 100) / 100;
}
calculate = __.out('Is Realized By').hasLabel('Initiative').
project('total_budgeted_cost', 'number_of_incoming_references_from_initiatives').
by(coalesce(values('total_budgeted_cost'), constant(0))).
by(union(__.in('Is Realized By').hasLabel('Initiative').count(), constant(1)).max()).
math('total_budgeted_cost / number_of_incoming_references_from_initiatives')
g.withSack(0).V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(emit().repeat(__.in('ardoq_parent')).
sack(sum).by(calculate.sum()).
sack().sum().map(toRoundedDecimalNumber)) |
Total Attributed Cost
This contains the Gremlin code that calculates the total attributed cost on the Objective component. The values are the aggregated sum total from the Initiative’s Total Direct Cost field via the “Is Realized By” reference:
def defaultFieldNames = ['total_attributed_cost', 'total_direct_cost']
def toAPIFieldName = {
if (it.get() == 'No Attributed Cost Flow') return 'total_attributed_cost';
if (it.get() == 'No Direct Cost Flow') return 'total_direct_cost';
return '';
} def getCostTypeAttributionFieldNames = {
values('cost_type_attribution').
unfold().
map(toAPIFieldName).
fold().
map{
fieldNamesToExclude = it.get()
defaultFieldNames.findAll{ defaultFieldName ->
!fieldNamesToExclude.contains(defaultFieldName)
} } } def hasCostTypeAttribution = {
getCostTypeAttributionFieldNames().unfold().count().is(gt(0))
} |
Business and Technical Capability Deltas
It is important to define both where the impact of a change initiative will be and what the business benefit of that impact will be. This is needed in Strategy to Execution to both highlight needs and benefits realization as well as to collect information needed for prioritization of proposed Initiatives.
Capability components are stable over time. They 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.
Capability Delta Component
A Capability Delta represents a change to a Capability and is either an identified desired, change, i.e. a capability gap found during capability-based planning, or an improvement that will be delivered as part of an Initiative.
Capability Deltas represent the business change needed for an objective and/or the benefit delivered from one or more Initiatives and will only remain relevant during the lifespan of the Initiative, or while the Objective remains relevant.
Please read Strategy To Execution: Purpose, Scope, and Rationale for more information about Capability Deltas and Navigating the Transient Nature of Strategy to Execution for a discussion about the temporary nature of particular components.
Capability Delta Fields
Field | Type | Description | Definition |
Name | Text | Name of the Capability Delta | Not applicable |
Description | Text | Brief description of what the Capability Delta aims to achieve | Not applicable |
Comments | Text | Section for additional comments to provide context to the Capability Delta | Not applicable |
Calculated Active Period* | The start date is derived from the earliest date from the initiatives referenced. The end date is derived from the latest date of the initiatives referenced | Not applicable |
*When creating the Calculated Active Period date ranges it is important to follow the field naming convention when creating the fields to ensure the preconfigured presentations and dashboards function properly.
Capability Delta References
The references are important in determining the suitability or structural complexity of an application, which is why it’s important to be mindful of creating the right connections. Below is an example of the references between the four component types:
Reference | Description | Source | Target |
Is Dependency For | This reference is used to show dependency between capability deltas. An example is if a delta needs to be realized before another delta can be delivered | Capability Delta | Capability Delta |
Is Impacted By | This reference is used to show the relationship between the Capability and the Capability Delta | Business or Technical Capability | Capability Delta |
Realizes | This reference is used to show what initiatives are delivering the capability delta | Initiative | Capability Delta |
Depends On | This reference is used to show when one component is dependent on another component in order for it to be realized | Objective | Capability Delta |
Capability Delta Gremlin Code
This section contains the Gremlin code used to implement the Calculated Fields of the Objectives components:
Calculated Date Ranges
Use the Calculated Date Range KB article to create the calculated date ranges on Capability Delta components.
Change Initiatives
Initiative Component
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 i.e. Initiatives with sub-Initiatives, allowing for 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 with other Initiatives:
Parent-child - where one Initiative is part of another initiative
Is Dependency For - which represents that one Initiative must be executed before another can execute
Jira Issue and Jira Project Components and other execution tools
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.
The Jira Issue and Jira Project components represent the projects, epics, and tasks imported in from your Jira instance. If your organization uses other tools you can follow the same modeling pattern to import your actual execution tasks and link them to Initiatives for traceability.
Initiative components have Is Realized By references to Jira Issues, Jira Projects, and other execution tracking tools to show the linkage between top-level Initiatives and the actual execution tasks that might be imported from other solutions.
Currently, we do not aggregate execution task information to the Initiative components. To find more information read our Strategy to Execution: Purpose, Scope, and Rationale document.
Initiative Fields
Field | Type | Description | Definition |
Name | Text | Name of the Initiative | Not applicable |
Description | Text | Brief description of the Initiative | Not applicable |
Active Period | Date Range | The time period when the Initiative is expected to start and end | Not applicable |
Initiative Stage | List | The stage of the initiative as it progresses through the delivery process |
|
Initiative Status | List | The status of the initiative as it progresses through the stages of the delivery process |
|
Percent Progress | Number | The estimation of the progress of the initiative toward its delivery | Not applicable |
Initiative Type | List | The type of initiative that it is. This accounts for a wide spectrum of delivery methodologies |
|
Business Case | URL | A link to the business case artifact associated with the initiative | Not applicable |
In Conflict | Calculated Text | A value to indicate when initiatives are in conflict with other initiatives | Initiatives are in conflict when resources have been assigned to initiatives that have overlapping Active Periods. |
Strategic Investment
Category | List | Field is used to capture how the organization is investing and whether those investments are tactical or strategic |
|
Initiative Cost Fields
Field | Type | Description | Definition |
Budget Capex | Number | The budgeted capital expenditure associated with the initiative | Not Applicable |
Budget Opex | Number | The budgeted operational expenditure associated with the initiative | Not Applicable |
Total Budgeted Cost | Calculated Number | The cost aggregation of budget from all referenced initiatives | Budgeted Capex + Budgeted Opex |
Capex | Number | The actual capital expenditure associated with the initiative | Not Applicable |
Opex | Number | The actual operational expenditure associated with the initiative | Not Applicable |
Total Direct Cost | Calculated Number | The aggregation of the initiative Capex and Opex fields | Capex + Opex |
Total Cost | Calculated Number | The cost aggregation Total Direct Cost fields | Total Direct Cost |
Initiative References
Reference | Description | Source | Target |
Is Realized By | This reference is used to show the alignment between objectives and the work taking place that is delivering those objectives | Objective | Initiative |
Impacts | This reference is used to show where the impact of the initiative will be across the organization. For example; who is impacted by a change to this system | Initiative | Capability/ Application / Org Unit |
Realizes | This reference is used to show which initiatives are delivering the capability delta | Initiative | Capability Delta |
Is Dependency For | This reference is used to show when one component is dependent on another component in order for it to be realized | Initiative | Initiative |
Owns | This reference is used to show ownership/responsibility of the initiative. This should be to a Person. It can also be to an Org Unit, Team, or Department as needed | Org Unit / Person | Initiative |
Assigned To | This reference is used to show who within the organization is assigned to work on the specific initiative | Org Unit / Person | Initiative |
Is Realized By | This reference is used to show the connection between multiple initiative workspaces and the centralized Change Initiative workspace | Initiative | Various Managed Workspace Initiatives |
Assigned To Reference Field
On the Assigned To reference between Person component and Initiative component there is a Time Allocated field used to capture the percentage of time each person/team is allocating to the initiative. This is to surface where people or teams are overextended.
Gremlin code
This section contains the Gremlin code used to implement the Calculated Fields of the Strategy to Execution Use Case.
In Conflict
This contains the Gremlin code that calculates when initiatives are In Conflict. This is done by looking at resources that are assigned to initiatives that have overlapping start and end active dates:
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(
__.in('Assigned To').
out('Assigned To').
dedup().
has('active_period_start_date').
has('active_period_end_date').
project('startDate', 'endDate').
by('active_period_start_date').
by('active_period_end_date').
fold().
map{
dateRanges = it.get()
dateRanges.any{ oneDateRange ->
dateRanges.any{ anotherDateRange ->
oneDateRange.startDate < anotherDateRange.endDate &&
anotherDateRange.startDate < oneDateRange.endDate
}
} ? 'True' : 'False'
}) |
Total Budgeted Cost
This contains the Gremlin code that calculates the Total Budgeted Cost on the initiative component by aggregating the sum total from the initiative’s budget Capex and budget Opex fields :
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(values('budget_capex', 'budget_opex').unfold().sum().map{ (it.get() as Double).round(0) }) |
Total Direct Cost
This contains the Gremlin code that calculates the total direct cost on the initiative component. The values are aggregated sum total from the initiatives Capex and Opex fields:
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(project('capex','opex').
by(coalesce(values('capex'), constant(0))).
by(coalesce(values('opex'), constant(0))).
math('capex + opex')) |
Total Cost
This contains the Gremlin code that calculates the total cost on the Initiative component. The values are the aggregated sum total from the Initiative’s Total Direct Cost field:
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(emit().repeat(
__.in('ardoq_parent')).
values('total_direct_cost', 'total_attributed_cost').unfold().sum().map{ (it.get() as Double).round(0) })
} } def hasCostTypeAttribution = {
getCostTypeAttributionFieldNames().unfold().count().is(gt(0))
} |
These queries are standardized as part of the Ardoq Cost Model. For more information please refer to the Ardoq ITCM Metamodel document.
Version | Date | Author | Rationale |
1.0 | 3/13/23 | Jason Baragry | Published |