• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Hazen michael
 

Hazen michael

on

  • 10,818 views

 

Statistics

Views

Total Views
10,818
Views on SlideShare
10,818
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Hazen michael Hazen michael Presentation Transcript

    • How Much is Enough?Applying the Discipline of Systems Engineering toSmall, Fast-Paced ProjectsNASA Project Management Challenge 2007 Michael Hazen Jacobs Engineering
    • Safety MomentLittle things can cause big problems“True Systems Engineering is about minimizingthe unintended consequences of a design” – Michael Griffin, NASA PM Challenge 2006 2
    • AgendaSmall Fast-Paced Project DescriptionHow Much Systems Engineering is Enough??Too Much??Methodology & EnablersJSC Initiatives and Case StudiesDiscussion 3
    • Small Fast-Paced Project Attributes Typically one person will wear several hats No time to philosophize on potential methodologies once the project is kicked off No money for anything that is not essential and explicitly required These attributes often apply to larger scale projects 4
    • Systems Engineering AttributesBroad variations in what Systems Engineering andSystems Engineers are perceived to be. Book manager, collection of tools, project team “visitor”? http://www.incose.org/atlanta/Library/Presentations/Why_SE_Doesnt_Work.pptMichael Griffin comments Project Management and Systems Engineering are opposite sides of the same coin. Systems Engineering must be the technical conscience of the program. Lead systems engineers must not be too busy to look at the big picture. 5
    • Systems EngineeringNPR 7123.1 NASA Systems Engineering Processes and Requirements Systems engineering at NASA requires the application of a systematic, disciplined engineering approach that is quantifiable, recursive, iterative, and repeatable for the development, operation, maintenance, and disposal of systems; integrated into a whole throughout the life cycle of a project or program. The emphasis of systems engineering is on safely achieving stakeholder, functional, physical, and operational performance requirements in the intended use environments over the systems planned life within cost and schedule constraints.http://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7 123_0001_&page_name=Chapter1 6
    • How Much is Enough??KEY POINT: “How much is enough?” shouldfocus on HOW you address SE processelements as opposed to IF you will address theseelements. 7
    • NPR 7123.1 SE Enginehttp://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7123_0001_&page_name=Chapter3 8
    • Systems engineering is a fractal processThe systems engineeringprocess is applied at levels ofgreater and greater detail. It isapplied to the system, then tothe subsystems, then to thecomponents, etc. Similarlyfor the fractal pattern on theright, the same algorithm wasapplied at the large structurallevel, then at the medium-scale level, then at the fine-detail level, etc. http://www.sie.arizona.edu/sysengr/ 9
    • The Pirates Code“Everything has to be adapted to the project ofinterest”Dr. Joel Sercel, Director of Caltech’s Laboratory forSpacecraft and Mission Design 10
    • MethodologyCan I afford systems engineering?Organizational prerequisitesEnablers you can use now 11
    • Organizational PrerequisitesKnow your SE Process(es)Characterize YOUR small fast paced projectsDecide in advance (before the clock startsticking) how you plan to execute SystemsEngineering on small projects (pre-tailor yourprocesses) 12
    • Small, fast-paced project definitionhttp://cio.energy.gov/documents/SEM3_1231.pdf 13
    • Process Tailoring Examples Adapting the lifecycle (exhibit 2.2-1, p. 30) Specifying (in advance) work products required for specific project sizes Planning (Exhibit 3.0-1, p. 51) Requirements Definition (Exhibit 4.0-1, p. 114) Functional Analysis (Exhibit 5.0-1, p. 157) System Design (Exhibit 6.0-1, p. 192) Construction (Exhibit 7.0-1, p. 223) Integration and Test (Exhibit 8.0-1, p. 249) Installation and Acceptance (Exhibit 9.0-1, p. 262) Tailoring example (Exhibit 2.4-1, p. 41)http://cio.energy.gov/documents/SEM3_1231.pdf 14
    • 15
    • 16
    • Enablers you can use now 17
    • NPR 7123.1 ChecklistsTwo checklists (entrance criteria and success criteria) provided for major milestone reviews:Mission Concept Test ReadinessSystems Requirements System AcceptanceMission Definition Flight ReadinessSystem Definition Operational ReadinessPreliminary Design DecommissioningCritical Design http://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_ PR_7123_0001_&page_name=AppendixG 18
    • TipsCan start using these checklists anywhere in thelifecycle.To get away from vague “yes” answers to eachquestion, add columns to record the specific product /deliverable associated with the yes and another columnfor completeness / maturity.Readiness reviews (based on the NPR 7123.1checklists) a few weeks before an actual lifecycle reviewcan make a big difference in the success of the review.Do not make the checklist a “surprise”. Make sureprojects know what they should be considering duringeach life cycle phase. 19
    • Entry Checklist Usage ExampleChecklist Item Yes / Project Manager Reviewer No comments/ specific Comments location of technical products1. Successful completion of the MCR (Mission Concept Review)and responses made to all RIDS (Review Item Dispositions).2. A preliminary SRR agenda, success criteria, and charge to theboard have been agreed to by the technical team, projectmanager, and review chair prior to the SRR.3. The following technical products for hardware and softwaresystem elements are available to the cognizant participants priorto the review:a. System Architecture.b. System requirements document.c. System software functionality description.d. Updated concept of operations.e. Updated mission requirements, if applicable.f. Baselined Systems Engineering Management Plan (SEMP).g. Preliminary system requirements allocation to the next lowerlevel system. 20
    • Success Checklist Usage ExampleSDR Success Criteria Project Manager Reviewer Comments Comments/ Identification of Yes related technical / No products1. The detailed design is Yes We have Audio quality is a concern. PM says expected to meet the demonstrated a the pre-mod audio quality was poor. requirements with adequate prototype to the end No plans to assess. margins at an acceptable level customer (ES) who of risk. was pleased with the results.2. Interface control documents Yes Interfaces for the ULD Color coding of cable connectors isare appropriately matured to and Camcorder still TBD (not yet called out onproceed with fabrication, are well defined. drawings). System can be plugged inassembly, integration and test, backwards & performance ofand plans are in place to backwards system is an unknown. Nomanage any open items plans to investigate - just try to make it obvious what the right connectivity is.3. High confidence exists in the Yes Not clear from documentation that weproduct baseline, and adequate are building six units (4 to fly & 2documentation exists and/or for training).will exist in a timely manner toallow proceeding withfabrication, assembly,integration, and test. 21
    • Other Key EnablersStakeholder Support Customer Collaboration Project management process flexibilityOrganizational Maturity (Discipline to do whatneeds to be done)Focused Peer Reviews (Plan to DO it right, notto see IF you DID it right) 22
    • Focused Peer ReviewsJSC Avionics Systems Division Inspection Process Focused Checklist developed directly from Document Template or Standard Moderator & small team Review is 2 hours max (deliverables for larger projects may require more than one review) Typical prep time for each reviewer is no longer than the scheduled review duration. Reviewers must have at least 5 working days to review material. Author responsible for disposition of identified defects 23
    • Typical ASD Inspection Checklist 24
    • CASE StudiesTRAD (Tile Repair Ablator Dispenser) SDR 25
    • Other Case StudiesCompound Specific Analyzer – CombustionProducts (CSA-CP) SRRRegenerative Environmental Control and LifeSupport Fluid Hoses (REFH) PDR/CDRUltrasonic Leak Detector Impedance AdapterCable (ULDIAC) PDR/CDRORU Temporary Stowage Device (OTSD) CDRDigital EVA/IVA camera SAR 26
    • What next?Identify your SE process (NPR 7123.1?)Pre-Tailoring for Small Fast Paced Projects(visit this BEFORE the Project starts)‘Project specific’ tailoring (within predefinedconstraints) – Pirates CodeApplication of proven high Return-On-Investment techniques. 27
    • Questions?Contact InformationMichael HazenJacobs EngineeringJSC Engineering and Science Contract281-461-5797michael.hazen@escg.jacobs.com 28