The project finishes. The new system runs. Six weeks later a second invoice arrives for work everybody in the room believed the first one covered.
Nobody lied. The scope of work named a deliverable and left a boundary undrawn. That undrawn boundary turned into billable hours, and the argument that follows costs more goodwill than money.
Businesses shopping for IT consulting in Arkansas usually compare proposals on two numbers: the total and the timeline. Both numbers sit on top of a document that decides what the project actually includes. Read that document first.
What a scope line is, and how it bills twice
A scope of work lists deliverables. Each deliverable has an edge where the consultant's responsibility stops. The scope line is that edge.
Double billing happens when two parties draw the edge in different places and neither writes it down. The consultant quotes the work up to their line. You approve the price expecting the work up to yours. The gap between the two lines is real work, somebody has to do it, and the contract puts it outside the fixed fee.
Nothing in that sequence requires bad faith. It requires a vague noun. "Integration," "migration," "training," and "support" all cover a wide range of effort, and a proposal that uses the noun without the specifics has left the edge for later.
The check: take the proposal and circle every deliverable stated as a noun with no verb attached to it. Each circle is a scope line nobody has drawn. Ask for the verb in writing before you sign.
The seven lines worth reading twice
Seven boundaries produce most of the change orders on a technology project. Read them in this order.
1. Discovery and what happens if it changes the plan
Most engagements open with a discovery phase. The consultant reads your systems and writes findings. That part is usually priced clearly.
The question the proposal often skips is what happens when discovery finds something the estimate did not assume. An undocumented database, a custom module nobody can compile, a license that expired in 2019. Ask whether the implementation price is fixed before discovery or after it. A price quoted before discovery is an estimate wearing a fixed-fee costume.
2. Integration, named system by system
"Integrate the new platform with your existing tools" is the most expensive sentence in technology proposals. It names no tool and no direction.
A real integration line names each system, each direction data travels, and how often it travels. Your accounting package sends invoices to the new platform hourly. The new platform sends payment status back nightly. Two named systems, two directions, two frequencies. A consultant can price that sentence in an afternoon, and the vague version leaves the price open until the work is already underway.
3. Data migration and who cleans the data
Moving records is one job. Fixing them is another, and the second job is bigger.
Old systems accumulate duplicate customers, dead addresses, and fields somebody repurposed for a different meaning in 2014. A migration line that says "transfer existing records" transfers the mess along with them. Ask who owns cleanup, how many records the price assumes, and what happens at record number one hundred thousand and one.
4. Testing, and whose staff runs it
Consultants test that the system works. Users test that the system works for the way your business actually operates. These are different tests and they catch different failures.
The proposal should name how many hours of your own people's time the plan assumes. That time is a real cost on your side of the ledger even when it never appears on an invoice. A plan that quietly assumes forty hours from your operations manager during your busiest month has a scheduling problem hiding inside a technology problem.
5. Training, counted in sessions and people
"Training included" tells you nothing about how much. Count it in sessions, in people per session, and in whether a recording exists afterward.
Staff turnover makes the recording matter more than the session. A business that trains eleven people in March and hires four more in July needs the material to survive the trainer leaving.
6. Documentation you can hand to the next firm
Ask for the deliverable by name: a configuration document, credentials in your possession, and a written description of every customization somebody wrote for you.
Firms rarely refuse this. They rarely volunteer it either. A project that ends with the knowledge living only in the consultant's head has locked you into that consultant, and the lock costs money the day you want to change.
7. The support window, with a start date and an end date
Post-go-live support is where the second invoice usually lands. The proposal says support is included. It does not say for how long, for how many hours, or what counts as support against what counts as a new request.
Write the window down. Thirty days from go-live, up to twenty hours, covering defects in the delivered work. Then write down what happens on day thirty-one, because that is the day the meter starts.
The check: for each of the seven, write one sentence on paper stating what you believe the consultant will do. Send those seven sentences back and ask for a yes or a correction on each. The corrections are your real scope.
The change order clause decides the whole argument
Every project changes. The clause that governs change is worth more attention than the price.
A workable clause does four things. It requires written approval before any extra work starts. It states the hourly rate in advance. It caps the total change budget without your signature. And it puts a deadline on how fast the consultant must tell you that something is out of scope.
That last one matters most. A consultant who discovers a scope gap in week two and mentions it in week nine has handed you a bill you could have prevented. Ask for notice within five business days of the discovery.
Fixed fee and hourly, and what each one hides
Both pricing models are honest. Each hides a different risk.
A fixed fee moves risk to the consultant, and the consultant prices that risk into the number. When the project runs long, they absorb it. When the scope is vague, they pad it, or they defend the boundary hard and every question becomes a change order.
Hourly moves the risk to you. The rate looks lower on the first invoice. Nothing caps the total unless you write a cap into the contract, and nothing rewards the consultant for finishing early.
The check: ask for the same project priced both ways. The gap between the two numbers is the consultant's own estimate of how much risk your project carries. A firm that refuses to quote both is holding an opinion about that risk it prefers to keep off the page.
Credentials, licenses, and who owns what you paid for
Three ownership questions decide whether the work belongs to you when the engagement ends.
Software licenses first. A license purchased in the consultant's name and resold to you as a line item may not transfer when you leave. Ask whose name sits on the account.
Administrator credentials second. You should hold the top-level administrator account for every system on the project on the day it goes live. A vendor holding the only admin credential controls your access to your own data.
Custom code third. If somebody wrote code specifically for your business, the contract should say you own it and you get a copy. Stone Path does not build software, and it does not take a position on anybody's code. Owning what you paid for is a contract question, and it belongs in the contract.
Reading an Arkansas proposal against a national one
Firms buying IT consulting in Arkansas often collect one local bid and two remote ones. The comparison is fair only after you normalize three things.
Onsite time is the first. A remote firm quoting a lower rate may bill travel when the work requires hands on hardware, and the travel line rarely appears in the summary. Ask how many onsite days the plan assumes and who pays to get there.
Response time is the second. A four-hour response commitment means something different from a next-business-day commitment when your point-of-sale system goes down on a Friday afternoon. Ask for the commitment in hours and ask what happens when it is missed.
References are the third. Ask for two businesses of similar size that finished a similar project more than a year ago. Recent references describe the sales experience. Older references describe what the support window felt like on day two hundred.
Where this fits in a larger plan
A scoping problem usually signals a sequencing problem underneath it. Firms buy a platform before deciding what order their systems should move in, and the scope goes vague because the plan is vague. A digital transformation roadmap settles that order before anybody writes a proposal.
The same math applies to any technology purchase. The break-even math on AI consulting walks the calculation for one common case.
How Stone Path handles a technology engagement
Stone Path Consulting works as a strategic facilitator. It reads what a business actually needs and connects that business with a vetted partner who does the work. Stone Path does not build software and does not deliver the technology work itself. The partner bills the client directly.
Ty Woods runs the firm and takes the calls. Stone Path charges nothing for a consultation and nothing for a referral.
Stone Path works with businesses across Arkansas and nationally. Use the contact page and describe the project you are scoping, the systems it touches, and the proposals already on your desk. The reply names the seven lines your documents leave undrawn.