There are many different types of software development. And these different types all require different methods of working and managing. They all of course involve developing a piece of software, but the nature of the projects are very different. Joel Spolsky lists five different worlds in one of his his excellent articles, and as he says: "different rules apply to different worlds". At Digimaker we are involved in at least three of these, namely internal software, consultingware, and shrinkwrap.
Our company has different departments, and they all live in different worlds. In one end we have our Telecom consultants. These are developing internal software and some commercial web based software for their customers. Our Professional Partner Services department are doing consultingware using the Digimaker CMS. And we have the Digimaker product R&D team. This part of the company is now in the process of moving from one world into another.
Websites
Until recently Digimaker has been delivering only consultingware. The Digimaker CMS product itself is not really what has been sold, but rather custom website implementations featuring a good CMS backend. The SiteBuilder has only been used by our own in-house deployment developers. Luckily, this has worked out quite well for us, and we got a good name in the market and some rather large customers all over the world.
In managing a consultingware project, you have a defined functional spec (SRS) that you work against. You have a defined cost that you need to keep within or you will lose money. You have a given time for when you are going to deliver, or you will lose money. All of this -- scope, cost, time -- is out of your control once the contract is signed by the customer. You are left to control resources and quality -- and to some very small extent, the scope, by creative fine-reading of the contracts. The product development team has been building the product in response to new features that these deployment projects needed.
The manager's job in this situation is to constrain all of these factors to fit inside the boundaries. He needs to track progress notoriously so he can provide delivery dates and see whether the project is slipping. So he needs to have a detailed plan of all tasks involved with accurate estimates. He needs to demand overtime, and motivate with bonuses and anything he can come up with to make the developers deliver on time and within budget. The deployment developers don't get much feeling of ownership of their code since they'll probably not see much of it again once it's delivered. The solution doesn't have to be particularly generalized or reusable because you just need it to work for this one customer, and you have limited time to use on those aspects. The quality aspect often comes second under these conditions, but that's fine as long as the product works well and delivers according to spec.
Another world
This consultingware work is now done by our partners and our Professional Partner Services department, and not R&D. We are now shifting our main focus onto selling Digmaker CMS as an off-the-shelf shrinkwrap product. We are moving from one world to another, where volumes are the way to go and custom implementations are a no-no. This of course requires a change in methods and in management.
When developing shrinkwrap a whole other way of working is called for. There are a different set of requirements and higher expectations from such a product than a custom solution. Our customers are now developers and not users. The product needs to "just work" in all of our partners' environments, so the quality aspect is not just important, but crucial, and the manager needs to put this in the highest priority. In this world we don't have to work within the constraints of a contract. We control all the aspects -- the quality by how we design, test and bugfix, the scope by what features we decide to include, our time of release, and our resources. We just need to find the optimal balance so we can deliver valuable features with high quality at a good speed to a reasonable cost. Otherwise we just won't be profitable.
The manager needs to understand this world and act accordingly. Creating a strong product is a creative process so we need room to think, research and experiment. There is less need for a long-running project plan since we are only planning toward our next release, and we have the choice to reprioritize, or to cut or delay features that we don't get time for, or that prove to be tougher to solve than expected. We need to listen carefully to the sum of our customers so we can hammer out the dents, and prioritize features that are widely asked for or that reduce barriers and open our product to new markets.