TechRam For Executives and GMs
How does TechRam scope fixed-price SharePoint work?
TechRam prices SharePoint work as a fixed price, agreed in writing after discovery, rather than a day rate — so what a SharePoint consultant costs you is known before the work starts. The scope covers build, test, documentation, handover and training, and the number doesn't move because the work turned out harder than expected.
Why fixed price is the harder promise
Time and materials is easy to sell and easy to deliver. The risk sits with the buyer, and if the work takes longer than anyone thought, the invoice absorbs it.
Fixed price moves that risk to us. That’s the point, and it’s also why the scoping has to be real. A fixed number written before anyone understands the work isn’t a commitment, it’s a guess that somebody will end up arguing about.
So the number comes last.
Discovery comes first, and it’s written down
Every engagement starts with discovery sessions with the people who actually do the work. Not the executive sponsor, and not only the IT manager — the person who fills in the form, chases the approval and rebuilds the report on the last Friday of the month.
We’re after three things:
How the process actually runs, including the parts that aren’t in the procedure. The workaround somebody invented two years ago is usually load bearing.
What it currently costs. Hours, rate, frequency. If the number is small, we’ll say so, and we’ll tell you the build isn’t worth doing yet. That conversation is cheaper for both of us than a project that never pays back.
What has to be true at the end. Not “an improved process”. A named state: this register exists, these people own it, this report goes out on this day without anyone assembling it.
That third one is the scope. If it can’t be written down, it can’t be priced, and we’ll tell you rather than guess.
What is inside the number
The price covers build, test, documentation, handover, and the training that makes handover real. All four of the last ones are the ones that get dropped from a cheaper quote, and they’re the difference between a system your team runs and a system that quietly stops being used.
The number doesn’t move because the work turned out to be harder than we expected. That risk is ours. It’s the thing you’re buying.
You also own everything at the end: the systems, the documentation, and the ability to maintain them without us. There’s no licensing fee to TechRam and nothing lives in our tenant.
The two things that do move it
Only two, and both are visible before they reach an invoice.
A change of scope you ask for. New requirement, different integration, another department added. We price the change, you decide, and it’s written down the same way the original was.
A dependency on your side that doesn’t arrive. Access to a system, a decision from a person, sign-off on a data model. We name these in the scope with a date against each, so the dependency is visible as a dependency rather than surfacing later as a delay somebody has to explain.
Nothing else moves the number.
Why the Baseline usually comes first
Most of the work we’re asked to scope sits on top of a tenant nobody has read. Scoping a governance project without knowing the permission model, or a migration without knowing what the storage holds, means padding the estimate to cover what we might find. That padding is a cost you pay for our uncertainty.
The Environment Baseline removes it. Two to three weeks, read-only, and it ends in a prioritised plan with a number against each item. Everything scoped after it’s scoped against what is actually in your tenant.
It’s also the cheapest way to find out that you don’t need us for the thing you thought you did.
What you get before you commit
A scope document that names the deliverables, the dependencies, the sequence and the timeframe. A fixed price against it. And, where the work is replacing something manual, the current cost of that thing so you can see the two numbers side by side.
You take that to whoever approves it. If they say no, you keep the document, and it’s still the clearest description of the problem anyone has written down.
Where to start
A Discovery Call is thirty minutes and it’s where we work out whether there’s something worth scoping at all. If there isn’t, we’ll tell you on the call.
Common questions
01. What happens in discovery before a number is given?
Sessions with the people who actually do the work, after three things: how the process really runs including the workarounds, what it currently costs in hours, rate and frequency, and what has to be true at the end as a named state. That third one is the scope.
02. What is inside the price?
Build, test, documentation, handover, and the training that makes handover real. Those last four are what gets dropped from a cheaper quote, and they're the difference between a system your team runs and one that quietly stops being used.
03. What can move the number once it's agreed?
Two things, both visible before they reach an invoice. A change of scope you ask for, priced and written down the way the original was. And a dependency on your side that doesn't arrive, which is why each one is named in the scope with a date against it. Nothing else.
04. Why does the Environment Baseline usually come first?
Scoping work on top of a tenant nobody has read means padding the estimate to cover what we might find, and that padding is a cost you pay for our uncertainty. It's also the cheapest way to find out you don't need us for the thing you thought you did.
05. What does a SharePoint consultant in Sydney cost?
It depends on the scope, which is why a fair price comes after discovery rather than before it. What moves it is how many departments the work covers, how many systems it has to connect, and how much clean-up the tenant needs first. We don't publish a range. You get a fixed price in writing once the scope is written down, and it doesn't move if the work turns out harder.