305
Systems Integration Management
The problem that must be solved with integration planning is to innovate and
find the unique events that will change the probabilities of success. Planning
helps expose those events so that the opportunities can be capitalized into
resources and activities to endure the hardships and anguishes that arise from
the inherent nature of building something that is new and as yet unexplored.
The focus of planning is on what should be done now to make desirable things
happen given the uncertainties that will show up in the future. “What futurity
do we have to factor into our present thinking and doing, what time spans do
we have to consider, and how do we converge them to a simultaneous decision
in the present?” (Drucker 1964).
Integration planning is not a schematic for the future; not a set of functional plans; not a rigid series of tasks that must be attempted because they
were stated in a planning document; and not a complete set of all that is
known about what is to be integrated. But integration planning is an effective
means of scoping what is to be accomplished given uncertainties (uncertainties that will be resolved over a series of events or alternatively a period of
time). The important point about integration planning is that it can be accomplished either in event-space or in the time domain (i.e., temporal space).
Event-space captures the events that need to occur to accomplish a set of
tasks. For integration planning, event-space is most useful as the combination of objects that provide various functionalities is for the most part known
after the preliminary design is completed. More often than not, the integration plans are time-based and laid out as if the objects will be completed at a
particular time. If one of two objects is completed and the other is not, then
the event-based planning has plan B (contingency) tasks to combine the work
forces of the completed object task with that of the uncompleted object task
to work together to demonstrate their object–object functionalities. This may
not be the case for time-domain planning, which may (1) try to integrate the
completed task with another completed task (based on the two assumptions:
any progress is making progress and the team completing their object can
then go on to work another object (and logically, sometimes to help with the
object that was supposed to have been completed), and (2) may embark on
tasks that are in fact counterproductive to the overall system integration
effort. It is particularly distressing to see integration activities that focus on
getting any objects to “work” with any other objects through the use of simulated interfaces. This practice requires the construction of simulations
based on the “completed” object and presumes that the completed object has
achieved its (near) final composition and outputs. This practice helps to reinforce the iterative aspects of existing integration thinking. Build it close to
what is expected, then modify it to work with another component, then modify it again to work with yet another component, and so forth, each time
moving the components toward an anticipated “integrated” whole. However,
this chase to integrate is often met with a seemingly unending set of changes
that doom a project to cancellation, as the key stakeholders lose confidence in
the ability of the integration effort to result in a product.
Systems Integration Management
The problem that must be solved with integration planning is to innovate and
find the unique events that will change the probabilities of success. Planning
helps expose those events so that the opportunities can be capitalized into
resources and activities to endure the hardships and anguishes that arise from
the inherent nature of building something that is new and as yet unexplored.
The focus of planning is on what should be done now to make desirable things
happen given the uncertainties that will show up in the future. “What futurity
do we have to factor into our present thinking and doing, what time spans do
we have to consider, and how do we converge them to a simultaneous decision
in the present?” (Drucker 1964).
Integration planning is not a schematic for the future; not a set of functional plans; not a rigid series of tasks that must be attempted because they
were stated in a planning document; and not a complete set of all that is
known about what is to be integrated. But integration planning is an effective
means of scoping what is to be accomplished given uncertainties (uncertainties that will be resolved over a series of events or alternatively a period of
time). The important point about integration planning is that it can be accomplished either in event-space or in the time domain (i.e., temporal space).
Event-space captures the events that need to occur to accomplish a set of
tasks. For integration planning, event-space is most useful as the combination of objects that provide various functionalities is for the most part known
after the preliminary design is completed. More often than not, the integration plans are time-based and laid out as if the objects will be completed at a
particular time. If one of two objects is completed and the other is not, then
the event-based planning has plan B (contingency) tasks to combine the work
forces of the completed object task with that of the uncompleted object task
to work together to demonstrate their object–object functionalities. This may
not be the case for time-domain planning, which may (1) try to integrate the
completed task with another completed task (based on the two assumptions:
any progress is making progress and the team completing their object can
then go on to work another object (and logically, sometimes to help with the
object that was supposed to have been completed), and (2) may embark on
tasks that are in fact counterproductive to the overall system integration
effort. It is particularly distressing to see integration activities that focus on
getting any objects to “work” with any other objects through the use of simulated interfaces. This practice requires the construction of simulations
based on the “completed” object and presumes that the completed object has
achieved its (near) final composition and outputs. This practice helps to reinforce the iterative aspects of existing integration thinking. Build it close to
what is expected, then modify it to work with another component, then modify it again to work with yet another component, and so forth, each time
moving the components toward an anticipated “integrated” whole. However,
this chase to integrate is often met with a seemingly unending set of changes
that doom a project to cancellation, as the key stakeholders lose confidence in
the ability of the integration effort to result in a product.