Planning Your Next Technology Project

A technology strategy connects a business outcome to the decisions needed to achieve it. It helps you decide which problem to address first, which parts of your operations will change, and how you will evaluate whether the work was useful.

Without that definition, you can end up comparing proposals that solve different problems or adopting a tool without knowing who will use and maintain it. You may also overlook a useful improvement to a system you already have.

Start with a decision

Choose a question you can investigate. For example: “What needs to change so that sales and operations work from the same order status?” This gives you a more useful starting point than a list of tools or a statement such as “We need AI.”

Describe the full workflow: who starts the task, what information they provide, who receives it, and what happens when an exception occurs. A delay the customer notices may start with an internal step you have not yet considered.

A working example

This fictional example is used only to explain the exercises. A small business receives orders through a form. Sales records them in a spreadsheet, and operations enters them again in its own system. When an order changes, both teams must confirm which version to use.

The initial problem is duplicate data entry and uncertainty about order status. Before recommending an integration, the team needs to establish what information each system handles, who can change it, and how errors are corrected.

Define the outcome and the evidence

• Desired outcome: describe what the team or customer should be able to do better. In this example, view a consistent order status and avoid unnecessary reentry.
• Current situation: record real examples and, if possible, a baseline measure, such as manual steps per order or orders that need a correction.
• Validation: state what you will observe after the change and who will review it. If you do not yet have data, gathering it is your first step.

Keep expectations separate from promises. Your objective guides the investigation; feasibility and results need to be established with evidence.

Record your starting point

• Process to review: …
• Observed problem and recent example: …
• People affected: …
• A change that would be valuable: …
• Evidence available or still needed: …

Before discussing features, build a shared understanding. If two teams describe the problem differently, record both views and find an example you can use to compare them.

Business goals and the user experience

1. What decision do you need to make, and why does it matter now? Identify any real deadline, operational change, or specific opportunity.
2. Who experiences the problem? Distinguish between the person using the system, the person receiving the service, and the person approving the investment.
3. What is that person trying to accomplish? Describe a complete task, from its starting point to the intended outcome.
4. Where does the workflow break down or slow down? Record a recent example, what happened, and what the team had to do to resolve it.
5. What should the user be able to do after the project? Include how they will learn about an error and what options they will have to continue.

Scope and constraints

6. Which part of the process is worth addressing first? Also identify what falls outside this initial decision.
7. Which systems, data, or integrations must stay? Explain why, and check whether each constraint is confirmed or assumed.
8. What volume and exceptions must the operation handle? Describe known peaks, corrections, and special cases.
9. What budget and team capacity can you commit? Separate the initial investment from ongoing operations and maintenance.
10. What needs to happen before implementation? Consider authorized access, documentation, availability of key people, and unresolved decisions.
11. Who will make the decision, and who will be responsible for the system afterward? Clarify the capabilities of each person or provider today.
12. What information needs protection? Identify the data involved and who must review its use and access before it is shared.

Summarize the decision

Use your answers to complete this statement:

• “We want to improve … so that … can …. Today, we observe …. We will review … and leave … out of scope. To decide, we need to verify ….”

If you cannot complete it yet, start with the question that most affects the decision. A clearly identified gap is more useful than a project scope built on assumptions.

Your technology stack is the set of tools, systems, and integrations that supports your operations. An inventory should show what each part does and how it connects to the others.

List the systems in your chosen process

Include the spreadsheets, forms, and manual tasks that connect your tools. They often reveal information essential to understanding the workflow. Use one row per system and add rows as needed.

Follow one example from start to finish

Choose a recent order, request, or task. Walk through each step with the person who performs it. Record where information is captured, who changes it, and how it reaches the next system.

• Where is the same information entered again? Who checks that it matches?
• What happens when information is missing, an order changes, or a connection fails?
• Which steps depend on one person or on knowledge that has not been documented?
• What does the customer see while the team resolves the problem?

Separate observations from explanations

“We copy every order into a spreadsheet” is an observation. “The system does not support integrations” is a conclusion to verify through documentation or with the system owner. Record these two kinds of information separately.

Keep an example or reference for each finding: vendor documentation, a process description, or a screenshot with personal information hidden. Use test data when it is sufficient. Do not include passwords, keys, or credentials in this document.

What this review should produce

You should have a focused inventory, the workflow for one real example, and a list of friction points supported by evidence. If access or information is missing, note who can help and why it is needed. This sets the boundaries for the next investigation.

A useful review identifies what already works and the conditions each change must meet. Improving a process does not require replacing the entire stack. Sometimes the next step is to investigate a capability you already have but do not use.

Review each system against the same criteria

Assign a provisional decision

• Keep: the system serves the required purpose, and you can explain the conditions it must continue to meet.
• Improve: configuration, usage, documentation, or a limited change may resolve the problem. Validate that hypothesis.
• Investigate a connection: two systems do their jobs, but the transfer of information creates work or errors.
• Consider replacement: a significant limitation remains unresolved within the current system.
• More information needed: you do not yet have enough evidence to choose a direction.

Treat these decisions as working hypotheses. Record the evidence behind them and what could change your view.

The fictional example

For the order workflow, keeping the operations system may make sense if it handles dispatch well. The open question is whether it can receive orders and return their status. Before recommending development, review its documentation and agree on a limited test using sample data.

If that connection is not feasible, compare other options. That finding alone does not require a replacement. You also need to consider migration work and the effect on your team.

Compare approaches that address the same problem. For each one, describe what changes, what stays, and what you need to verify before committing to implementation.

Start with a manageable set of options

• Make better use of what you have: review the configuration, responsibilities, and use of existing tools.
• Connect systems: move information between tools that already work, defining how data will be validated and exceptions handled.
• Replace a component or build a solution: consider a different platform or custom software when the scope and constraints justify it.

Automation and AI may fit into any of these approaches. Evaluate them against the task, the available information, and how their outputs will be reviewed. Neither is a requirement for the project.

Test the solution against a real task

Ask for a demonstration of your use case, including its exceptions. Seeing a screen does not establish whether a tool can exchange your data, handle your volume, or work with the permissions you need.

Review official documentation and record relevant limits: required plans, integration conditions, data export, support, and usage-based costs. If something is unconfirmed, record the validation needed rather than assuming it is included.

Compare the full cost

Separate initial configuration or development, migration, training, and launch costs. Then record subscriptions, usage charges, maintenance, and support. Compare the same period and currency. Leave missing amounts as unknown, and state the assumptions behind any estimate.

Choose a next step that resolves an important uncertainty: a vendor question, a technical review, or a test. Document why it is worth doing before committing to the full project.

A recommendations table brings together your observations, the options, and the proposed next step. It helps business, operations, and technology teams discuss the same decision while keeping facts separate from expectations.

Use one row for each decision

• Describe the decision. Use a specific statement, such as “evaluate a connection between orders and operations.” A label such as “implement a platform” is too broad.
• Record the evidence. Explain the observed problem and how you verified it. If it is only a perception, say so.
• State the recommended approach and the alternative. Include what you would keep and why. Make the conditions that could change the choice explicit.
• Define the validation. State what needs checking, who can check it, and what result would let you proceed or rule out the approach.
• Set the order of decisions. Weigh business value, effort, risk, and dependencies. Avoid numerical precision your evidence cannot support.

A fictional recommendations example

This continues the order example. The rows illustrate the reasoning; they are not recommendations for a real business or results achieved by Spinlab.

Finish with a clear recommendation

Summarize what you propose to do now, why, what remains unresolved, and what the decision excludes. Note when to revisit it, for example after a vendor responds or a test is complete.

The table prepares you to make a decision. Implementation budget, scope, and commitments are agreed separately.

Copy this page and expand the rows to fit your project. Keep descriptions brief and link to evidence where available. Write “unknown” when you do not yet have an answer.

Decision context

• Business or department: …
• Process reviewed: …
• Decision owner: …
• Business, operations, and technology participants: …
• Review date: …

• Problem and available evidence: …
• Desired outcome and how to validate it: …

Project conditions

• Systems and data involved: …
• What must stay and why: …
• Budget, timing, and team constraints: …
• Out of scope for now: …

Your recommendations table

Review together

• Does the recommendation address the problem we agreed to review?
• Have we distinguished facts from assumptions?
• Do we know what needs checking before approving implementation?
• Is someone responsible for the next step?

• Decision and reason: …
• Missing information: …
• Revisit this decision when: …

Look for a team that can explain how it will move from your problem to a recommendation and how it will work with you afterward. The conversation should clarify the scope, dependencies, and your role.

Questions for the first conversation

1. How will you investigate our processes and technology before proposing a solution? Ask what information the team will need and what it will review.
2. How will you connect technical decisions to our desired outcome? Ask for an example of the reasoning, as well as finished screens.
3. What will we receive from the assessment? Ask for an anonymized sample or an explanation of its structure and level of detail.
4. Which options will you consider? Ask how the team decides whether to keep, connect, replace, or build.
5. Who will do the work and review technical decisions? Clarify the roles and points of contact on both sides.

Questions before you hire

1. What is in scope, and what is excluded? Ask for assumptions, deliverables, and change conditions in writing.
2. What will our team need to contribute, and when? Check whether that involvement is realistic given your availability.
3. Which dependencies could affect the project? Ask what happens if access, documentation, or another vendor’s response is missing.
4. How will we verify that the work meets the agreement? Discuss use cases, testing, corrections, and acceptance.
5. Who will manage the accounts and system afterward? Clarify documentation, training, support, maintenance, and access to deliverables.

Compare evidence and scope

Two proposals may have different prices because they include different work. Before comparing them, check whether both cover assessment, migration, integrations, testing, client participation, and ongoing operations.

Another client’s story can help you understand a team’s experience. Ask what problem the team solved, what it was responsible for, and which parts are genuinely similar to your situation. Do not assume your business will achieve the same results.

When to ask for more information

Ask for clarification if a solution appears before the problem is understood, dependencies are unexplained, or no one can specify what you will receive. Do the same if a promised timeline or outcome omits the conditions needed to achieve it.

By the end, you should be able to explain what you are buying, how your team will participate, and what information you will have to decide on the next step.

SpinGuide is our paid technology assessment. Every Spinlab project for a small or midsize business starts here, whether the eventual solution includes AI or uses other technologies.

We work with you to connect your business goals to an assessment of your processes and existing technology. The central deliverable is a recommendations document that brings together the findings, options considered, and priorities for your next step. We tailor the strategy to your business so you can make informed decisions about the technology experiences you create.

The five steps

• Onboarding Questionnaire.We gather context about your business, goals, challenges, current systems, and the people involved. We also identify questions and constraints that need attention.
• Ideation Workshop.We work with your team to describe the experience you want to create and connect it to the needs of your business and the people who will use the system.
• Assessment & Research.We review what can stay, what needs improvement, and which alternatives are worth exploring within the agreed scope.
• Clarity Workshop.We evaluate the options against budget, timing, team capacity, and other constraints to make priorities and dependencies clear.
• Recommendations Doc & Call.We organize the assessment and alternatives, then discuss the recommended direction and the conditions for moving forward.

These five steps describe how the work progresses. The depth of the review, session format, and timing are agreed as part of the scope.

What your team contributes

Your knowledge of the business is essential to evaluating the options. It helps to involve a decision maker, someone who knows the day-to-day operation, and the owners of the systems involved. We work with them to define the documentation and access needed for the agreed scope.

What happens next

If you decide to implement, we define and contract that project separately. SpinBuild covers design and development. SpinScale covers the support and ongoing evolution you agree to afterward. Each stage has its own scope.

Bring the answers or open questions from this guide to the first conversation. The initial goal is to understand your challenge and define the scope and terms of the paid SpinGuide engagement.

These published Spinlab stories show how a decision about processes and technology can develop into a project. They describe end-to-end work. They do not attribute every result to the assessment or predict what your business will achieve.

Moovin

Moovin needed its delivery operators to work directly in its platform. Spinlab created an interface with QR scanning to register packages, update their location, and assign them to routes. The case describes an operation that relied on WhatsApp and spreadsheets, and a project that combined SpinGuide, SpinBuild, and SpinScale.

Mundo HR

Mundo HR wanted to bring content, services, and business opportunities together in one platform. Spinlab worked with the client to define the product direction, prioritize ideas, and build a roadmap. It then designed and implemented the website in Webflow and integrated automations with Make.

Let us talk about your next decision

If you have a technology decision to make and need to evaluate the possible approaches, book a call with Spinlab. We will discuss the challenge, the people involved, and what you need to decide. That context will help us define the scope and terms of SpinGuide.

SpinGuide is a paid service. Implementation is agreed afterward, with its own scope. The initial call is a chance to understand the challenge and explore how we could work together.

What to bring to the conversation

• A specific process you want to improve and an example of what happens today.
• A list of the systems involved and the constraints you already know.
• Your recommendations table, even if some questions remain unanswered.

You do not need to arrive with a tool already chosen. Understanding what needs to change in your business is a useful starting point for deciding what to do next.