JWST Rules of Engagement
November 25, 2003
5/28/2016
1
Why we need ‘em

Good reasons:





Management reasons:



More STScI staff are attending JWST working groups, SI teams etc.
Many requirements and ICDs are being developed that will affect the
observatory performance and the S&OC (STScI).
JWSTP has indicated that they do value STScI input.
We (STScI) need to maximize our effectiveness in raising issues and
responding to CCRs and reviews.
The Project has not yet implemented a clear review and consent process.
We do not want to commit ourselves to effort not covered under our
current contract.
Now in Phase B we can find ourselves in disagreement with the
Project.

The Project is deviating from the HST lessons learned


A number of architectural, requirements and process problems have arisen

5/28/2016
The lessons from HST seem obvious to us but may often not be known to or
selected by the Project (for budgetary or other programmatic reasons).
The solutions under consideration or the current lack of a solution may have
suboptimal consequences for science or operations.
2
We have many opportunities to
affect JWST plans:
Technical advice in support or leadership of
working groups and SI teams.
 Reviews of documents prior to baselining
 Submittal of CCRs (Change requests)
 Response to CCB actions (baselining & CCRs)
 Contractual changes & negotiations.
The earlier we affect a document or design, the
better.

5/28/2016
3
When should we request changes
or raise issues?



5/28/2016
When a design or requirement reduces the ultimate
scientific performance of JWST (particularly with
respect to previous designs).
When a design or requirement is technically flawed (we
can show that it won’t work or carries a significant and
definable risk).
When a design or requirement is inconsistent with our
contract/development plans/operations concept (e.g.
raises our costs).
4
Who can raise an issue?

Any STScI staff member can raise an issue:

In support of a working group or SI team:



In reviewing documents



To designated lead reviewer
To WBS manager/MO
As a result of an internal study

5/28/2016
To chair of working group or PI
If not resolved, to WBS lead and/or Mission Office
To WBS lead
5
Working Group Etiquette


Know the Chair and Charter of the Working Group
Raise issues in natural course of discussion:





5/28/2016
Be more concerned about substance than style
Don’t harp on same concern (but feel free to email the Chair if you
think that the group misunderstands the issue or underestimates its
impact.)
Show others the respect that you would want for your own ideas.
Try to work from a position of knowledge and not opinion. If you
are not sure about a fact, take it offline as homework and
communicate by email or at the next meeting.
In general, make clear that you cannot commit the STScI
to a course of action or concurrence on a document. You
may be the most knowledgable/informed STScI staff
member but even then, there may be additional concerns,
dependencies, and contractual agreements of which you
are not aware.
6
Working Group Etiquette (2)


When a group seems to be deadlocked on an issue ask the chair (or
most senior GSFC person present) what the mechanism is for issue
resolution. If they don’t know, ask if there is a higher level body to
which the issue can be raised.
Be aware of documents or CCRs that will be submitted for to the CCB
and bring these to the attention of your WBS lead and/or MO so that
they can have wider review within the STScI and comments returned to
the author/working group chair before CCB submittal.



5/28/2016
This step should be facilitated by the working group chair/PI/instrument
manager but often isn’t.
NASA will often assume that your presence and participation guarantees a
STScI rubberstamp approval. It doesn’t.
It is much better to indicate impacts and concerns before the CCB process
than during it. At a minimum, it reduces the elements of surprise and
frustration.
7
What do you do if a new capability
is allocated to the S&OC?

If you are participating in a meeting wherein a capability is being
allocated to the S&OC that exceeds the scope of the S&OC
contract/requirements/architecture (e.g.via requirements or interface
definition) then:





5/28/2016
identify to the group that there is an impact to the S&OC,
ensure that the requirement/request for the capability is documented
(Specification, ICD, OCD, CCR)
if you believe the impact to be small allow the group to proceed with their
assumption that the S&OC will provide the new capability,
if you believe the impact is large encourage the group to develop
alternatives as the proposed change to the S&OC may not be approved,
report the situation to your JWST direct report (Team Lead, WBS
Manager or JWST Mission Office).
8
External Review Etiquette


If you are a member of a board, you will be advised of your
responsibilities by the chair of the board and the board’s charter.
If you are in the audience:



Maintain a professional decorum. (snickering, muttering, groaning, etc. is
discouraged)
Generally, you are at the review to support another speaker or to learn.
You should interject only when there is a significant factual error
presented (raise your hand and be recognized by the speaker or the chair).
NASA has discouraged the submission of RIDs or RFAs by project
personnel (including the STScI) at external reviews.



Nevertheless, if you are sure that an important technical issue has been
missed or misrepresented, we suggest the following steps:


5/28/2016
Gives the impression of poor communication within the Project (may be true!)
Should have been another opportunity for raising the issue (see working group
etiquette).
Speak with the chair or a member of the board at a break. They may ask you to
write up the concern so that they can discuss it later.
For some reviews, the MO will provide a procedure for submitting a concern
through a designated STScI representative to the Board/Project.
9
Sometimes a strategic retreat is
the best option:

If a working group/PI etc. is dedicated to a course of action
with which you disagree, there are other opportunities to
mitigate the impact on science and/or the STScI.




5/28/2016
Issues can be brought to the Project’s attention through the MO
monthly reporting process.
Risks can be tracked within the STScI and in the Project Risk
database.
Ultimately, impacts to the STScI can be addressed with additional
funding by the CCB/Contract modification process (and this
process can result in the course of action or CCR being denied
because of its overall financial impacts.)
Take some solace in the overall scientific power of JWST
and the healing power of additional funding (even if it is
not the optimal solution).
10
Remember



You probably have the most operational and scientific
expertise on your working group.
The STScI is expected to represent the ultimate scientific
user of the observatory.
Our SOW explicitly requests that we endeavor to:



5/28/2016
Minimize total mission costs (including operations)
Maximize ease of observatory operations
We must earn the respect of the Project. We have the
respect of the HST project because we earned it but it is
not transferable to JWST; it needs to be earned anew.
11
How do we track issues, risks,
assumptions?



5/28/2016
Within the STScI, issues and risks are presented and
tracked through the MSR and MA-01 process.
Within JWSTP, issues are tracked by the JWST
engineering team and at the Top-Issues meetings. Risks are
tracked in the Risk management database and Risk Board
reviews.
Contract assumptions are tracked by the MO and will be
reported as part of our semi-annual planning responses and
in negotiations.
12