Software development: what to include and how to prioritize it

When a team works with spreadsheets, messages and tools disconnected, the request usually comes as follows: "we need a program." The problem is that that phrase does not clarify what should be resolved, who will use it, or what would have to happen to consider the investment useful.

The software development is worth it when you translate a specific need into a system that allows you to perform actions, apply rules and manage information in a more orderly way. Upon completing this guide you can decide what to include in a first version, what to postpone and what information to prepare before evaluating the project.

If you are still comparing a standard tool, configurable solution or your own development, start with the criteria for choose business software. This guide starts from the back step: how to define and prioritize a project that does require development.

Direct answer: start with the problem, not with the application

Before choosing between a web application, a mobile app or an internal tool, it defines the change you are looking for. For example: reduce duplications when registering orders, give visibility to the status of a service or allow customers to consult documentation without relying on mail.

Technology is the solution; the goal is the reference to decide. If you can't describe the problem, the users and the action that needs to be improved, you still don't have a clear enough reach.

7 elements to be specified by a software development project

Operational or commercial objective It describes what should change with an observable phrase. "Manage management" is too broad. "Letting the team consult the status of each order in a single place" better defines the need and helps to check whether the solution fulfils its function.

People using the system It is not enough to indicate that it will be used by the company. It distinguishes, for example, between administration, commercial equipment, operations managers and customers. Each profile may require different screens, permissions and actions.

The main work route It explains what happens from the time a request enters to the time it is completed. A tour can include recording data, assigning a task, changing a state, attaching a document and alerting a person. This order reveals rules and exceptions that are usually hidden in an initial idea.

Data to be consulted or modified Identify what information the software needs: customers, orders, appointments, documents, incidents, inventory or other records specific to your activity. It is also important to define who can view, edit or delete each data.

The functions required in the first version A function must respond to both a target and a user. For example, a panel for assigning requests may be necessary if it prevents multiple people from working on the same subject; an advanced reporting system can wait if you start by simply consulting the main states.

Connections with other tools If the software must exchange information with mail, billing, payments, calendars or other services, specify what data travels, at what time and what should happen if the connection fails. Name an integration without describing that flow leaves a relevant part of the scope undefined.

Maintenance and evolution The project does not end when the system is put into use. Decide who will update content or data, who will have access and what changes are predictable. Thinking about it from the start helps avoid a solution that is difficult to modify when changing processes or needs.

How to prioritize without trying to build everything at once

It classifies each need into one of these four categories. Classification forces one consequence: include something now, postpone it or consciously discard it.

-Resistible: without this function the minimum target is not met. If the goal is to centralize requests, create, assign and consult a request you can enter here. -Desirable: provides utility, but the system still fulfils its initial function without it.For example, configurable warnings for different events. -Future: may make sense later, although it is not part of the first delivery.For example, an area for suppliers if you start with only the internal team. -Out of scope: does not meet the agreed target or belongs to another project. Leave it written prevents it from appearing as an implicit expectation.

To decide the category, answer these questions for each function:

• What goal does he support?
• Who's gonna use it?
• What if it doesn't exist at first?
• What data, decisions or external services does it depend on?
• How will you check that it works as you expect?

A function that has no user, purpose or way of validating itself is still a hypothesis, not a ready-to-develop requirement.

Example applied: a company that manages applications through multiple channels

This is a hypothetical example. A company receives requests by phone, mail and forms. Information is copied to a spreadsheet and the team does not always know who is handling each case.

Its objective could be formulated as follows:Register each request and make visible its responsible and state for the team.

A first version could include:

• access for the persons in the equipment;
• registration of applications with agreed fields;
• the assignment of the person responsible;
• defined states, such as pending, ongoing and closed;
• basic search and history query;
• a management view to review open cases.

However, the creation of tailor-made reports, a specific mobile application or connections with tools that have not yet been described in sufficient detail could be left for a later stage.

The decision is not to determine whether these improvements are good or bad, but to check whether they are necessary to solve the initial problem and whether their dependencies are clear.

What to leave out of the first conversation

You don’t need to arrive with a closed technical specification. In fact, deciding the technology before understanding the work you should endure can limit useful alternatives. It is preferable to leave these issues open until you specify the scope:

• the exact name of the technology or the type of app;
• functions defined only as ‘completes’, ‘simples’ or ‘intuitive’;
• integrations without a clear data flow and responsible;
• deadlines linked to a date without reviewing contents, accesses and dependencies;
• results formulated as guarantees;
• extras that do not contribute to the objective of the first version.

Nor should an application be treated as an isolated solution. If a process depends on internal decisions, incomplete information or rules that change frequently, those conditions must be reviewed before they become functionality.

Next step: turn need into a reviewable scope

It brings together a real example of the current process, the people involved and the tasks that generate the most problems. On that basis it will be easier to distinguish if you need an internal tool, a customer portal, a mobile app or another solution.

If you want to contrast the scope of an idea and its priorities, you can explain your custom software project . The useful starting point is to share the problem, users and actions that the system should allow; the technical solution must be validated later.