The Devil is in the Details

Here’s something not that shocking: the same amount of time spent on different Web development activities can yield vastly different productive results.

Put another way: you can spend two hours on Activity A or the same amount of time on Activity B. Does this mean they will both contribute equally to getting your project done? Nope.

Example: in three hours you could:

• Define the complete content model for your Web site, build the data model, define the content objects, and either configure a CMS like eZ publish or stub out an admin section in a framework like Rails.

• Fix one infuriating CSS bug.

Again, this isn’t rocket science, but it is very important for people who get paid to develop.

The first example is something that would fit into “Principle Construction.” This is the stage in the project where you’re fundamentally building the site. This is a fun stage because you progress rapidly. You spend two hours on something, and you have a lot to show for it. You feel great – things are moving along.

The second example can come during “Spit and Polish.” This is after Principle Construction is done – the web site is more or less feature complete, and you’re just fixing stuff and tidying up (another firm I’ve worked with calls this “Dust and Clean,” or “D & C”).

Spit and Polish can be frustrating, because the pace slows. You can spend the same block of time on something as you did during Principle Construction, but have comparatively little to show for it.

Joe and I were working on a project once, and things started out great – right out of the gate, we were streaming along the requirements list. We were solidly in Principle Construction, but back then we didn’t have a name for it.

A week later, the project didn’t seem that fun. The work was…ickier and much less satisfying. I mentioned this to Joe: “Why was this project so much more fun last week?”

His response was so true: “Well, I guess all the easy problems have been solved.” That is to say, we were smack-dab in Spit and Polish where you spend a lot of hours for little results. It’s not nearly as satisfying.

So, what’s the point of all this? It comes down to bidding web projects. We have always had a tendency to bid Principle Construction only. You look at a project, and you think, “Well, it will take X hours to implement the content model, X hours to set up the users, X hours to do this and that.” Then you just add up the X’s to get a total.

In this stage, you don’t bother to bid things like “Fix a little CSS bug” because that seems so small in comparison to “Implement the data model” and because you can’t foresee a specific CSS bug that you’re going to have to fix. But how many of us have killed ourselves for two straight hours trying to figure out why a pixel won’t like up in Internet Explorer? Yeah, I thought so.

What this means is that you have to explicitly account for this stuff in your bid. You have to add a phase to your proposals called “System Testing” or something which is where you’re going to do all the Spit and Polish, all the Dust and Clean, all the things that you can’t bid separately because you just don’t know about them yet.

The fact is, you’re going to do these things – you have to, in order to deliver a project. The only question becomes, are you going to get paid for it?

But should you get paid? I mean, if you were good, these things wouldn’t happen, right?

Not a chance. No matter how much experience we have, stuff just happens. Bugs pop up, things change slightly, original plans have to deviate. Things will have to be done at the tail end of a project that you could never have individually speculated in the beginning.

So, bottom line, when you bid a web project, don’t just bid Principle Construction. Know that the unplanned but crucial details will crop up, and you are going to need some budget to pay for them.

On the one hand, this feels sneaky, doesn’t it? We’ve all heard the proverb, “Estimate the number of hours the project will take…then double it.” I’m not saying you should double all your estimates, but you should have a buffer there.

If you don’t, the client ends up losing out. The budget runs out long before the project is done. You’re not getting paid anymore, so details go unfixed, stuff gets pushed back, and – most importantly – your enthusiasm for the project nose dives. Not only are you working for free, but you subconsciously feel stupid because tail-end bugs have once again cropped up that you didn’t account for. Didn’t this happen last time? When will you learn? It’s a morale killer.

Bugs are going to happen. In all but the most controlled situations, little bugs are going to come up that you have to fix, and that could never have estimated. I don’t care how good you are – this stuff will happen.

The only question becomes: how prepared is your project for it?