How to run a small digital project
If your organisation uses the Technology Assurance Framework, your digital project must meet the Digital Scotland Service Standard.
Following the standard helps you plan well, reduce risks and get better results. It also promotes good working practices that work for projects of any size.
Small services or projects generally cater to a limited number of people and have a budget of less than £250k.
This guide follows the same Agile phases as larger projects, but in a simpler way. You can still benefit from this structure, even if you do not follow every step.
Start your project
At the start of your project:
- be clear about what you want to achieve
- plan how you’ll do it
- think about any risks
Write a business case to record these details.
Check early if you need to buy anything and involve your procurement team if you have one.
In a small team, one person might do all of this.
Define the purpose
Write a short summary of what your service will do. Agree a small set of objectives with your stakeholders, so that you can start measuring your progress towards these.
Identify roles and tasks
List the main tasks and who will do them. Record any missing skills so that you can start planning how to fill the gaps.
Record risks and issues
Create a short risk log. Example risks are things like:
- the project lead being unavailable, which may make the project timeline slip
- no one taking ownership after launch, which may result in the service not being supported
Typical outputs
- Project summary
- List of responsibilities
- Risk and issue log
Who can help
Larger projects often have a service owner. If your team does not, read the service owner role description to decide who will provide leadership and make decisions. A delivery manager can support planning, team setup and early risk tracking.
Discovery phase
Small projects may not need a full discovery phase. But you should still take time to understand your users, any constraints and the wider context.
Learn about your users
If you have a user researcher in your team, you can follow the normal user research recommendations. If you do not have access to a user researcher, you can:
- run a workshop with users or staff yourself
- get user insights from web analytics or user feedback from similar services
Understand the full process
Find out where users come from, what they expect, and what happens after. A full blueprint is not needed. A simple list or sketch of the process is enough.
Share what you learn
Summarise what you learn and share it with others involved. This helps everyone understand the service before development starts.
Typical outputs
- Summary of user needs
- Basic user journey or service map
- Discovery summary
Who can help
If available, a user researcher can support this work. If not, other team members can take on parts of it. A business analyst or service designer can help you understand how your service fits into wider systems or processes.
Alpha phase
Use alpha to explore and test ideas before building the real service. Some small projects may combine alpha and beta.
Test different ideas
Create simple versions of your ideas, such as sketches or mock-ups. Share these with users or stakeholders to gather feedback.
Compare options
Review different tools or approaches if relevant. For example, compare the benefits of using an existing form tool versus building a custom solution.
Decide what to build
Record what worked, what didn’t and what you plan to do next. Use this to shape the minimum viable product (MVP).
Typical outputs
- Basic prototype
- Feedback and decisions
- List of delivery or technology options
Who can help
A content designer can help write and test early content. An interaction designer can support layout and flow. A product manager can help prioritise and plan what to build.
Beta phase
In beta, build a working version of your service. Focus on delivering the core features and preparing for day-to-day running.
Build the MVP
Use beta to build a working version of your service. Focus on key features and prepare for day-to-day use.
Get feedback
If possible, test the service with users or gather feedback as you build. If not, plan to improve it after launch.
Plan for running the service
Write down how the service will run, how users will get help, and who is responsible for ongoing support.
Typical outputs
- Working MVP
- List of known issues and improvements
- Operational plan and contacts
Who can help
A product manager can help define the MVP and track changes. A delivery manager can prepare the team for launch. A performance analyst can help set up basic metrics.
Live phase
Once live, focus on supporting users, monitoring performance and making improvements.
Track performance
Monitor usage and record any issues and how you fixed them.
Use feedback
Review support requests, user comments and usage data. Identify patterns and common problems.
Improve the service
Create a list of improvements and decide what to prioritise. This could be a simple backlog or roadmap.
Typical outputs
- Performance log or metrics
- Feedback summary
- Prioritised improvements list
Who can help
A product manager can lead improvements. A performance analyst can provide data and insights. A service owner can help make decisions and align improvements with wider goals.
Retirement phase
If the service is no longer needed, plan how to close it down properly.
Plan the closure
Set out how and when the service will end. Include any risks or dependencies.
Communicate with users
Tell users and relevant teams what will change. Give them time to respond and offer alternatives if needed.
Handle data
Make sure data is archived or deleted according to your organisation’s policies.
Typical outputs
- Retirement plan
- Communications plan
- Data handover or deletion checklist
Who can help
A business analyst can help manage the process and assess impacts. A service owner can approve decisions and lead communication. A content designer can update or remove user-facing content.