Product Cost Reduction and Architecture

With continuous cost pressures on products, companies are constantly looking for ways to cut costs out of their products. If you are in the same situation as many others, you probably are exploring your options in these two main areas:

• Re-design all or parts of the product for lower cost,
• Outsource all or parts of the product to a lower cost manufacturer.

In most cases, re-designing a product from scratch is prohibitively expensive, with questionable return on investment (ROI). Similarly, outsourcing the whole product is risky for your intellectual property, which you have heavily invested in.

When you need to cut costs quickly and with minimum risk, the obvious solution is to find the low-hanging fruits for cost reduction and tackle those areas first. But, how do you partition a product, identify and isolate the target assemblies, and ensure painless re-integration after taking out the costs? This is the main challenge that is derailing many cost-cutting initiatives.

The solution to the problem lies in the architecture of the product. Most products are not architected in the first place to allow partitioning and re-integration. This does not necessarily mean that one should give up. Instead, take the following steps to significantly improve the chances of your cost-reduction activity:

1. Create an architectural representation for the existing product. A good architecture should include, as a minimum, the following four components:
   i) Functional architecture: what does the product and its sub-assemblies do?
   ii) Design architecture: what sub-assemblies and components does the product have?
   iii) A mapping of functions to sub-assemblies: what is the function of each sub-assembly and component?
   iv) Interfaces: Identification of each interface between the sub-assemblies.
2. Identify acceptance criteria for each sub-assembly. How do you know that sub-assembly is doing what it is supposed to do?
   
3. Target one or more sub-assemblies for cost reduction. Control re-design or outsourcing through established acceptance criteria and interfaces.
   
4. Re-integrate lower cost sub-assemblies and enjoy higher profitability.
5. With the baseline you established in steps (1) and (2), repeat steps (3) and (4) as necessary.

Make Your Process Work For You, Not The Other Way Around

One of my colleagues walked into my office today and said "Some people may kick me for saying this but I love the process." This got my attention immediately, because the product development process he was referring to is one of my contributions to the organization. Here is the rest of my conversation with my colleague, whom I will call PMC (Process-Minded Colleague):

FB: [Cautiously] Why do you like it so much?

PMC: [Enthusiastically, as he always is] Because it makes my life easier; it is straightforward and at the right level of detail. Our previous process had too much detail in it and in many cases those details were either irrelevant to the project or needed modifications. But, the team members were usually not too keen on modifying activities in fear of doing something wrong.

FB: Do the team members feel differently now?

PMC: Two of the parts of the process are 1) clear identification of the decision-maker for each major activity, and 2) process tailoring tools provided to the team. It literally takes me two hours at the beginning of each project to tailor out unnecessary activities and related artifacts from my project. The fact that tailoring output is explicitly required in the process makes modification a natural exercise to go through.

FB: Glad to hear this! The purpose of the decision-maker identification and tailoring was to exercise the team to come up with what makes sense in each project. It is meant to be a cover-all process, and by that definition, significant chunks of it may be irrelevant to a smaller project. For example, a derivative product development project does not require all the steps that would have been required in a new product platform development project.

PMC: And, better yet, we still need to run the tailored version of the process with the decision-makers to ensure that we are not missing something in the larger scheme of things. It is a great way to catch out-of-project knowledge while explaining the tailored version to the stakeholders. In the old days, we did not have the forum for such a discussion and typically there would be something that comes and bites us way too late in development.

FB: I guess we should give ourselves a pat on the back and work on making it better.

PMC: Yup, I am on it, see you later!

My moral of the story was that we got three aspects of the process development right:

1) Develop an all-inclusive high-level activity plan in the process flow,

2) Identify the stakeholders and decision-makers,

3) Provide the tools to the project team and require the team to tailor it to suit their needs.

Software Requirements - Four Fundamental Tools

Your product development methodologies may be inspired by waterfall, agile or, most likely, a combination of the two. Whatever your development practices may be, the way requirements are managed plays an important role for the success of your projects. Many organizations and developers consider requirements as written statements. In fact, visual representations of the requirements typically add significant value to the understanding of the product to be developed when little information is known about the required functionalities and features.

Visual representations continue to be useful beyond the confines of one development project and can be helpful in future derivatives by creating a solid baseline for the product.

There are a number of representations to choose from and they all have their value in different situations. Here, we discuss four of them, which are used as the fundamental requirements representations at MDS Sciex (http://www.mdssciex.com/), a division of MDS Analytical Technologies, in the early phases of software product development.

1) Context Diagram: A powerful and simple way to describe the scope of the product to be developed. The diagram clearly shows the context of the product and identifies the interfaces and the interactions of the product with its operational environment.
2) Task Flows: represent the typical and atypical tasks and activities performed by the user who will be using the product. A task flow provides a simple graphical representation of core user requirements for the product by describing how the users perform their everyday tasks, which include the tasks targeted by the product to be developed.
3) Product Navigation Models: show how the product operates. Product Navigation Models are often shown with User Task Flows overlaid, allowing verification of how well they support the Task Flows.
4) High-Level User Interface Design: provides a common, high-level view of what will be built, from the target audience’s perception. This is where we start to introduce more detail compared to the previous three artifacts. Key frames are wire frame drawings of key components of the user interface. A low-fidelity sketch of a user interface component; it includes indication of the type of information shown and main functions available, and shows a potential, general layout. Visual details and secondary functions are either omitted or preliminary.

These artifacts form the foundation of software requirements in an Agile software development environment at MDS Sciex.