Skip to content
FSS
Discuss a project
Implementation · PDF workbook

Software Project Readiness Kit

Prepare a useful software brief by defining the problem, users, data, first release and ongoing owner. Use the kit to expose missing evidence before committing to a supplier or a build.

By Faithful Software Solutions Ltd

Published · Updated

For Charity leaders, Church administrators, Operational software buyers.

Sources and evidence

First-party scope and product information. Workflow examples are illustrative; no measured customer outcomes are claimed.

Four-page planning workbook. Complete with your process owner and budget holder. File format: PDF.

  • Define the operational problem and evidence

  • Map roles, records, scope and acceptance tasks

  • Assign owners to open questions and ongoing support

Download for Free

Submit once to unlock immediate download access.

By downloading, you agree to receive strategic updates. Unsubscribe anytime.

Prepare your project brief

Step 1

Define the problem

Record one workflow, its current evidence and the outcome you want to test.

Step 2

Agree the first release

List essential tasks, roles, data responsibilities and explicit exclusions.

Step 3

Resolve open questions

Give each uncertainty an owner before asking suppliers to scope delivery.

Prepare the next software decision.

Complete the resource with the people who own the process and agree which open question to resolve next.

Get the Free Guide

Implementation Guidance

What should we prepare before speaking to a supplier?

Prepare one operational problem, the people who own it, the systems it touches and the decision you need to make. The downloadable worksheet takes you through scope, data, acceptance and ongoing ownership. It is a planning aid, not a quotation or a guarantee that a custom build is suitable.

Use the Manual Process Audit if the current volume, delays and handoffs are still unclear. Capture evidence from a normal working period and label estimates.

Who should complete the kit?

Bring together the process owner, a budget holder, someone responsible for data and access, and people who do the work. For an illustrative charity referral workflow, that might include a programme manager and the staff member reviewing incoming requests. For a church registration workflow, include an occasional volunteer as well as the administrator.

Do not include real beneficiary, safeguarding, donor or payment records. Describe record types and use fictional examples when preparing an initial brief.

What does the worksheet cover?

  1. The problem, its baseline and the outcome you want to test.
  2. Current tools, handoffs and options already considered.
  3. User roles, access boundaries, exceptions and data responsibilities.
  4. A first release, explicit exclusions and acceptance tasks.
  5. Migration, training, support, budget assumptions and a decision owner.

The custom software cost guide explains why these details affect scope. A target date is a constraint to investigate, not a delivery promise.

How do we decide whether we are ready?

Mark each section ready, needs evidence or blocked. Do not total the answers into a misleading percentage. A missing owner for sensitive records or an untested integration may matter more than several completed sections. Give each open question a person and a next action.

Compare configuration, integration and bespoke options using the Software Investment Framework. A smaller change may meet the need.

What is the next step?

Use the completed kit to brief a custom software project discussion. Ask the supplier to identify assumptions, propose a discovery scope and explain what evidence would change the recommendation. Keep responsibility for the decision with your organisation.

Related resources

Want to learn more? Read our blog or talk to FSS directly.