Guidelines for Project Technical Managers

-- This document is for information only, based on past historical experience of project engineers --

• These guidelines are divided into sections by the types of responsibilities a Project Technical Manager has. This list is not all-inclusive. See What's New for the latest changes. Comments and suggestions for additions are always welcome!!

Contents

• Orientation
• Hardware
• Mechanical Design
• Electronics Design (link to ESB document)
• Analysis
• Fabrication
• Procurement (link to ESB document)
• Testing
• Documentation
• Office of Mission Assurance (safety, reliability and QA)
• Software
• Working with other centers
• JSC-specific advice
• KSC-specific advice
• Working with NASA HQ
• Logistics
• Flight operations
• Work Breakdown Structure / resources / schedules
• Proposal development
• Reviews
• Communication
• Project Close-out
• General/Philosophy
• Definition of a Project Technical Manager
• Summary of Responsibilities
• Division of Responsibilities within a Matrix Organization
• Appendix: All referenced files

Orientation for New Project Technical Managers

• In order to do the best job they are capable of, here are some things that may help a new Project Technical Manager get started:
• pre-training -- placing candidate Project Technical Managers in "co-op" or assistant Project Technical Manager positions.
• a mentor -- a more experienced person the new Project Technical Manager can ask questions of.
• a face-to-face introductory session before they start their duties, from a person who is familiar with the job.
• read and understand this handbook, and be familiar with commonly used references.
• PPMI System Engineering, Project Management, and Task Management training classes.
• See also LHB 7122.1 Systems Engineering Handbook.

Hardware

Mechanical Design

• Make sure there is adequate up-front contingency established to meet mass, power and environmental design requirements. Good PDR-level margins for resources were defined in LHB 7120.1.
• Make sure designers satisfy technical and performance requirements as well as LHB 7320.1 (i.e. MIL-STD 100); recommend discussion session to familiarize them with the LHB if necessary. See also additional design standards and references to use for stress corrosion cracking, outgassing, etc. Assure that designer is using appropriate materials, tolerances and coatings.
• During design phase, assure that designers are coordinating with counterparts in other functional areas (electronics, software, fab, testing, spacecraft, etc.). Coordinate design concepts with fab -- go to fab early to get their recommendations. Also include fab QA in discussions.
• Make sure the design takes into account the ground environment, not just the flight environment.
• Get OSEMA involved early -- this is the time to connect with them on reliability, fracture control, drawing configuration, log book use and safety design philosophy.
• Make sure the drawing checker is familiar with standard fab procedures and methods. Ask the checker to bring up any recurring concerns with designers' methods.
• Also check drawings globally; don't rely only on a checker who may not have the full information on everything that must be integrated together. Brief how-to for drawing checking. Sign each drawing.
• Complete layout drawing (reflecting conceptual design) before fabrication; complete final assembly drawing and assembly procedure before doing assembly. Don't leave your assembly drawings till the last minute! Don't allow assembly without a procedure and/or drawing. Sample assembly procedure (zipped Word 6 file). Red-lined procedures can be used for prototype hardware, not for flight.
• Designers can make use of previous lessons learned by using hardware/adhesives that have been used by engineers on previous programs.
• Identify all fastener hardware on assembly drawing; make sure it is ordered.
• Remember that GSE is part of the design.
• Make sure the requirements get defined -- push the project and PI to get these signed off early. After requirements definition, assure that changes and impacts are justified and understood. Get help on this from the Systems Engineering office.
• Make sure designer takes into account development and final testing requirements, as well as assembly and inspections.
• Consider inertia and momentum for moving parts, and in selecting motors and lubricants.
• The Project Technical Manager should understand the overall design.
• Seek guidance from Test and Development Branch technicians when it comes to assembly -- how, what process, what order, etc.

Electronics Design (link to ESB document)

Analysis

• Make sure margins and extreme cases are considered.
• Use these analysis references.
• Correlate the analysis models with test data -- make sure the model is valid.
• Include ground and test cases (e.g. gravity effects) as well as flight -- especially for optics where the alignment may be different.
• Get OSEMA to identify analyses that will be required to verify hazard controls.
• Common thermal analyses: hot/nominal/cold, transient
• Common structural analyses: modal, stress (especially fasteners), fatigue, fracture (for STS), deflection
• Always add margins to critical analysis predictions (e.g. might double critical deflection prediction).
• Support functional performance and control analyses as necessary. This will normally be done by electronics personnel instead of mechanical personnel.
• Use classical analyses as appropriate.
• Coordinate with designers to assure desired performance margins.

Fabrication

• Have a dedicated fab lead in the fab division who generates the travelers, helps allocate work among the different shops, etc. Take this person the drawings for a manufacturability review when they are at a preliminary stage so that recommendations can be made before the drawings are brought in for fab.
• Include this person in technical staff meetings as necessary so they are aware of priorities and upcoming events, and can make recommendations to the project.
• On large projects, have only one person responsible for the contact with the fab shop (on smaller projects, there may only be one designer). Define before going to fab whether the designer or Project Technical Manager will be submitting drawings and process sheets.
• Complete work order and process sheet (LaRC Forms 133, 136) for fab before submitting drawing (or have all info on drawing). Assure that person filling these out sits down with someone in fab, or any other fab-experienced person, and get a tutorial on how to fill out process sheets.
• Think about what the coating will do to the part -- changes in thickness, surface properties, electrical properties. Remember, anodizing leaves surface non-conductive electrically, iridite leaves it conductive. Check with electronics designers to determine conductivity requirements.
• Fab people can be very helpful -- listen to them and accept suggestions -- they can help make your design better.

Procurement (link to ESB document)

Testing

• Coordinate with test engineering early and often. Have a dedicated test manager/engineer assigned and define responsibilities.
• Get an overall test plan and test matrix developed early. Test plan should define the testing to be done, the test manager, and give some idea who will be conducting tests. Sample test plan (zipped Word 6 file).
• Make sure all tests have a procedure. Procedures can be red-lined for development testing -- not for flight. Make provisions for off-nominal results. Zipped test procedures as samples (Word 6 files):
• Sample test plan
• Sample thermal test procedure (zipped)
• Sample vibration test procedure (zipped)
• Sample acoustic test procedure (zipped)
• Get QA involved in developing the test procedure. If QA is aware of all facets of testing, they may be better able to help in follow-through. QA should ensure people follow the test procedures.
• Common tests: vibration (modal, random, quasi-static), thermal, thermal-vac, mass and c.g. (LaRC capability), EMI/EMC, pressure test.
• All Shuttle middeck payloads have to have the habitable compartment offgassing test done on them (MACE, GPPM and MIDAS had this done at White Sands) -- check with JSC Safety if unsure. It is possible to send a mock-up unit only, that only includes the same non-metallics as are in the flight payload, but does not have to be operational. Plan your outgassing test early, and determine if you can send a mock-up or whether you have to send a flight-like item.
• Fasteners must be tested at the OSEMA R&I lab -- see them to coordinate.
• Conduct a test review prior to any tests that could damage flight hardware.
• Comments on environmental testing of electronics from AESD point of view.

Documentation

• At the start of the project, get a block of drawing numbers from EDF. Divide them into blocks to be used by mechanical and electronics designers. Consider a separate block of numbers for GSE drawings.
• Define approval and revision process in configuration management plan (Sample CM plan (zipped)).
• Define who will hold drawing numbers, document numbers etc. for the project (depending on the size of the project, this may be the PM, Project Technical Manager, or configuration manager).
• Define drawing, procedure and file storage process for project.
• For flight hardware, file drawings with EDF when they are released for fab. File revisions with EDF as they are released. The objective is to maintain configuration control for flight hardware. For prototype hardware, the Project Technical Manager and PM can decide whether to file drawings with EDF, or maintain the log of drawings' status internal to the project.
• You are the mechanical lead focal point for all filing: memos, viewgraphs, pictures, drawings, etc.

Office of Mission Assurance (safety, reliability and QA)

• Have an assurance process in place. Sample PA plan (Netscape view or zipped Word 6 file).
• QA people are your friends -- don't do something yourself when it's their responsibility -- let them help you. They will be especially helpful in getting through STS procedures, hazard analyses, etc.
• Follow the OSEMA handbook LHB 5300.1 "Program Assurance Manual".
• Define the configuration management plan (Sample CM plan (zipped)).
• Have QA work with you to set up bonded stores, flight bonded stores, and control procedures.

Software

• Project Technical Manager needs to be aware of and communicate how hardware tradeoffs, ground testing requirements, etc. may impact the software design. Also should ensure that a proper balance of hardware and software is utilized to minimize cost and effort.
• Active thermal systems will require extensive interaction with electronics and software designers.
• OSEMA will support development of your Software Assurance Plan.
• Additional lessons learned from ESB.

Working with other centers

• During design and test procedure development, etc., make sure all applicable personnel (safety, spacecraft, QA, facilities, etc.) are involved at each center.
• Have an ICD in place defining the mechanical, thermal, electrical, and software interfaces between your system and the other center. Include roles and responsibilities if possible. Do this as soon as possible (but do not hold up engineering decisions).
• Don't assume that just because we do something what you feel is the "right" way here at LaRC, it will necessarily satisfy other centers. Make sure the way you do it will satisfy them -- remember, "When in Rome...."
• Pictorial flow of JSC/KSC safety data packages and reviews (John Greco has original)

JSC-specific advice

• For STS applications, safety and human factors will be extremely important in design and integration.
• JSC Directives

KSC-specific advice

• Some useful links to KSC information:
• Shuttle Operations
• For STS applications, the design should reflect a minimum of testing and "hands-on" activities at KSC.



Working with NASA HQ

• In general, let the PM handle discussions with HQ.
• Coordinate any necessary communication with HQ through the PM.
• Keep copies of anything you send them, as they may need it sent again.



Logistics

• Look at shipping logistics early -- route, environment, etc. Consider fragility, physical size, environmental control, security, etc. Air vans and barges can diminish travel vibration.
• QA has an environmental data recorder you can use to record the environment during storage, shipping, testing, etc.
• Wooden shipping containers that go into KSC clean rooms must be painted both inside and out.
• In general, consider taking everything you might need with you. Seemingly simple items can be hard to find in other places.



Flight operations

• Plan early for workforce usage -- be aware that flight ops may go continuously for a long period of time and you may need personnel backups. If it is 24-hour ops, have enough people for the rotations. Don't be one-deep in any area. Brief all personnel that might be used in ops, such as QA, so that they can perform the function when needed.
• Use flow charts to help define the sequence in flight ops and ensure nothing is left out.
• Practice or have simulations; train people on consoles.



Work Breakdown Structure / resources / schedules

• These are tools -- use them as such. Systems Engineering and Controls Branch can be of great assistance in preparing these (although PC-based software can also be used and maintained by the Project Technical Manager).
• Make sure a WBS is developed, and use it to help define the tasks to be done. The Project Technical Manager may use the WBS with more layers of detail than the PM. Sample WBS (html file or zipped Word 6 file).
• Guides to preparing a WBS.
• Use flow charts to help plan what needs to be done, when, and in what sequence (e.g. PERT network).
• Make sure all sub-systems' schedules are in line with project schedule and milestones.
• Plan for leave, holidays and availability of resources.
• Be aware that actuals reported have margins on them relating to leave and other apportioned costs -- don't expect them to line up with estimates exactly.



Proposal development

• Help develop WBS (sample: html view or zipped Word 6 file), time and resource estimates. In estimates, be conservative (i.e. add a factor to bottoms-up estimates, since some people tend to be optimistic on how long it will take them to do things). However, don't "reserve" us out of business -- the reserve should reflect the technical risk and confidence level, which will change with the phase of the project.
• Don't "buy in" to a low time or cost estimate coming down from above -- i.e. don't overly constrain the problem -- don't base the estimate on how much you're being given.



Reviews

• Refer to official LaRC procedures.
• Rehearse for formal reviews. Have consistent format of slides. Professional, polished presentations will do much to build panel's confidence, as well as being easier to follow.
• Hold internal peer reviews (table-tops) as necessary -- you can make these quick and dirty and they can be a fast way to solve problems.



Communication

• Management by walking around and talking to people -- you are the thread that holds the technical work together, and keeps people aware of the interfaces. People tend to each get in their own little hole and solve the problem they have -- make sure information flows between them. Offer assistance but don't meddle!
• One method of improving communication is sending out brief minutes (at least summarizing action items) from every meeting held, to make sure everyone on the project has the same information. If the project is not having regular meetings of the technical staff, the Project Technical Manager should arrange them. The meeting location is important -- depending on the phase of the project, the meeting might be held in a technical lab, testing lab, fab building, etc.)
• Document communication informally and/or formally as necessary.
• People tend not to communicate when things are changing -- they are waiting for things to settle out before informing others. This can be the most critical time for communication.
• Keep line management aware of the project, its needs, and upcoming changes.
• Keep the people working for you aware of changes on the project -- be their point of contact. Let them know clear due dates for their tasks, and how that ties into the project schedule. Keep them happy (which may include keeping the rest of the project off their back) and they will do better work.



Project Close-out

• Plan ahead for project documentation archival at the end of the project.
• Sort documentation and archive with Systems Engineering and Control Branch, PM, and Stores as appropriate. Items sent to LaRC Stores should be minimized, and a list kept of what was sent.
• Make sure all drawings are archived with EDF. Process sheets should be archived with project documentation and procedures.
• Electronic copies of drawings, models, documents can be archived on DMSS.
• Update hardware databases with lessons learned from hardware/materials used on project, or document the project's hardware separately.
• Hardware should be sorted and then stored, offered to other projects, placed in general bonded stores, surplused, or discarded, as appropriate.
• Document lessons learned on NASA Lessons Learned Information System



General/Philosophy

• Make and test engineering or prototype hardware if at all possible -- push the project for it -- it has been found to save time and money in the long run not to go straight to flight hardware.
• Seek and accept advice from people -- they are not trying to make you look bad, they are trying to help you improve. This applies to those you are working for as well as those working for you.
• A project is a team effort -- treat the team well. Make sure people get the credit they deserve (e.g. write commendation letters), and shield them from blame and harassment where appropriate. Even small rewards like T-shirts or a social gathering are appreciated. Don't forget while walking around to pass out verbal compliments.
• The Project Technical Manager will always have dual allegiance to line management and the project (more on this below). It is important to help project and line management establish a common perception of the project mission and priorities, so that conflicts will be minimized. Definition of responsibility on the Performance Appraisal (PA) can also help.
• Don't set up a situation where people will be surprised -- this almost always means a small concern has ballooned into something big -- use communication to keep this from occurring.
• Don't go to someone's supervisor before you talk to the individual concerned. If you go to someone's supervisor about a problem, have at least one possible solution in mind.
• Additional philosophy from AESD/ESB lessons learned.



Definition of a Project Technical Manager

SEC plays a critical role in the development of flight hardware at the Langley Research Center. Flight Systems performs a lead role in the technical management and coordination of such projects. In order to carry out these responsibilities, a Project Technical Manager or lead engineer is appointed to those projects of a significant size involving multiple organizations and disciplines.

The management structure on a project often has the following form:



Historically, large projects have had this type of an organization, where the TPE or Project Technical Manager is a mechanical lead who oversees all aspects of the mechanical development and testing, the IPE is an electronics lead who does the same for electronics and software, and a systems engineer ties them both together with the science requirements. However, on smaller projects, or projects which are either mostly mechanical or mostly electronic in nature, the Project Technical Manager, IPE, or PM may act as the systems engineer and oversee the entire development.

It is important to negotiate with the project manager when assuming the Project Technical Manager duties, to clearly define who will be responsible for what, and set up the chain of command. In particular, different project managers will often draw the dividing line differently between their responsibilities and the Project Technical Manager's. Define this division up front. The Project Technical Manager often wears two or three different hats -- reporting to the project, the systems engineer, line management, and overseeing the work being done. It is much easier to resolve the conflicts that will arise due to this split allegiance if there is clear communication about who is doing what. If the person is a full-time Project Technical Manager, they should have the PM and branch head agree on how to handle PA plan and evaluation.

In general, the Project Technical Manager is responsible for co-ordination of all mechanical functions including the engineering design and development, fabrication, qualification testing, quality assurance, and cost and schedule analysis and control. The Project Technical Manager has overall responsibility for integrating research requirements with mechanical functional responsibilities to develop and implement a plan that reflects schedule, cost, workforce, and performance requirements. The Project Technical Manager is responsible for negotiating and maintaining support levels from all other organizations for activities led by TPE.

The Project Technical Manager is the primary point of contact between mechanical activities and the project. All information on progress, problems, and status flow through the Project Technical Manager. Provides direct support to the project for all periodic and milestone status reviews.



Summary of Responsibilities

Responsible for and handles all mechanical technical aspects of a job, program, activity, contract, etc. Whether it is all technical aspects (instrument manager position), or only mechanical technical aspects (Project Technical Manager position) will depend on the size of the project, and negotiation between PM and Project Technical Manager. A good summary is in the SED Engineering Handbook EHB-1 "Systems Engineering Division Product Assurance Plan" (1/90).

Workforce-- For activities with mechanical development/fab, responsible for developing workforce requirements, negotiating support with other organizations, and monitoring workforce utilization. Coordinates all activities of SEC, obtains help as needed from other organizations. Contract with line management to commit personnel where possible.

Facilities -- Ensures necessary facilities and equipment are available to meet assembly and test requirements.

Requirements -- Establishes mechanical engineering requirements for system/subsystems and allocates resources (power, weight) to subsystem level. Ensures compatibility with mission requirements.

Development -- Responsible for in-house design, fabrication, assembly, inspection, test, certification, calibration, integration, check-out and operation of parts, equipment and facilities.

Initially assists PM in development of programmatic aspects: QA, configuration control, resources, schedules, etc.

Supports development and implementation of technical plans for in-house projects, ensuring resources and schedules are adequate.

Defines and directs trade studies. Leads continual trade-off of cost/schedule/performance.

Oversees in-house analytical efforts and evaluations (has the responsibility of seeing that contractor's analytical efforts are complete and adequate).

Responsible for generation/evaluation and approval of contractor or in-house test plans, verification matrices, specifications, designs, drawings, procedures, test data, reports, safety plans, inspections and program documentation.

Conducts in-plant inspections and witnesses fabrication, assembly, integration, check-out, testing, shipping and handling, and operations as necessary.

Works directly with OSEMA to ensure adherence to safety, reliability, and quality provisions.

Leads technical work-arounds and adjustments.

Reviews/Reporting -- Aids PM in preparing design reviews and subsystem reviews on contract or in-house (SRR, PDR, CDR, FRR, IRR, TRR, OSR, PFRR, etc.). Conducts periodic management reviews and presentations on technical status and accomplishments. Lead for informal table-tops.

On flight programs, participates in various safety reviews (Phase O through III).

Participates in Material Review Board (MRB) activities as necessary. Technically buys-off discrepancies, directs rework, etc.

Reports to line management, lets them know what's coming up.

Schedule -- Ensures that schedules are maintained and milestones are met.

Documentation -- Responsible for maintaining a project technical file.

On Contract --

Helps establish engineering requirements on contractual efforts beginning with preparation of procurement packages (RFP's, SOW's, justification memos, specifications, drawings, etc.). Aids in evaluating sources, bids, proposals (may inspect potential sources and contractors).

Responsible for evaluation, review, and approval of contractor specifications, designs, drawings, procedures, verification matrices, test plans, reports, safety plans, inspections and program documentation, and ensuring resources, schedules, and technical objectives are consistent. Depending on the task, may act as the TRCO or technical monitor on contract activities.



Division of Responsibilities within a Matrix Organization

Line Manager	Project Technical Manager
Scope tasks and ensure quality of work	Establish and coordinate project technical approach for design and development
Resolve workforce problems	Establish and control system/subsystem/interface requirements
Mutually establish resource requirements (personnel, funds)	Allocate system resources (mass, power, thermal, data, etc.)
Maintain personnel and schedule commitments	Aid in establishing and tracking schedule and resource needs, and developing work-arounds
Staffing	Support project reporting and reviews
Delivering a product to the project that meets performance requirements	Mutually establish resource requirements (personnel, funds)
	Negotiate with line supervisors for required resources
	Report status and pending problems to line management
	Oversee/coordinate fabrication, testing and field operations



Appendix: All referenced files

• Zip file containing all sample files (assembly and test procedures, test plan, PA plan, CM plan, WBS).
• Sample thermal test procedure (zipped Word file)
• Sample vibration test procedure (zipped Word file)
• Sample acoustic test procedure (zipped Word file)
• Sample assembly procedure (zipped Word 6 file).
• Sample test plan (zipped Word 6 file).
• Sample CM plan (zipped Word 6 file).
• Sample PA plan (html view or zipped Word 6 file).
• Sample WBS (html view or zipped Word 6 file).



If you are reading a local or hard copy of this document, the Web page is maintained at http://meweb.larc.nasa.gov/meweb/refs/tpe_hdbk.html.

---


This page last modified on 4/16/05.
Suite of pages last modified on 4/16/05.

---

Site last reviewed: July 22, 2008.
Responsible NASA Official: Ruth M. Amundsen, Structural and Thermal Systems Branch, Systems Engineering Directorate, Ruth.M.Amundsen@nasa.gov, (757) 864-7044
Site Curator: Ruth M. Amundsen, Structural and Thermal Systems Branch, Systems Engineering Directorate, Ruth.M.Amundsen@nasa.gov, (757) 864-7044
Privacy Statement
Feedback on Langley Products and Services