291
Systems Integration Management
meaning in a specific context, but the fundamentals of a project by definition
are pervasive across these various circumstances.
After World War II, scientists were motivated to push technology as they
explored the limits of the known physical laws. Progress seemed only limited by imagination, yet the appetite for innovative products that could be
produced inexpensively seemed insatiable. Management techniques, applicable since the industrial revolution, were being revised. The design of new
products was no longer governed by a single physical law or simple set of
rules. The confounding factors were the number of items in the product, the
myriad types of and relationships between these items, and the number of
these items that required choreographing to achieve the desired functionality. The management systems that were used to develop such products were
not designed to deal explicitly with these confounding factors. Therefore,
visibility into the progress of work was limited, delays (due to changes in
work, insufficient skills of workers) were common, and predictability of status and progress suffered. Systems engineering grew out of the need to build
products whose elements were inextricably intertwined.
The systems engineering view required its own brand of management, not
unlike what most others use, but postured to reinforce the focus on defining
requirements, system design, architecture, and integrative processes. Some
books on project management sometimes reference systems engineering
(Kerzner 2009), many systems engineering books included section(s) on
managing for systems engineering projects (Sage and Armstrong, 2000;
Hitchins 2007), and a few systems engineering books are devoted entirely to
the subject (Forsberg and Mooz 1996; Blanchard 1998). One can easily fail to
count or acknowledge all that has been written about project management.
However, the author knows of no writings that focus on the management of
integration. Aside from the litany of books, handbooks, organizations, professional journals, practicing managers, and consultants, new concepts arise with
the intention to replace, yet still add, only to add to the funambulation* that
ropes terms together into the web of ideas we term as project management.
For developing a product or service using systems engineering, the focus
is on managing the systems engineering process. The systems engineering
management plan (SEMP) lays out the plan, procedures, and the representations (or models) that are necessary to describe, provide, and be the documentation, milestones, reviews, and steps for the project team to carry out.
However, invariably the section on systems integration begins with the word
integration, follows through with words discussing integration, and then
ends with the word integration. Nowhere is there a discussion of any detail
about what management of integration means or even what is entailed.
Typically, integration is viewed as a phase of work that must occur as development ends and prior to completing the product or service work.
* Tightrope walk.
Systems Integration Management
meaning in a specific context, but the fundamentals of a project by definition
are pervasive across these various circumstances.
After World War II, scientists were motivated to push technology as they
explored the limits of the known physical laws. Progress seemed only limited by imagination, yet the appetite for innovative products that could be
produced inexpensively seemed insatiable. Management techniques, applicable since the industrial revolution, were being revised. The design of new
products was no longer governed by a single physical law or simple set of
rules. The confounding factors were the number of items in the product, the
myriad types of and relationships between these items, and the number of
these items that required choreographing to achieve the desired functionality. The management systems that were used to develop such products were
not designed to deal explicitly with these confounding factors. Therefore,
visibility into the progress of work was limited, delays (due to changes in
work, insufficient skills of workers) were common, and predictability of status and progress suffered. Systems engineering grew out of the need to build
products whose elements were inextricably intertwined.
The systems engineering view required its own brand of management, not
unlike what most others use, but postured to reinforce the focus on defining
requirements, system design, architecture, and integrative processes. Some
books on project management sometimes reference systems engineering
(Kerzner 2009), many systems engineering books included section(s) on
managing for systems engineering projects (Sage and Armstrong, 2000;
Hitchins 2007), and a few systems engineering books are devoted entirely to
the subject (Forsberg and Mooz 1996; Blanchard 1998). One can easily fail to
count or acknowledge all that has been written about project management.
However, the author knows of no writings that focus on the management of
integration. Aside from the litany of books, handbooks, organizations, professional journals, practicing managers, and consultants, new concepts arise with
the intention to replace, yet still add, only to add to the funambulation* that
ropes terms together into the web of ideas we term as project management.
For developing a product or service using systems engineering, the focus
is on managing the systems engineering process. The systems engineering
management plan (SEMP) lays out the plan, procedures, and the representations (or models) that are necessary to describe, provide, and be the documentation, milestones, reviews, and steps for the project team to carry out.
However, invariably the section on systems integration begins with the word
integration, follows through with words discussing integration, and then
ends with the word integration. Nowhere is there a discussion of any detail
about what management of integration means or even what is entailed.
Typically, integration is viewed as a phase of work that must occur as development ends and prior to completing the product or service work.
* Tightrope walk.