CUST309

So Easy a “Grey Beard” Can Do It:

The Modernization of the “Paper-
Influenced” Release Process

Presented By:
Vanessa Martins, NASA KSC – ESC
Christopher Savela, NASA KSC – ESC
Paul Schwindt, NASA KSC

Boston, MA
June 18, 2014 * All presentations are subject to change

ESC Principal Engineering Technology Development Group

The Engineering Services Contract (ESC) at Kennedy Space Center (KSC)

provides services to NASA in respect to flight and ground systems design
and development. To aid this effort, the ESC Principal Engineering
Technology Development Group investigates and provides the necessary
tools, aid, and best practice methodologies required for efficient, optimized
design and process development. The team is responsible for configuring
and implementing software, along with training, documentation, and
administering standards. The team—comprising of 6 members—supports
over 200 engineers and design specialists with the use of PTC Windchill,
PTC Creo Parametric, NX, AutoCAD, and a variety of other design and
analysis tools.

2
Overview

• Legacy Process
– Paper Release

• Current Process
– Electronic Release
– Areas of Concerns
– User Response

• Proposed Process
– Goals and Focus Areas
– Proposed Implementation
– Value Added/Gained

Legacy Process

Paper Release Process

• [Process Diagram will go here]

4
Current Process

The PLM Compromise - “Paper-Influenced” Electronic Release

• [Process Diagram will go here]

Current Process

Areas of Concern
• Checking not involved in overall process
– Users must remember to submit work

• Process Redundancies/Inefficencies
– New Promotion Request must be created each time rework is completed
– For each Change Request, a Change Notice is manually created by CM
– Bottleneck effect/delays experienced based upon the response time in creating CNs
– Multiple CRs/CNs sometimes created in a single process

• Manual creation of Change Objects hinders overall process progression

– Users/Managers must manually keep track of objects
– Influx of requests occur near deadlines

• Additional training and support required from both users and CM to perform
process steps/tasks

6
Current Process

User Response
• “____ is not here today, and they’re
holding up my release.”

• “I don’t understand what I’m supposed

to do next.” Number
Change Object
Created
• “Can you set my objects back to ‘In Promotion Request 1224
Work’? I have to fix something.” Change Request 389

• “What’s the current status of this?” Change Notice 396

Total Manual Creations 2009
• “Why does it take 3 months to
release?” Release Metrics for 4948 objects

• “I have to create another Promotion

Request? I just made one!”

• “Who is supposed to do this?”

Proposed Process

Goal and Focus Areas

• Goal
– To optimize the current Release process through the utilization of system functionalities for the
benefit of the applicable users and NE as a whole.

• Focus Areas
– Efficiency/Streamline
– System Automation
– Traceability/Communication
– Visibility

New Process, Same End Results

8
Proposed Process

Initial Release
• [Process Diagram will go here]

Proposed Process

Revision and Release

• [Process Diagram will go here]

10
Value Added: Efficiency/Streamline

Eliminating Redundant and Inefficient Steps

• Promotion Request no longer required
– All required signatures collected during the Change Notice/Task process

• Manually created Change Objects reduced to a single Change Request

– Workflow evaluates the state of all identified “Affected Objects” in the Change Request and
routes objects appropriately
– Change Notice and Change Tasks automatically created and assigned by the system
– [information on workflow code for creating automatic objects will go here]

11

Value Added: Efficiency/Streamline

Eliminating Redundant and Inefficient Steps

• Change Notice remains open during review and rework (if necessary)
– [Information on “refine”/“rework” transitions from lifecycle/workflow will go here]

12
Value Added: System Automation

Removing Confusion Over “Who Does What”

• Tasks assigned using “Product Team” roles
– Users placed in their appropriate Team role(s) within their Product will automatically receive their
applicable review/rework tasks
– Users granted the ability to modify the assigned participant, in case modifications need to be
made
– [Information about “Shared Teams”/Team Roles will go here]

13

Value Added: System Automation

Reducing Wait Times

• Voting timer
– On a task with multiple signatories, timer is initialized when one of the assignees completes their
task with the “rework” vote
– If not yet completed by the timer’s end, the task will be terminated and automatically routed for
“rework”
– [Information about workflow timer will go here]

14
Value Added: Traceability/Communication

Preserving the “Who, What, When, and Why”

• Work instructions and voting comments shown within tasks
– Provides an additional mode of communication between reviewers, Team Lead, and task
recipients
– [Information on voting/comments gathering will go here]

• Team Leads able to communicate with reviewers in regards to rework

requests
– Team Lead may approve or oppose a rework decision made by a reviewer
– Opposing a rework request returns all opposition comments to the reviewer(s), who then can
revote for approval or rework (once again)

15

Value Added: Visibility

Improving Awareness
• “Pending/Resulting Change” icon displayed on all Affected Objects
– Occurs as a result of the Change Request/Change Notice remaining open
– Icon (visible to all users within the system) identifies an object will be changing
• Critical for objects utilized in multiple designs (or shared across Products)

• “Observer” role available within all review/signature tasks

– May be used to allow users (outside of required signatories) to have visibility to process
progression

• E-mail notifications enabled throughout process

– System set to automatically send out notifications based upon process progression

16
Convincing the Grey Beards

Final Steps to “Lift Off”

1.Perform Final Evaluations on Test Server

2.Update Roles and Access Controls

3.Update Product Teams

– Leads/Product Managers will be responsible to fill-in roles with the appropriate user

4.Import and Implement Workflow on Production System

– Visibility limited to first test (“Beta”) group

5.Train Beta Users

– Ensure support documentation is prepared and approved

6.Gather Beta Testing Results for Final Stakeholder Approval

17

Questions?

18
liveglobal.ptc.com