Product Development: Lifecycle Macro-Phases

Understanding both functional and physical hierarchies is important when developing new products. It is not in our human nature to stop and think about these details because they are not necessarily in the critical path of getting to a prototype, and we tend to start designing right away. So, the question is: how do we counter the human nature of taking the path of least resistance and seeking the instant gratification of getting to a prototype? You have to counter it with tools, procedures, and processes in your design methodology. We counter that with tools and methodologies and putting those in place. These methodologies enhance product competitiveness, and if you have a rigorous way of identifying customer needs and distilling system requirements from that, then you have a way of truly meeting those needs. And that is one of the best things that you can do when solving a problem: to actually meet the needs in a very specific way without over designing. You can always overdesign and you have a larger chance of meeting the needs but you also may be putting things in there that are not necessary, so that it increases the cost, and it reduces your competitiveness; not just at certain points in time, but also throughout the lifecycle of the product. Being intentional in strictly meeting the needs of products and client goes a long way to minimize issues later down the road, and we can achieve this by understanding all the system requirements and applying systems engineering techniques. Through those, you are going to be developing functional and physical hierarchies, and you will be able to consider all parts of the systems in a holistic way so you can breakdown the system into subsystems all the way to components, and consider all the different parts in a very systematic way: inputs, outputs, processes, and what are the interoperability requirements at the interfaces. You will be able to recognize how does the team need to look without having resources that are superfluous in the context of the development; and you also will have a disciplined approach to reviewing designs, evaluating designs, and also building feedback into the process of developing products. This ensures the largest likelihood of success. There are no 100% guarantees, but this gives you the best the best chance for success. There are a lot of projects that do not see the light of day, there are a lot of failed projects you do not hear about. The ones that you hear about are a very small minority actually, so there is a lot of room for improvement, and that is a good thing because I would say there is almost no way to go but up if you follow these techniques. So, let us take at first a very simplified view of this life cycle. We want to start by breaking it into two parts. The first one, we want to call it the acquisition phase and that refers to all the work that must be done to have your system at a point that is ready to be deployed or put into operation. That is the second phase, and we call that the utilization phase. The first one we call acquisition because maybe as part of your development, as you go through the process, the best way of developing the system is to acquire it. Maybe you do not develop it, and we will talk about those tradeoffs. In the acquisition phase, you start with the need and you are going to go through three big steps: conceptual design focusing on the beginning of the process putting all the disciplines in place but with that view of the life cycle, with a very holistic view ahead. Then we have the detailed design and development. That is when the actual design happens. Then we have production or construction. There are massive construction projects that are also complex systems and when you put it in the utilization phase you need to worry about support and phase out, and sometimes disposal.