ATST Risk Management Plan · ATST Risk Management Plan SPEC-0037, Rev D Page 1 of 20 1....

Project Documentation SPEC-0037 Revision D

Advanced Technology Solar Telescope 950 N. Cherry Avenue Tucson, AZ 85719 Phone 520-318-8102 [email protected] http://atst.nso.edu Fax 520-318-8500

ATST Risk Management Plan J. McMullin, S. Craig, H. Bass

21 January 2013

Name Signature Date

Released By : Joseph McMullin

Project Manager J. McMullin 06-Mar-2014

ATST Risk Management Plan

SPEC-0037, Rev D Page ii

REVISION SUMMARY:

1. Date: 13 June 2006 Revision: A Changes: Initial Release

2. Date: 30 April 2009 Revision: B Changes: Updated for FDR

3. Date: 17 September 2012 Revision: C Changes: Update to project risk management methods; pre-NSF baseline review.

4. Date: 31 January 2013

Revision: D Changes: Update to Risk Register development and handling.


SPEC-0037, Rev D Page iii

Table of Contents

1. Introduction ................................................................................................................... 1 1.1 Project History of Risk Management ................................................................................................ 2

2. Project Summary ............................................................................................................ 7 2.1 Project Management Approach .......................................................................................................... 7 2.2 Project Acquisition Strategy ............................................................................................................. 10

3. Definitions .................................................................................................................... 13

4. Risk Management Strategy and Approach ..................................................................... 14 4.1 ATST Project Risk Register ............................................................................................................... 14 4.2 JIRA Issues Register ............................................................................................................................. 15

5. Organization ................................................................................................................. 18

6. Risk Handling ................................................................................................................ 18

7. Risk Monitoring ............................................................................................................ 19

8. Risk Management Information System, Documentation and Reports ............................ 20


SPEC-0037, Rev D Page 1 of 20

1. INTRODUCTION

The objective of risk management is to affect the results of uncertainties in future events, with the goal of

maximizing outcomes favorable to execution of a project. In this case, the project is the design and

construction of the Advanced Technology Solar Telescope (ATST) which will be the world’s leading

resource for studying solar magnetism that controls the solar wind, flares, coronal mass ejections and

variability in the Sun’s output. Design and construction of this four-meter off-axis solar telescope is a

complex undertaking, one that benefits from the application of risk management. The risk management

plan outlined herein is intended to help the project by;

Providing methods to identify risks,

Providing criterion to evaluate risks in terms of probability and consequence,

Outlining the process of risk handling or mitigating potential adverse events,

Providing a methodology for risk monitoring in terms of review and reporting, and

Providing a format for documenting the process and results of risk management.

Risk management is a proactive management approach to meeting project objectives and keeping risk at

an acceptable level. There are three types of risk associated with a project such as ATST: 1) Technical

Risk consisting of the risk of not meeting performance requirements; 2) Programmatic Risk which

consists of the risk of project failure due to cost or schedule overruns; and 3) Risk of Harm, in other

words Personnel Safety. All three of these risk types can interact and must be carefully managed. The

first step in managing these risks is careful project definition, followed by risk identification, assessment,

risk handling or mitigation activities and risk monitoring with assessment of the success of mitigation

actions.

Figure 1 provides a top-level process flow view of our risk management processes which is based on the

PMI model.



1.1 PROJECT HISTORY OF RISK MANAGEMENT

Project definition is the critical first step in risk management, and was performed early in the D&D phase

of the project. The highest priority was given to the development of science requirements, which were

then documented in the Science Requirements Document (SRD). Refinement of the science requirements

and their flow down into design requirements occurred next. By developing stable requirements, the

project team ensures that design requirements, fabrication statements of work, and test and acceptance

plans can be directly traced back to science requirements.

After project definition, risk identification was initiated. Methods used to identify and mitigate risks early

included:

Identify key performance and cost drivers

Identify the critical path through the system-level schedule through construction completion

Use existing proven designs, concepts and lessons from other systems

Figure 1: Project risk management process flow diagram



Strive for good fit at major subsystem level for industry

Use experienced experts for independent review of design progress

Inputs to risk identification included the WBS, project budget, schedule, and information collected from

other large telescope projects by way of interviews of key personnel and attendance at relevant project

workshops and reviews.

After risk identification, came assessment, proactive response planning, action, risk monitoring and

control. Several critical tasks designed to identify and reduce technical and programmatic risks to the

project were successfully completed. Early in the D&D phase, the team identified major performance and

cost drivers, developed a system-level schedule through construction, and used critical- path and critical-

chain analysis to prioritize the early studies, demonstrations, and trades required. Highlights taken from

the ATST construction proposal include:

Adaptive Optics: Identified prior to the D&D phase, AO on solar telescopes is a relatively new

technology that is required for successful implementation of the ATST. A major design goal was to

develop AO technology that is easily scalable to the higher depth of field (needed for the ATST).

Under separate award in collaboration with the New Jersey Institute of Technology, the Air Force

Research Laboratory and Kiepenheuer-Institut für Sonnenphysik, the system developed for the Dunn

Solar Telescope at Sacramento Peak is capable of providing diffraction-limited observations during

median seeing conditions (r0 at 500 nm = 9 cm) and has already produced excellent results at visible

wavelengths. This success achieved by our AO team, which has years of experience in developing,

commissioning and operating solar adaptive optics systems, results in confidence that the ATST AO

system can be constructed and successfully commissioned.

Telescope Mount: An example of a very early trade was in the area of mount configuration. Our

early choice of the Alt/Az makes use of the latest typical large telescope designs, thus providing a

very low-risk approach. We also gained the ability to spend more of our efforts on areas that were not

as clear for a large solar telescope such as the choice of an off-axis design and ventilated enclosure.

Off-axis Design: Early in the ATST concept development, analysis and discussion at community

design workshops resulted in another early choice in favor of an off-axis optical layout that is capable

of superior performance. Primary-mirror cost and manufacturability concerns led to five successful

industry studies to develop approaches for manufacturing, testing, and quantifying the cost and

schedule. With the cost and schedule bounded and folded into the project schedule with adequate

contingency, risk areas such as heat-stop thermal performance concerns were reduced. This was due

to the fact that the off-axis design allows much more flexibility to implement the cooling

infrastructure given the better access to prime focus when compared to an on-axis case.

Enclosure Concept: Given the early trades of mount and optics configuration, we were able to

concentrate on enclosure design, judged as the most critical conceptual trade study. After extensive

study and design efforts, two competing solutions emerged. One, a hybrid, co-rotating, vented

enclosure and the other an open telescope with a retractable enclosure. Both concepts were

developed in parallel in enough detail to allow performance modeling. The enclosure trade study

balanced the two highest priority risk areas: 1) telescope performance and protection, and 2) cost and

technical risk. As a result of analysis of the trade study data, and in light of the advice offered by the

various reviews and workshops, the ATST project adopted the hybrid, co-rotating enclosure as the

best able to meet the science requirements with minimum cost and risk.



The use of proven design concepts as used on other projects is a solid method to reduce risk on new

projects. Given we are building a solar telescope, not everything can be copied from recent nighttime

telescope examples, but major areas of need are similar.

Early involvement of qualified vendors who have extensive experience in large telescopes continues to

help focus our efforts, provide realistic solutions early. Table 1.1 gives examples of concepts taken from

existing systems that are proven to work well.

Table 1.1. Design concepts adopted from other successful projects

Subsystem Project

Hydrostatic Mount Bearings Keck and Gemini

Drive System Design Gemini, SOAR, VISTA

Mount Base Design Gemini

Coudé Rotator Dunn Solar Telescope

Cable Wraps Gemini, VISTA

Mirror Cover Gemini

Solar Adaptive Optics Dunn Solar Telescope

M1 Assembly SOAR

M2 Assembly SOAR

Software Communications

Model SOLIS and ALMA

Software Device Model SOLIS

Software Observing Tool ESO

Telescope Pointing Kernel Gemini, SOAR

Feed Optics National Synchrotron Light Source (Brookhaven National

Laboratory)

Initially, during the transition from Design and Development to early construction, a Project ‘Watch List’

was developed which noted high areas of risk and an assessment of the likely draw on contingency that

would result from the realization of that risk. This was included in the monthly reports to the NSF.

However, it did not provide an encompassing view of all of the high level risks (i.e., it was incomplete), it

lacked adequate justification for the costs (i.e., there was no BOE) and it lacked any strategy for

mitigation. As a result, in early 2012, the project migrated to using a Risk Register methodology (Figure

2).



Figure 2: Project Contingency Watch List (from October 2011).



Figure 3: Project Risk Register Development Sheets to illustrate fields, categories, and process.

The risk register assigns a responsible person, summarizes actions to mitigate, and logs significant

changes or results of mitigation efforts. It is the subject of internal review at least every quarter and a part

of all external management and progress reviews. It is maintained by the Project Manager with feedback

from engineering leads for adherence with technical and safety requirements.



2. PROJECT SUMMARY

2.1 PROJECT MANAGEMENT APPROACH

It is understood that, in large telescope projects, late delivery and/or cost overrun by a vendor can

seriously impact the project cost and schedule. This is most clearly understood by consideration of the

schedule for delivery of the large primary mirror blank and its subsequent polishing which forms the basis

for the many telescope projects’ critical paths. To mitigate this type of risk, a strong and rigorous

approach to vendor selection, contracting and contract monitoring has been developed. This approach is

the result of input from seasoned professionals with extensive experience with large telescope project

contract management. We not only reserve financial contingency that may be used to solve scheduling

problems, but we also manage and protect schedule contingency wherever possible. There may be cases

where we consider changes in functional scope to protect the highest priority scientific goals. Changes

here can only occur with review by the Project Scientist with input from the ATST Science Working

Group and the approval of the Director.

Our project management approach will rely on clearly defined work packages, which include detailed

specifications and interface requirements, with aggressive but achievable schedules and agreed-upon

deliverables. Participating organizations will be held accountable for their contracted work packages and

the project will have the authority to curtail or terminate participation of groups that do not produce

results.

Another risk associated with funding is the development of an unforeseen construction problem or

overrun that requires additional funding. Trades on use of contingency and performance trades will occur

to resolve any issue. If an issue cannot be resolved in this manner, requests for guidance or additional

funds from the funding agencies will be used as a last resort. The funding agencies will be kept apprised

and will be invited to participate in any activities that may lead to this result.

Critical-path analysis is used to identify schedule risks as plans are developed and work progress and

schedules are tracked. The critical path is defined as the longest path in the schedule network. The path is

critical because the associated tasks determine the total completion time of the project. Moreover, at least

one of the associated task’s duration times must decrease in order to decrease the total completion time.

Conversely, if a critical task’s duration time increases the total completion time increases by the same

amount.

Along with the critical path, we also monitor multiple tracks in the schedule to identify associated paths

that risk pushing their way onto the critical path if task duration times on those paths increase. This is

sometimes referred to as critical chain analysis. Examples of associated paths that we are already

monitoring through critical-chain analysis include the M1 fabrication, delivery and integration, as well as

the science instruments fabrication and delivery tracks. The slack ranges from a few to twelve months for

these examples. Other items have either larger slack or the time estimated to perform is more certain.

Employing critical-path and critical-chain analysis allows us in-depth understanding of the interactions

between the various tracks in the schedule. This understanding of the critical and near-critical items

allows us to manage schedule issues as they arise.

Schedule contingency and consistent tracking are critical to advanced warning of problem areas. Earned

Value Analysis gives an estimate or indication of budget and schedule problems. A detailed

understanding of the interaction of the various critical and near-critical items is required to actively

manage schedule issues as they arise. Making decisions early protects project slack. Follow through by

beginning each item early is also required to manage schedule issues effectively.

The project team is following a design-to-life-cycle cost philosophy. As designs are developed, value-

engineering principles are employed to ensure that costs are driven only by the science requirements, not



by mere goals. The cost of each subsystem is estimated, and where areas of high cost are identified,

targeted technology development may be initiated to mitigate the cost risk.

Accurate cost estimates for both the construction and operations phases of the facility are essential, and

ATST regularly refines these estimates as the design work progresses. These estimates have been

compared with recent large telescope projects as well as design analysis and estimates performed by

independent vendors. This comparison allows for continuous monitoring and verification of the overall

project costs. These costs include item-by-item estimates of uncertainty to determine an appropriate level

of financial contingency.

As the project progresses, realistic cost goals will be allocated not only to groups but also to specific

individuals, and a system of accountability, reporting and review will be established. Just as tradeoffs

between subsystems are required in the error budget, so too will there be a need for frequent tradeoffs in

the cost of subsystems. Design studies will indicate which cost targets are hardest to achieve, within a

fixed overall cost budget.

A strong systems engineering team has been formed. One of the most critical functions of systems

engineering during the construction phase is configuration control. The ATST configuration control

approach is based on careful definition of project requirements, identification and definition of interfaces

and control of interfaces using ICDs. The philosophy of our systems and WBS breakdown is to strive for

a good fit of subsystem requirements and scope to industry or partner capability that result in a testable

unit. Following this path lowers the relative risk of performance, budget, and schedule surprises that

would otherwise have to be addressed at a later date. To the extent documentation needs to evolve during

the project, it shall be done in accordance with ATST Change Control Plan, SPEC-0040.

During construction, interface control between various vendors and the project team will be handled

through the development of detailed specification documents that will form the basis for the fabrication

contracts. Acceptance test plans will be developed to ensure that interface requirements have been met.

This approach will also apply to instruments. The interfaces between the various telescope systems and

instruments will be carefully documented and controlled.

Contingency is a key feature of risk management. It gives the program flexibility to solve unforeseen

issues impacting the budget, schedule and performance.

Contingency has been estimated using the procedures outlined in the ATST Cost Estimating Plan SPEC-

0039. Wherever possible, contingency is compared to the experience gained by others who have built

similar large telescope facilities (e.g., Gemini, SOAR, Magellan, and WIYN). Contingency funds are

carefully tracked as the project progresses and are only used after a high-level review of the need (c.f. the

Contingency Log, reported on monthly). The Project Manager controls the contingency funds. No part

of the internal project is allowed to “own contingency.” Upon any contract or sub-award, we will review

the parties’ schedule, performance and financial margins to assess the level of risk with each effort. The

project will maintain contingency centrally outside of any built-in contract contingency as appropriate.

Contingency funds are used as a safety valve in case of genuine unforeseen circumstances, are an

appropriate means to deal with project uncertainties and risks, and are a key to risk mitigation.

It is also important to develop schedule or time contingency. We have assumed the earliest possible dates

for most non-critical path items to conserve as much schedule contingency as possible at this point. In

addition, the schedule is predicated upon a 5-day work week, while our labor efforts can move to 6-day

work weeks as needed; this represents additional schedule contingency.

The project team is following a design-to-life-cycle cost philosophy. As designs are developed, we will

refine costs for the construction and operations phases of the facility. These estimates are compared with

recent large telescope projects as well as design analysis and estimates performed by independent

vendors. This comparison allows for continuous monitoring and verification of the overall project costs.



These costs include item-by-item estimates of uncertainty to determine an appropriate level of financial

contingency

The ATST team will consult with partners and vendors when considering environmental, safety and

health issues. As the scope of construction work is defined and prioritized, and resources are considered,

the hazards associated with the work are identified, analyzed, and categorized. This is done in

coordination with relevant partners and vendors. Applicable standards, requirements and controls to

prevent or mitigate the hazards are being identified and the plans and controls will be implemented.

Opportunities for improving the definition and planning of the work and controls are identified and

implemented.

The heavy construction work at the site will need emphasis that is outside the normal level of safety

concern at an established observatory. AURA has experience from recent projects, such as the Gemini

Observatory, to use in developing our detailed construction safety plan, ATST Safety Plan SPEC-0031.

The safety plan includes features such as a dedicated construction safety officer, specialized training for

staff, flow down of project and government standards to contractors, safety meeting and reporting

requirements, and independent mechanisms to report and correct any issues at the highest level. In

addition, based on the annual safety review recommendations, the Project has participated in other large

project safety processes (NREL) and is incorporating their lessons-learned into the construction plan.



2.2 PROJECT ACQUISITION STRATEGY

The ATST project team has created detailed specification documents that will become the basis for

contracts for the final design and fabrication of most items. Documentation for long-lead items has been

prepared first, including the primary mirror blank, primary mirror polishing, telescope mount, enclosure,

and site buildings and infrastructure. Contracts are in place for each of these items.

Instruments will be purchased by contract or sub-award. All the instruments will be developed from

detailed designs produced by collaboration of partner organizations with the project during the design and

development phase. The NSO will be responsible for instrument infrastructure, active and adaptive optics,

and a common camera/detector program. The detailed but modular interaction of the detector systems

and common control systems is being defined through work the development of the instrument design

phase. This allows for standardization of common design elements and minimized duplication of effort in

electronics and software development.

Contract administration will be performed in-house and includes a contracts administrator with sufficient

support staff to administer and monitor all aspects of contracts and procurements. Personnel familiar with

government contracting procedures, federal acquisition regulations (FAR), and NSF contracting policies

will administer all contracts. All procurements will comply with applicable Federal regulations.

The contract type employed will depend on the nature of the specific task. However, most contracts will

be firm fixed price. Contracting clauses will be negotiated with the awardees to provide AURA with

sufficient protections to ensure contract completion on schedule and within budget. Contract form will

correspond to the nature of the contract, the provider/vendor, and the method of funding (contract, sub-

award, sub-grant, etc.). In all cases, any required flow-down provisions from applicable regulations will

be included.

All purchases over $5K are made using competitive procurement unless there is an adequate justification

for using a sole source. This approach maximizes competition, which helps to minimize costs. The PI

and co-PIs may make exceptions to competition for some partner sub-awards and contributions. Likely

sub-awards include two instrument work packages described below. All will have appropriate

management requirements for tracking progress that includes measurable milestones, payment and

reporting needs. Detailed procedures currently in place for AURA procurements will be used or adapted

to any unique project needs. Any unique procedures will be documented prior to the beginning of the

construction phase.

For a standard item purchase, existing procedures for obtaining quotations will be followed. For non-

standard high-cost or risk items, the project contracts office will prepare a formal solicitation plan, which

includes a Request for Proposal (RFP), establishing a source selection board, and a set of formal

evaluation criteria to be used in grading each proposal. The RFP package will consist of a document that

requests vendors to submit technical proposals to perform the work; management and cost proposals; a

proposal form; a sample contract form for the work, which includes a detailed statement of work; and the

requirements document for the work. The procurement will be publicized through the Federal Business

Opportunities website, the ATST website, and through partner agencies as appropriate. Notices will be

sent to vendors known to the project and partners. The RFP will be sent to all vendors who request it.

Vendors will not be selected based on price considerations alone. A small selection committee will

evaluate each vendor's proposal, assigning scores to criteria such as proposed design, management,

experience, facilities and staffing. Vendors will be selected by balancing their technical scores and prices

in order to ensure that the project obtains the best value, considering both price and capability.

Whenever possible, contracts will be on a fixed-price basis so that the project will be able to effectively

manage its budget. In instances where the extent of the work cannot be reliably determined in advance, it



may be necessary to use other approaches, such as paying hourly rates or distributing the work in ways

that reduce risk.

The award of custom design and fabrication work will be based on an evaluation of bid price, ability to

meet specifications, ability to meet schedule, experience, resources, personnel and other similar factors.

The Project Manager must review and approve all sole-source procurements. The required final approval

level is based upon delegated financial authority to the responsible technical manager, Project Manager,

NSO Director, AURA and the NSF, as agreed to upon ATST construction project start. Currently, these

approval levels are $250K for the Project Manager and $1000K for the Director with any higher amount

requiring AURA and NSF approval.

Once a contract is in place it must be monitored, to ensure that the work is completed successfully and on

time. The contracts will identify information that will be supplied to the project office so that ATST will

have early warning of problems relating to schedules, costs and performance. A project staff member will

act as the technical representative for each contract and will be solely responsible for monitoring the

vendor's performance. This person will communicate with the contractor frequently to make sure the

work is on track, provide needed technical information, coordinate work being done by different

contractors when necessary, and evaluate whether progress milestones are being met on schedule. In

special cases, where particular activities are critical, the project technical representative may reside for

some period at the contractor's facility. The objective is to resolve problems before they impact schedule

and to provide the Project Manager with insight into contractor progress.

Contracts will be structured with objectively verifiable progress milestones so that it is possible to detect

early on if a vendor is getting into trouble. Contract payment provisions will be tied to these milestones

that represent completion of concrete, quantifiable performance objectives. Milestones payment

provisions based on elapsed time alone will be avoided to the extent possible for fixed-price contracts.

The responsible manager and contract administrator must approve any modifications to a contract as

consistent with established financial authority levels. Modifications must also be evaluated, negotiated,

and formally changed by a contracting officer. Technical changes must be reviewed and approved by the

responsible systems engineer and change control board to enforce configuration management.

The instrumentation program is a critically important component of the ATST facility. Therefore, it is

placed at the same priority as the telescope design, development and construction and the management of

those phases. The ATST instruments approach in size and complexity instruments for 8 to 10-m

nighttime facilities, such as Gemini, Keck and VLT. We have reviewed extensively the “lessons learned”

from those nighttime instrumentation programs and are using that experience along with our own to form

our ATST instrumentation program. Important examples of these lessons include the following:

Strong, central instrumentation management.

Close and frequent communication within the partner and project teams.

Contracts with detailed specifications and measurable milestones with financial ties.

Progress reports including detailed cost, schedule and scope tracking information.

Solid configuration and change control.

A team attitude focused on both the project’s and instrumentation partner’s success.

A detailed plan is under development with the partners to ensure a strong, centrally managed, and

coherent instrumentation program through the end of design, development, and construction, that will

continue during operations. This coherency is important because building instruments will continue

through the life cycle of the ATST facility.

The project will continue to manage the instrumentation program centrally throughout construction. The

partner organizations, through the Director’s Co-PI and advisory group meetings are directly involved

with the project team in the establishment of instrumentation design, development, construction, and

instrument commissioning priorities. This allows the partners to participate in the final approval of



instrumentation sub-awards. No award will be granted until adequate management and project plans are

in place, including agreed upon detailed tracking requirements, as outlined below, and successful review

of the instrument preliminary design. Provisions for cancellation of work not meeting expectations will

be included in all awards. ATST will have a manager for the instrumentation program and an

instrumentation scientist who will work together to ensure adequate progress or to recommend action for

changes to the project manager.

Instrumentation work packages conducted directly by the project include the instrument facility and

associated infrastructure, outfitting of labs and support facilities, acquisition and guiding, active and

adaptive optics, and the camera detector program for all instruments, as well as high-level software and

controls including the command and data communication infrastructure and data handling systems. In

addition, the Visible Broad-band Imager (VBI) will be developed within the NSO as part of the ATST

construction. Sub-awards for three external instruments have already been established:

High Altitude Observatory: ViSP (Visible Spectro-Polarimeter)

Institute for Astronomy: Cryo-NIRSP (Cryogenic – Near InfraRed Spectro-Polarimeter)

Institute for Astronomy: DL-NIRSP (Diffraction Limited - Near InfraRed Spectro-Polarimeter)

In addition, a fifth instrument will be developed through an international contribution from the

Kipenheuer-Institut fur Sonnenphysik (KIS):

Kipenheuer-Institut fur Sonnenphysik: VTF (Visible Tunable Filter instrument)

Each instrument effort has measurable milestones with financial ties. The contract administrator will

circulate an approval memo for any changes that includes distribution to the partner representative,

technical representative, responsible manager, systems engineering team and the Project Scientist or his

designee at a minimum. Modifications also must be evaluated, negotiated, and formally changed by a

contracting officer. Technical changes also must be reviewed and approved by systems engineering and

the change control board to enforce configuration management.

Monthly progress reports will be required and will contain information adequate to evaluate the technical,

schedule, and financial status of the instrumentation work package. At a minimum, these progress reports

should contain:

A written narrative, in a standard format determined by the technical representative, which

provides the following:

o Technical status of the work overall, and in each engineering discipline, including

progress accomplished since the last progress report.

o Problems encountered and the solutions the contractor is pursuing.

o Any changes in key personnel.

Revised WBS;

The following earned value metrics: Planned Value (PV) which is the budgeted cost of the

scheduled work, Earned Value (EV) which is the budgeted cost of the performed work, Actual

Cost (AC);

A table of financial data, in a standard format determined by the technical representative,

including, for direct labor dollars, capital dollars, and total dollars, the following categories:

planned value for the report month, actual value for the report month, actual minus planned value

for the report month, cumulative to date planned value, cumulative to date actual value, and

cumulative to date actual minus planned value. An estimated cost at completion (if not fixed

price), total dollar value of invoices, and payments received to date will also be included;

Action Items (open and closed) for ATST and the contractor, which will include a summary of

actions closed during the reporting period and new actions opened; and



MS Project schedule in electronic form to show progress with percent complete for each task and

the overall project percent complete through the end of the report month.

The instruments have been developed from detailed designs produced by the collaboration of partner

organizations with the project during the design and development phase. Detailed specification

documents have been created from these designs. The detailed specification documents form the basis of

contracts for the final design and fabrication of the instruments. Once an instrument contract is in place, it

is monitored closely. Each instrument contract will have a project staff member who will act as the

technical representative and who is solely responsible for monitoring the vendor's or partner’s

performance. This person will communicate with the contractor frequently to make sure the work is on

track, provide needed technical information, coordinate work being done by different contractors when

necessary, and evaluate whether progress milestones are being met on schedule.

3. DEFINITIONS

Risk is a measure of the potential inability to achieve overall project objectives within defined cost,

schedule and technical constraints. It has two components: the probability of failing to achieve a

particular outcome and the consequence or impact of failing to achieve that outcome. The relationship

between the two components of risk is typically complex necessitating the separate assessment of the two.

Risk events are things that could go wrong with a project. The events should be defined to a level where

and individual can comprehend the potential impact and its causes.

Risk management is the act or practice of dealing with risk. It includes planning for risk, assessing risk

areas, developing risk handling options, monitoring risks to determine how they are evolving over the life

of the project and documenting the overall risk management program.

Risk management planning is the process of developing and documenting an organized, comprehensive

and interactive strategy and methods for identifying and tracking risk areas, developing risk handling

plans performing continuous risk assessments to determine how risk has changed and assigning resources

to affect outcomes.

Risk identification is the process of examining the project areas and each critical technical process to

identify and document the associated risk

Risk quantification is the process of examining each identified risk area or process to refine the

description of the risk, isolating the cause and determining the effects. It includes risk rating,

quantification and prioritization in which risks are defined in terms of their probability of occurrence,

severity of consequence and relationship to other risk areas or processes.

Risk handling is the process that identifies, evaluates selects and implements options in order to set risk at

acceptable levels given project constraints and objectives. This includes the specifics on what should be

done, when it should be accomplished, who is responsible and the associated cost and schedule. The most

appropriate strategy is selected from these options.

Risk monitoring & control is the process that systematically tracks and evaluates the performance of risk

handling strategies throughout the project life cycle and develops further risk handling options as

appropriate. It feeds information back to the other risk management activities of planning, assessment and

handling.

Risk documentation is recording, maintaining and reporting assessments, handling analysis and plans and

monitoring results. It includes all plans and reports for the program officer (NSF PO), NSF and Awardee

decision authorities.

Contingency is the amount added to an estimate to allow for items, conditions or events for which the

state, occurrence and or effect is uncertain and that experience shows will likely result in additional costs.



4. RISK MANAGEMENT STRATEGY AND APPROACH

The project employs two interrelated tools that form the basis of our risk management process. The

Project Risk Register and a JIRA Issues Register system. Both are reviewed weekly and updated as part

of the team review of project technical issues, risks, budget and scope.

4.1 ATST PROJECT RISK REGISTER

The Risk Register records details of the risks identified throughout the life of the project. The risks are

categorized by the likelihood of occurring and the seriousness of impact on the project. The details of

plans for mitigating each high-level risk and the subsequent results of the actions taken are documented.

The Risk Register is maintained throughout the project and will change regularly as existing risks are re-

graded, as the effectiveness of mitigation strategies is assessed, and as new risks are identified. In order to

be effective, the risk register is kept brief and to the point so it quickly conveys the essential information

(as appropriate, separate documentation detailing mitigation strategies and costing may be referenced for

major risks). The Risk Register is reviewed and updated regularly. Risks that are addressed and no longer

deemed to be of concern are marked “retired”, but remain within the active Risk Register spreadsheet, for

reference, review and completeness.

The risk register exists to accomplish the following risk management goals:

provide a tool for managing and reducing the risks identified before and during the project;

document risk mitigation strategies being pursued in response to the identified risks and their

grading in terms of likelihood and seriousness;

provide project management with a document from which status can be reported to oversight

bodies;

ensure the communication of risk management issues to key stakeholders;

provide a mechanism for seeking and acting on feedback to encourage the involvement of the key

stakeholders; and

identify the mitigation actions required for implementation of the risk management plan and

associated costs.

Many team members involved in the project have responsibility for project risk management. However,

the project manager is responsible for monitoring and managing all aspects of the risk management

process. This process includes the following:

development of the risk management plan and risk register;

continual monitoring of the project to identify any new or changing risks;

continual monitoring of the effectiveness of the risk management strategies; and

regular reports to project management oversight bodies.

During the construction phase the project manager may choose to assign risk management activities to a

separate risk manager, but the project manager retains the overall responsibility.

The Risk Register includes the following information:

a unique risk identifier;

a description of the risk and how it might affect the project (this includes identifying the type of

risk, e.g., safety, cost, schedule, performance);

the review status indicates when the last review or update for that risk occurred.

The trigger date or date at which the project expects to encounter (pay off) or avoid that risk; note

all mitigations also have a trigger date.

A probability for the risk.



The cost for the risk broken into:

o Non-labor (materials)

o Schedule (labor)

The expected exposure cost (Probability * Sum of the non-labor and schedule costs)

Owner

An example of the Project Risk Register entry sheets is shown below.

4.2 JIRA ISSUES REGISTER

JIRA is a COTS system for tracking issues (investigations, tasks, actions, defects, etc) developed by

Atlassian. It is widely used in astronomical construction projects (e.g., ALMA, EVLA, etc). The system

enables recording of issues identified throughout the design and construction process and provides a tool

for driving these issues to resolution.

The Issues Register is developed and maintained by the Project Manager to provide an efficient tool for

managing, communicating and addressing the issues identified during the project and allows the team to

develop and document actions taken to address the identified issues and their subsequent resolution. This

register is maintained throughout the project and updated regularly, as existing issues are closed as a

result of successful actions and new issues added as they are identified.

The Issues Register exists to accomplish the following risk management goals:

provide a tool for tracking identified issues during the project;

provide project management with a document from which status can be reported to oversight;

ensure the communication of issues to key stakeholders; and

provide a mechanism for seeking and acting on feedback to encourage the involvement of the key

stakeholders.

The Issues Register includes:

a unique issue identifier number;

a description of the issue;

who raised the issue;

date reported;

required date for resolution

the person or group who is responsible for resolution;

status, usually open, in progress, resolved or closed;

date resolved; and

how the issue has been resolved (e.g. included as action in the project work plan and budget,

documented in the Risk Register, or closed).

The Risk Register and JIRA Issues Register when combined with the project’s budget, schedule, WBS

and ICDs form a comprehensive risk management toolbox and are employed as essential tools and guides

in our risk management process. They allow the project team to easily record and track risk management

issues, quickly assess the technical status of the designs in the context of risk assessment and proactively

manage risk related issues.

A regular weekly review led by System Engineering provides the forum which allows the project team to

identify, assess and track risks, risk mitigation effectiveness and form the associated risk mitigation plans

and actions. The detailed technical readiness of the various assemblies and subsystems is considered and

updated as they evolve throughout the project, all in the context of the overall budget and schedule.

These risk management tools allow the project to quickly assess and compare the technical status of the

overall system, specific assembly or subassembly with any associated risk or issue that has been identified

or raised.



The project office will prepare reports as the method of documenting risk management plans, actions and

effectiveness. The project manager, from project team input, will prepare a monthly report. This report

will cover the monthly activities of the project team and will relate them to schedules and milestones for

the construction phase. A quarterly report will be sent to the NSF program officer. The others will be

made available on the ATST web site with protection of any proprietary information and will be made

available to the NSF program officer upon request.

Figure 1 Screen shot of personalized JIRA dashboard showing assigned, reported and watched issues as well

as current activity and overall status.



Figure 2 TBEG JIRA Issues Register Project Summary Dashboard.

Figure 3 TBEG JIRA Issues Register Issues Summary.



Figure 4 JIRA Issues Register navigation workflow.

5. ORGANIZATION

Project team members will be actively involved in identifying and evaluating risk as well as crafting

mitigation strategies for project risk management. However, the project manager is ultimately

responsible for monitoring and managing all aspects of the risk management process. A core risk

management team, led by the project manager, has the responsibility for executing the risk management

process. It will consist of a safety officer, systems engineer and project manager. Health and safety risk

estimations will be the responsibility of a designated safety officer. Technical risk estimations will be the

responsibility of the systems engineer. Programmatic risk estimation will be the responsibility of the

Project Manager.

6. RISK HANDLING

Risk handling is the identification of the course of action or inaction selected for the purpose of

effectively managing a given risk. Risk handling strategies are selected after the determination of

probability and seriousness so that the handling strategy balances risk with other factors such as cost and

schedule. Responses to risks generally fall into one of four categories; mitigate, accept, avoid or transfer.

The selected strategy is documented in the applicable risk assessment form. Cost and schedule impacts

related to the scope of the related risk handling strategies are there by included in the project baseline cost

and schedule independent of any cost contingency or schedule contingency



Mitigate: Mitigation strategies identify specific steps or actions which will increase the probability

that the activity will succeed either by reducing the probability of occurrence or by reducing or

mitigating the consequences of the event. Using this strategy, the risk remains but at a reduced level

labeled residual risk. Residual risks are used to quantitatively model risk and develop contingency

estimates. If mitigation action is selected, the cost and schedule for implementation is estimated on

the appropriate risk assessment form and is included in the project baseline cost and schedule

estimate.

Accept: Accepting a risk is essentially a “no action” strategy. Selection of this strategy is based upon

the decision that it is more cost effective to continue with the project as planned with no resources

specifically dedicated to addressing the risk. Contingency plans are typically developed in case of

non-negligible risks for a course of action to take in case the risk event occurs.

Avoid: Avoidance focuses on totally eliminating the specific risk by eliminating the potential that the

risk can occur. This can be accomplished through system or component redesign, shift of

implementation strategy, etc. which does not include the particular risk. If this strategy is selected,

cost and schedule implications are documented on the appropriate risk assessment form.

Transfer: This strategy is used when a risk is identified that can be transferred to another project of

entity, especially when this same risk may be more easily and cost effectively handled within the

receiving entity. Two examples of risk transfer are insurance in the form warranties or performance

bonds and firm fixed price procurement methods. For these examples, residual risk may still be

present in terms of either cost or schedule if these methods of risk management are selected.

The cost and schedule impacts of residual risks are then estimated in terms of a best case, average case

and worst case scenarios. Using these probability distributions, individual risks are combined statistically

to produce a contingency estimate.

7. RISK MONITORING

A primary criterion for successful management is formally monitoring and documenting the on-going risk

management process as it:

Provides the basis for program assessments and updates as the project progresses,

Provides the framework for a more comprehensive assessment,

Provides a basis for assessment of risk handling success,

Provides project background for new personnel, and it

Provides a history of rationale for project decisions.

The Risk Register and JIRA issue tracking when combined with the project’s budget, schedule, WBS and

ICDs form a comprehensive risk management toolbox and are employed as essential tools and guides in

our risk management process. They allow the project team to easily record and track risk management

issues, quickly assess the technical status of the designs in the context of risk assessment and proactively

manage risk related issues.

A regular monthly review during construction will provide the forum which allows the project team to

identify, assess and track risks, risk mitigation effectiveness and form the associated risk mitigation plans

and actions. The detailed technical readiness of the various assemblies and subsystems is considered and

updated as they evolve, and issues raised are recorded and reviewed, all in the context of the overall

budget and schedule. This process extends throughout construction including the integration test and

commissioning phase.



8. RISK MANAGEMENT INFORMATION SYSTEM, DOCUMENTATION AND REPORTS

The project office will prepare reports as the method of documenting risk management plans, actions and

effectiveness. The project manager, from project team input, will prepare a monthly report. This report

will cover the monthly activities of the project team and will relate them to schedules, milestones and risk

management activities. A quarterly report will be sent to the NSF program officer. The others will be

made available on the ATST web site with protection of any proprietary information and will be made

available to the NSF program officer upon request.

ATST Risk Management Plan · ATST Risk Management Plan SPEC-0037, Rev D Page 1 of 20 1....

Documents

Transcript of ATST Risk Management Plan · ATST Risk Management Plan SPEC-0037, Rev D Page 1 of 20 1....