IT Consulting

The asymmetry that costs you

When a business hands software development to an outside partner, the two sides of the table don’t have the same information. One knows the subject in depth; the other has to evaluate quotes, approve specifications and sign a contract for something it cannot verify.

This is rarely down to bad intent. It happens because the two sides speak different languages and measure success differently: the software company delivers what the contract describes, while you expected what you had in your head. The gap between the two is what produces delays, extra costs and applications that nobody ends up using.

With our IT Consulting service we undertake to close that gap. We sit on your side of the table.

Three levels of involvement

Depending on where you are and how much you want to keep in your own hands, the collaboration takes one of three forms. They work independently, but also in sequence: many projects start with the first and end with the third.

1. Process organisation and specifications

Before you even look for a contractor.

Most businesses know that something needs to be computerised, but haven’t settled on exactly what. The processes exist — they just aren’t written down anywhere: they live in Excel files, in emails and in the memory of three people.

Together with your managers we document how you work today, find where time is lost and where the same data is entered twice, and translate your needs into a documented specification: what the application must do, in what priority, and what is explicitly not included.

That document is the greatest protection you can have. You request quotes against it — and for the first time the quotes you receive will be comparable with one another, because they cover exactly the same scope.

2. Technical adviser in your meetings

When you have a contractor and want to understand what you are agreeing to.

We attend your meetings with the software company as your own person. Our role is twofold: to translate towards you and to articulate towards them.

Towards you, we explain in plain language what you are hearing means in practice: what an architectural choice implies, what hides behind a term, where a decision that looks like a technical detail today will commit you, and exactly what you will have in your hands at the end.

Towards the other side, we state your needs in the terms an engineer expects, so that nothing is lost in translation and there is no room for “we didn’t understand it that way”.

Typically we take on:

• Evaluating and comparing quotes, with emphasis on what they leave out
• Reviewing the technical terms of the contract before signing
• Taking part in design and progress meetings
• Assessing changes requested along the way and their real cost
• The questions that usually aren’t asked in time: code ownership, access to the data, backups, and what happens if the collaboration ends

3. Full project management

When you don’t have the time or the person to follow it.

In the fullest form of the collaboration we manage the project on your behalf, from choosing the contractor to final acceptance. We become the single point of contact: the software company deals with us, and you are involved only in the decisions that are really yours.

Management covers:

• Communication. Daily contact with the development team, so questions are answered without blocking the project.
• Schedule. Tracking progress against the agreed milestones and flagging deviations early, while there is still time to correct them.
• Quality control of deliverables. Every deliverable is checked before approval: tested against real usage scenarios, checked against the specification, and findings returned in documented form.
• Acceptance. Organising the final testing and acceptance with clear acceptance criteria — so that approval isn’t a matter of impression.

The aim is simple: your signature should not be the only technical judgement exercised on the project.

Why a software company for this role

It’s a fair question: VK Solutions develops software. Why should it oversee a project that someone else carries out?

For exactly that reason. Since 2006 we have been on the other side of the table: we know how a quote is put together, where time is usually underestimated, which questions are never asked at the start, and what a deliverable that “is ready” means in practice. That knowledge isn’t acquired from the customer’s side.

When we act as advisers, we don’t compete for the development of the project. If at some point it is judged preferable for us to take it on, that is discussed explicitly and separately — it doesn’t emerge from within the consulting relationship.