Life Cycle Model - Revision history

Tkokotas at 09:26, 17 May 2019

2019-05-17T09:26:21Z

← Older revision		Revision as of 09:26, 17 May 2019
Line 1:		Line 1:
			''*Disclaimer: The articles are created by DTU students. As part of the course, students are introduced to knowledge related to IP rights, plagiarism and copyright infringement. Additionally, the articles are a product of critical engagement of students with the literature review, and their aim is to contribute to the Project Management holistic field of science. If you discover any potential copyright infringement on the site, please inform thereof by sending an email to ophavsret@dtu.dk.''

	''Developed by Philippe Maurice Stotz''		''Developed by Philippe Maurice Stotz''

Tkokotas at 12:09, 20 December 2018

2018-12-20T12:09:42Z

← Older revision		Revision as of 12:09, 20 December 2018
Line 1:		Line 1:
			''Developed by Philippe Maurice Stotz''


	The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study\|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model\|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.		The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study\|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model\|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

Tkokotas at 14:00, 9 November 2018

2018-11-09T14:00:38Z

← Older revision		Revision as of 14:00, 9 November 2018
Line 77:		Line 77:

	<references/>		<references/>

			[[Category:Project Management]][[Category:Life cycle‏]]

Student: /* Life Cycle Model Approaches and Reflection */

2014-12-01T11:29:45Z

Life Cycle Model Approaches and Reflection

← Older revision		Revision as of 11:29, 1 December 2014
Line 58:		Line 58:
	*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.		*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
	*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools in this context.		*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools in this context.
	However, the approaches do require refinement by the user in order to achieve the best possible result in relation to ~~their~~ use-context. As focus areas vary in every Engineering System, so does the Life Cycle Model and its approaches demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:		However, the approaches do require refinement by the user in order to achieve the best possible result in relation to the use-context. As focus areas vary in every Engineering System, so does the Life Cycle Model and its approaches demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
	::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.		::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

Student: /* Life Cycle Model Approaches and Reflection */

2014-12-01T11:29:25Z

Life Cycle Model Approaches and Reflection

← Older revision		Revision as of 11:29, 1 December 2014
Line 55:		Line 55:
	The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:		The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
	*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.		*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
	*The '''incremental and ~~Iterative~~ development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach ~~would~~ be ~~for example if the~~ project requirements ~~are unclear at~~ the ~~beginning~~ or if integration of emerging technologies during the development of the system should be possible.		*The '''incremental and iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach could be unclear project requirements during the development phase or if integration of emerging technologies during the development of the system should be possible.
	*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.		*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
	*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools in this context.		*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools in this context.
	However, ~~depending on the use-context~~ the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every Engineering System, so does the Life Cycle Model and its approaches demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:		However, the approaches do require refinement by the user in order to achieve the best possible result in relation to their use-context. As focus areas vary in every Engineering System, so does the Life Cycle Model and its approaches demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
	::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.		::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

Student: /* Case Example Disposal Phase */

2014-12-01T11:24:59Z

Case Example Disposal Phase

← Older revision		Revision as of 11:24, 1 December 2014
Line 47:		Line 47:

	====Case Example Disposal Phase====		====Case Example Disposal Phase====
	Company A continues to ~~receives~~ poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.		Company A continues to receive poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as an activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

	==Activity Cycles within Individual Life Cycle Phases==		==Activity Cycles within Individual Life Cycle Phases==

Student: /* Case Example Utilisation Phase */

2014-12-01T11:24:29Z

Case Example Utilisation Phase

← Older revision		Revision as of 11:24, 1 December 2014
Line 41:		Line 41:

	====Case Example Utilisation Phase====		====Case Example Utilisation Phase====
	Company A has implemented the redesigned product ~~within the system~~. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.		Company A has implemented the redesigned product. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

	=== Disposal Phase ===		=== Disposal Phase ===

Student: /* Case Example Realisation Phase */

2014-12-01T11:23:51Z

Case Example Realisation Phase

← Older revision		Revision as of 11:23, 1 December 2014
Line 35:		Line 35:

	====Case Example Realisation Phase====		====Case Example Realisation Phase====
	Company A has developed a concrete concept to deal with its unsatisfied ~~customer~~ and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.		Company A has developed a concrete concept to deal with its unsatisfied customers and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

	=== Utilisation Phase ===		=== Utilisation Phase ===

Student: /* Development Phase */

2014-12-01T11:23:06Z

Development Phase

← Older revision		Revision as of 11:23, 1 December 2014
Line 23:		Line 23:
	The development phase consists of four steps:		The development phase consists of four steps:
	*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.		*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
	*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis\|Situation Analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.		*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis\|Situation Analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy\|Risk Management Strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
	*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.		*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
	*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.		*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
	==== Case Example Development Phase ====		==== Case Example Development Phase ====
	The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company ~~asses~~ the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).		The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company assesses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
	The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.		The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

Student: /* The Life Cycle Phases */

2014-12-01T11:21:33Z

The Life Cycle Phases

← Older revision		Revision as of 11:21, 1 December 2014
Line 10:		Line 10:
	== The Life Cycle Phases ==		== The Life Cycle Phases ==
	[[File:Life Cycle Phases.jpg\|400px\|thumb\|alt=Puzzle globe\|Figure 1: Life cycle phases and decision gates]]		[[File:Life Cycle Phases.jpg\|400px\|thumb\|alt=Puzzle globe\|Figure 1: Life cycle phases and decision gates]]
	Most of the literature divides the life cycle of an ~~engineering system~~ in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:		Most of the literature divides the life cycle of an Engineering System in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

	::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>		::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>
Line 16:		Line 16:
	The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.		The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

	A common feature of any structure in the Life Cycle Model are the decisions gates~~, which~~ mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>		A common feature of any structure in the Life Cycle Model are the decisions gates that mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1). Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

	=== Development Phase ===		=== Development Phase ===
Line 23:		Line 23:
	The development phase consists of four steps:		The development phase consists of four steps:
	*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.		*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
	*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.		*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis\|Situation Analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
	*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.		*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
	*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.		*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.