To be wise or to be right?

Yesterday I was watching a group of kids trying to define an ad-hoc game. They had about 15 minutes of play-time at their disposal.

Most of the kids just wanted to play and make up the minor details as the game went along.


There was one girl who was strong willed and was insisting and defining every possible rule - and she had a strong opinion as to what those rules should be.


Result: They spent the entire 15 minutes defining rules. Not all of them; some of them left earlier in disgust and went to play.


There's a delicate balance between a fully completed  spec and a perfect one.


This is one of those tough calls that a Project Manager has to make. The spec most cover everything. Or must it?


My father tells the story of how the programs in his time - coded on punch-cards (!!!) were able to handle leap years - including the exceptional ones - like the turn of the century. Their systems were Y2K-proof.


After all, they had no idea that the world would progress past punch cards - so the date formula was written for posterity.


At the time it was probably the best decision: the date formula is used all the time and adding an extra condition in the code was not a big deal.


After a spec is written, there is a spec-review meeting - where all those who will be involved in the implementation and testing should be invited; attendance is conditional on having first read the spec.


At those meetings there will be some heated debates about missing features or how to implement seemingly trivial functions.


The key is to listen carefully to what is not being said. Very often one of the vocal (loud or insistent) reviewers of a spec has a hidden agenda: e.g. a pet concept or implementation that they want to use - or learn how to use.


Or a skill set they want to use. Or a fear of the unknown. Sometimes it may be a (self declared) expert who (erroneously) thinks she needs to have original input to everything, otherwise she'll lose her job.


Sometimes it is a simple case of "Perfection is the enemy of Completion".


A trick that I learned for all meetings that get side-tracked or are taking too long: After 30 - 45 seconds simply interrupt the interruption and say "let's take that off-line".


Write it down and make sure to follow up (usually with an email, to as few people as possible) - otherwise they will stop letting you use that line. 


Often the follow-up email will be the end of the story. After all, the proposed concept was only to gain attention during the meeting and not to actually try improve the spec.


Sometimes the ideas being suggested are correct - but will kill the scope of the project. Be realistic about the life expectancy of the project. 


besides, it's often best to ship a feature-free product ASAP and then - if it's a success - to release frequent updates.


It's better to get requests for more features rather then complaints about poorly implemented features.




- Danny Schoemann