An Extract from Part 3, "Managing product development projects":
Everyone knows about the “killer features” which propel software products or websites to stardom. Much more common are the unneeded features which destroy schedules and kill development projects. Evslin’s Law #1 is that the time required to complete software is proportional to the square of the number of features. Law #2 is that schedule predictability decreases in proportion to the square of the length of the project. Quite literally, a project with too many features will never be completed.
To get software projects done with a modicum of predictability, make three lists:
* Priority One are those features without which the product couldn’t possibly ship – printing for a word processor is a good example.
* Priority Two are highly desirable features.
* Priority Three are nice-to-haves...
If you are managing version 1.0 of something, it is particularly important to hold the line on features and get the software out to your users fast. Why? Because you don’t know what features are important until you get user feedback. The bell or whistle you thought was so cool that it would be blow users away will end up never getting used. Something nobody ever thought of will turn out to essential and you won’t find that out until real users – not beta testers – have the product. Then you can hustle and get that real must-have into version 1.1 before your competitors know what’s happening.
Remember I said that you should save the Priority Two list for the next version. The purpose of that is mainly to show you how wrong you and your team were about what is important. When you make the priority lists for the next version, Zero and One will be populated by those things your users, tech support, and marketing people discovered AFTER version 1.0 shipped. Stuff that was on the Priority Two list for version 1.0 will end up on the Priority Two list for the next version as well. Priority Three features, of course, will be long forgotten.
Another from An Extract from Part 2, "Done is a Four Letter Word::
There are a bunch of other “dones” in programmer-speak – code-complete, feature-complete, alpha-ready etc. Ignore these. They have no value in telling you, the CEO, when the thing is actually going to reach whatever doneness you are interested in.
Having agreed on a definition of “done”, you then want to ask on every occasion when the project is going to be in that state. There is only one answer to that question: a date. Anything else anybody tells you is just blowing smoke. The date is what you want to know; insist on hearing it at every opportunity. Don’t be lulled by any yardsticks like “halfway there” or “right on schedule”. Just the date, please.
You will be told by the engineers that the project doesn’t lend itself to this methodology, that you will slow things down by creating these artificial waypoints, that they can tell you on a biweekly basis how far along they are without this. This is not something you can afford to give in on. Accept no substitutes for testable milestones.
An Extract from Part 1, "Decompiling Programmer-Speak":
As a CEO or hope-to-be CEO of a technical company, it is essential that you crack the code. Otherwise you will have no hope of knowing when any particular piece of essential development will be done or even what it will do if it is ever finished. Today’s blog is a phrase book of programmer-speak. Soon I’ll blog some secrets on actually managing programming projects.
“It’ll be done ASAP.”
Translation: There is no schedule yet.
“That feature shouldn’t add any time to the schedule.”
Translation: There is no schedule yet.
“It’s fifty percent done.”
Translation: It hasn’t been started yet.
“It’s ninety percent done.”
Translation: The remaining ten percent will take ninety percent of the elapsed time.
Arun Natarajan is the Editor of TSJ Media, which tracks venture capital activity in India and Indian-founded companies worldwide. View sample issues of TSJ Media's Venture Intelligence India newsletters and reports.