Fixed Fee vs Time and Materials When Scope Keeps Moving

A developer needed to take a few days off. Then the client didn't get us their content when they said they would. All of a sudden I was at the end of the project, trying to explain why we were hundreds of hours over. It was death by a thousand cuts. There was never one thing that killed it.

Another time, I didn't track the changes as they were going along. They piled up like a dam that was about to break. Then I brought all of it to the client at once, a little aggressive, and the client said it was the first time they were hearing it or seeing it.

Key Takeaways

• You should always have a mix of fixed bid and time and materials projects in your agency.
• If we're confident in the delivery and we've done this before, I would usually fix the price.
• If the designs change, the scope changes.
• Every change gets logged where the client can see it.

Why does scope keep changing on agency projects?

Email happens in a moment. But the client is making little decisions over time, and all that stuff just gets swept under the rug. You need to show it's building toward a big change in the schedule, the scope, the money or the timing.

Time will fill whatever space you give it. That's just how the world works.

It's harder when the client has scoped the project themselves and hands you a scope to execute. That never goes well.

Fixed fee or time and materials: which fits the work?

There is no ideal. There's either time and materials or fixed bid projects, and you should always have a mix of them in your agency. With custom work you don't have a standard way of working, so it's impossible to have one way of presenting cost to a client.

If we're confident in the delivery and we've done this before, I would usually fix it. It's easier for the client, and then the responsibility is on the team to deliver.

When somebody asks for a website with three screens, a newsletter form, a contact page and a blog, you know what to do. You've done this. Just fix it, and make some extra money off of it.

Some work is unknown. Even the client couldn't tell you how a third-party integration works. You should never fix that, because that's just irresponsible. You're making it up.

If it's time and materials, usually give a wide range, because you're dealing with less confidence. The developer says it could take a day or it could take two weeks, because they've never done it before.

Then ask whether it's a strategic client. If it's a fly-by-night startup and you're worried they won't even pay you, go straight into time and materials because the risk is higher. And start invoicing them monthly.

At agencies I was at in the past, we'd offer a fixed bid price next to a time and materials price. The client would always go with time and materials, because they thought it would come in cheaper.

Whether to leave hourly billing altogether is a different question, covered in value-based pricing for agencies.

How do you fix the known and bill the unknown?

Custom, weird things we've never done before should be more time and materials than not. I'd fix the first phase and bill the integration as time and materials.

We set clear expectations with the client: the project has a budget for the core and a separate budget for the unknown part. You give it to the team and tell them to track both. You basically have two estimates within one. Then we just send them two contracts. One is a fixed cost for the core project, and the other is a time and materials project for the unknown part.

Sometimes the unknown appears mid-project. Then we go back to the client and say we're going to do a deep dive into that system and come up with another estimate.

When it's never been built before, we charge for an architecture phase. I'm not going to give away estimating an architecture for free, because it's valuable work. The project plan should have been to build nothing until we know what we're building.

If the estimate is bigger than their budget, you say okay, great. Pay me to design a solution for the budget you have. The people who said yes were people I wanted to work with, because they understood you've got to spend money to make money.

People don't want to pay for discovery anymore, so we can't use that word. A decade ago, we could get away with it.

If there's a fast follow, you've got to have a clear separation of what was in the past phase and what's in the next one. Work that didn't get done in the first phase gets rolled into the second, which happens all the time. That separation draws the line in scope, and it protects your own internal profit.

How do you pin scope so a change is easy to point at?

If the designs change, the scope changes.

At the agency I ran, the client signed a scope of work, and the design file was the scope of work in practice. Only what's in the design file is in scope, and the client has access to it at any time. If we're in a sprint and they say it's really got to do this, great. We can adjust the design and up the scope right then and there.

A screen is easier to explain than a spreadsheet. A line item with a price makes the client ask why. When they see the screen, you can say, see how the drop-down now does this? That's another line item.

If you don't get design involved, you're already moving against a headwind in every project.

When the work has no design file, write the scope down. Before the team makes a feature, they have to write out what it does. Then we give the client test acceptance criteria: follow these steps, and that's how you test your software. If they then say they logged in but couldn't reset their password, we ask whether that's anywhere in the acceptance. It's not there, so you pay for adding that feature.

We start to front-load sales with requirements gathering, which slows everything down, because now you've got to have it down to whether or not there's a forgot-password link.

How do you track changes so the client sees them?

Every change gets logged. If the client is just making some copy tweaks, a lot of times we're not going to charge for that. But if someone on the team sees a new copy change every single week, we need to stop.

The client has to see how the decisions they're making along the way affect the schedule and the money. If they don't, it's on you. They don't know how to do this.

It also makes you less of a black box to the client.

On one project I told the client we needed to do more discovery, and they flatly refused to pay for discovery. The site had changed, with new designs and new copy. When I called it brainstorming, they were all in. It's just a different word for the same work.

The whole purpose of demos is to show the client that work is in progress. We used to write a big, long scope of work and go dark. Then we'd show the finished work, and the client would say, this cost me that much? They didn't understand the effort that went into it.

When a change comes up in a demo, ask: do you want to pay for it or not? Right then and there. If they say they don't think they should have to pay for it, great. We can keep going and move it to a parking lot discussion. The project manager is then in control of the budget and the project, because they're seeing how it's going every two weeks, and so is the client.

Skip this and you get to the end of the year with a project that went way over budget and a client who isn't paying for the scope changes. That comes straight out of the agency profit margin.

How does Schmidt Consulting Group help an agency owner price when scope moves?

Schmidt Consulting Group works with founder-led agencies and professional services firms on positioning, pricing and new business.

Mentorship is twice-monthly counsel for founders on pricing, hiring, clients and direction. The founder sets the agenda, and the firm's team does the work.

Advisory is a weekly operating rhythm for growth: a written plan, one priority at a time, and a review of results every week.

A two-founder production studio worked with us twice a month. The list of companies built in those sessions got them a meeting with Google.

You'll hear the fee on our first call.