I have about 20 years of progressive practical experience in program and project management. And I conducted extensive academic research while writing a book, "Practitioner's Guide to Program Management." As a result, I have extensive knowledge of program and project management that I would like to share. The blog will provide a methodology and tools to execute programs and projects, illustrated with many practical examples. It will cover multiple topics related to program and project management.
Traditionally, software and other products are being delivered utilizing a project delivery approach. Under this approach, the product is being built for a particular customer. Even if it is a standardized product, it is than being rebuild to a degree or entirely (depending on the contract terms) for other customers. This approach allows for full customization of the product. However, it results lower product standardization, increase in waist and duplication of effort. Multiple teams work on resolving similar or the same issues. The product vary from project to project as some rules are a subject for interpretation.
Product delivery approach builds a standardized product that is being customized for each customer. This approach allows for higher efficiency and resources utilization, higher level of standardization, reductions in waist and duplication of efforts. This approach allows for a fully standardized product. Issues are found and fixed once. This approach allows to maximize team effort, improve efficiency and reduce waist. On the down side, some customization may not be possible.
What model do you use in your work? In your experience what are pros and cons of each.
It really depends on the type of the company . For example a company that creates commercial software would most likely be producing new releases of it's software every few months. The software will have features that have been incorporated as a result of feedback/requirements/bugs reported from multiple customers or the company's own regression testing regime. Such a company would most likely be focusing on a Product Delivery Approach.
Unless they are minor configurations or my product allows for customers to do minor tweaks themselves, If I were a product based company , i would like to keep my out-of-the-box product or software exactly the same for each customer.
Off course, I would be testing it's integration with different reporting tools, office products, web services so I can offer a level of customization on top of my base product, thereby creating an additional avenue for $$$ Generation.
If on the other hand, I was a development shop, for example, employing a number of Java or .Net software engineers with the capability of developing web applications, I could build custom products for different customers and thereby use a Project delivery approach. In this case no two products for two different customers may be similar.
This approach enables me to develop the skills of my software engineers and allows me to offer a number of other consultancy skills like Testing, Business Analysis , Project Management , after development support etc to my clients.
I would lean towards the product delivery approach with a wee-bit of customization. We should define boundaries of the product so that we know which customers to include. If it requires too much customization for a new customer, I 'd question if it even falls under that product. You can for sure share common components from a software architecture perspective but it could be a totally different end product.