Phase III: Solving Problems, Success Stories, and Handoff
Phase III: Solving Problems, Success Stories, and Handoff
This is showing all stakeholders that the "juice was worth the squeeze"; Leadership's initial up-front investment is either saving people time or the model has provided capabilities which were not available before. To please leadership we need to be able to come to the table with some success stories.
However, the more important stakeholder in this phase is the users of the model which will likely be the systems engineering team. This effort needs to be focused on making the model useful enough for them to want to use. It is critical that the SE team buys into the product. If you have members which would rather "revert back to the old spreadsheet", you need to dedicate time to implement that spreadsheet into the model in a user friendly way.
The vision needs to remain that Cameo should act as the "sole source of truth". Those who oppose this will likely be able to explain the model's shortcomings. These need to be addressed immediately.
Note: This is a crucial Phase. Without this step there is a good chance that the user gets irritated with the model after he/she doesn't know how to do something and then reverts back to "special" excel spreadsheet which has been "good enough" for some time. If the model is not liked, then its existence will become a burden to maintain rather than a helpful tool.
Success Story Examples
Rapid Training: Cameo can help train new engineers more quickly on the system because all the information is in one location.
Napkin Estimates: If some sort of trade study is added, first order sensitivity studies can be completed for leadership which may help make high level decisions. For example, if we increase the wingspan of the aircraft 10%, how much extra payload weight would we anticipate gaining? This may help leadership determine if they need to fund a new variant.
Greatest Risk
There is a risk that if the end user does not understand or does not like using or does not see value or is not properly trained, that the model will be abandoned after that pass off.
Then the systems engineer would not do their work in Cameo, they would continue to do their work in other toolkits such as Excel, Powerpoint, Windchill, Creo, etc. and then manually putting reports together while having the extra overhead burden of updating the Cameo model.
Phase III Steps
Note: When steps happen in parallel they are labelled on the same reference point in the diagram.
Step 7)
Focus On End User Useability: Meta Model Data & Navigation Page
Adding features to make the model easier to navigate
The actual training of the end user
The training documentation and reference materials required for the end user to add additional content.
Step 8)
Probe End User for Tasks Model Could Solve
Work with the end user to determine common work functions which are repetitive or tasks which require compiling data from several different sources or some weekly report which is expected.
Step 9)
Add Content & Cleanup to solve End User’s Problem
Use the model to automate or simplify the task.
Note: At the end of Phase III end users should be fully trained to operate the model themselves. After Phase III is complete, the "training wheels" come off, the support team passes the model development off to the end user.
Quod Erat Demonstrandum
QED or Quod Erat Demonstrandum (roughly translates from Latin into "That which was to be proven")
We must follow the following steps during phase III.
What is the Question we need to answer?
How can we Extract it form the model?
How should we Display it to stakeholders in a meaningful easy to consume way?
More details: Systems Architecture Guild
Don't Forget The Purpose: Why We're Here
"In the Systems Engineering Handbook (v. 4) (SEHv4), INCOSE states that the goal of systems engineering is “providing a quality product that meets the user needs.” To put the bottom line up front, then, the fundamental purpose of systems engineering is to design/architect a solution to our customer’s problem that can be realized within the constraints of the problem space to meet the customer’s needs." -Zane Scott
"A Model has 3 features: 1) Mapping: A model is a mapping of something else, 2) Reduction: A model only reflects parts of the original thing, and 3) Pragmatic: A model fulfills a specific function and is used in place of the original for this purpose. -Stachowiak" (Model Based Systems Architecture, pg27)
"Your journey begins with choosing a destination. From there, you need a map of best practices and advice for the road. " "You begin by understanding your problem. You decide what you need to do before you choose how to do it. You resist the temptation to jump to implementation before you have mapped out the process by which you will meet your needs. " -Zane Scott
A systems model must have the following:
"Language—The model is seen in terms of language. The system definition language (SDL) [what we now characterize as the systems metamodel] expresses and represents the model clearly, so that understanding and insight can arise. This is critical to successful system design. The system definition language must be clear and unambiguous in order to depict the model accurately and understandably.
Structure—The model must have structure. This allows the model to capture system behavior by clearly describing the relationships of the system’s entities to each other.
Argumentation—The purpose of the model is to represent the system design in such a way that the design team can demonstrate that the system accomplishes the purposes for which it is designed. Therefore the model must be capable of making the critical “argument” that the system fulfills the stakeholders’ requirements.
Presentation—Not only must the system be capable of making that argument, but it must also include some mechanism of showing or “presenting” the argument in a way that can be seen and understood." -Vitech Primer for Model-Based Systems Engineering