A new acquisition brew: systems engineering and lean six sigma make a great mix.
* Implement problem-solving techniques;
* Assess key processes;
* Employ a variety of analysis, control, and performance tracking tools;
* Draw on their functional competencies even though their educational pedigrees are noticeably different; and
* Leverage experience.
Today, it is fundamentally important that the defense acquisition workforce capitalize on their combined intellectual muscle. Directives and guidance governing their individual actions are not enough to obtain the performance outcomes the
Department of Defense (DoD) needs. Acting together, these two distinctive groups more than others can close the development, production, and operational support gaps we occasionally see in our defense acquisition business. After all, they know how to:
* Carefully assess requirements and decompose them into optimal solutions;
* Craft comprehensive blueprints and reduce unnecessary design implications;
* Creatively integrate new systems with legacy ones;
* Build manufacturing techniques that safely and efficiently guide production;
* Optimally support products under fire;
* Unify interdisciplinary teams; and
* Influence performance outcomes.
They also ask questions all the time and, not surprisingly, they are frequently asked what went wrong and/or what is needed to fix a deficiency in the event of a performance failure.
Not unlike other key functional areas, both SE and LSS seek to implement only necessary actions that favorably drive the development, production, and support of a quality product or essential service. Naturally, there could always be more synergy between any two groups, especially ones like SE and LSS that exert such a major influence on performance outcomes. So, the time is now to go way beyond simple collaboration. They need to officially join forces. The Defense Acquisition Workforce would be well-served if these two camps jointly led the charge against escalating costs and performance failures that in today's procurement environment, appear to surface ever more frequently along the acquisition continuum inside DoD's weapon system developments or during their modification and adaptation.
Problem solving is a good launching point to start understanding one of the common bonds both camps already share. Do they approach problems much differently? Actually, SE and LSS start their respective journeys by implementing very similar practices. SE itself is actually a "problem-solving process that drives the balanced development of system products and processes" (Defense Acquisition University, 2001, p. 10). Systems Engineering also kicks off problem solving with the identification of a problem and/or deficiency. After further investigation, a problem or deficiency gets translated into a definitive requirement of some kind, eventually resulting in a solution that traces back to the problem/deficiency. The hallmark of SE has been its ability to justify everything built in terms of the original requirements. To SE, this well-known construct looked something like Figure 1 in the early 1990s when it was codified in draft Military Standard (MIL-STD) 499B. In its basic form, it continues to survive as evidenced by its 2005 MIL-STD 499C descendant.
[FIGURE 1 OMITTED]
Systems Engineering clinches to a problem-solving process that is deeply rooted in subjective and objective scrutiny. Classical SEs: a) perform a requirements analysis by assessing the deficiency; b) logically, efficiently and iteratively decompose the requirements into design functions; c) synthesize the overall design; and d) conduct relevant trades within the overall design envelope, then build it, test it, and field it--analyzing and controlling the design along the way. This early methodology was eventually adopted by the International Council on Systems Engineering (INCOSE) in the 1990s. The U.S. industry eventually adopted a variant in the form of the Institute of Electrical and Electronics Engineers (IEEE) 1220 version as the standard for the application and management of systems engineering.
In DoD, SEs are trained to help transform a concept into reality through Technical Processes and Technical Management Processes. These processes become essential since new technology and the integration of new technology frequently find their way into either already very complex systems or new ones just getting underway. These processes serve as barometers and gate checks while products evolve from concept to deployment to ensure technology readiness levels (TRLs), manufacturing readiness levels (MRLs), and system readiness levels (SRLs) are hitting their mark. In actual practice, Technical Processes are used to design and realize system products while Technical Management Processes are used to manage the technical development of the system along the way (Table 1).
The LSS business management strategy does not necessarily include system design, but it does use a variety of complementary problem-solving processes to influence or change designs that would improve speed, quality, and cost. This element of Six Sigma is called Define-Measure-Analyze-Improve-Control (DMAIC) and takes aim at improving and balancing processes.
* Define means to "have the team and its sponsor reach agreement on the scope, goals, and financial and performance targets for the project" (George, Price, & Maxey, 2005, p. 4).
* Measure means to "determine inputs and outputs" (p. 8).
* Analyze means to "pinpoint and verify causes affecting the key input and output variations" (p. 12).
* Improve means to "learn from pilots of the selected solution(s) and execute full scale implementation" (p. 14).
* Control means "to complete project work and hand off improved process to process owner with procedures for maintaining gains" (p. 17).
By inspection, both SE and LSS employ many similar key systems processes in the development and assessment of systems. They also share several other fundamental attributes as indicated by the Venn diagram in Figure 2.
[FIGURE 2 OMITTED]
LSS uses a number of handy problem-solving mixtures like value stream mapping and process flow diagrams to ensure that only necessary processes take place (George et al., 2005). These tools are also known as system thinking diagrams--a method of visualizing system behavior through a series of feedback links and loops.
They illuminate inefficient processes and reduce variations and defects in fundamental processes. System thinking also forces an understanding of the relationships and interactions among its parts (Powell, 2002). And, LSS goes beyond Six Sigma since the best solution would be to eliminate inefficient ones (Olsen, 2008).
So, the LSS problem-solving process does look a lot like the problem-solving process used by SE. The DMAIC model appears to inject a little more creativity and scrutiny into the problem-solving equation, however. Better said, both camps do indeed have a very similar solution-oriented process. They both take a broad view of customer needs/users and extend it to people inside and outside the company.
They both temper the inputs that drive their respective processes and ultimately build solutions (or build better ones) in the form of outputs that satisfy a user's needs. They both have built-in controls, improvement mechanisms, and feedback loops that guide and attenuate their decisions, selections, and solutions. Granted, the labels might be a little different; the characterization and language may even be a little different, but the intent is still the same. Both camps would probably agree that this generalized iterative form of thinking is intuitive and has been ingrained in their training. For SE, it has served their community rather well. After all, in one form or another, it ultimately helped them place a man on the moon on July 20, 1969. In retrospect, LSS might even argue that SE possessed many of the key LSS components back then, particularly in areas like innovative thinking and ground-breaking improvements-especially in safety, which became a necessity after the Apollol fire in 1967. Since safety and efficiency became a necessity with space flight, then many LSS elements were already invoked to a large extent from the outset.
Today, LSS strategists go a little beyond the standard way SE solves problems, displaying a tendency to look more closely at the efficiency quotient with a greater focus on the trade space. They even build in a few more triggers that focus on quality. They also try to avoid the decisions that most groups make--rushing to design decisions (e.g., convergent thinking), which can lead to lower quality outcomes (Lamb & Rhoades, 2008, p. 5). Historically, quality has been the Six Sigma community's original focus since poor quality has a ripple effect downstream--especially negative performance outcomes. Sometimes, its effect is catastrophic. LSS identifies and attempts to eliminate sources of waste and activities that do not add value to create maximum productivity, capacity, and throughput. Even though SE tries to make quality an integral element in all of engineering, the root cause of a few performance failings can generally be traced back to limited trade analyses, poor design, product pedigree, or even insufficient testing. In those instances, was there perhaps less attention on good systems engineering practices that caused any failings to surface? In many cases, failings can be traced back to lack of a disciplined problem-solving methodology, a reduced focus in a process, or a failure in following a prescribed process (or following a dysfunctional one). In all cases, both groups would probably agree that when organizations start rationing their processes, problems can quickly mount.
So where does process play in problem solving between both camps, and does process have a quality all of its own? It does indeed--and here is why: It bounds problem solving by invoking the necessary terms, conditions, assumptions, and anything else associated with the execution of a disciplined and comprehensive problemsolving methodology. In fact, process is inextricably linked to just about everything that SE and LSS do--reinforcing the underlying common process bond they both share. Oddly enough, process is not the enemy of innovation that some might think. Instead, it is the foundation for innovation since it more critically describes what should stay and what could go.
What do we mean by process anyway? Actually, process is one of the most instinctive practices known to mankind--one of those critical necessities important to any action let alone any profession. In fact, we would be hard-pressed to find an activity that does not depend on some type of process of some kind whether it is comprehensive or not. Processes can be evolutionary in many ways, and even revolutionary in others. Processes are everywhere and in some cases they are internalized as a procedure, method, course of action, routine, means, training, practice, etc. Whatever the name, they are pervasive and the examples that follow help emphasize the importance of their structure, execution, and intended results in the face of changing conditions--especially environmental and human factors. For instance:
* Can a quarterback help drive the offense down the field without a process, especially in the face of a defense that has learned to read all the options and stop any forward momentum? The quarterback might be forced to call an audible at the last minute if he sees a blitz coming on. Is there a process involved? Yes.
* Can a race car driver ultimately get by the checkered flag first without the synchronization and responsiveness of the pit crew in the face of some pretty formidable mechanical odds that accompany car speeds exceeding 200 miles per hour? What if the pit crew sees something the driver can not and needs to quickly advise the driver that immediate action is required without complicating matters? Is there a process involved? Yes.
* Can a military commander successfully execute and win a military campaign without a highly equipped, trained, and tested battalion in the face of a tireless enemy that is determined to seek the same outcome? Military personnel train day and night. But, something as simple as improvised explosive devices and suicide bombers, now household words, have changed the dimension of warfare; these simple yet deadly devices have also forced the military to re-think force protection. Is there an overall process involved in assessing and responding to this dynamic form of warfare? Yes.
* Can a program manager overcome the consistent programmatic turbulence and successfully meet the warfighter's needs without the full complement and synchronization of functional experts working diligently to mitigate all known development risks, test the design through various methods as it evolves from concept to production, and safely deliver the product? Yes. However, trouble can easily derail progress in no time flat without a known and disciplined process.
In any of these examples, clearly the lack of certain processes can have very unfavorable results, which makes process particularly consequential in many cases. Take International Launch Services and their Proton M Satellite launcher that left their AMC-14 spacecraft stranded in the wrong orbit leaving it useless (Taverna, 2008, p. 31). A ruptured exhaust gas conduit caused a turbo pump on the upper stage to shut down prematurely. Eventually, they traced the problem to the conduit walls that were thinner than specified. A root cause analysis found the forming process of the conduit "thinned" when it was bent. No one caught it. No one thought to measure it. Apparently, their design process did not call for more intensive testing on such a critical component. Regrettably, there are many more well-known engineering process breakdowns etched in history with more tragic human consequences, including the Titanic, the Tacoma Narrows Bridge, Chernobyl, 3-Mile Island, Bhopal India chemical plant, the Concorde, Space Shuttles Challenger and Columbia, TWA Flight 800, etc. What could have helped prevent these failures? Possibly a more holistic approach to certain processes that are today better understood by the SE and LSS communities.
So, what do SE and LSS practitioners say about process today? Inarguably, both camps embrace many key processes and have begun to emphasize even further the "evaluation" part of the equation when it comes to thoroughness in meeting the requirements, and the value to their customers when it comes to importance and usefulness.
ANALYSIS, CONTROL, AND PERFORMANCE TRACKING TOOLS
What about the analytics? Both camps employ a number of useful and critical thinking tools that are either deterministic, probabilistic, or a combination of both. Each is designed to ultimately help influence decisions--whether it be a design, production, test, operations, or support decision. From trade studies to risk assessments, these helpful decision aids can provide significant contributions to the decisionmaking process because they are designed to avert premature solutions and combat developmental, production, and operational risk. The following represent just a few of the examples available:
Used to determine the optimal course of action or solution that satisfies a known requirement; compares alternatives against multiple criteria (either weighted or unweighted). Example: What [fictitious] vendor offers the best deal on tires if we need a new set (Table 2)? Based on weighted criteria such as price, installation, warranty, and future rotation and alignment labor, it looks as if Tire Land offers the best deal.
RISK ASSESSMENT MATRIX
A risk assessment matrix is used to weigh the likelihood of a risk materializing against the consequence if it actually does. Example: Consider an automobile tire with significant wear pattern where the steel belts are starting to show through the rubber treads. Riding on an unsafe tire at any speed might endanger the occupants. Riding on an unsafe tire under excessive speeds could have devastating results for its occupants. Is it a risk that the driver and occupants are willing to take with the odds of a fatality so likely and the consequences so severe (denoted by the circled cell "A" in Figure 3)? Probably not.
[FIGURE 3 OMITTED]
The Five Whys are used to narrow a decision pathway through the use of sequenced and logical questioning. Example: Why do we need to buy a new car? Because our old car is too costly to maintain any more. Why is our car too costly to maintain? Because the major parts that need to be replaced are becoming obsolete. Why are the parts becoming obsolete? For safety reasons, the manufacturer has discontinued the production line and the second-tier spare parts vendors have vanished. Why is this car unsafe? Because this car has a significantly higher serious injury rate whenever it is involved in accidents compared to other vehicles in the same class. Why does it have such a high injury rate? Because when the car is hit from behind, the gas tank tends to explode like a Molotov cocktail--seriously injuring the occupants inside!
OTHER COMMON TOOLS
Modeling and Simulation. Used to imitate or mimic specific aspects of a particular system in a synthetic environment to safely and cost-effectively gain insight into the operational and/or behavioral characteristics of its individual and/or collective components.
Technical Performance Measures (TPMs). Used to compare actual versus planned technical progress throughout system development. Reports the degree to which system requirements are met in terms of performance, cost, schedule, and progress in implementing risk handling; traceable to user-defined capabilities.
Force field analysis. Used to support requirements analysis by describing the forces that either promote or oppose a decision of action.
Sensitivity analysis. Used to determine the robustness of an optimal solution when subjected to different sets of parameters.
Multivariable analysis. Used to determine the effects of all variables on an outcome and to help identify design drivers and uncover correlations.
Cause and effect diagram (also known as a fishbone diagram). Used to show causes of certain events that contribute to overall effects; starts with a problem, then identifies possible causes depicted by branches (or bones) of a fish.
Value stream mapping. Used to analyze the flow of material and information used to support product or service development while discovering areas of lead time improvement.
PEDIGREE AND CORE COMPETENCIES
SE and LSS strategists tend to be deep system thinkers and have been known to behave like collaborative campaigners--actively seeking participation from their teams (Lamb & Rhoades, 2008). But, what about their education and training? Not surprisingly, both SE and LSS practitioners have certain educational pedigrees and expected technical competencies, but SE is more established at many colleges and universities. As of 2006, INCOSE (2008) reported there were about 75 institutions in the United States that offered 130 undergraduate and graduate programs in systems engineering. INCOSE also recently "established a multi-level Professional Certification Program to provide a formal method for recognizing the knowledge and experience of systems engineers, regardless of where they may be in their career" (Figure 4). (Kepchar, 2006)
[FIGURE 4 OMITTED]
For LSS, no colleges or universities to date offer exclusive undergraduate or graduate degrees in LSS nor is there a certification body for LSS. However, many colleges, universities, and training institutions offer LSS certificates; and they all follow an acknowledged practitioner stratification such as White Belts, Yellow Belts, Green Belts, Black Belts, and Master Black Belts (George, 2004, pp. 48-49). Attainment of each belt requires a minimum level of training and experience.
Most industries as well as the DoD recognize the potential LSS dividends and welcome any functional expert with the motivation to seek the training and apply the methodology. At first glance, the business world might appear to be where LSS could make the most visible contributions to efficiencies and savings. And, according to the Six Sigma Academy, Black Belts (where they exist) can save companies approximately $230,000 per project. "General Electric, one of the most successful companies implementing Six Sigma, has estimated benefits on the order of $10 billion during the first 5 years of [their] implementation." (iSixSigma, 2008)
Industry is not alone in their quest to promote efficiencies and achieve savings though. In 2007, the U.S. Army completed about 770 Lean Six Sigma projects with an estimated savings of $1.2 billion (Robinson, 2008, p. 2). Given the potential for even greater savings to DoD, Deputy Defense Secretary Gordon England intends to have 5 percent of the department's employees trained as Green Belts, and 1 percent of its workforce trained as Black Belts (Robinson, 2008). To satisfy this kind of nationwide interest and potential demand, many undergraduate and graduate engineering programs have already started to blend LSS into their SE curriculum.
Early on and as a result of their education and training, SE and LSS are expected to have the requisite knowledge, expertise, and leadership to unite all the disciplines required during the evolution of a system's design or uncover the cause(s) for its shortcomings in order to prevent performance limitations or failures in operations. Three core competencies central to Systems Engineering are embodied in the following business processes: 1) Systems Thinking (e.g., the underpinning system concepts and system skills required by the business and technological environment); 2) Holistic Life Cycle View (e.g., all the skills associated with a system's life cycle from requirements identification through disposal; and 3) Systems Engineering Management (e.g,. all the skills associated with a managing/affecting a system's life cycle, including the planning, monitoring, and control that are integral to the systems engineering process) (Cowper, et al., 2005, p. 7). In industry, LSS competencies are not as consistently codified across the community but in general include the essential soft skills (e.g., leadership, strategic planning, communication, change management, organizational development, and relationship building) and many of the same systems engineering technical competencies. Within DoD, LSS competencies can be found within their aggregate Continuous Process Improvement (CPI) strategy. The top-level categories are very similar to the ones found under SE and include: 1) conceptual skills (e.g., CPI philosophy, project management, process management, systems thinking, systems engineering, problem solving, decision analysis); 2) human interaction skills (e.g., conflict resolution, leadership, change management, team dynamics, communications); and 3) technical skills (e.g., value analysis, waste analysis, risk analysis, flow analysis, constraints analysis, metrics, probability/statistics, and TPM/ RCM) (Department of Defense, 2006, pp. C2-4).
Naturally, to be more effective, both SE and LSS strategists would need to understand the other disciplines that ultimately impact design solutions and associated support concepts. Traditionally, systems engineers are taught that the virtues of program management, logistics, test and evaluation, budget and finance, and even contracting are indispensable--and practice them--especially since these other disciplines tend to dictate the available trade space that guides just about every design alternative.
For example, aside from the ground stations that support them, satellites need no logistics support since repair in space at such high orbits is impractical. In sharp contrast, combat tanks need comprehensive logistics support. Routine maintenance and sometimes unscheduled maintenance occur frequently. Invariably, the design phase of each of these systems would have different considerations. For satellites, reliability is always an imperative. It must be extremely high since routine or unscheduled maintenance is not part of the equation. With very little exception, satellites are not repaired in space because it is cost-prohibitive. Consequently, the aggregate component "meantime-between-failure (MTBF) in medium to high earth-space orbits should equal satellite life--on the order of 15 years or more. To the credit of the development teams, many satellites have already exceeded their design life. Of the 245 satellites Boeing has launched into service (with more than two--thirds built by Hughes before they were acquired in 2000), 166 are still flying beyond their expected life span (Pae, 2008, p. 1). Conversely, tanks have a much different supportability concept. Their survival is heavily dependent on maintenance intervention. They have a lot more moving mechanical parts that wear out quickly in the face of different inhospitable environmental conditions. Since tanks are terrestrial and easy to access, operational support is a much easier and cost-effective proposition. Invariably, the aggregate MTBF for tanks is much lower and, again, to the credit of the development teams, every design characteristic is optimized for safety and warfighting effectiveness.
If space engineers designed tanks, tanks might never fail but the costs might be out of this world! Ultimately however, to be successful with the development of satellites, tanks, ships, aircraft, missiles, etc., SE must be tightly integrated with all functional disciplines. And, LSS must do the same. Otherwise, the DoD and industry might never see the potential gains.
Without question, SE and LSS practitioners unequivocally understand the environmental constraints that bear on design considerations and design constraints. Consequently, they vigilantly weigh system design features against a wide range of supportability concepts. Along the same line, based on the wide array of product lines and services in the DoD, SE and LSS practitioners have had to quickly recognize and anticipate unforgiving operational environments as well as recognize the need for tight integration of all the disciplines to make those systems peerless in the face of anticipated adversaries. Certainly, DoD's weapon and support systems need to be second to none in their combat roles. Toward that end, today's SE and LSS strategists have become much more focused on processes, with LSS seemingly leading the charge. Further, the tangible and recurring benefits seen with LSS give ample justification for LSS practitioners to be embedded into the design solution process from day one versus merely serving as process referees. They need to join SE practitioners who already sit at the center of gravity of the development and execution of key design processes. In fact, no one is in a better position to uncover a process that is not working/required or at least one that could be improved than LSS practitioners. They bring a new view of performance improvement--that improvements should be both reactive and proactive (Setijono, 2007, p. 9). More process awareness and even more proactive behavior on the Proton M Satellite team could have made a favorable difference if perhaps LSS and SE practitioners had joined forces beforehand.
Unmistakably, education and training has served as a guidepost for the capabilities expected of SE and LSS. Practitioners of both disciplines are encouraged to take courses that promote thinking within and beyond their specific functional areas of expertise. In DoD, these two disciplines like other functional areas also undergo mandatory certification training that verifies whether competency levels have been met. And, thanks to an extensive network inside and outside DoD, both camps have access to a rich source of knowledge and expertise that can further develop and nurture the necessary experience they need over time--which leads to the next key area both camps have in common.
Experience plays a huge role in the success of any profession, and it is no different for these two disciplines. Theoretical concepts that form the knowledge foundations for any discipline have significantly greater value if they can relate to practical experience. Within the DoD, this relationship is a necessity. The INCOSE recently codified experience as a fundamental part of their certification construct (Figure 5). Already, major companies including Booz Allen Hamilton, General Motors, Lockheed Martin, Northrop Grumman, SAIC, and Scientia Global are posting SE jobs requiring these certification qualifications (INCOSE, 2008).
[FIGURE 5 OMITTED]
In DoD, we operate as a multi-discipline cohort (e.g., intact) teams. We practice as teams. We become better teams with practice. Likewise, both SE and LSS require a set of unique skills that must be partially learned by practicing. Over time, SE and LSS help give teams the technical depth, collaborative instinct, and practical experience they need. In sharp contrast, inexperience can be perilous as exemplified by Boeing's Future Imagery Architecture (FIA) Satellite development program. Boeing built satellites before, but this was a specialized domain. They had never built the kind of spy satellites the government was seeking. Defective parts, like gyroscopes and electric cables, repeatedly stalled work. An elementary rule of spacecraft construction--never use tin because it deforms in space and can short-circuit electronic components--was violated by one of its parts suppliers. By the time the project was killed in September 2005--a year after the first satellite was originally to have been delivered--final cost estimates ran as high as $18 billion. The original cost was $5 billion (Taubman, 2007). Many other issues including ethical ones surfaced, but inexperience quickly complicated matters and appeared to be the predominant factor.
To combat the threat of inexperience, SE and LSS practitioners undergo a wide array of "practical" training and educational programs throughout their careers. Before long, their training and education is reinforced by actual experiences, and even sometimes guided by personal mentors. Eventually, their expertise deepens over time. They begin to ask the tough questions and conduct more comprehensive analyses and assessments. These varied and shared experiences that SE and LSS practitioners learn can help them more carefully and "jointly" sense, think, judge, and assess the challenges and opportunities they face before and after selecting the most fitting analytics. Tough decisions prevail in DoD. To make matters worse, the slow rate of performance improvement is usually not due to a lack of knowledge but in making the transition from theory to implementation (Stephen, 2004), which invariably depends on confidence and experience. Based on the expectations of their job tasks and assignments, both DoD and industry continue to look to these two particular groups for insights, especially when the need arises for any necessary design, development, production, or process adjustments.
So, what do you get when you mix together SE and LSS professionals? In short, you get a comprehensive multidisciplinary collaboration team. You get a natural blending of two camps with exceptional, unifying, and many common functional competencies. You get a profitable merger of two camps steeped in disciplined yet creative problem-solving processes. You get a far-reaching problem prevention team that can jointly mitigate design, production, and fielding issues--early. In fact, you gain immediate efficiencies. You get full technical coverage thanks to complementary and educational pedigrees. You get experiences that are priceless. More importantly, you get one integrated camp that can have a profound effect to help drive down programmatic risks and costs while helping to attain difficult schedule and performance goals--and eliminate process waste. Moreover, no two groups could do more to build in extra cohesion among all the functional disciplines so critical to DoD and the warfighter. Invariably, tightly integrating both SE and LSS can have a favorable multiplier effect.
So, go ahead and try to flavor the discussion between SE and LSS. Ask what divides them. There will indeed be a conspicuous silence. However, once these two opposing camps engage in deeper thought, they will not stop talking about how much they actually have in common, and how much more they can jointly influence performance outcomes, especially when they begin to ask a few questions of each other and of themselves. Ask them what matters most. Many of them might just be inclined to say, as did Kipling in 1900 (p. 85): I keep six honest serving-men (They taught me all I knew); Their names are What and Why and When And How and Where and Who.
Cowper, D., Bennison, S., Allen-Shalless, R., Barnwell, K., Brown, S., El Fatatry, A., et al. (2005, May). Systems engineering core competencies framework. International Council on Systems Engineering. Retrieved January 6, 2009, from http://www.incose.org.uk/Downloads/Systems%20Engineering%20Core% 20Competencies%20Issue%201b%20_2_.pdf
Defense Acquisition University. (2001). System engineering fundamentals. Fort Belvoir, VA: Defense Acquisition University Press.
Department of Defense. (2006, May). Continuous process improvement transformation guidebook. Washington DC: Author.
George, M., Rowlands, D., & Kastle, B. (2004). What is lean six sigma? Penn Plaza, NY: McGraw-Hill.
George, M., Rowlands, D., Price, M., & Maxey, J. (2005). Lean Six Sigma pocket toolbook: A quick reference guide to nearly 100 tools for improving process quality, speed, and complexity. Penn Plaza, NY: McGraw-Hill.
International Council on Systems Engineering (INCOSE). (n.d.). Systems engineering professional certification. Retrieved November 5, 2008, from http://www.incose.org/educationcareers/certification/index.aspx
iSix Sigma. (2008). Six Sigma--What is Six Sigma ? Retrieved October 29, 2008, from http://www.isixsigma.com/sixsigma/six_sigma.asp
Kepchar, K. (2006, January 28). INCOSE certification overview. Presentation to the International Council on Systems Engineering (INCOSE). Retrieved October 30, 2008, from http://www.incose.org/educationcareers/doc/ 081116_Certification_Overview.ppt#314,1,INCOSE Certification Overview
Kipling, R. (1900). Six honest serving men. In Just So Stories (p. 85). Harvard University Library of the Graduate School of Education. The Dorcas M. Bishop Collection of Children's Literature. Retrieved November 14, 2008, from http://books.google.com/books?id=mQMCAAAAYAAJ&dq=Just+So+Stories& pg=PP1&ots=11_j7NZfrm&source=bn&sig=xlig8NDcAPusNOre9FUhgcPmrVQ& hl=en&sa=X&oi=book_result&resnum=4&ct=result#PPP1,M1
Lamb, C. T., & Rhodes, D. H. (2008). Details for collaborative systems thinking research: Exploring systems thinking within teams. International Council on Systems Engineering (INCOSE). Retrieved November 6, 2008, from http://lean.mit.edu/index.php?option=com_docman&task=doc_details& gid=2064&Itemid=332
Olsen, F. (2008, June). DoD gives big nod to Lean Six Sigma. Federal Computer Week. Retrieved October 22, 2008, from http://www.fcw.com/online/news/152708-1.html#
Pae, P. (2008, December 9). Some satellites don't know when to quit. The Seattle Times. Retrieved December 12, 2008, from http://seattletimes.nwsource.com/html/businesstechnology/ 2008484433_satellites09.html
Powell, B. (2002). A brief introduction to systems diagrams. Continuous Improvement Associates. Retrieved October 16, 2008, from http://www.exponentialimprovement.com/cms/uploads/systemsdiagrams2.pdf
Robinson, B. (2008, March 3), DoD rallies around Lean Six Sigma: The methodology has become the Defense Department's. Federal Computer Week. Retrieved November 2, 2008, from http://www.fcw.com/print/22_5/features/151766-1.html?page=1
Setijono, D., & Dahlgaard, J. J. (2007.). Selecting improvement projects that add value to customers. Asian Journal of Quality. Retrieved November 7, 2008, from http://www.diva-portal.org/diva/getDocument? urn_nbn_se_vxu_diva-19802_fulltext.pdf
Stephen, P. (2004, June 11). Application of DMAIC to integrate Lean Manufacturing and Six Sigma. Partial fulfillment of a master's thesis. Virginia Polytechnic Institute and State University, Blacksburg. Retrieved November 1, 2008, from http://scholar.lib.vt.edu/theses/available/etd-06152004-123300/ unrestricted/thesis.pdf
Taubman, P. (2007, November 11). In Failure to launch; death of a spy satellite program. The New York Times. Retrieved December 24, 2008, from http://query.nytimes.com/gst/fullpage.html?res=9A07E0D61439F932A25752C1A 9619C8B63&n=Top/Reference/Times%20Topics/People/T/Taubman,%20Philip
Taverna, M. (2008, July 7). Back to work. Aviation Week & Space Technology, 169(1), 31.
Mr. Robert L. Tremaine is associate dean at the DAU West Region. Prior to joining DAU, he served over 26 years in the U.S. Air Force in acquisition assignments that spanned air, missile, and space. He holds a BS from the U.S. Air Force Academy and an MS from the Air Force Institute of Technology. He graduated from the Canadian Forces Command and Staff, and U.S. Army War Colleges. He is level III certified in Program Management and Systems Planning, Research, Development and Engineering.
(E-mail address: Robert.email@example.com)
TABLE 1. TECHNICAL & MANAGEMENT PROCESSES Technical Technical Processes Management Processes Top-Down Processes Technical Planning (include requirements development, Technical Assessment logical analysis, and design solution) Bottom-Up Realization Processes Decision Analysis (include implementation, integration, Technical Control Processes verification, validation, and transition) (include requirements management, risk management, configuration management, and technical data management) TABLE 2. TIRE SELECTION TRADE SUMMARY Criteria Weighting 3 1 2 1 Availble Tire Prices The Insta- The Free High Vendor for llation, Warranty Rotation Score Tire Needed Balancing Free Wins and stems Align- ment Tire Land $99/Tire $9.99/Tire Life of Yes 15 Tire 3x2 1x2 2x3 1x1 Tire Planet $94/Tire $8.99/Tire 65,000 No 13 3x3 1x2 1x2 0 Tire Galaxy $101/Tire Free 65,000 No 8 3x1 1x3 1x2 0 Tire Universe $99/Tire $12.99/Tire Life of Yes 12 Tire 3x2 1x2 1x3 1x1 Criteria Weighting Fasctors (1 = Low; 2 = Medium; 3 = High) Best Value (3=Best; 2=Good; 1=Fair)
|Printer friendly Cite/link Email Feedback|
|Author:||Tremaine, Robert L.|
|Publication:||Defense A R Journal|
|Date:||Apr 1, 2009|
|Previous Article:||Shaping the life cycle logistics workforce to achieve desired sustainment outcomes.|
|Next Article:||Letter from the editor.|