James J. Mattice (SES, Ret.), Hubble Space Telescope SE Case Study, Air Force Institute of Technology, Center for Systems Engineering, 10 Mar 2005
Free Download from the USAF http://www.afit.edu/cse/casedocs/files/Hubble%20SE%20Case%20Study.pdf
This soup-to-nuts look at the Hubble Space Telescope (HST) takes the reader through the programmatics and engineering from 1962 through 2005. The bulk of the reading is focused on the system development efforts from 1977 through the first on-orbit servicing mission (1993) in which corrective optics were installed. Mattice presents a combination of “just the facts, ma'am” passages interspersed with interpretations, captured as learning points for the student.
Beyond the learning points identified by Mattice, several systemic leadership observations can be easily identified. The HST program was plagued with multiple examples of transactional and management-by-exception approaches that are incongruous for such a novel system development. Ultimately, for the optical system contractor, the relationship with the associate-prime contractor and the two NASA centers was very formally by contract, with little to no insight, accountability, nor communication. Ultimately, this arrangement contributed to the optical system flaw that had to be corrected on the 1993 on-orbit service mission. Further, the relationship between the two NASA centers, Goddard and Marshall, was by a very specific set of allocated responsibilities by NASA Headquarters and the U.S. Congress. Mattice gave a compelling example of this in the disconnects between the servicing concept development (Goddard) and the launch design/development (Marshall), which required many redesigns.
However, this development was not only transactional. For example, later in the program (1983), a transformational approach to requirements development and management was attempted by creating the Space Telescope Science Institute. This institute fundamentally changed how the NASA centers and contractors interacted with the scientific community (the primary end users for the HST), and moved the users to discuss the HST at the appropriate level.
This case study is not very long, only 46 pages in the main body, which makes it very approachable and digestible to students of systems engineering and program management. Mattice meets the goals set forth by the Air Force Institute of Technology by describing the technical, political, and programmatic context of the case. Mattice mentioned interviews with the Hubble Program Manager (1981-1986) and the Chief Engineer (1974-1988), although almost no description of these key players is given, which is typical for engineering case studies.
I recommend this case study to acquisition and systems engineering professionals, especially those in the space system development domains. In a couple of hours, a reader can identify and internalize many lessons that are still relevant to systems acquisition today.
Read More......
Showing posts with label systems engineering. Show all posts
Showing posts with label systems engineering. Show all posts
Saturday, August 27, 2011
Monday, May 30, 2011
Book Review: Shop Class as Soulcraft
Shop Class as Soulcraft: An Inquiry into the Value of Work, Matthew B. Crawford, Penguin Books, 256 pages, ISBN-10: 0143117467, 2010
Overall impression
Ever wonder how engineers can be more educated, yet less experienced? Have you wondered what the value of hands-on experience is? Wonder how, when using the best model of engineering, a system can fail? In reading Matthew’s work, I quickly built up an understanding of why my intuition rebelled against prescriptive engineering models being useful for growing the next generation of experienced engineers. First, we’ll look at a key systemic leadership take away from having read this book, followed by an overall review of the book itself.
Key take away for Systemic Leadership
In analyzing his experiences in knowledge work, after achieving his PhD in Philosophy, he had a starveling observation: “if occasions for the exercise of judgment are diminished, the moral-cognitive virtue of attentiveness will atrophy.” Applied broadly from the systemic perspective, we have a situation in which prescriptive models of how to do work (formal systems engineering or software engineering models) actually counters our desire to develop experienced engineers. Essentially, detailed, solution-agnostic engineering checklists drive our engineers to be less attentiveness and have less detailed knowledge about what lies underneath. In other areas, he observes that knowledge work and education alone is insufficient to have people who have intuition to form a problem solving strategy when information is incomplete or imperfect. Ultimately, he also observes how the best minds and most motivated people will generally not choose to work in environments which are highly controlled by these intellectual models of what is to be done. This leads to “a vicious circle in which degraded work plays a pedagogical role, forming workers into material that is ill suited for anything by the over-determined world of careless labor.”
Book literature review – approachability, readability, etc.
Overall, “Shop craft as Soulcraft” was a easy read, very approachable, generally using personal narrative stories to illuminate broad areas of inquiry. Yes, there are portions that use precise, philosophical language, but those parts are generally the conclusions at the end of each chapter. If you are interested in the philosophical implications of the stories told in a chapter, this is great. If you aren’t, skip the last few chapters and you won’t miss too much.
The reader must understand that Matthew exposes quite a bit of bias against modern knowledge work, assuming that people want to understand the world around them. While this can be argued one way or the other or the general population, my interest in understanding engineers makes that assumption inherently valid (as the job of the engineer is to understand how something works). Ultimately, if you are disillusioned with “Office Space” type work, you’ll find this book provides some well-articulated discussion points for your use. On the other hand, if you understand the value to society and people of aggregating knowledge to decrease the expertise (and cost) needed to deliver products, you may have problems overcoming the personal experience biases that Matthew exposes.
Overall: I enjoyed this book, and the author was both approachable and capable of keeping my mental focus. Read More......
Overall impression
Ever wonder how engineers can be more educated, yet less experienced? Have you wondered what the value of hands-on experience is? Wonder how, when using the best model of engineering, a system can fail? In reading Matthew’s work, I quickly built up an understanding of why my intuition rebelled against prescriptive engineering models being useful for growing the next generation of experienced engineers. First, we’ll look at a key systemic leadership take away from having read this book, followed by an overall review of the book itself.
Key take away for Systemic Leadership
In analyzing his experiences in knowledge work, after achieving his PhD in Philosophy, he had a starveling observation: “if occasions for the exercise of judgment are diminished, the moral-cognitive virtue of attentiveness will atrophy.” Applied broadly from the systemic perspective, we have a situation in which prescriptive models of how to do work (formal systems engineering or software engineering models) actually counters our desire to develop experienced engineers. Essentially, detailed, solution-agnostic engineering checklists drive our engineers to be less attentiveness and have less detailed knowledge about what lies underneath. In other areas, he observes that knowledge work and education alone is insufficient to have people who have intuition to form a problem solving strategy when information is incomplete or imperfect. Ultimately, he also observes how the best minds and most motivated people will generally not choose to work in environments which are highly controlled by these intellectual models of what is to be done. This leads to “a vicious circle in which degraded work plays a pedagogical role, forming workers into material that is ill suited for anything by the over-determined world of careless labor.”
Book literature review – approachability, readability, etc.
Overall, “Shop craft as Soulcraft” was a easy read, very approachable, generally using personal narrative stories to illuminate broad areas of inquiry. Yes, there are portions that use precise, philosophical language, but those parts are generally the conclusions at the end of each chapter. If you are interested in the philosophical implications of the stories told in a chapter, this is great. If you aren’t, skip the last few chapters and you won’t miss too much.
The reader must understand that Matthew exposes quite a bit of bias against modern knowledge work, assuming that people want to understand the world around them. While this can be argued one way or the other or the general population, my interest in understanding engineers makes that assumption inherently valid (as the job of the engineer is to understand how something works). Ultimately, if you are disillusioned with “Office Space” type work, you’ll find this book provides some well-articulated discussion points for your use. On the other hand, if you understand the value to society and people of aggregating knowledge to decrease the expertise (and cost) needed to deliver products, you may have problems overcoming the personal experience biases that Matthew exposes.
Overall: I enjoyed this book, and the author was both approachable and capable of keeping my mental focus. Read More......
Monday, May 24, 2010
Thoughts on the "Engineering Battle Rhythm" of Configuration Management
We discussed battle rhythm being important. Even started some definition of Battle Rhythm on the wiki. But now let's look at one close to my heart, the engineering battle rhythm.
In the newest wiki page, Engineering Battle Rhythm, I'm starting a discussion on the nature and impact of various engineering processes and the inherent rhythm that grows up around them in an acquisition organization. The most infamous SE process is that of Configuration Management (CM), and especially the very painful Request For Change (RFC). Nothing can strike fear and doubt into an innovator's heart faster than a first meeting with the configuration managers and all the associated boards and reviews inherent to an RFC.
Of course, what I'm hoping to examine is how to operate as a Systemic Leader in that very process heavy and entrenched battle rhythm of formalized systems engineering processes (such as CM). I'm starting to apply this at work, so hopefully I'll have some perspective and experiences to share and see if any of my thoughts survive their first encounter with "the enemy" (be that enemy the configuration manager or merely reality). Read More......
In the newest wiki page, Engineering Battle Rhythm, I'm starting a discussion on the nature and impact of various engineering processes and the inherent rhythm that grows up around them in an acquisition organization. The most infamous SE process is that of Configuration Management (CM), and especially the very painful Request For Change (RFC). Nothing can strike fear and doubt into an innovator's heart faster than a first meeting with the configuration managers and all the associated boards and reviews inherent to an RFC.
Of course, what I'm hoping to examine is how to operate as a Systemic Leader in that very process heavy and entrenched battle rhythm of formalized systems engineering processes (such as CM). I'm starting to apply this at work, so hopefully I'll have some perspective and experiences to share and see if any of my thoughts survive their first encounter with "the enemy" (be that enemy the configuration manager or merely reality). Read More......
Subscribe to:
Posts (Atom)