Consulting lessons from three years of client work

The first year, we said yes to almost everything

Early on, the instinct was to treat every "can you build this" as a yes, and figure out scope once the work had already started. A few of those projects went well. More of them didn't, not because the work was bad, but because the client and our team had different pictures of what "done" meant, and we only found out at the end.

What changed in how we scope a project

We now spend longer on the proposal than we used to, and it's the highest-leverage time on the whole engagement. A good scope document names what's explicitly out, not just what's in. It's uncomfortable to write "this does not include X" in a document you're hoping someone signs, but the discomfort is smaller than the argument about it three months later.

The client is not always right about the solution, and that's fine

Clients are almost always right about the problem; they live inside it every day. They're less consistently right about the solution, because that's the part we're supposed to know better. The projects that went sideways early on were often ones where we built exactly what was asked for, instead of pushing back on a spec that solved the wrong layer of the problem.

Smaller milestones, said out loud

We build in check-ins now that are short and specific: what shipped, what didn't, what's next. Not because clients need managing, but because a surprise at the midpoint of a project is always worse than the same information delivered two weeks earlier, even if the information itself hasn't changed.

The lesson underneath all of this

Most of what we've learned isn't really about software. It's about the conversation before the software gets written. Get that right, and the build tends to go the way everyone expected. Get it wrong, and no amount of good engineering fixes a project that was scoped badly from the start.