Programmer for Hire

My recent involvement in spot checking someone else’s proposal really brought home for me an interesting dichotomy in approaches and schools of thought when it comes to spec’ing out a project.  (By “spec’ing”, I refer to the process of assessing and describing the specific needs of a project, and then assigning a price tag and time line to that assessment.)

My training (or, perhaps more accurately, my invented approach from when I started doing this back in the MonsterCommerce days) has taught me to do a rigorous analysis of all facets of the project up front.  I don’t submit a proposal until I can firmly describe what features will be included (to at least the level of detail of which entities the system will model and manage), and am able to assign a price tag to each one of those features.   There are a few pros to this approach that I can think of:

• A pretty accurate price tag for the whole project falls out just by adding up the module costs, plus perhaps some overhead of communication, project management, and/or padding for middle- and end of-project tweaks and revisions.
• I’m clear what I’m committing to so I know I can deliver on time (and not bust).
• My client sees exactly what they’re getting: it’s an opportunity to verify that our understandings align, and they can spot if there is anything missing.
• A sort of a la carte pricing becomes possible when clients can see how various features contribute to the cost: it enables them to tailor things to fit their budget or decide to hold off on certain features if necessary.

The major con of this approach is the time and effort it takes on my part to cook up such a rigorous sketch of the project before I see the first dollar.  The ability to do it quickly thanks to copious practice does well to mitigate this con, however.

The other approach then is of the quick, more glossed over variety.  This is where a price is given based on satisfying the high-level needs of a project, and that price will be set to cover a fair chunk of reasonable expectations to that end.  (In other words it’s like the contractor saying “We don’t need to go into details, I’ll price it so that no matter what specifically you’re thinking I’ll be happy to deliver.”)  I’ve seen it done often enough to know that it’s not uncommon, and there’s good reason for its popularity.  From the perspective of the one preparing the proposal, it’s quick, it’s easy, and though it may be accepted less often, it’s more profitable when it is.

Now with this dichotomy laid out it bears mention that the two approaches I describe are actually two points on a spectrum, one that extends out to greater extremes in both directions than what I describe above.

There is no objective best place on this spectrum to be for both clients or contractors, every point has certain drawbacks and merits.  (I may seem biased towards the detailed end, but rest assured I know the dangers of being too detailed: clients eyes glaze over, and/or they’ll feel locked in by too much contractual rigidity).  Still, if you’re hiring someone to do a project, it’s probably useful to recognize where your contractor is with their proposal: if you get a proposal where the feature scope is fuzzy AND it names a price, you’re probably paying for a big cushion of guesswork.