Before signing an IT proposal: what leadership must verify

Why a technical proposal needs a second reading

A technical proposal is already a way of framing the relationship, future dependence and the company's ability to steer delivery. Once it is signed too quickly, it becomes the reference for later discussions, even if its assumptions were incomplete.

For non-technical leadership, the trap is rarely obvious at first glance. The document may look structured, reassuring and priced in neat work packages. What is missing often matters more than what is written: acceptance criteria, responsibilities, reversibility, maintenance, security, hosting, support, governance and explicit exclusions.

The useful question is not only whether the price looks reasonable. It is whether the document lets leadership steer the next months without depending solely on the vendor's interpretation. That steering capacity is what actually protects the budget.

Signal 1 — Scope described as intentions

Vague scope is the first weak signal. When deliverables are described as intentions rather than observable results, later discussions become asymmetric. Phrases such as “customer portal”, “journey optimisation” or “ERP integration” can cover very different realities.

A usable proposal should make clear what will be delivered, what will not, what depends on the client, what depends on a third party and what will need a further decision. Without that split, every grey area can become a change request, a delay or a dispute.

Before signature, ask for examples of expected deliverables, explicit limits and a list of assumptions. If the vendor cannot clarify these points simply, that does not automatically mean the vendor is the wrong partner. It does mean the proposal is not yet ready to sign.

Signal 2 — No acceptance criteria

If nobody can say what will validate the work, the budget is exposed to endless iterations. Leadership thinks it is buying a result; the vendor may think it is selling effort, a phase or a list of tasks.

Acceptance criteria do not need to be complicated. They should answer practical questions: how will a feature be validated? Who gives the go-ahead? Which tests will be run? What happens if a delivery does not match the expected result? What correction window is included?

Without those points, the conversation quickly slides into impressions: “that is not what I understood”, “it was out of scope”, “we need another phase”. The larger the project, the more expensive that ambiguity becomes.

Signal 3 — An architecture imposed without alternatives

A serious partner explains the consequences of a choice. Leadership does not need to become a software architect, but it does need to understand effects on cost, maintenance, reversibility and later change.

When a vendor recommends a technology, hosting model, no-code tool, ERP, connector or platform, it should be able to say why that option fits this context, which options were discarded and why. The risk is economic as well as technical: an architecture can create a strong dependence on a vendor, a licence or an operating model. If that dependence is not understood before signature, it will be suffered afterwards.

Signal 4 — Ongoing costs are missing

Maintenance, hosting, monitoring, recovery, support, licences, updates, backups, security and later evolution are often underestimated. An incomplete proposal can look cheaper while preparing a lasting cost.

Ask what happens after delivery. Who maintains the system, at what price, with what response time? What does support include? What happens if the vendor is no longer available? How are data recovered? What will be documented? A delivered system without clear maintenance quickly becomes debt. A platform without reversibility quickly becomes a lock-in.

Signal 5 — Time pressure

When the company is asked to sign quickly without a contradictory reading, the risk is no longer only technical. It becomes a decision risk. Genuine urgency exists, but it should not prevent clarification of the points that bind the company.

A serious vendor can accept a short clarification phase before signature. If a few simple questions create tension, the proposal often cannot withstand scrutiny. Signature should not be used to make grey areas disappear. It should come when the important ones are clear enough.

Questions worth asking before signature

Concentrate the discussion: which deliverables will be visible at the end of each stage? Which criteria will allow acceptance? What is explicitly excluded? Which recurring costs should be expected? How can the company leave the relationship if needed? Who holds access, data and documentation?

These questions do not replace a full review, but they change the conversation. They force a move from commercial language to a steerable frame, and they show whether the vendor accepts a clear relationship or prefers an information imbalance.

Reconstructed field situation: the quote looks clear, the interfaces do not

In professional projects combining business applications, ERPs and flows between several systems, a proposal may cover screens or a connector without saying who supplies reliable data, who runs end-to-end tests and how an error will be corrected after delivery. The risk is not necessarily the announced price. It is often a responsibility left between two suppliers.

A useful reading compares the proposal with the real journey: where customer and product identifiers come from, how an order moves, what happens when a synchronisation fails, who validates discrepancies. From those answers, it becomes possible to complete the scope, prepare an exchange architecture and organise acceptance. This situation is reconstructed; it is not a Mahthildis client reference.

When senior expertise is useful, then how the project can move

Senior help becomes useful when the proposal binds a central tool, when integrations are complex, when leadership lacks internal technical capacity, or when a vendor is becoming the only source of truth. Mahthildis can stay with an independent review. If the project requires it and the scope is agreed, Paulo Castro can also frame interfaces, design the architecture, lead contributors and take on technical work. The first exchange is there to determine what is actually useful.

The best outcome is not always a refusal. Sometimes the right exit is to sign after clarification, with a few renegotiated points and clearer governance. In other cases, the reading shows that the proposal should be rewritten before it creates an expensive dependence.

A technical proposal should help leadership decide, not force it to trust blindly. If the document does not allow the company to steer what follows, it is not yet clear enough to commit the organisation.

What to keep after signature

If the decision is to sign, keep a record of the clarifications obtained. Vendor answers, exclusions, acceptance criteria and maintenance commitments should enter the contractual frame or at least the steering file. A verbal clarification protects little when the project becomes tense.

The reread proposal then becomes a governance tool. It helps prepare reviews, check milestones, arbitrate new requests and avoid returning to a vague relationship of trust. Depending on the mandate, this work can remain an independent analysis or open a precisely defined steering and delivery assignment.