1. I ask the client for a brief (an outline of what they want, not a detailed spec, the general what rather than how, when or why).

2. I give them a spec which satisfies the brief, highlights any areas they might not have thought of, and outlines exactly how the work will be done and what it will entail (and what it won't), and how long it will take in days of work (not days on the calendar), broken down into small subunits of several days each.

3. We sign off on the spec (with any revisions they want), agree on a schedule (based on the time estimates with plenty of padding added for feedback, approval stages etc), and I start work.

The padding for the schedule (perhaps 3 x work days) won't cost them extra, and is there to cover the inevitable friction that working in groups produces, but if you're contracting you can spend that time waiting for feedback doing other work, so it comes at no cost to both parties. Probably the padding increases as the size of the company you're working for does.

I've never received a spec from a client that I was completely happy with, so it's easier to turn it around and accept a brief describing their goals in general terms, then give them a detailed description of how, when and why I would produce what they want. Asking them for the detailed specification, or even accepting one from them without lots of discussion, usually leads to problems as you're relying on the client to specify things they may not fully understand, you're asking them to tell you exactly how to do all the work, and by starting with their spec and mangling it or forcing lots of compromises, you make them feel they're not getting what they want. Whereas turning this around and giving them a spec lets you explain the cost/benefit of all decisions up front, and still gives them room to add/remove things as they wish as they approve the spec.

I do this even for design work as well as programming work, as there are a surprising number of constraints which a client may not consider, but will wish by the end of a project they had. All that said, most of my best ideas come from clients half way through a project, so you can't expect things not to remain fluid - that's just the nature of creation - as long as changes improve the end result and don't have knock-on effects I welcome them.

I'm not really convinced the article is correct in estimating 1 day as the horizon over which most developers can't see - in my experience that's too low, and it'd be more like several days, and as long as you split tasks up when estimating, it's not hard to estimate the actual hours worked - far harder is to estimate the friction introduced by bureaucracy and politics in larger organisations. I suspect that's where most inaccuracies in scheduling creep in.