IT consulting and system design

IT consulting and system design is the work that happens before programming: finding out how a process works today, writing down what the system must do and designing the parts it consists of. The result is a requirements specification and an architecture decision from which any developer can build the system.

When it pays to start with analysis

There are four situations where analysis pays for itself sooner than development.

• Before a tender. You need to run a tender or get several quotes, but there is no document that makes suppliers price the same thing.
• When proposals cannot be compared. Three suppliers sent three different prices for three different scopes, and there is nothing to compare them against.
• When a project has already stalled. The system is being built, but the scope grows every month because nobody agreed at the start where it ends.
• When it is unclear whether a system is needed at all. The process hurts, but it is unclear whether the problem lies in the tool or in the process itself.

What you get

The analysis ends not with a presentation but with a set of documents that can be handed to a third party. The scope is adjusted to your needs, but the standard set looks like this.

• Process map. How the work is done today: who does what, where data changes hands and where it gets retyped a second time.
• Functional requirements list. What the system must do, written as separate items that can be accepted or rejected one by one, and later used to test the result.
• Non-functional requirements. Number of users, data volumes, access rights, security and accessibility requirements, backups. The most frequently forgotten part, and the one that later drives the price.
• Architecture decision. Which parts the system consists of, where data is stored, how the parts talk to each other and why this particular structure was chosen.
• Integration list. Which existing systems need to be connected, how, and which data flows in which direction.
• Technical specification. A document for a tender or for collecting quotes, written in requirements rather than technology names.
• Scope and phasing plan. What goes into the first version, what is postponed, and the reasoning behind that order.

How it works

A conversation about context. One meeting where we find out what hurts and which solution you are already considering. Afterwards we send you the analysis scope and an estimate.

Process interviews. We talk to the people who do the work every day. Not to a single representative but to several people from different stages, because they usually describe the same process differently, and those differences are the most important information.

Review of existing systems. We look at what already works: accounting, spreadsheets, the online store, warehouse software. Some requirements fall away once it turns out the function already exists and only needs an integration.

Writing and agreeing the requirements. We review the list with you and split it into what is essential for the first version and what can wait. This conversation usually determines the project price.

Architecture and specification. We design the structure of the system and prepare the document. We present it in person, so that it is clear not only what is written but why.

The document is written for you, not for us

A specification would be useless if only its author could understand it. That is why requirements are written as functions and outcomes rather than technology names. If a decision is dictated by your existing environment, such as your accounting software or public sector requirements, it is stated as a constraint with an explanation, not presented as our choice.

In practice this means you can take the finished specification to several developers and get comparable proposals. If we build the system afterwards, the completed analysis is counted towards the development scope.

For public sector procurement

In public sector projects, the analysis must end with a document that holds up throughout the procurement procedure. The technical specification is written in terms of functional requirements and a description of the outcome, without references to specific products, brand names or patents that would favour a single supplier.

On top of that come requirements private buyers usually do not have: accessibility to WCAG 2.1 AA, personal data processing requirements and document retention periods. We write these down together with the functions instead of leaving them to the supplier's discretion.

What this service does not cover

We do not advise on server administration, workstation support or computer networks, even though in Lithuania this work is also called IT consulting. Our field is software: processes, data, requirements and system structure.

If you need an existing website assessed rather than a new system designed, there is a separate free website audit for that.