Review goals, users, technology, security, leadership, adoption, measurement and future needs before starting a larger digital programme.
Most digital programmes that struggle do so for reasons that were visible at the planning stage. The objective was vague, the people doing the work were consulted late, or nobody owned the decisions that slowed delivery down. The eight checks below are designed to surface those issues early, while they are still inexpensive to resolve. They work as a review of an existing plan or as a structure for building a new one, and they apply whether the programme is a single application or a wider change across several functions.
1. Define the change you need
Write down the problem, affected users and intended outcome. Set a baseline so that later results can be compared with the starting point.
A useful test is whether the problem statement would make sense to someone outside the project team. “Modernise our reporting” is a direction, not a problem. “Regional managers spend two days each month reconciling figures from three spreadsheets before they can submit a forecast” describes something specific that can be observed, measured and improved. The more precise the statement, the easier it becomes to judge which options are relevant and which are distractions.
The baseline does not need to be elaborate. A sample of recent cases, a simple time log over a few weeks or a count of requests and errors is often enough to give the programme a credible reference point. Without it, later conversations about benefit rely on impressions, which tend to be optimistic at launch and contested a year later.
2. Understand how teams work
Include the people who use and support the process. Their experience can reveal workarounds, dependencies and concerns that are not visible in a systems inventory.
Consider a commercial operations team that appears to follow a documented approval process. When the process is walked through with the people who run it, it emerges that half of the requests arrive by email rather than through the official form, that one reviewer keeps a private tracker because the system does not show status clearly, and that a monthly deadline drives most of the volume into a single week. None of this appears in the process diagram, yet each point would change the design of a new solution. Short working sessions with representative users, and a review of real examples rather than idealised ones, are the most reliable ways to find these details.
3. Assess technology against the brief
Compare options using functional needs, integration, usability, cost and maintainability. A new tool should have a clear reason to be part of the plan.
It helps to write down the evaluation criteria before looking at products, so that a persuasive demonstration does not quietly reset the requirements. Include the less visible factors: how the option connects to the systems that hold the source data, who will configure and support it, what happens when the vendor changes its pricing or roadmap, and whether existing platforms the organisation already licenses could meet the need. In some cases the right answer is a modest change to an existing tool; in others it is a purpose-built application. Our AI and digital strategy work often begins with this kind of structured comparison, because it keeps technology choices tied to the brief rather than to trends.
4. Agree security and information requirements
Involve relevant IT, security and data protection specialists early. Record requirements and testing responsibilities appropriate to the systems and information involved.
Security reviews that arrive at the end of a project tend to produce rework, delays or uncomfortable compromises. Bringing these specialists into the scoping stage allows the programme to classify the information involved, identify where personal data is processed and consider obligations such as GDPR from the outset. Where AI features are proposed, it is also worth agreeing how inputs and outputs will be handled, who can access them and how the use case will be assessed against internal policy and applicable regulation. Recording these decisions in writing gives delivery teams a clear standard to build and test against.
5. Establish sponsorship and decision-making
Name the sponsor, delivery lead and people authorised to resolve scope and priority decisions. Agree how risks and changes will be escalated.
A sponsor is more than a signature on a business case. The role involves protecting time for the people who need to contribute, resolving conflicts between functions and making trade-offs when scope, budget and timing pull in different directions. Leaders reviewing a plan can ask a few direct questions:
- Who can approve a change to scope without waiting for the next steering meeting?
- Which decisions need input from legal, medical, finance or security, and how quickly can that input be obtained?
- What happens when two stakeholder groups want incompatible things?
If the answers are unclear, delivery will slow at exactly the points where momentum matters most.
6. Plan adoption alongside delivery
Consider communication, training, support and changes in responsibilities. Provide opportunities for people to try the new approach and raise concerns.
Adoption is often treated as a launch activity, but the groundwork belongs much earlier. People are more likely to use a new process if they have seen early versions, influenced the design and understood why the change is happening. Responsibilities also shift: a team that used to chase information by email may become responsible for maintaining data in a system, which is a different kind of work and may need different skills. Planning training and change support alongside the build, rather than after it, gives those changes time to settle.
7. Review the evidence
Use a small set of measures linked to the original objective. Examine quality, effort, use and unintended effects, rather than relying on launch milestones alone.
Go-live dates and feature counts confirm that work was delivered, not that it helped. A more useful review returns to the baseline from the first check and asks whether the problem has improved, for whom and at what cost. It is also worth looking for effort that has simply moved elsewhere, for example a faster submission step that creates more queries for reviewers. Scheduling reviews at agreed intervals after launch keeps attention on outcomes once the project team has moved on.
8. Consider maintenance and growth
Understand how the service will be supported and updated. Test the assumptions about demand, integrations and operating cost that affect future use.
A solution designed for one team may later be requested by others, connected to new systems or asked to handle a larger volume of work. Planning does not need to predict every scenario, but it should make clear who owns the service, how changes will be requested and prioritised, and what the ongoing costs of hosting, licences and support are likely to involve. Documentation, a named owner and a simple release process make a service far easier to sustain than one that depends on the memory of the original project team.
Choose a focused next step
These checks help identify questions to resolve; they do not guarantee success. A discovery or process review can turn the most important questions into a practical scope. A structured readiness review, such as the approach described in our AI readiness assessment framework, is one way to test a plan against these questions before committing to larger investment. Glyz can support the strategy, design, development and team capability involved.
