How to Read an IT Proposal When You're Not Technical: A Practical Guide for Executives

Daniel Sarica

Published: April 1, 2026

If you run a company of 50–150 employees, you probably receive IT proposals a few times a year. Maintenance, cybersecurity services, SOC 2 or HIPAA compliance, cloud migration, hardware, IT outsourcing, licenses. The proposals arrive in different formats, with different terms, at prices that vary enormously.

And every time it’s the same situation: you have to make a decision, but the document in front of you is written in a language you don’t fully command. It’s not that you’re not capable — it’s that IT proposals are written for technical people, not for management.

This guide helps you evaluate an IT proposal without technical knowledge. It won’t turn you into an expert, but it puts you in a position to make an informed decision (or at least to ask the right questions before you sign).

Part 1: The structure of a clear IT proposal

A well-built proposal, regardless of the field, should contain a few elements you can evaluate as an executive.

Context and the problem

The proposal should start with a description of your situation: what the vendor identified, what problem it solves, why it matters now. If the proposal jumps straight to the solution without describing the problem, that’s a signal the vendor is selling a product, not a solution tailored to your company.

An example: “Your company has 85 employees, one on-premises server, and no MFA on email accounts. We propose implementing X to reduce the risk of unauthorized access.” That’s clear context.

Compare with: “We propose our complete, market-leading cybersecurity solution with advanced protection features.” That says nothing about your company.

Scope — what it does and what it doesn’t

This is probably the most important thing to check and the most frequently ignored. The scope defines exactly what’s included in the proposal and (just as important) what isn’t.

Things that are frequently missing from the scope and generate additional costs:

migrating existing data
team training
user-level configuration (not just system-level)
post-implementation support
documentation for the deliverables
the required software licenses (sometimes they’re separate)

If the proposal doesn’t explicitly state what’s not included, ask. It’s better to find out now than to discover it on an invoice three months later.

Concrete deliverables

What do you get at the end? A report? A configured system? Documents? Access to a platform? If you pay $40,000 and can’t show the board what you concretely received, the proposal was too vague from the start.

Phrases like “consulting and support” without defined deliverables are a red flag. Not because the vendor is dishonest, but because without clear deliverables it’s impossible to evaluate whether you got what you paid for.

Timeline

When it starts, when it ends, what happens if it takes longer. Proposals without a clear timeline are proposals without real commitment. Delays usually come from unclear dependencies — the vendor is waiting for something from you, you didn’t know you were supposed to deliver anything, and the project stalls.

Price and terms

This is where the biggest variations and the most confusion appear. The price section is covered in detail below.

Part 2: How to read the price of an IT proposal

Price is usually the first thing an executive looks at and the last thing they fully understand. Not because it’s complicated, but because it’s presented in different ways that make comparison difficult.

Fixed price vs. hourly estimate

Fixed price: you pay one amount, you get what the proposal says. The overrun risk sits with the vendor. Preferable when the scope is clear.

Hourly estimate: you pay based on hours worked. The risk sits with you. It can be reasonable for exploratory projects, but if the estimate is “100–180 hours,” the 80-hour spread at $300/hour is $24,000. Ask: “What’s the maximum cap? What happens if we exceed the estimate?”

Setup + monthly subscription

A frequent model in managed services and cybersecurity. The setup looks small, the subscription looks reasonable, but calculate the total cost over 24 and over 36 months. We’ve seen proposals with a $6,000 setup and a $4,000/month subscription that reached $102,000 over two years. A fixed-price alternative at $60,000 would have been cheaper over the same period.

That doesn’t mean the subscription model is wrong. Sometimes it really is the better fit. But you have to compare on the same time basis.

The all-inclusive package

It sounds good, but in practice it usually means you’re paying for things you’ll never use. The key question: “What can I remove from the package without compromising the outcome?” If the vendor can’t answer clearly, it’s probably not all-inclusive — it’s an all-in-one they haven’t adapted to your size.

Common hidden costs

software licenses billed separately from the service
data migration costs
training billed extra
post-implementation support at additional cost
the cost of exiting the contract (if you want out)
automatic annual price increases

A simple exercise: take the proposal and calculate the total cost over 24 months, including everything you can identify. Then compare it with other proposals on the same basis.

Part 3: How to compare two IT proposals

Most executives compare IT proposals on price. It’s the only variable that’s easy to compare, especially when everything else is technical and hard to evaluate.

The problem is that two proposals at different prices don’t necessarily mean different quality. Most of the time, they mean different things.

Where the big price differences come from

From practical experience, big differences (for example $30,000 vs. $100,000 for “the same thing”) almost always come from three sources:

Different scope. One includes more phases, more deliverables, or more systems covered. The other covers strictly the required minimum.

Different sizing. One proposal is calibrated for your 80-employee company. The other is a standard package for 500-employee companies, sent without adaptation.

Different delivery model. One is a project with a beginning and an end. The other is a 24-month subscription that also includes services you may never use.

A practical exercise: bringing the proposals to the same basis

Take each proposal and fill in a simple table:

Criterion	Proposal A	Proposal B
What problem it solves
What I concretely get (deliverables)
What is NOT included
Total cost over 24 months
Exit terms
References from a similar client

If you can’t fill in a cell, ask the vendor for clarification before you compare prices. A decision based on an incomplete table is a decision made on a guess.

Part 4: 10 questions any executive can ask an IT vendor

You don’t have to be technical to ask good questions. You have to be clear about what you want to find out.

What concrete problem does this proposal solve for my company?
What do I tangibly receive at the end of the project?
What is not included in the price?
What’s the total cost over 24 months, with everything required?
What happens if the project takes longer than the estimate?
What happens if I want to drop the service after a year?
How did you size this proposal? Is it standard or adapted to my company’s size?
Do you have a client of similar size and industry? Can I talk to them?
What’s the concrete difference between your proposal and one that costs half as much?
If I had to cut 30% of the budget, what would you remove without compromising the outcome?

Question 10 is probably the most useful one. The answer shows how well the vendor understands what’s essential and what’s optional for your company.

Part 5: Quick checklist — evaluating an IT proposal

Before you approve an IT proposal, check:

Do I understand what problem it solves? (in plain words, not technical ones)
Do I know what I concretely get at the end?
Do I know what is NOT included?
Have I calculated the total cost over 24 months?
Is there a clear timeline with defined milestones?
Have I asked what happens if I want to exit the contract?
Have I asked for references from a client of similar size?
Have I compared it with at least one other proposal on the same basis?
Has my IT person (or an external consultant) validated the technical side?
Can I explain to the board in 3 minutes what I’m buying and why?

If you can check all ten, you’re in a good position to make a decision. If you can’t check more than half of them, it’s worth asking for clarifications or a second opinion before you sign.