Value Compass: from idea to business value

What is business value in a development initiative?

Business value is the measurable value an initiative gives the organization: increased revenue, lower costs, reduced risk, a better customer experience, shorter lead times, or strategic value that makes future initiatives possible.

Something being delivered is not the same as the value having arisen. Value only arises when someone uses the solution and behaviors or processes actually change. That is why following up delivery is not enough – it is the value that should be measured.

When you build with AI

Use the assessment before investing more in an AI-built prototype. Who owns the benefit? Which workflow should change? Which baseline will you compare against? Have access to the data and operational responsibility been checked?

A high score does not establish that generated code is safe or that integrations work. Arrange a separate technical review, with tests of access permissions, data handling, dependencies and operation. A business-value workshop and a security assessment answer different questions.

Why does the value fail to appear?

The most common causes are rarely technical. Usually one of the following is missing:

• The goal has no measure or no deadline, so nobody knows whether it was reached.
• Nobody owns the value, or the owner lacks time and mandate.
• The solution is built without involving the users.
• The scope grows until first value is pushed into the future.
• Nobody measures after launch, so the value is never followed up.
• The roll-out is not planned, and the solution goes unused.

The ten areas below are built to catch exactly these gaps in time, while they are still cheap to fix.

The ten areas that decide whether the value arises

Each area has four statements. Go through them and ask: is this true for our initiative? If not, the line under the statement shows what is needed.

1. Goals & business value

Without a measurable goal you cannot know whether the initiative succeeded – or when to change course.

• We have a clear, quantified goal with a deadline.Formulate a measurable goal with a date, and also define a “wild success” level that exceeds expectations.
• We know the starting point – there is a measured baseline.Measure the current state before you start, otherwise you cannot prove the value arose.
• The business value is calculated and agreed with management and finance.Produce a simple benefits case (revenue, cost, risk) and get buy-in from the decision makers.
• We know who must act differently for the value to arise.Map out which roles, behaviors and processes must change for the value to be realized.

2. Ownership & stakeholders

Initiatives with clear ownership and short decision paths deliver faster and with less waste.

• There is an appointed product owner with the mandate to prioritize.Appoint a product owner and give them a written mandate to prioritize and say no.
• The product owner has actual time set aside for the initiative.Free up time in the product owner’s calendar – or appoint a proxy product owner.
• Key stakeholders are identified and agree on the target picture.Do a stakeholder analysis and hold a short workshop to get everyone pulling in the same direction.
• Decisions are made within days, not weeks.Define a decision forum and escalation path, and set a response time for decisions.

3. Users & needs

Value only arises when someone actually uses the solution. Understand the problem before you build.

• We have talked to real users or customers about the problem.Book user interviews or observations before the scope is locked.
• Needs are described as problems, not as ready-made solutions.Rewrite requirements as problems and desired outcomes, so the team has room to find the best solution.
• Users are involved continuously during development.Plan regular demos and tests with real users.
• We know what makes users actually choose to use the solution.Define adoption goals and identify barriers to use (habit, training, resistance).

4. Scope & prioritization

Most value for the least effort: deliver what gives first value first, and be clear about what you are not doing.

• Scope is limited to what is needed to reach first value.Define a minimal first delivery (MVP) and postpone the rest.
• Prioritization uses transparent, agreed criteria.Use a structured prioritization model, such as the prioritization matrix, so the prioritization becomes visible and agreed.
• We have a clear picture of what we are deliberately not doing.Write a “not now” list and get buy-in from the stakeholders.
• The backlog is broken down so the team can start work.Break the highest-priority epics down into stories with acceptance criteria.

5. Team & competence

The right competence in a stable team beats large teams with divided attention.

• The team has the right competence (development, test, UX, architecture).Do a competence gap analysis and complement the team before starting.
• The team is stable and dedicated, not shared across several assignments.Avoid sharing members between assignments – every switch costs time and focus.
• The team has direct access to domain knowledge and customer dialogue.Appoint a contact in the business and book recurring check-ins.
• Roles and responsibilities (PO, PM, QA, architect) are clear.Clarify roles and responsibilities and communicate them to everyone involved.

6. Process & delivery

Short delivery cycles give early value and early feedback – and reduce the risk of building the wrong thing.

• We deliver in short iterations with a demo for stakeholders.Introduce fixed iterations (1–2 weeks) with a demo and retrospective.
• Our “definition of done” includes testing and quality.Write down a shared definition of done and follow it up.
• We can release often and without drama.Automate build, test and deployment (CI/CD) for safe, frequent releases.
• We have a working way to handle changing requirements.Introduce a simple change process: prioritize new items against what is already there.

7. Technology & architecture

Technical obstacles found late are among the most expensive. Clarify them early.

• The target architecture is understood and sufficiently documented.Have a system architect sketch the target picture and key decisions before the build picks up speed.
• Dependencies on existing systems and integrations are mapped.Map integrations and data sources, and verify them early with small tests.
• Development, test and production environments exist or are planned.Secure environments and access before the team starts – otherwise the team waits.
• Requirements for security, performance and operations are defined.Define non-functional requirements and include them in planning.

8. Measurement & follow-up

What gets measured gets done. Follow up value – not just delivery.

• We measure value continuously, not just what has been delivered.Choose 2–3 indicators that reflect the value and measure them every iteration.
• There is a fixed rhythm for follow-up with management.Set a fixed follow-up meeting with a short dashboard of value, risk and progress.
• We have criteria for changing direction or stopping.Define in advance which outcomes lead to changing course or ending the initiative.
• Someone owns the benefits realization even after delivery.Appoint a benefit owner responsible for the value actually arising after launch.

9. Risks & dependencies

Risks that are known and have an owner are manageable. It is the unknown ones that cost.

• The biggest risks are identified and each has an owner.Hold a risk workshop, identify the top five risks and give each an owner and an action.
• External dependencies (suppliers, other teams) have an owner and a timeline.Set up check-ins with each dependency and make them visible in the plan.
• Budget and timeline include a realistic buffer.Add a buffer to time and budget – and be clear about what it covers.
• Legal, GDPR and compliance have been looked into.Involve legal and information security at an early stage.

10. Adoption & change

A solution creates no value until it is used. Plan the roll-out as carefully as the build.

• There is a plan for roll-out and adoption.Produce an adoption plan: pilot, roll-out, support organization.
• Training and support for users are planned.Plan training, manuals and support already during development.
• Affected managers support and communicate the change.Give managers communication material and a clear message about why the change is happening.
• We know what is to be phased out when the new solution arrives.Plan the retirement of old systems and routines, otherwise the value is only half realized.

How to do the assessment

1. Describe the initiative.Write down the purpose, the owner and a measure of success with a deadline, plus a “wild success” level that would exceed expectations.
2. Value the business benefit.Choose which types of benefit apply, estimate the value per year and how certain you are.
3. Rate the 40 statements.Score each statement from 1 (not true at all) to 5 (completely true). Answer “don’t know” if you do not know – it counts as a gap.
4. Weight the areas.Mark which areas are especially important in your initiative: low, normal, high or critical weight.
5. Close the biggest gaps first.The tool lists actions sorted by importance. Pick the ones to include in your action plan.

Let several people assess separately, for example the product owner, the sponsor and the team, and then discuss where the scores differ. The differences often show where people hold different pictures of the initiative.

How the score and illustration work

Illustration, not forecast: SEK 1,500,000 × 0.7 × (1 − 0.4) gives SEK 630,000 in the model. It does not mean that SEK 630,000 will be lost or that 40% of the benefit will occur. The relationship between the self-assessment and economic outcomes has not been statistically validated.

Unanswered statements are excluded from the score. The assessment is provisional until all forty are answered. Selecting an action assumes a rating of 4 for that statement in a scenario. It does not mean the action has been completed or produced an effect. Security requirements need separate assessment even with a high score.

How to prioritize the actions

Every statement rated 3 or lower produces an action. An action’s importance is calculated as (5 − score) × the area’s weight, so large gaps in important areas end up on top.

The list is often longer than what can be done at once. A prioritization model helps you choose among the actions, for example the prioritization matrix.