Project vs. Product delivery approach

From the Practitioner's Guide to Program Management Blog
by
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.

About this Blog

RSS

Recent Posts

Does PM need to be SME?

How to become CEO of your own Program

Standardization of project processes

Project vs. Product delivery approach

Happy Holidays



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.

 

Posted on: January 07, 2019 03:35 PM | Permalink

Comments (8)

Please login or join to subscribe to this item
Simple and good one. Thanks for sharing.
In my area of work we use Project delivery approach

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.

Both. Product delivery approach for department projects and project delivery approach for cross-functional projects.

In the construction industry, we use Project Delivery Approach.

good discussion.....savvy software developers have used abstraction for many years to build flexible products that can be applied in many ways I think OO Inheritance is relevant in this discussion

ps...at this time of year it is best to avoid discussions of 'increase in waist' ....:)

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.

Dear colleagues, thank you for sharing your thoughts, valuable comments and experiences.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"A fanatic is one who can't change his mind and won't change the subject."

- Winston Churchill

ADVERTISEMENT

Sponsors