Jeff initially deals with Steve McConnel's doghouse analogy and the problems encountered when scaling projects (and by implication, developers) from the doghouse to the skyscraper. That is worth a read, even just to revise.
The bit that caught my eye was where he discussed Steve's more recent build-a-fort home project. Jeff counterpoints the copious evidence of underestimated tasks with pointers to agile and iterative development techniques. Not to apear jaded, but the advantages of of short iterative cycles should, to my mind, be obvious these days. I certainly consider it a bit old-hat, since we were doing it in the AVM at Lotus Consulting over a decade ago.
What I found missing, was any discussion around "tooling", and by this I'm not trying to focus on choosing the right framework, but rather the broader scope of all the tools your team will use, no matter how inconsequential.
Having done a similar fort home project for my kids, I believe it is the perfect case study, perhaps because we are unwilling to sacrifice quality and thus highlight the other aspects. I of course have a ready example to illustrate my point. The culprit of some serious delays, a teeny weeny little star screwdriver bit from a kit.
During construction of The Jungle Gym (fort) I used a drill and wood screws for the smaller stuff like floor planking and balustrades. I had opted for a drill bit adapter that could take both the drill and the screwdriver. Initial tests proved successful and I could drill and screw in fast succession, often with one hand. However, once I was in full swing I noticed that this task took far longer than estimated.
Initially I thought it was due to poor quality screws, as the heads would often strip (I was using a speed adjustable drill since screwing them in by hand was just not an option). Unfortunately there were no other makes available and my frustration grew. Eventually my frustration led to me damaging the bit in an attempt to remove a stripped screw.
Since doing this by hand was still not an option, I did a fair bit of searching, and bought a packet of nondescript screwdriver bits and resumed work. The difference was amazing, I was driving in screws faster than I'd originally anticipate and I wasn't stripping any screw heads anymore. This same screwdriver bit is still going strong a good year or so on.
This seems to have been one of those few times when losing my cool has paid off. After all, how was I, as an ardent non-metallurgist, to have a hope in hell of knowing the difference in the bits? In fact the bit from the kit was titanium coated and should have been superior. The hardware store drones were certainly not in a position to help. So I just chalked it up to good old fashioned experience and moved on.
Then I read Jeff's article and it got me thinking. When do you hit that breakdown point that leads to experience, and can it be brought forward or even to light, without a breakdown? Especially in such less obvious cases?
After much mulling and list making, I've come to the conclusion that there's only one factor, awareness. You have to be aware that such situations can arise and must look for them and their possible solutions. Perhaps even plan for them, or at least the exercise to unearth them. The alternative is to blindly continue until you reach the breakdown point, if ever.
As with most issues in project management, there are many shades of Grey. This is is a discussion on efficiencies, which boil down to cost. But at least you can then make informed decisions and substantiate the trade-off early, rather than make excuses late.
Since I like lists, here are some of the more salient points to consider:
- Your tools might not be equally suited to all phases of a project, be they in-house or vendor sourced.
- The more inconsequential a tool seems, the more likely you are to overlook it's impact.
- If you don't look for it, you may never find it.
- As illustrated above, it may not be obvious until you try something different.
- Especially in IT Development, the focus on getting the job done very often blinds our objectivity. Regularly step back and re-evaluate (one of many excellent tips from GTD).
