Should You Start a Digital Project? Seven Questions for Managers Before Approval

Summary: A digital project is worth pursuing when it solves a specific management problem, changes an important decision or workflow, and has usable data, clear acceptance criteria and an owner for ongoing operation—not because it uses many new technologies. This seven-question, 14-point screening method helps managers decide whether to seek formal approval, run a pilot or pause investment.

A worthwhile digital project should answer at least four things: who will use which data, in what situation, to make which decision or management action?

The hardest part is deciding whether the project is worth doing now. Technology and provider selection should follow that judgment.

Management cockpits, dashboards, business systems, data platforms and digital twins are all implementation forms. What matters more to a manager is who will make a faster or better-informed decision after launch, or perform a management action that was previously difficult.

If that cannot be explained, early debates over features, budgets and providers can expand the scope during delivery and leave an attractive system that no one uses regularly.

Start With Seven Questions and 14 Points

Answer these seven questions before discussing budget, schedule or technology. Score how clear each answer is, then decide whether to evaluate formal approval, run a pilot or defer the investment.

1. What Management Problem Will the Project Actually Solve?

A worthwhile project starts with a specific, persistent problem that affects business or management. “Build a management cockpit,” “launch a digital platform” and “raise digital maturity” describe directions, not complete project goals.

A more useful phrasing is: who cannot complete which management action on time, in what situation, because what information or process support is missing?

“Build a project-management cockpit” only names an output. “Regional managers cannot identify delayed projects before the weekly meeting, so cross-department coordination starts late” names a management problem. It can lead to data, users and acceptance criteria.

If the team can describe what it wants to build but not the problem it will solve, postpone full procurement or development.

2. Which Decision or Workflow Will Change After Launch?

The value is not that the business gains another screen or system. It is whether decisions, coordination or execution change.

Ask which role will detect problems earlier, which decision will have better evidence, which repetitive step will need less manual compilation, who will judge and assign an exception, and whether outcomes can be tracked.

If meetings, workflows and responsibilities remain the same before and after launch, the project may only be a new presentation format for old reports. That may still have a use, but scope and priority should be reconsidered.

3. Who Will Use It, Where and How Often?

“Leaders will look at it” is not a complete user requirement. Name the first core users, the exact context and expected frequency before approval.

A monthly executive review needs a different information level from daily exception handling by a business owner. A meeting-room display, office PC and mobile device also differ in typography, density and interaction. One page rarely serves presentation, analysis and daily operations equally well.

If the team cannot identify the initial users, when they will use it and what they will do afterward, interview actual users before fixing feature scope.

4. Is the Need Information Display or a Closed Management Workflow?

“Build a visualization platform” can hide four levels of need: see the current state, detect an exception, analyze its cause and drive a response. Each higher level demands more from data quality, business rules, APIs and organizational coordination.

The organization need not commit to one tool immediately. Define how far phase one will go. A small but usable and verifiable management loop can come first, with more departments, data and contexts later.

5. Can Existing Data Be Supplied Reliably, Accurately and Lawfully?

Data that “exists” is not necessarily usable. Data readiness is a prerequisite for formal approval, not a technical detail to solve only before launch.

For every key measure, confirm its system, database or spreadsheet source; whether departments share a definition; how often it updates; who owns quality; and whether access rights exist.

For sensitive business, customer, financial, production or personnel data, define access, security and usage boundaries separately. If key figures still rely on ad hoc consolidation or departments disagree on definitions, run a data inventory and small prototype first rather than promising a complete system result.

6. How Will You Know Whether the Project Worked?

Set acceptance criteria before approval. Looking for value only after launch tends to reduce acceptance to whether pages, buttons and feature lists were completed.

Track both deliverables and management results. Delivery measures can cover feature scope, metric accuracy, refresh, permissions, performance and deployment documents. Management results can cover shorter information-assembly time, earlier exception detection, less duplicate entry and ongoing tracking of issue resolution.

Not every outcome must be numerical, but record the current baseline and how the post-launch result will be compared. Without a baseline or test method, it is hard to know whether delivery improved the original problem.

7. Who Will Keep Operating It After Launch?

Launch completes construction; named owners and an operating routine make the project usable.

Before approval, name the business owner, data owner, system maintainer and iteration process. Who can change definitions, handle data errors, maintain accounts and access, collect real feedback and prioritize the next phase?

Metrics, organizations and workflows will change. If funding covers construction but not business ownership or maintenance, long-term value is difficult to sustain. Score this item zero if there is no named ongoing owner.

Seven Questions, 14 Points: Approve, Pilot or Pause?

Score all seven questions for a maximum of 14. This is a pre-meeting screening tool, not a replacement for formal feasibility review.

Three hard stops may also apply: the management problem is undefined, critical data has no owner, or there is no business owner after launch. If any applies, do not move directly to full implementation even with a high total score.

This score is not an industry standard and cannot replace financial, technical, security or compliance reviews. Its purpose is to expose basic gaps before committing significant time and budget.

A One-Page Project-Approval Card

Use the following card to align information at the next digital-project discussion before moving into solutions, quotes and provider comparison.

The choice is not simply “do it” or “do not do it.” Management can reduce scope, test key assumptions, or pause while data and ownership are unresolved. Pausing is not a rejection of digitization; it avoids turning an immature small problem into an oversized project.

A worthwhile project generally has a defined problem, usable data, users willing to participate and a team that remains responsible after launch.

Frequently Asked Questions

What should an enterprise confirm first before approving a digital project?

The specific management problem and which decision or workflow will change after launch. “Build a platform,” “improve efficiency” and “strengthen management” are too broad for formal approval.

Can a digital project start before the data is ready?

Data inventory, requirements review and a small prototype can start, but do not promise full-system outcomes yet. Confirm at least key sources, definitions, update frequency, rights and owners.

How should we choose among dashboards, BI and custom software?

Use a dashboard for fixed metrics and milestone reports, BI for multidimensional filtering and analysis, and a business system or custom software for approvals, assignments, permissions and workflows. See also How to Choose Between Dashboards and Software Systems.

What should a score of 8–11 out of 14 lead to?

Pilot one department, one core scenario and one complete data path. Test real use, data quality and acceptance criteria before scaling up.

Does a high score mean full implementation can start immediately?

No. The score is only an initial screen; financial, technical, security and compliance reviews are still needed. Missing problem definition, data ownership or post-launch business ownership is a reason not to proceed directly.