After the Project-Delivery
Life of the Product
Delivering a project is certainly a big milestone. It is the milestone at which we get paid for the work done.
But it is not the last milestone. Why so?
Because, like anything else in heaven and on earth, the product must have its own life trajectory (S-Curves) regardless of a particular customer.
The product that has just been delivered is nothing but one instance on the curve.
Let’s take for example the ADAS-HIL product.
The product takes on a life on its own. Each customer is a driver for the next version of the product, a better version of the product. This improvement is recorded by the version number. Here, ADAS-HIL version 1.0, then, ADAS-HIL version 1.1, …. This climb is guaranteed by the “Continuous Improvement” process.
Pic. The Continuous Improvement Process as triggered by feedback and technical support requests from the customer.
The point here is that the feedback and technical support requests from the customer is the most valuable information that comes straight from the marketplace. This information must be captured in the “Customer Action Requests (CAR)” database. This database then must be used to create the new version of the product.
Here it should be also mentioned that the CAR database is not only used to capture customer requests, but also used internally to record future improvement ideas that appear during the development of the current version – ideas that will be implemented in the next versions. The CAR database is a practical mechanism to realize the Continuous Improvement idea.
With every new customer the product moves up the curve – a move that gets fixed in the version number.
But the continuous improvement process must not turn into an endless process. At some point, a major transition must happen to the next S-Curve, which is Innovation. This is when a newly available technology gets introduced into the product, or a new design philosophy adopted. Why is this necessary? This is dictated by the concept of competitive strategy, which is the strategy that keeps us always ahead of competition. Imagine that the rival competitor introduces the newly available technology ahead of us. That will throw us right out of the market. The Product Owner must always be aware of this. The newer S-curve is usually marked by a change in the first digit of the version – ADAS – HIL 1.2 becomes ADAS-HIL 2.0, and so on.
And we get the following life story of the product as in the picture below
The moral of the story is that a product does not end with its delivery. The product has its own dynamic that calls for continuous improvement and continuous innovation.
Life of the Development Process
As mentioned above – anything in heaven and on earth has its own life trajectory (S-Curves). In the previous paragraph we talked about the life trajectory of the product. Now we will be talking about the life trajectory of the Development Process. It too can be shown as the sequence of S-Curve.
Warning: Above we are showing S-curves of two different things – one was for the product, the other one is for the process. They must not be confused with each other. They are different things, except for the method of analysis, which here are the S-Curve method.
How do we accomplish this speed? It is through internal technologies that must be developed and packaged in every version of the product. The more the internal packaged technologies, the faster the development of the next version. In the below picture we see how the development of the system moves from high-level of customization (left picture) to a very low level of customization (right picture). Meaning that the time to deliver the last version of the system has been dramatically reduced because of the big number of pre-packaged modular technologies.
Why is this needed? For one, this will reduce the cost of development by 10X at each subsequent version of the system, which translates to bigger Gross Margins. For two, the debugging and supporting of the newer versions will be greatly reduced. For three, the extra people capacity can be directed onto new projects.
For more reading about this, we can refer to two articles written about this in the 3rd Issue of the EC Journal titled “The 3-Layered Architecture” and “Packaging Internal IPs and Technologies”.
The Product Care-Taker
It is the Product Owner who is the “Care-Taker” of this product. This Care-Taking is no less than taking care of the growth of a child – from kindergarten to school to university. Perhaps, Care-Taker is a stronger word than Product Owner.
For the Care Taker to realize this, he must own the project folders. This entails:
Cleaning up the folders.
Freezing the files in the Release Folder stamped by the version and date.
Creating the CAR database and nurturing it.
Packaging the internal technologies in a separate folder with appropriate descriptions, versions, dates, and standard interfaces. These are the packaged IPs that represents the wealth of the company.
The Benefit to the Community
And finally, after delivering the project, articles for the EC Journal must be written. The bigger the project, the more articles must come out of the project team. The articles may contain the stories (the dramas) of the project, the discoveries made during the project, the technologies and science used in the project, the recommendations that came out of the project, …. In short, the articles contain everything that the team wants to transfer to the wider EC community (beyond their own organization). This will complete the stakeholder triangle.

