For the last 10 years or so, I’ve been working in the software business. I’ve worked in almost every way from freelancer to R&D Director, and in the process I’ve had the opportunity to work at some quite good companies.

Some of these companies did exceptionally well during the time I worked for them, and some had real problems. Profitability was an issue almost always. In a competitive environment, the pressure comes from both directions; competitor companies bidding for lower prices, and talented developers rising costs, or worse, incapable developers rising costs.

Given all the pressure, I’d choose a product company over a project company any given day, unless some very rare conditions exist. The product company does not have to deal with some of the really nasty problems that the project company always faces.

The project company will usually have wrong specifications, incomplete specifications, learning curves of many sorts, deadlines, shocks, earthquakes and terrorist attacks etc.. I’m sure you get the idea. I project based approach to solving a particular problem is usually hell on earth, due to some difficulties that arise from the very nature of software development. First of all, customers have that genuine feeling that something is being built for them exclusively, and they do not hesitate to demand for more, claiming that it should have been implemented anyway. Too bad it was missed during the initial analysis, but this has to be done!

Needless to say, keeping costs and development under control is a very tough job, and staying profitable in this kind of environment is very hard. Now, there are some cases in which you can stay profitable, and these cases seem to be specific to particular industries. Defense for example, is an industry with very expensive contracts,  and relatively stable requirements management. Even though delays and problems are quite common in defense contracts, the way that these projects are handled seems to cover unexpected issues and costs most of the time.

I guess two important variables for deciding whether or not to go for a project based approach are, the competition in the domain and maturity of software solutions in the domain.  Where you have a fierce competition with many competitors claiming that they can do what you’d do for half the price and half the time, you are in trouble. This has been the state of business application development for quite some time now. On top of that, when you have a set of customers who can not realize that their continuous demand for changes and additions is bringing down the project you are really going to have a hard time staying profitable.

Product based companies on the other hand, give the very important image of “product”. Something that is completed, built and ready to be used for a particular task. If it does not cover what you want, you can wait for the next version. The company won’t say we’d change it for you right now, and more important than that, you do not expect them to! This gives a huge advantage to product based company, and when you get large enough, you are free from the many troubles of project based approach.

In short, focusing on creating a product is a good idea, if you have various pressures due to nature of the domain you are working in. All the project companies I’ve seen have this life cycle, where they first get a lot of projects, and seem to be doing great. Then their rise ends, and their fall begins, as increasing costs, and delays in projects start consuming all the profit, bringing losses.

I guess this is a field where there is much that can be said, and one last comment that I should add is; it is not easy to create a product company from a project company, but this seems to be the holy grail for many companies out there. I’ll hopefully write about why this is harder than it seems.