From Requirements to Rewards: Managing Life-Cycle Costs in the Development of Complex Products

I have just finished a 10-post series on LinkedIn about "Life Cycle Cost (LCC) management for development of complex products". My first article on LinkedIn about it has compiled the 4 initial posts of this series. Its focus was the definition of high-level requirements (HLR) and the initial steps to be taken for effective LCC management during the development of complex products. 

This article (the 2nd and last one of this series) is about the deployment of HLRs into lower-level requirements, technical and commercial strategies, and further steps in the implementation of LCC management for a competitive product. This is a compilation from Post #5 to Post #10. I recommend that you read Article #1 first.

I have spent a big chunk of my career around this subject, developing and implementing processes, methodologies and models successfully, towards the top goal of delivering products (and related services) with competitive LCC. I hope these knowledge-sharing posts and articles help you achieve greater results in your projects. Thank you for following.

Deployment of Requirements

How to deploy your LCC-related High-level Requirements (HLR) into Lower-level Requirements? I mean, in order to achieve the desired performance, you need to get to system/component level to make sure you have an effective set of requirements.

First step: try to understand ALL the factors that affect the LCC of your product. Some of them are technically manageable, others are commercially manageable, and some of them are beyond your control (Figure 1). You need to slice and dice the LCC and related HLRs.

Figure 1: Deployment of LCC-related Requirements

Organizational Challenges and Competing Priorities

While you are setting High-Level Requirements about LCC, technical and commercial challenges are not all clear yet. However, when you start breaking LCC down for the definition of lower-level requirements, it becomes clearer that you need a truly holistic approach to thrive.

Other teams within the Project Team have their own specific goals and challenges. Depending on company culture, LCC competitiveness might not be among their top priorities. Two examples (Figure 2): Supply Chain Management teams usually focus on solutions that minimize development and production costs; Product Engineering teams tend to focus on alternatives that minimize design process complexity.

It naturally happens in every organization. The problem is: such internal forces must not be left alone, because they create the perfect habitat for blind spots. One of the possible consequences is unpredicted, high LCC when the Product enters into service.

I created the chart in Figure 2 to represent a bit of what I learned in my LCC management experience. Is it clear? You can share your thoughts as comments to this article.

Figure 2: Examples of Multidisciplinary Forces Within the Project Team

Consistency Challenges

Take this advice as a reminder: requirements of different levels must keep harmony among them (Figure 3). Example: the summation of LCCs of a set of systems must not overrun the LCC of the product. The same idea is valid for reliability and availability: the bottom-up composition of requirements must not exceed the top-level requirement.

The trickiest part of the story is that LCC, reliability, and availability (and maintainability and...) are all interlinked and coupled. How to manage them all? In my point of view: in addition to all the requirements management work, you can't flee from quantitative bottom-up modeling.

Figure 3: Harmony between Requirements of Different Levels

Support to Implementation of LCC-related Requirements

OK then. You have a list of LCC-related requirements. Some are high-level, some are not. For many engineers in the team, some of those requirements will sound a bit abstract, or mere formality. How to make sure they will be effective?

Depending on the type of metric (we called it "driver" in Figure 1 above) and type of requirement, there will be different ways to implement LCC management. Please check Figure 4 below.

Figure 4: Solutions for Implementation of LCC-related Requirements

Drivers can be either technically manageable (e.g. reliability metrics), commercially manageable (e.g. spares pricing), or external/not controlled (e.g. CPI/inflation rates).

There can be several types of LCC requirements. Some examples are listed as green arrows in the figure: technical requirements, performance guarantees, commitments, business solutions, and pricing conditions. We also need to monitor external drivers (assumptions), because they tend to affect LCC requirements.

Figure 4's example considers 3 types of solutions to manage LCC requirements: technical req. documents (e.g. a technical contract), main contracts (with suppliers or with customers), and commercial solutions (e.g. lifetime services to customers).

What I've seen in my experience is that LCC management usually converges to contracts. The LCC manager supports contract administration and negotiation, demanding commercial skills alongside technical understanding.

LCC Management Cycle during Product Development

You can see below (Figure 5) that there are Solutions [yellow boxes in the figure] to formalize/address LCC-related Requirements [green].

Figure 5: LCC Management Cycle during Product Development

The design process [gray] is usually changing and unstable:

• System architectures evolve as design details are defined;
• Design challenges arise in multiple functions;
• Commercial relations with suppliers/customers can sparkle the negotiation of technical/commercial requirements;
• Market requirements are dynamic, e.g. we might need to review our requirements when a competitor improves its features.

Therefore, LCC management [blue] must be, at least, as dynamic as product design.

• Economic/Financial modeling is key to prioritize actions, measure KPIs, estimate impacts of design changes, and re-negotiate requirements;
• The LCC standpoint is essential to avoid blind spots in decision-making;
• Business development needs the right assumptions (incl. cost prediction/management) in accordance with the latest design characteristics;
• Project management is needed to manage LCC-driven action items properly.

The LCC management process is constant and cyclical, not restricted to definition of requirements, but persisting until product delivery and beyond.

Verification and Validation of LCC-related Requirements

How can one confirm that all LCC-related requirements will be fulfilled - in the future - by a product that you're about to deliver to your first customer?

It's not a simple task. Actually, it won't end completely until you are thousands (or millions) of operating hours into real-life service. It can take a few years. But you can't just wait passively. 

To make V&V efforts feasible as soon as possible (Figure 6, top), there are at least 3 general tips: (1) The more detailed/specific you get when breaking down requirements, the easier it is to V&V them. (2) Get ready for more analysis & modelling. (3) Develop processes & tools to collect data and monitor in-service performance, so you'll be able to deploy action plans for service level recovery when needed.

Figure 6: Verification & Validation of LCC-related Requirements

Examples of V&V solutions before entry into service (Figure 6, bottom):

• For Reliability: reliability analysis, HALT/HASS, operational tests.
• For Availability requirements: simulation of maintenance procedures and manpower estimation, combined to reliability and maintenance program analyses.
• For Maintenance Cost requirements: modeling of spare parts provisions and maintenance costs, analysis & management of contracts.

Final Considerations

The sound development of a complex product needs to take LCC aspects into account since its early stages. Omission or negligence in relation to LCC are not options. Consequences of poor LCC management are high maintenance costs, pricy spare parts, low reliability, insufficient availability and so on. Lack of competitiveness and bad reputation will be just around the corner. 

Nowadays, most companies and tech startups focus on delivering a MVP (minimum viable product), what is good. However, LCC management is often postponed until just before the in-service phase. According to my experience (and many other colleagues of mine), this is a bad move. You won't be able to control or reduce operating/maintenance costs as much as you'll need to. After a long development effort, your business will be at risk. Start early to achieve the LCC level you need, to make your product successful and to assure long-term profitability.