How to Definitely Prevent a Release From Happening

I often get the idea that most companies don’t really want to release their software products. Maybe they are worried that potential customers out there will find it wanting and will criticize it unduly or worse, never buy it.

I have worked on a projects in my career where it is difficult to conceive of this product reaching the market in my lifetime. What is really scary is that the company and their venture partners still think it is going to be released in the next three months. How can I see a disconnect?

Washing an Elephant With an Eye Dropper

By the sheer number of requirements for the product… over 750 out of a 1000 still to be implemented. (They have been working on this project for over a year.) Granted, this customer can be commended for actually delineating them. Most do not. And for the most part the requirements are well formed and are singular in their feature identification. But the team assembled to develop them is only four developers, not the Army division they would need to tackle this task in the time they are hoping for.

What is wrong here? The requirements list is not being assessed to take into account the shear size of it relative to the resources available. Tough choices are not being made to get the size down to a manageable list based on the resources at hand.

The sad part of this is that the release has slipped over a year. They have missed a year of potential revenue because they could not support their feature list in a timely manner.

A Slipped Release is Profit Lost

Software like everything else, is bound by the rules of “physics.” Only so much can be accomplished based on the team you have assembled. You can’t count on parallel universes to help you. Yes, you can get various levels of effort on behalf of your team. But, you cannot get the effort of fifty developers out of a team of four no matter how much you pressure them to deliver.

You have the tools to stop the release schedule bleed. You have the estimate of the effort required if you have delineated each requirement carefully and can count them. Yes, all requirements are not equal in size but you can at least estimate more accurately how long it will take to implement based on the number of requirements you do have and the team you have assembled to develop them.

You Don’t Make Any Money if You Don’t Have Anything to Sell

Realize that if you do not have the resources to support your present requirements list in the timeframe you need, you are best off trimming the list to where you can release it when you need to. After all, there is no way to make money on a product that never gets finished.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>