Free resource

Software project scoping checklist for UAE companies.

Prepare for a software project before you talk to anyone. Work through the questions on your own or with your team, then bring your answers to a discovery call.

Download the PDF
  • Free, no sign-up
  • Plain language
  • Arabic and English needs covered
  • Used in our free discovery call

In short

A software project scoping checklist is a short set of questions that helps a company describe a project before it talks to a software team. It covers the workflow, people, approvals, connected systems, data, languages, hosting, security and success. This free checklist is written for UAE companies, and Digital Cubic uses your answers in the discovery call.

How to use it

Three ways to get value from it.

You do not need a specification. A clear description of the work and the people in it is enough to begin.

  • Answer in your own words

    Rough answers are fine. Plain language is better than technical terms.

  • Skip what you do not know

    Leave a question blank, or write “not sure”. We work through the gaps with you.

  • Bring it to the call

    Download it, print it or copy the questions into a document, then keep it with you for the call.

The checklist

Questions to answer before the call.

Eleven short sections. Tick a box when you have an answer, and write it down beside the question.

The workflow and the problem

We start from the work, not from screens. A plain description of how it runs today is enough.

  • Which piece of work do you want to run better? Name it in one sentence.
  • Walk through it from start to finish: who starts it, what happens next, and how it ends.
  • Where does it slow down, go wrong or get lost today?
  • What do people use now: spreadsheets, email, WhatsApp, paper, an existing system?
  • What happens when something changes halfway through, such as a revised request or a late approval?
  • Which reports or answers do you need and cannot get quickly today?
  • Is this one workflow, or several that are connected?

People and roles

Roles decide what each person sees and can do, so we design them before any screen.

  • Which teams touch this work: site, office, finance, management, suppliers, customers?
  • What job titles or roles are involved, and what does each one do?
  • Does anyone outside your company need access, such as consultants, subcontractors or customers?
  • Who should see everything, and who should see only their own part?
  • Do people work in the office, on site, or both? Do they use phones, tablets or computers?
  • Which roles change often, for example temporary staff or project teams?

Approvals and rules

Approvals are where most spreadsheet and chat-based processes break. We write them down first.

  • Which steps need someone to approve or sign off?
  • Who approves what, and does it depend on the type or value of the request?
  • What happens when an approver is away, or says no?
  • Which business rules must always be enforced, such as limits, mandatory fields or required documents?
  • Which decisions need a record of who decided, when and why?
  • Do any contracts, policies or regulations shape how the work must be done?
  • Are there exceptions that happen often and need their own route?

Systems to connect

A new system rarely stands alone. Knowing what it must talk to keeps later changes small.

  • Which systems do you already use: accounting, ERP, HR, CRM, email, a document store?
  • What should flow between them and the new system, and in which direction?
  • Which of them can be replaced, and which must stay?
  • Do the existing systems offer a way to connect, or only file exports?
  • Who looks after each system today, and can we speak to them?
  • Are there tools people rely on that nobody officially owns, such as shared spreadsheets?

Data and documents

Existing records and files shape the design, and bringing them across takes care.

  • What records and documents must the system hold: drawings, contracts, invoices, forms, photos?
  • Where do they live now, and in what format?
  • Which existing data must be moved into the new system, and which can stay behind?
  • How clean is that data today? Are there duplicates, gaps or several versions?
  • Which documents need versions, expiry dates or approval history?
  • Who owns the data, and who is allowed to change or delete it?
  • Do you need to keep records for a set period for audit or legal reasons?

Arabic and English

Language affects layout, forms, reports and training, so it is decided at the start.

  • Which languages do the people who use the system work in?
  • Do screens need to switch between Arabic and English, with right-to-left layout in Arabic?
  • Do documents, reports or emails need to be produced in both languages?
  • Do names, addresses and notes need to be stored in both?
  • Are there company terms that must stay in English, or in Arabic, everywhere?
  • Who will review the Arabic wording before it goes live?

Hosting and data location

Where the system runs affects security, cost and who looks after it. There are several valid options.

  • Do you have a preference or a requirement for where data is stored, including the UAE?
  • Would you prefer it on Azure, on AWS, on private servers managed by Vloud, or in your own cloud account?
  • Does your company or a client have a policy on cloud providers or data location?
  • Who should look after hosting, monitoring and updates after launch: your IT team, us, or a third party?
  • Do you already have a cloud account or an IT team we would work with?
  • Is there a system built by another team that needs hosting or support too?

Security and access

Access rules are designed with the roles, not added at the end.

  • How should people sign in, and does your company already use a single sign-in system?
  • Which information is sensitive, and who may see it?
  • Do you need a record of who viewed or changed what?
  • Do you have a security questionnaire or policy we should follow?
  • Do clients or partners require specific controls from your suppliers?
  • Should we sign an NDA before we discuss details?
  • How should access be removed when someone leaves?

What success looks like

A clear picture of success tells us what to build first and how to judge the result.

  • If the project works, what is different for your team on an ordinary day?
  • What would you stop doing, and what could you start doing?
  • Which result matters most: control, speed, accuracy, visibility, or something else?
  • How will you tell that it is working? Name a check you would trust.
  • Which part would deliver value first if it were usable early?
  • What would make you call the project a disappointment?

Who decides and who uses it

Projects move at the speed of decisions. We plan around the people who make them.

  • Who is the main contact for the project, and who has the final say?
  • Who else must agree before work begins, such as finance, IT or the owner?
  • Who will use the system every day, and can they take part in early reviews?
  • How does your company usually approve a new project or a new supplier?
  • Is anyone likely to resist the change, and what would help them?
  • Who will be the owner of the system after launch?

Constraints

Limits are easier to design around when we know them early.

  • Is there a date or event this has to be ready for? What is behind it?
  • Is there a budget range or approval process we should know about? You can leave this blank.
  • Are there tools, vendors or technologies you must use, or must avoid?
  • Are other projects or changes happening at the same time?
  • Can the work be released in stages, with one part used first?
  • Is there anything we have not asked that we should know?

What happens next

How we use your answers.

The checklist is the starting point of the first conversation. It makes that call shorter and more useful for you.

  1. Free 30-minute discovery call

    A working session on your answers, not a sales pitch. We ask follow-up questions and tell you honestly if we are not the right team.

  2. Written scope and proposal

    If we fit, we confirm scope, timeline and price in a written proposal, one phase at a time, before you commit to anything.

  3. A first module you can use

    We design the architecture first, then release the system in modules so your team uses real software early.

Take it with you

Download the PDF to fill in on paper or on screen, or print this page. No email address is needed.

Download the PDF

Want to see how we work after the call? Read how we engage and our six-stage method.

Ready to talk?

Bring your answers to a free discovery call.

Send us your answers, or just the name of the workflow you want to fix. It starts with one conversation. We get back to you as soon as possible to arrange a free 30-minute discovery call.