Function before Software: a practical management guide

The decision in two paragraphs

For “Function before Software: a practical management guide”, define the outcome as a change in management practice. The central object is goals and management decisions; it needs an agreed source, decision owner and observable state after the action “verify the outcome”.

The first evidence is not a solution presentation but a reproducible example of “recurring gaps between strategy and projects”. It allows the team to set the process boundary, inspect baseline data and select the fact that will confirm completion.

Maxim Kantarovich's source argument

In his RBC Companies article “Ten principles of digitalisation before implementation”, Maxim Kantarovich focuses on the decisions an organisation should make before selecting and configuring technology. This guide develops that authorial framing for “Function before Software: a practical management guide”.

For the present question, the starting object is initiatives, dependencies and resources, and the first observable signal is “recurring gaps between strategy and projects”. The management decision is documented before technology selection: name the owner, process boundary and baseline verification method.

• Maxim Kantarovich is the author of the cited RBC Companies article.
• Practical implication: agree the outcome owner, baseline data and acceptance criterion before the project starts.

Starting situation and evidence

The work starts with an observable situation, not with interface selection. The diagnostic signal for this article is: recurring gaps between strategy and projects. It should be supported by a real example such as a document, data sample, decision record or registered variance.

The first scope is limited to one object and one decision. Changing every process, master-data set and system at once obscures causality. For the signal “inconsistent system maps”, a representative boundary is a period, business unit or transaction class where the situation can be tested again.

• Management signal 1: Recurring gaps between strategy and projects. Use condition: a link to an actual example and to systems and integrations.
• Diagnosis records “competing initiatives without shared criteria”, its recurrence and its impact on initiatives, dependencies and resources.
• Observation 3: Inconsistent system maps. Required fields: frequency, source and consequence for goals and management decisions.

What belongs in scope

Describe the boundary through object records rather than system names. For initiatives, dependencies and resources, record meaning, identifier, source, quality owner and update event; for goals and management decisions, also document the relationship rule.

Test the link between initiatives, dependencies and resources and goals and management decisions using an end-to-end example. The team performs “identify the management object”, traces transformations and identifies where a discrepancy arises, who corrects it and which dependent outputs are recalculated.

• Subject area 1: Goals and management decisions. Verification basis: system of record, owner authority and the signal “measures without decision owners”.
• Record 2. Object: Capabilities and processes. Required details: identifier, lineage, quality rule and update event. Signal: Investment without a target state.
• Control record 3. Object: Data and measures. Observable signal: Recurring gaps between strategy and projects. Accountability: semantic owner and quality owner.

The decision point to resolve

State the decision before compiling requirements. It identifies capabilities and processes, the role authorised to choose, the permitted action and the evidence participants will use to accept or reject an option.

Do not combine the signal “recurring gaps between strategy and projects” and the risk “planning projects without dependencies” into one measure: the former describes an observable state, while the latter describes a possible consequence. The action “verify the outcome” connects them in a testable scenario.

• Decision 1: object — goals and management decisions; signal — investment without a target state; action — verify the outcome.
• Decision 2: object — capabilities and processes; signal — recurring gaps between strategy and projects; action — frame the problem.
• Decision 3: object — data and measures; signal — competing initiatives without shared criteria; action — identify the management object.

A practical decision model

For goals and management decisions, the sequence begins with “verify the outcome”. The owner of the next step reviews its output; an incomplete result is returned with a specific issue concerning data, a rule, authority or an architecture dependency.

Maintain an assumptions log for goals and management decisions. Each entry states its basis, owner, review date and the event after which it must be confirmed, changed or closed.

• At position 1, the action is “frame the problem”; its result is systems and integrations.
• Stage 2: identify the management object. The working artefact describes initiatives, dependencies and resources.
• Stage gate 3 connects the action “assemble data and constraints” with the result “goals and management decisions”.
• 4. Action: assign roles and actions; verifiable result: capabilities and processes.

Record lineage

An integration design begins not with arrows between applications but with events and accountability. It defines who creates a record, where it becomes authoritative, which checks run before transfer, how duplicates are handled and which action is blocked when records disagree. The reference object here is goals and management decisions.

Every exchange has a business owner, technical owner and observable control point. API, messaging, file transfer or another technology is selected after frequency, volume, resilience and error behaviour are known. For the signal “recurring gaps between strategy and projects”, quality is assessed before transfer and after loading so that the origin of a discrepancy can be located.

• Object 5: Initiatives, dependencies and resources. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Inconsistent system maps.
• Boundary 4. Object: Systems and integrations. Define the source, frequency, permitted transformations and response to “competing initiatives without shared criteria”.
• Control record 3. Object: Data and measures. Observable signal: Recurring gaps between strategy and projects. Accountability: semantic owner and quality owner.

Process and data owners

Build the authority matrix around decisions concerning capabilities and processes. Assign the right to change a rule, duty to prepare data, authority to approve an exception and accountability for confirming the outcome separately.

Define the escalation path for “verify the outcome” concerning capabilities and processes in advance. The business owner is accountable for decision meaning, the data owner for evidence fitness, the architect for dependency integrity and the project manager for the agreed work sequence.

• Role: Business owner. Decision object: systems and integrations; verified step: verify the outcome.
• Architect decides within initiatives, dependencies and resources; the basis is prepared through “frame the problem”.
• For goals and management decisions, the assigned role is Data owner; its control duty is to identify the management object.
• Project manager: authority is linked to capabilities and processes, and participation is tied to “assemble data and constraints”.

Baseline and actual outcome

Verification of capabilities and processes starts with the baseline. The sample, period, calculation rule, known exceptions and interpretation owner are preserved. After the change, the same scenario is repeated under comparable conditions; a new method or data population is documented as a separate version.

A functioning feature is not yet acceptance evidence. A user must receive the signal “recurring gaps between strategy and projects” from the agreed source, understand its lineage, make an authorised decision, execute the action through the working environment and observe confirmed actuals for initiatives, dependencies and resources.

• Control record 1: Goals and management decisions; data version, calculation rule, expected change and actual outcome. Signal: Recurring gaps between strategy and projects.
• Criterion 2 uses capabilities and processes; the result is compared with the baseline using one method. Signal: Competing initiatives without shared criteria.
• Criterion 3: Data and measures; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: Inconsistent system maps.
• Criterion 4. Object: Systems and integrations. Test fields: baseline, target change, source and owner. Signal: Measures without decision owners.

Assumptions, stop signals and rollback

The risk map starts with two conditions: “planning projects without dependencies” and “having no owner for the target model”. Each receives an observable event, decision owner, control and outcome that requires a stop or rollback.

Every assumption has an owner, supporting evidence and a review event. The risk “having no owner for the target model” needs particular control here because its status affects the scope, delivery sequence and acceptance criterion.

• For the risk “replacing architecture with a product list”, assign the action “assign roles and actions” and evidence “goals and management decisions” in advance.
• Risk review starts with the condition “planning projects without dependencies”. The decision uses the action “verify the outcome” and data about capabilities and processes.
• Risk record 3. Condition: Disconnecting business goals from data. Control action: Frame the problem. Evidence source: Data and measures.
• Risk: Having no owner for the target model. Control: identify the management object. Evidence: systems and integrations.

Initial working cycle

The first working session on initiatives, dependencies and resources uses real material: a transaction example, report or plan, systems diagram, role list and the variance “recurring gaps between strategy and projects”. Participants select one scenario, identify data gaps and perform the action “verify the outcome”.

The output is a decision pack: problem statement, object map, baseline sample, owners, dependencies, verification criteria and open questions. The risk “planning projects without dependencies” helps determine the next format: a pilot, architecture discovery, competitive selection or process correction without a new system.

• At position 1, the action is “frame the problem”; its result is systems and integrations.
• Stage 2: identify the management object. The working artefact describes initiatives, dependencies and resources.
• Criterion 4. Object: Systems and integrations. Test fields: baseline, target change, source and owner. Signal: Measures without decision owners.
• 5. Acceptance object: initiatives, dependencies and resources; compare the baseline sample, expected change and confirmed actuals. Test signal: Investment without a target state.