255
Integration in Systems Engineering Context
• Explicated: The difference between making a decision without analysis (in this case mathematical) [the part: what can be done] and without carefully soliciting and considering all the opinions expressed
by the project team (people who will in great part determine the success of the project and your decision) [combined as the part: what you
need to do] and you know the design best suited to meet the schedule
needs to be chosen because difficult times lie ahead for the entire
project team should a catastrophically wrong decision be made too
early in development and you have no viable plan to succeed (should
there be inordinate delays in the work) [the part: you do not know how
to achieve what needs to be done] you have a problem. The problem
involves not having enough schedule to make catastrophic mistakes
(in this case early on).
Domain of a Problem
The domain of the problem is succinctly characterized as a trait of the team’s
work and the project context rather than an intrinsic property of the project. The team takes responsibility for determining the problem within the
structure and culture of the project. The problem does not present itself in
isolation. The problem is inextricably tied to the stakeholders, one of which
is the project team. But the problem is neither an inherent part of the project
nor the context of the project. In short, the project cannot be blamed for a
faulty problem statement, but the team can. Therefore, it is vital for the team
to diligently work to better the definition of the problem, to focus effort on
satisfying the needs of the stakeholders so the problem can be mitigated,
mollified, or solved, and to create a collaborative environment for all stakeholders to share openly. If the problem was always thought of as success or
failure (representing an intrinsic part of the project), then every decision
would be in the vein of fatalism (an unavoidable necessity). Were fatalism the
operative doctrine, one would have not proposed to tackle the work (and by
any measure should not be a part of the team).
Systems engineer’s Perspective of a Problem
It is instructive to point out a key difference between systems engineers and
project managers. Indeed, the difference is so pronounced that it is the rare
individual that should perform both roles. In the example of the project
where the systems engineer needed to decide between two conceptual
designs, the project manager advocated compressing the development and
delivery schedule, resulting in acquiesce by the development team (including
the systems engineer). The sensitivity to a shortened schedule heightened
the importance for the systems engineer to take particular care, as there was
no time to mature a design as might be planned. The project manager’s
intuition instilled sufficient confidence to bring up the idea of compressing
Integration in Systems Engineering Context
• Explicated: The difference between making a decision without analysis (in this case mathematical) [the part: what can be done] and without carefully soliciting and considering all the opinions expressed
by the project team (people who will in great part determine the success of the project and your decision) [combined as the part: what you
need to do] and you know the design best suited to meet the schedule
needs to be chosen because difficult times lie ahead for the entire
project team should a catastrophically wrong decision be made too
early in development and you have no viable plan to succeed (should
there be inordinate delays in the work) [the part: you do not know how
to achieve what needs to be done] you have a problem. The problem
involves not having enough schedule to make catastrophic mistakes
(in this case early on).
Domain of a Problem
The domain of the problem is succinctly characterized as a trait of the team’s
work and the project context rather than an intrinsic property of the project. The team takes responsibility for determining the problem within the
structure and culture of the project. The problem does not present itself in
isolation. The problem is inextricably tied to the stakeholders, one of which
is the project team. But the problem is neither an inherent part of the project
nor the context of the project. In short, the project cannot be blamed for a
faulty problem statement, but the team can. Therefore, it is vital for the team
to diligently work to better the definition of the problem, to focus effort on
satisfying the needs of the stakeholders so the problem can be mitigated,
mollified, or solved, and to create a collaborative environment for all stakeholders to share openly. If the problem was always thought of as success or
failure (representing an intrinsic part of the project), then every decision
would be in the vein of fatalism (an unavoidable necessity). Were fatalism the
operative doctrine, one would have not proposed to tackle the work (and by
any measure should not be a part of the team).
Systems engineer’s Perspective of a Problem
It is instructive to point out a key difference between systems engineers and
project managers. Indeed, the difference is so pronounced that it is the rare
individual that should perform both roles. In the example of the project
where the systems engineer needed to decide between two conceptual
designs, the project manager advocated compressing the development and
delivery schedule, resulting in acquiesce by the development team (including
the systems engineer). The sensitivity to a shortened schedule heightened
the importance for the systems engineer to take particular care, as there was
no time to mature a design as might be planned. The project manager’s
intuition instilled sufficient confidence to bring up the idea of compressing