Weeding
Out a Solution
All
too often a design of a system encounters problems when there is not an
understanding of the requirements or poor communications among the team members. The Systems Engineer must take all the facts
into account and make decisions based on the requirements. In many cases, it involves a design program
review with the client to ensure that the requirements are met. In some cases, it may require changes to the
design or performance parameters based on the program review.
For
this research assignment, the use of commercial-off-the-self hardware, rather
than a customized design solution, resulting in going over our original
allotted weight budgets. This is a
common problem that can be remedied by going through an internal engineering
review. If the viable options do not resolve the weight issue or caused new
discrepancies that cannot be resolved internally, a program review with the
client is justified to discuss the options available to correct the
situation.
Internal Program Review
Following
the steps proposed by Tavassoli (2008), I will conduct a internal program review
to review the requirements, establish alternative actions, and prepare for a
program review with the client.
Requirements
The
internal program review starts with the review of the original requirements and
then use management tools such as those proposed in our readings by Tavassoli
(2008) to come up with a solution to address the weight issue. Take a close look at the “shall”, “will” or
“must statements, which are mandatory.
Then take a look at those that are “should” or “may” statements to see
how impact the current design of the aerial vehicle.
If
the requirements documents require that we make adjustments to the solution,
have the engineering teams do so. If
not, look closely at the structure of the requirements and make it clear to the
client that the requirement document has lead us down a path that now need to
be revisited so that the final product still meets their expectation.
Manage
and link customer needs, requirements and contracts
Even though, the
marketing team may have influenced expectations that are not realistic, you
need to address the issue directly with the client to ensure they understand
the impact of using the existing COTS solution or the cost in making
changes. The resource cost may be a
point of negotiations, but something that needs to be address to ensure cross
increases or compensations by our team are clearly articulated and documented.
Before engaging
the customer, a review of the contract to capture any changes based on the
existing situation must be evaluated. As
Tavassoli states, you must capture the user requirements, maintain traceability
and any proposed changes to the contract.
Manage Constraints
At the point, once
the requirements and contract obligations are clearly understood for this
project, nonfunctional requirements or constraints need to be understood. Here is where expectations made by the
marketing team differ from actual engineering requirements that address
performance, and safety for this project as it relates to the issues at
hand. There are other constraints that
must be address for the overall project, which include, but are not limited to
reliability, availability and maintainability.
Visualize Requirements
I
would ask the engineering team to visualize the problem and to propose
alternative options to include the introduction of customized solutions or
alterative COTS equipment. There may be
alternatives that they have not considered that could solve the problem. By having visual presentations of the
requirement and current issues on a whiteboard or PowerPoint presentation, the
engineering teams will be consistent in presenting alternative actions, provide
traceability on how the solutions are obtained, and control design changes.
Test Requirements
Although
Tavassoli’s 10 step process was designed for the IT sector, it still has
applications in engineering reviews, such as the one embarked in this
project. In the test requirements phase,
I will have the two engineering team present their alternatives solutions, and
propose courses of action to determine which one is the most viable within the
current requirements. If one cannot be
found, then recommendations to changes in the requirements should be proposed.
Bridge the Chasm Between Business and Development
This
is an important juncture to bring in the marketing team and engineers to
maintain a link between the engineering team requirements and customer needs to
ensure the proper recourses are expended in the final proposed solution. If the solution is going to be different and
may counter the clients expectations, the marketing team’s input is important
and may modify the engineers’ proposed solution.
Control Change to Requirements
If a change is
going to be made to the initial requirements, this is the time to document the
change. This will require a formal
process to ensure traceability of the change.
This will also require coordination with the contracts team to review
the legal documentation and propose changes, which will be reviewed with the
customer.
Capture and Track Metrics and Trends
I
would hope that my engineering teams where capturing and tracking data to get
to the point they are today with regards to the issue of allotted weight
budgets. A review of this data to see
how they got themselves into this situation is warranted. It could serve to see
if other issues besides the weight issue are present or if this individual
issue can serve to find other issues in other programs being worked by these
engineering teams. This data can also
serve to review of other requirement changes that may affect other engineering
teams working this project. At this
point, it may require the involvement of the customer in a full program review
to see if the original requirements were poorly specified leading to these
requirement changes.
Provide Examples of Good Requirements
Before proposing
changes to the existing requirements, a review of the requirements should be
made by referencing previous work done by our company. It may be good to use this exercise as a
lessons learn process by looking back at previous work and also documenting
these changes for future reference.
Reuse Requirements
Once the changes
are made to the orginal requirements, documentation and traceability are
essential so that the same errors are not repeated. At the same time, these new requirements can
server future projects. No sense in
reinventing the wheel.
Customer Program Review
Regardless
of the decision made to make changes to the solution or the initial
requirements, a formal discussion with the client is required. This will ensure the customer’s expectation
is met and the legal obligations are met.
All too often, either the client or the provider short change this
process. The customer ends up not
satisfied with the final solution. This
can lead and final payment for the project are withheld or not paid.
Considerations and Priorities
In
resolving this overweight problem, my focus is to understand the requirements,
legal obligation, and customer’s expectations.
If changes to the requirements are required ensure the client
understands the rational of the changes and impact on resources and timelines. If contract modifications are required,
address them early in the process.
Regarding
the actual engineering process decision cycle, documentation and tractability
are as important as the final ‘next generation or enhanced” solution. To get to
this final solution, I will use the alternative options and propose several
courses of actions. From these courses
of action, I will propose the best courses of action or may propose only one
option based on the available information.
The
final solution based on my approach is only as good as the customer accepts as
a viable solution to meet his requirements.
In the best case, the customer will accept my solution and make the
proper contract accommodations or modifications. In the worst case, the contract is terminated
because neither party can agree to a final solution. Sometimes, walking away from an opportunity
is in the best interest of both parties.
Although, this is rare, it does occur from time to time.
Conclusion
In resolving
issues that come up during the development of a project, the process used is in
most cases is more important that the actual engineering solution. The changes to get to the final solution
requires documentation and traceability.
As we learned this week, there are numerous tools and processes that can
be used. In my discussion, I chose to
use the one proposed by Tavassoli. There
are others that are equally effective.
Reference
Tavassoli,
D. (2008, October). Ten steps to better requirements management. [PDF].
Somers, NY: IBM. Retrieved from ERAU ASCI 530 2.1 Module Topic Reading
